Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Charles Plessy]

Hi Andreas,

I agree that we can remove EMBOSS in all 32-bit platforms.  I think that
a large fraction of the scientific field has no appetite to do any extra
volunteer work to such as accepting our patches to support scientific
computations on 32-bit systems in 15 years...

Have a nice day,

Charles

Bug#1041556: [R-pkg-team] Bug#1041556: What is the architecture name in R what we call armel/armhf

[Charles Plessy]

Le Thu, Aug 17, 2023 at 07:52:35AM +0200, Andreas Tille a écrit :
> 
>   arch <- R.version$arch
>   identical(arch, "i386") || identical(arch, "i686") || identical(arch, 
> "armel") || identical(arch, "armhf")

Hi Andreas, how about:

system("dpkg-architecture -qDEB_BUILD_ARCH", intern=TRUE) %in% c("i386", 
"i686", "armel", "armhf")

Have a nice day,

-- 
Charles

Bug#1042776: [R-pkg-team] Bug#1042776: Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

[Charles Plessy]

Le Tue, Aug 01, 2023 at 09:29:59AM +0900, Charles Plessy a écrit :
> 
> the DESeq Bioconductor package was removed from the 3.17 release
> upstream.  I think that we can remove it from unstable and testing too.
> 
> I will fill a removal later today.

Actually it was removed from BioC 3.10 and the fix is easy, so I just
uploaded a fixed version.

I will still fill a removal unless somebody objects.  The replacement
package, r-bioc-deseq2, is well established and I am not aware of
people or pipelines using the old version.

I note that the med-bio-dev metapackage will need to be updated
accordingly.  I can to so after my joini request is accepted.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home, https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1042776: marked as pending in r-bioc-deseq

[Charles Plessy]

Control: tag -1 pending

Hello,

Bug #1042776 in r-bioc-deseq reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/r-pkg-team/r-bioc-deseq/-/commit/bad370412269ea6b7543b3f76d238f1765e3affd


r-bioc-deseq (1.39.0-12) unstable; urgency=medium

  * Team upload.
  * Update patch to rebuild for BioC API 3.17 (Closes: #1042776)

 -- Charles Plessy   Tue, 01 Aug 2023 11:41:09 +0900


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1042776

Bug#1042776: [R-pkg-team] Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

[Charles Plessy]

Le Mon, Jul 31, 2023 at 09:46:48PM +0200, Andreas Beckmann a écrit :
> 
>   The following packages have unmet dependencies:
>r-bioc-deseq : Depends: r-api-bioc-3.16 but it is not installable

Dear Andreas,

thanks for the catch,

the DESeq Bioconductor package was removed from the 3.17 release
upstream.  I think that we can remove it from unstable and testing too.

I will fill a removal later today.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1022307: [Debian-med-packaging] Bug#1022307: status on t_coffee causing biopython ftbfs

[Charles Plessy]

Le Tue, Nov 22, 2022 at 11:54:48PM +0100, Étienne Mollier a écrit :
> 
> Hi, mostly retitling the open entry against biopython for the
> sake of clarity, and also pinging both bugs to reset auto-
> removal counters.  We don't have much news from t_coffee
> upstream to day unfortunately.  Maybe it will be necessary to
> revert the t-coffee version bump for the upcoming Debian release
> or do people see other options?

Hi Étienne,

I think that we do not have enough evidence that t_coffee was properly
tested on other architectures than amd64.  Even though a particular
version may build fine, and let biophython pass its tests, we do not
know if t_coffee produces sound results on these architectures.  Unless
we know or hear from an ARM user, I would recommend to play safe and
only distribute it on amd64 for this release.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1023230: [Debian-med-packaging] Bug#1023230: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: test times out after 2:47 hours

[Charles Plessy]

Le Mon, Oct 31, 2022 at 09:27:47PM +0100, Paul Gevers a écrit :
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/libb/libbio-tools-run-alignment-tcoffee-perl/27686780/log.gz
> 
> autopkgtest [11:59:24]: ERROR: timed out on command "su -s /bin/bash debci

Hi all,

I think that t-coffee never worked on ARM.  It built, but never worked.
The simplest would be to distribute it only on amd64.

See https://bugs.debian.org/631249

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#946850: [Debian-med-packaging] Bug#946850: last-align ftbfs on non-x86 architectures

[Charles Plessy]

Le Wed, Dec 18, 2019 at 09:35:44AM +0100, Michael Crusoe a écrit :
> 
> dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow last-align

Hi Michael,

I ran the commmand a bit more than one hour ago.

My Debian skills are a bit rusty; I am not sure if I should receive an
automatic email feedback; at the moment I have not.

Have a nice day !

--- 
Charles

Bug#946850: LAST build fails on non-amd64 platforms.

[Charles Plessy]

[CCed to Debians' bug tracking system]

Hi Martin,

LAST fails to build on non-amd64 platforms, where it does not find
the immintrin.h header file.

We can either try to fix that (most likely relying on you to do it), or
restrict the builds to the amd64 platform (missing opportunities to find
portability bugs such as this one).

What would you prefer ?

Have a nice day,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#890117: Bug #890117 in bedtools marked as pending

[Charles Plessy]

Control: tag -1 pending

Hello,

Bug #890117 in bedtools reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/bedtools/commit/c0e8d812e70e59a4268e69fcdd2c77d0c7bf5aae


bedtools (2.27.1+dfsg-4) unstable; urgency=medium

  * Disable the shuffle test on other 32-bit architectures.
  * Restrict build to little-endian release architectures. Closes: #890117
  * QA-build with Salsa.

 -- Charles Plessy   Thu, 14 Feb 2019 22:11:21 +0900


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/890117

Bug#890117: Bug #890117 in bedtools marked as pending

[Charles Plessy]

Control: tag -1 pending

Hello,

Bug #890117 in bedtools reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/bedtools/commit/25d45b7a051249d4c482fb5095a9bf45ac4825c2


Restrict build to little-endian release architectures.

Closes: #890117


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/890117

Bug#890117: bedtools FTBFS on big endian: Tools failing: bamtobed bamtofastq coverage genomecov groupby intersect jaccard map merge multicov negativecontrol

[Charles Plessy]

Le Wed, Dec 19, 2018 at 08:45:10AM +0100, Andreas Tille a écrit :
> Control: tags -1 help
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/arq5x/bedtools2/issues/676

Hi Andreas and everybody,

I bisected the build failure on the sparc64 porterbox kyoto.d.o, and
somewhat unsurprisingly, it pinpointed the following commmit, between
version 2.26.0 and 2.27.0:

commit 93c11d1f01d6692bac05b3335850ef50947493ca
Cause make test to exit with non-zero status in the event of a test failure.

I looked at the sparc64 logs for version 2.26.0 (wich did not fail to
build from source) and indeed, I see test failures that did not cause
a makefile errors, and that are not visible from the i386 build log.

I have not checked other platforms but my conclusion is that big-endian
versions have been buggy for some time wihtout any user noticing it.
Actually, I am not sure we have evidence that bedtools ever worked
properly on big-endian machines.

Altogether, this calls for removing bedtools from big endian architectures 
on Debian at the moment, until Upstream or somebody else steps up to do
the porting work.

I will fill a request for removal.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Bug#879886: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Charles Plessy]

Hi Diane and everybody,

Le Tue, Nov 07, 2017 at 05:09:34PM -0800, Diane Trout a écrit :
> 
> I do think we should bring back the symbols file

I think so too.

Symbols file are strange to work with because their update usually goes
through a build failure that outputs a patch, which is not very
intuitive.  And then the patched symbols file has to be edited to remove
the Debian minor version, otherwise it complicates backports etc.
Perhaps it can be simplified, better explained and streamlined.  In any
case, I think that for the htslib it is worth the effort.

> I was wondering if we should split the cram headers into a
> libhts-private-dev so we can at least track what is depending on the
> non-public api.

An ideal solution, and I understand that it may not be easy, would be to
make the upstream users of htslib talk with the htslib developers, so
that they can implement what they want to without needing to access
private functions.  I think that it would fit the aims of both sides.

> I did realize that my thought about updating the SOVERSION might be
> wrong because I was just looking in the source tree for the removed
> functions but I should have been checking the public header files.

Indeed, packages using private functions need to have a tight dependency
on the htslib (unless we are very confident that there are regression
tests that cover this area of the code).  Packages that are more
well-behaved can infer their dependency through the (to be re-added)
symbols file.

Have a nice day,

Charles

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

Bug#861333: r-base: R packages uploaded to Debian before 14 April 2017 that use .C or .Fortran fail to find objects

[Charles Plessy]

Le Sat, Apr 29, 2017 at 09:50:01AM -0500, Dirk Eddelbuettel a écrit :
> 
> I think I will cover these by hand now:
> 
>package dotFortran  dotC recommended
>  1:   class-7.3-14  FALSE  TRUETRUE
>  2:  cluster-2.0.6   TRUE  TRUETRUE
>  3: foreign-0.8.68  FALSE  TRUETRUE
>  4: KernSmooth-2.23-15   TRUE FALSETRUE
>  5:MASS-7.3-47  FALSE  TRUETRUE
>  6:  Matrix-1.2-10  FALSE  TRUETRUE
>  7:mgcv-1.8-17  FALSE  TRUETRUE
>  8:   nlme-3.1.131   TRUE  TRUETRUE
>  9:nnet-7.3-12  FALSE  TRUETRUE
> 10: spatial-7.3-11  FALSE  TRUETRUE
> 11:survival-2.41-3  FALSE  TRUETRUE
> 
> and we should binNMU the remaining ones satisfying
> 
>   binary: any   (ie applicable for Debian binNMUs)
>   has either .C() or .Fortran()
> 
> I have access to a fully expanded directory of CRAN sources of if we start we
> the reverse depends I can refine the script above to get a set of packages
> for which we can then set up binNMUs.
> 
> One caveat: the shell script does not (yet?) filter out those packages that
> already had a post R 3.3.3 update which includes eg several from the set 
> above.

Hi Dirk,

this is very neat to pinpoint which package needs to be rebuilt.  Related to
this I had one more reminder from a member of the Release team that r-base
should not be co-installable with the packages that it breaks.  This is related
to the support of partial upgrades that I was mentioning earlier.

At this point I see 3 options:

 - For each rebuild, insert a "Breaks" relationship in r-base's control file;

 - Increment r-api-3 to r-api-4 (or r-api-3.4, etc.) in order to not have to
   maintain a long list of "Breaks" declarations.  In that case, we have to
   rebuild everything.

 - Just rebuild what has to be rebuilt, and do not support partial upgrades,
   which is what has been done until now.

Not supporting partial upgrades puts the maintainers of the r-cran and r-bioc
packages between the hammer and the anvil.  This said, I think that we have
made constant progresses over the years, so I do not feel shy saying "not yet"
to the Release team again if needed.

Have a nice day,

Charles

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

Bug#859255: binNMU needed for more R packages.

[Charles Plessy]

Package: release.debian.org
Severity: grave
X-Debbugs-CC: debian-...@lists.debian.org, debian-scie...@lists.debian.org

Hello again,

as a follow-up to #858183, I looked at which other R Bioconductor
packages were broken by R 3.3.3-1, and it seems that the previous round
of binNMUs did not repair some of them.

Can you make the followig binNMUs ?

nmu r-bioc-rsamtools_1.26.1-2 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-shortread_1.32.0-1 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-variantannotation_1.20.2-1 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-genomicalignments_1.10.0-1 . ANY . -m "Rebuild for R 3.3.3." 

Note to debian-science: there are also R CRAN packages that fail with R
3.3.3, (r-cran-lubridate, r-cran-spam), but I am not yet sure if a
binNMU is enough.

Have a nice day,

Charles

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

Bug#858183: binNMU needed for r-bioc- packages broken by R 3.3.3.

[Charles Plessy]

Package: release.debian.org
Severity: grave

Hello everybody,

the update of R to version 3.3.3 unexpectedly breaks some R packages, which
need to be reinstalled from source.  In Debian terms, given how we package R
packages, this can be solved by a binNMU.

A quick look at ci.debian.net shows that a large number of Bioconductor
packages (r-bioc-*) started to fail their tests at the end of February
following the upload of r-base version 3.3.2.20170227-1, which was a release
candidate of 3.3.3.  Some of the failures are direct, and some may be a ripple
effect.

On Bioconductor's support forum 
(https://support.bioconductor.org/p/93695/#93719),
it was suggested to reinstall the packages "BiocGenerics", "S4Vectors",
"IRanges", and "GenomicRanges".  I tried this on my computer (using sbuild 
--make-binNMU)
and their regression tests restarted to pass.  These packages are very central 
in
Bioconductor's dependency graph.

If time remains, how about starting with these four and see if the failures in 
the 
the other packages dissapear ?

nmu r-bioc-biocgenerics_0.20.0-1 . all . -m "Rebuild for R 3.3.3."
nmu r-bioc-s4vectors_0.12.1-2 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-iranges_2.8.1-1-m . ANY . "Rebuild for R 3.3.3."
nmu r-bioc-genomicranges_1.26.2-1 . ANY -m "Rebuild for R 3.3.3."

Otherwise I can prepare a more extensive list of packages to rebuild.

Cheers,

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

Bug#857466: marked as done (r-base: CVE-2016-8714: R: Buffer overflow in the LoadEncoding functionality)

[Charles Plessy]

Hi Dirk and Salvatore,

> From: Dirk Eddelbuettel 
> On 11 March 2017 at 17:56, Salvatore Bonaccorso wrote:
> | 
> | The relevant changes seem to be the following, but I might be mistaken. 
> (btw,
> | is there a VCS repository for r-base or does upstream not share development
> | VCS?)
> 
> They do at svn.r-project.org  -- but that isn't browsable -- and the
> community has a mirror here https://github.com/wch/r-source

Actually there is anonymous access:

$ svn log https://svn.r-project.org/R/trunk/ | head

r72357 | luke | 2017-03-16 04:32:54 +0900 (jeu. 16 mars 2017) | 4 lignes

Use two uniforms in sample() for higher precision when the uniform
generator is one of the Knuth generators or a user-defined generator
and the population size is at least 2^25.


r72356 | luke | 2017-03-16 03:58:45 +0900 (jeu. 16 mars 2017) | 2 lignes

But the GitHub mirror is likely to be more convenient 

> | Can you as well please make sure with the release team that the fix might 
> enter
> | for stretch?
> 
> How would I do that?  Suggest current upstream 3.3.3 to be passed down, or
> prepare a 'testing-security' upload?

Actually, I see 3.3.3 in testing already.

On my side, I plan to fix the security issue in jessie-backports by
updating it to 3.3.3 as well.

Have a nice day,

-- 
Charles

Bug#845505: sra-sdk 2.7.0-1 is broken libncbi-vdb2 2.8.0+dfsg-1

[Charles Plessy]

Package: sra-sdk
Severity: grave

Hi all,

quick note from work; sorry to not being able to go deeper.

A colleague has reported to me that sra-sdk 2.7.0-1 is broken
libncbi-vdb2 2.8.0+dfsg-1.  For instance:

fastq-dump
fastq-dump: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libncbi-vdb.so.2: undefined symbol:
mbedtls_ctr_drbg_seed

Downgrading libncbi-vdb2 to 2.7.0+dfsg-4~bpo8+1.

There are no build logs for sra-sdk on amd64, but I guess that sra-sdk
2.7.0-1 could have been built against 2.7.0+dfsg-4 by mistake (given
that they have been uploaded on the same day, I assume that they were
intended to be used together).  Note that now, with source-only uploads,
it is easier to get build logs.

If we are lucky, maybe a binNMU will be enough ?  On the other hand,
maybe the only way to prevent problems for the users upgrading form
Testing would be to tighten the dependency.

Have a nice day,

-- 
Charles

Bug#831833: [Debian-med-packaging] Bug#831833: Tagged as fixed-upstream - do you intend to upload?

[Charles Plessy]

> On Wed, Nov 02, 2016 at 09:03:45PM +0900, Charles Plessy wrote:
> > 
> > I was hoping that Upstream would make a new release with the fix :(
> > 
> > So one would need to check if the following commit would be enough as a 
> > patch...
> > 
> > https://github.com/arq5x/bedtools2/commit/be2633d4951328264611e4cabc65e12fa8fef1cd

Hi again,

it turns out that the patch representing the commit be2633d fixing the issue
can not be applied alone; the package fails to build.

Then, I tried to look for other commits to apply in order to make the patched
package buildable, and I realised that first, there has been only 16 commits in
total since the last upstream release, and second, some of these commits do fix
other bugs, less severe, but real bugs.  None of them introduce novel
unreleased features.

So I am tempted to propose to distribute the current contents of Upstream's
master branch in Squeeze.  Technically, I can:

 - Just drop a big monolithic patch in debian/patches, or
 - drop the patches produced by `git format-patch v2.26.0, or
 - make a new tarball, version 2.26.0-19-g6bf23c4 (`git describe --tags`).

What do other people think about this ?

Have a nice day,

Charles

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

Bug#831833: Tagged as fixed-upstream - do you intend to upload?

[Charles Plessy]

Le Wed, Nov 02, 2016 at 12:52:58PM +0100, Andreas Tille a écrit :
> 
> you have set #831833 as fixed-upstream at 20 Jul 2016.  Do you intend to
> upload the fix to the Debian archive?

Hi Andreas,

I was hoping that Upstream would make a new release with the fix :(

So one would need to check if the following commit would be enough as a patch...

https://github.com/arq5x/bedtools2/commit/be2633d4951328264611e4cabc65e12fa8fef1cd

I am not sure if I can do it in the short term...  Everybody is welcome to be
faster than me :)

Cheers,

-- 
Charles

Bug#838748: Bug#695327: Patch pending for cloud-init bugs 838748, 780637 and 695327

[Charles Plessy]

Le Sat, Sep 24, 2016 at 03:34:52PM +0200, Nicolas Braud-Santoni a écrit :
> Control: tag -1 pending
> X-Debbugs-CC: hol...@debian.org
> 
> Hi,
> 
> I prepared an upload for a new version of cloud-init which fixes
> (among other things) this bug.  It is currently available in the
> v0.7.8/master branch on alioth.
> 
> Should I NMU this?

Hi Nicolas,

may thanks for your help,

cloud-init is in collab-maint, so you can also add yourself to Uploaders or
mark your upload "team upload" instead of NMUing.

Have a nice week-end,

-- 
Charles

Bug#831833: Processed: Re: [Debian-med-packaging] bedtools is marked for autoremoval from testing

[Charles Plessy]

Control: tag -1 +sid

Le Wed, Jul 27, 2016 at 05:03:05AM +, Debian Bug Tracking System a écrit :
> Processing control commands:
> 
> > notfound -1 2.25.0-1
> Bug #831833 [src:bedtools] bedtools groupby broken; will break users 
> pipelines.
> Ignoring request to alter found versions of bug #831833 to the same values 
> previously set

Hmmm... sorry for the noise.

Bug#831833: [Debian-med-packaging] bedtools is marked for autoremoval from testing

[Charles Plessy]

Control: notfound -1 2.25.0-1

Le Wed, Jul 27, 2016 at 04:39:03AM +, Debian testing autoremoval watch a 
écrit :
> bedtools 2.25.0-1 is marked for autoremoval from testing on 2016-09-02
> 
> It is affected by these RC bugs:
> 831833: bedtools: bedtools groupby broken; will break users pipelines.

This bug only affects the new upstream release.

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

Bug#831833: [Debian-med-packaging] Bug#831833: Command `groupby` broken; will break users pipelines.

[Charles Plessy]

Control: retitle -1 bedtools groupby broken; will break users pipelines.
Control: forwarded -1 https://github.com/arq5x/bedtools2/issues/418
Control: tag -1 +confirmed

Marking as forwarded now that commented in the issue.

The command is completely broken, but unfortunately the regression tests for
this command are not run by `make test`.  (probably by accident)

This reminds me that `make test` fails on Debian because of issues with seeded
random numbers.  It would be a great help if somebody would have time to solve
that problem (which may be hard).

Cheers,

-- 
Charles

Bug#831833: Command `groupby` broken; will break users pipelines.

[Charles Plessy]

Source: bedtools
Version: 2.26.0-1
Severity: serious
Tags: upstream

Hi all,

at work I was just bitten by upstream issue 418, reporting that `bedtools
groupby` is broken.

https://github.com/arq5x/bedtools2/issues/418

I am filing this bug to prevent migration to Squeeze.

Have a nice day,

-- 
Charles

Bug#823673: samtools: FTBFS in testing

[Charles Plessy]

Version: 1.3.1-2

Le Sat, May 07, 2016 at 03:03:45PM +0200, Santiago Vila a écrit :
> 
> This package currently fails to build from source in stretch.
> 
> 
> === Testing mpileup.reg regressions ===
> 
> UNEXPECTED FAIL: Output mismatch for $samtools mpileup -x -d 8500 -B -f 
> mpileup.ref.fa deep.sam|awk '{print $4}'
> See FAIL-47.out.1 vs expected/47.out
> 
> 
> The full build log is attached.
> 
> I see that this package required a change recently for htslib 1.3.1.
> However, if this only builds now with libhts >= 1.3.1, then the
> Build-Depends field should be updated accordingly.

Thanks for the report; the issue was already reported in #822701, which I just
fixed by updating Build-Depends.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#822701: [Debian-med-packaging] Bug#822701: samtools: FTBFS: UNEXPECTED PASS: Task worked when we expected failure;

[Charles Plessy]

Control: tag -1 +pending

Le Wed, Apr 27, 2016 at 10:12:31AM +0900, Charles Plessy a écrit :
> 
> Perhaps we also need htslib 1.3.1 to "Break" samtools < 1.3.1... I cloned
> this bug to address that issue.

Hi all,

I added: "Breaks: samtools (<< 1.3.1)".  I think that it would be better to
update the package before backporting it to Jessie.  Are there other opinions,
or other changes to make to the package ?

Cheers,

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

Bug#822701: [Debian-med-packaging] Bug#822701: samtools: FTBFS: UNEXPECTED PASS: Task worked when we expected failure;

[Charles Plessy]

clone 822701 -2
reassign -2 htslib
retitle -2 htslib 1.3.1 breaks samtools 1.3, at least at build time.
retitle 822701 samtools 1.3 fails to build against htslib 1.3.1.
tag 822701 +pending

Le Tue, Apr 26, 2016 at 07:02:28PM +0100, Chris Lamb a écrit :
> Source: samtools
> Version: 1.3-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi Chris,

this was a race condition where you built samtools 1.3-1 against htslib
1.3.1-1.  Now, with samtools 1.3.1-1 which entered the archive yesterday, the
reproducibility build should work (as it did on the buildds).

I have tightened the build-dependancy to libhts-dev >= 1.3.1, just in case:
since we see that samtools 1.3 does not work with htslib 1.3.1, I worry
that the converse will be true as well.

Perhaps we also need htslib 1.3.1 to "Break" samtools < 1.3.1... I cloned
this bug to address that issue.

Have a nice day,

-- 
Charles

Bug#796114: Phasing out libnetty-java (was Re: Bug#796114: CVE-2015-2156)

[Charles Plessy]

Le Wed, Aug 19, 2015 at 04:59:58PM +0200, Moritz Muehlenhoff a écrit :
 Source: netty
 Severity: grave
 Tags: security
 
 This was assigned CVE-2015-2156:
 http://netty.io/news/2015/05/08/3-9-8-Final-and-3.html
 
 Fix:
 https://github.com/slandelle/netty/commit/800555417e77029dcf8a31d7de44f27b5a8f79b8.patch
 
 In addition to src:netty (3.2.6), there's also src:netty-3.9 (3.9.0)
 and there was also src:netty3.1 at some point (now removed).
 
 Please phase out src:netty towards the updated src:netty-3.9 so that
 there's only one version around.

Hello everybody,

in my understanding, libnetty-java is a relic of when we attempted to package
Eucalyptus in Debian.  However, there are two new packages, zookeeper and
bookkeeper, created recently, that depend on libnetty-java instead of the more
recent libnetty-3.9-java.

Is that because of incompatibility ?  If libnetty-java is still needed, would
it be possible to transfer it under the umbrella of the Debian Java team ?

Have a nice day,

Charles

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

Bug#796114: Phasing out libnetty-java (was Re: Bug#796114: CVE-2015-2156)

[Charles Plessy]

Le Thu, Aug 20, 2015 at 05:27:34PM +0200, Emmanuel Bourg a écrit :
 Le 20/08/2015 13:40, Charles Plessy a écrit :
 
  Is that because of incompatibility ?  If libnetty-java is still needed, 
  would
  it be possible to transfer it under the umbrella of the Debian Java team ?
 
 Hi Charles,
 
 I did the transfer to libnetty-3.9-java and I'm working on packaging
 netty 4.x. I'll reuse the libnetty-java package and move it under the
 Java Team umbrella.

Thanks a lot !

-- 
Charles

Bug#795847: [Debian-med-packaging] Bug#795847: jellyfish: FTBFS: error: 'struct std::__cxx11::basic_stringbuf_CharT, _Traits, _Alloc::__xfer_bufptrs' redeclared with different access

[Charles Plessy]

Le Mon, Aug 17, 2015 at 12:46:40PM +0100, Chris Lamb a écrit :
 Source: jellyfish
 Version: 2.2.3-1
 Severity: serious
 Justification: fails to build from source
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs
 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
 
 jellyfish fails to build from source on unstable/amd64:

Hi all,

I could make the package buildable by patching it with an upstream commit
(develop branch).  But I could not test the resulting binary since I do not
have a Sid system upgrated to the latest libstdc++6, so I have not uploaded.

Have a nice day,

-- 
Charles

Bug#792442: [pkg-eucalyptus-maintainers] Bug#792442: jsilver: Should this package be removed?

[Charles Plessy]

Le Tue, Jul 14, 2015 at 09:44:47PM +0200, Moritz Muehlenhoff a écrit :
 
 There's just a single upload, which was apparently made
 for Eucalyptus which is no longer in the archive. Upstream
 seems dead with last code activity in 2010. There's also
 no reverse deps.
 
 Should we remove it?

Thanks Moritz for the heads up.  I agree to remove it: I do not see manpower
anymore here, and on my side, I would not be able to provide assistance in case
a serious bug would be found.

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


signature.asc
Description: Digital signature

Bug#762647: [Debian-med-packaging] Bug#762647: samtools: FTBFS: test suite errors

[Charles Plessy]

Le Thu, Jun 18, 2015 at 11:25:46PM -0400, Aaron M. Ucko a écrit :
 
 I'm glad to see those platforms are doing better now, but that was only
 part of the problem.  There are still unexpected failures on i386 and
 kfreebsd-i386 (though the count's dropped from 95 to 2, a big improvement):
 
   UNEXPECTED FAIL: Output mismatch for $samtools mpileup -x -F 0.60 -u -f 
 mpileup.ref.fa indels.bam|$filter|awk '/INDEL/'
   
   See FAIL-59.out.1 vs expected/59.out
   UNEXPECTED FAIL: Output mismatch for $samtools mpileup -x -F 0.60 -u -f 
 mpileup.ref.fa indels.cram|$filter|awk '/INDEL/'
   
   See FAIL-59.out.2 vs expected/59.out
 
 Could you please look into them as well?

Hi Aaron,

failures on 32-bits platforms are expected to be fixed in the next upstream 
release.

https://github.com/samtools/samtools/issues/305

I propose to wait for it.  But if need is, it may be possible to backport the 
patches.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780637: cloud-init: needs to be build in the cloud

[Charles Plessy]

Le Tue, Mar 17, 2015 at 10:15:38AM +0100, Holger Levsen a écrit :
 
 building the cloud-init package fails during package tests because the 
 hostname metadata.google.internal cannot be resolved and cloud specific URLs 
 like http://169.254.169.254/openstack/latest cannot be accessed, see attached 
 log.

Hi Holger,

it is more complicated than this: the package builds fine with sbuild.

To what extent do we need to support pbuilder ?  Please adjust the severity
according to your answer if necessary.

Have a nice day

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769219: function moved

[Charles Plessy]

Le Sun, Nov 16, 2014 at 12:36:05AM +0100, Bill Allombert a écrit :
 
 Do you know if there is a org to XML (or SGML) conversion option ?

Hi Bill,

according to its documentation, Pandoc can do convert Org-Mode to DocBoox

Have a nice Sunday,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763218: [Debian-med-packaging] Bug#763218: python-pysam: FTBFS: Tests failures

[Charles Plessy]

Control: tag -1 - jessie

Le Sun, Sep 28, 2014 at 07:15:05PM +0200, David Suárez a écrit :
 Source: python-pysam
 Version: 0.7.7-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140926 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
  ==
  FAIL: testBAM (__main__.TestUnmappedReads)
  --
  Traceback (most recent call last):
File ./pysam_test_offline.py, line 998, in testBAM
  self.assertEqual( len(list(samfile.fetch( until_eof = True))), 2 )
  AssertionError: 0 != 2
  
  --
  Ran 158 tests in 9.110s
  
  FAILED (failures=2, errors=31)
  E: pybuild pybuild:256: test: plugin custom failed with: exit code=1: cd 
  tests  PYTHONPATH=/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build python2.7 
  ./pysam_test_offline.py
  dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned 
  exit code 13
  make[1]: *** [override_dh_auto_test] Error 13
  debian/rules:29: recipe for target 'override_dh_auto_test' failed
 
 The full build log is available from:

 http://aws-logs.debian.net/ftbfs-logs/2014/09/26/python-pysam_0.7.7-1_unstable.log

Thanks David.

The build logs show that the tests fail because the version of samtools is not
0.1.19.  Here is an example:

==
ERROR: testBam2fq (__main__.BinaryTest)
--
Traceback (most recent call last):
  File ./pysam_test_offline.py, line 303, in setUp
samtools_version ))
ValueError: versions of pysam/samtools and samtools differ: 0.1.19 != 
1.1

Given that samtools is still at version 0.1.19 in Jessie and that it is unsure
whether the version in sid (1.1) will migrate before the Freeze, I am removing 
the
tag 'jessie' from this bug.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762647: [Debian-med-packaging] Bug#762647: samtools: FTBFS: test suite errors

[Charles Plessy]

Le Tue, Sep 23, 2014 at 11:20:15PM -0400, Aaron M. Ucko a écrit :
 
 The builds of samtools for arm64 and ppc64el both failed because
 the first samtools faidx test hit the autobuilders' activity timeout.
 Given that these timeouts are generous (300 minutes for arm64, 150 for
 ppc64el), I suspect the test managed to hang on those systems.
 
 Meanwhile, the other builds attempted so far all encountered
 unexpected test failures -- 2 on kfreebsd-amd64, and 95 each on i386,
 kfreebsd-i386, and mipsel.

Hi Aaron,

regarding the test failures on the ‘stats’ command (2 unit failures), I
reported the issue upstream and will implement a workaround if necessary.

https://github.com/samtools/samtools/issues/300

The other failures and timeouts are probably symptoms of non-portability
outside amd64.  Some porters have contacted upstream on endianness issues, but
I do not know if the problem is likely to be solved in the short term.

https://github.com/samtools/samtools/issues/268

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756780: Status bowtie + tophat (Was: [Help] Need help for architecture specific code)

[Charles Plessy]

Le Sat, Aug 23, 2014 at 07:30:21PM +0200, Andreas Tille a écrit :
 
 What can we do to get tophat and bowtie into testing?
 
  tophat:
 1. tophat only Recommends: bowtie2 | bowtie   or
 2. tophat Architecture: amd64 kfreebsd-amd64
  I think 1. is the better option

Hi Andreas,

In my understanding, it is not possible to run TopHat without Bowtie (version 1
or 2).  Therefore, the “Depends” relationship is the most appropriate.

Regarding the migration to Testing, it looks like both bowtie2 and bowtie must
be installable to satisfy “bowtie2 | bowtie”, so we need to adapt ourselves to
this constraint.  Here are two possible solutions to the problem :

  1. bowtie2 and bowtie provide a virtual “bowtie-aligner”, and tophat
 depends on “bowtie2 | bowtie-aligner”.

  2. tophat depends on bowtie2 only.

Given that bowtie and bowtie2 can be co-installed, and given that most users
will want to use Bowtie 2 with TopHat, how about solution 2 ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755333: [pkg-eucalyptus-maintainers] Bug#755333: wsdl2c: FTBFS: [javac] /«PKGBUILDDIR»/src/org/apache/axis2/builder/MultipartFormDataBuilder.java:28: error: package javax.servlet.http does not exi

[Charles Plessy]

Le Tue, Jul 22, 2014 at 01:47:49PM -0300, Miguel Landaeta a écrit :
 
 This is just about a missing jar file in the classpath of the
 compilation.
 
 diff -Nru wsdl2c-0.1/debian/rules wsdl2c-0.1/debian/rules
 --- wsdl2c-0.1/debian/rules   2012-06-23 04:07:09.0 -0300
 +++ wsdl2c-0.1/debian/rules   2014-07-22 13:25:42.0 -0300
 @@ -6,4 +6,4 @@
  REQUIRED_JVM_VERSION := 1.5
  JAVA_HOME:= /usr/lib/jvm/default-java
  DEB_ANT_BUILDFILE:= build.xml
 -DEB_JARS := commons-logging wsdl4j backport-util-concurrent 
 gnumail httpcore jaxen commons-fileupload commons-cli geronimo-jms_1.1_spec 
 commons-httpclient httpcore-nio
 +DEB_JARS := commons-logging wsdl4j backport-util-concurrent 
 gnumail httpcore jaxen commons-fileupload commons-cli geronimo-jms_1.1_spec 
 commons-httpclient httpcore-nio servlet-api-3.0

Applied and uploaded, many thanks !

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755333: [pkg-eucalyptus-maintainers] Bug#755333: wsdl2c: FTBFS: [javac] /«PKGBUILDDIR»/src/org/apache/axis2/builder/MultipartFormDataBuilder.java:28: error: package javax.servlet.http does not

[Charles Plessy]

Hello everybody,

I received a bug report that the wsdl2c package started to fail to build from
source (see below).

On my side, I could confirm that indeed, after upgrading my machine to the
latest Sid, it also failed to build locally, while before the upgrade it did
not give a problem.

I am not sure what to do.  Is that due to some transition ?  Shall I just wait
and try again in a couple of weeks ? 

(The VCS URL of the package is svn+ssh://svn.debian.org/svn/svn/pkg-eucalyptus)

Have a nice day,

-- Charles Plessy, Tsurumi, Kanagawa, Japan

Le Sat, Jul 19, 2014 at 08:34:02PM +0200, David Suárez a écrit :
 Source: wsdl2c
 Version: 0.1-2
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140718 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
   debian/rules build
  test -x debian/rules
  mkdir -p .
  cd .  /usr/lib/jvm/default-java/bin/java -classpath 
  /usr/share/ant/lib/ant.jar:/usr/share/ant/lib/ant-launcher.jar:/usr/share/java/commons-logging.jar:/usr/share/java/wsdl4j.jar:/usr/share/java/backport-util-concurrent.jar:/usr/share/java/gnumail.jar:/usr/share/java/httpcore.jar:/usr/share/java/jaxen.jar:/usr/share/java/commons-fileupload.jar:/usr/share/java/commons-cli.jar:/usr/share/java/geronimo-jms_1.1_spec.jar:/usr/share/java/commons-httpclient.jar:/usr/share/java/httpcore-nio.jar:/usr/lib/jvm/default-java/lib/tools.jar
-Dant.home=/usr/share/ant org.apache.tools.ant.Main -Dcompile.debug=true 
  -Dcompile.optimize=true   -buildfile build.xml  
  Buildfile: /«PKGBUILDDIR»/build.xml
  
  compile:
  [mkdir] Created dir: /«PKGBUILDDIR»/build
  [mkdir] Created dir: /«PKGBUILDDIR»/build/classes
  [javac] /«PKGBUILDDIR»/build.xml:9: warning: 'includeantruntime' was 
  not set, defaulting to build.sysclasspath=last; set to false for repeatable 
  builds
  [javac] Compiling 1665 source files to /«PKGBUILDDIR»/build/classes
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/builder/MultipartFormDataBuilder.java:28:
   error: package javax.servlet.http does not exist
  [javac] import javax.servlet.http.HttpServletRequest;
  [javac]  ^
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/builder/MultipartFormDataBuilder.java:79:
   error: cannot find symbol
  [javac] private MultipleEntryHashMap 
  getParameterMap(HttpServletRequest request,
  [javac]  ^
  [javac]   symbol:   class HttpServletRequest
  [javac]   location: class MultipartFormDataBuilder
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/deployment/WarBasedAxisConfigurator.java:35:
   error: package javax.servlet does not exist
  [javac] import javax.servlet.ServletConfig;
  [javac] ^
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/deployment/WarBasedAxisConfigurator.java:54:
   error: cannot find symbol
  [javac] private ServletConfig config;
  [javac] ^
  [javac]   symbol:   class ServletConfig
  [javac]   location: class WarBasedAxisConfigurator
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/deployment/WarBasedAxisConfigurator.java:95:
   error: cannot find symbol
  [javac] public WarBasedAxisConfigurator(ServletConfig 
  servletConfig) throws DeploymentException {
  [javac] ^
  [javac]   symbol:   class ServletConfig
  [javac]   location: class WarBasedAxisConfigurator
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/transport/http/AbstractAgent.java:27: 
  error: package javax.servlet does not exist
  [javac] import javax.servlet.ServletException;
  [javac] ^
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/transport/http/AbstractAgent.java:28: 
  error: package javax.servlet.http does not exist
  [javac] import javax.servlet.http.HttpServletRequest;
  [javac]  ^
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/transport/http/AbstractAgent.java:29: 
  error: package javax.servlet.http does not exist
  [javac] import javax.servlet.http.HttpServletResponse;
  [javac]  ^
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/transport/http/AbstractAgent.java:55: 
  error: cannot find symbol
  [javac] public void handle(HttpServletRequest httpServletRequest,
  [javac]^
  [javac]   symbol:   class HttpServletRequest
  [javac]   location: class AbstractAgent
  [javac] 
  /«PKGBUILDDIR»/src/org/apache/axis2/transport/http/AbstractAgent.java:56: 
  error: cannot find symbol
  [javac]HttpServletResponse httpServletResponse)
  [javac]^
  [javac]   symbol:   class HttpServletResponse
  [javac]   location: class AbstractAgent
  [javac

Bug#751255: TreeView X abandonned upstream … (was: Re: [Debian-med-packaging] Processed: severity of 751255 is serious).

[Charles Plessy]

Le Tue, Jul 22, 2014 at 12:57:05AM +, Debian Bug Tracking System a écrit :
 Processing commands for cont...@bugs.debian.org:
 
  # blocks the on-going wxwidgets3.0 transition
  severity 751255 serious
 Bug #751255 [treeviewx] treeviewx: Please update to use wxwidgets3.0
 Severity set to 'serious' from 'important'
  thanks
 Stopping processing here.

Thanks Olly,

in the meantime, I contacted upstream who informed me that he does not have
time anymore for working on TreeView X, and we started to discuss on the
Debian Med mailing list what would be the best solution.

Is it enough for you to have it out of Testing, or is it needed to remove it
from Sid to ease your work ?

For us, I think that the next step is to call for help on general purpose
mailign lists relevant to TreeView X, and to contact the Fedora and Gentoo
maintainers of the treeviewx packages there to see if they have found a
solution on their side.

Thanks again, and 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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753210: [Debian-med-packaging] Bug#753210: bamtools: FTBFS: Patch failed

[Charles Plessy]

Le Sun, Jun 29, 2014 at 07:18:07PM +0200, David Suárez a écrit :
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
  make[1]: Entering directory '/«BUILDDIR»/bamtools-2.3.0+dfsg'
  # since the upstream build does not create versioned we need to tweak 
  d-shlibmove
  cp /usr/bin/d-shlibmove /«BUILDDIR»/bamtools-2.3.0+dfsg/debian/d-shlibmove
  patch -p0  debian/d-shlibmove.patch
  patching file debian/d-shlibmove
  Reversed (or previously applied) patch detected!  Assume -R? [n] 
  Apply anyway? [n] 
  Skipping patch.
  1 out of 1 hunk ignored -- saving rejects to file debian/d-shlibmove.rej
  make[1]: *** [override_dh_install] Error 1

Hi Andreas and Michael,

it looks that the package will fail to build each time the d-shlibmove program 
will
change, and this is not under our control.

If you use it to find the multiarch path, have you considered dh-exec as an
alternative ?  Here is how I used it in htslib.

In debian/control, build-depend on dh-exec.

In debian/libhts0.install :

#! /usr/bin/dh-exec
usr/lib/libhts.so.* usr/lib/${DEB_HOST_MULTIARCH}/

Debhelper does the rest.

See https://wiki.debian.org/Multiarch/Implementation for details.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: [Debian-med-packaging] Bug#736565: NMU patch for staden-io-lib 1.13.5-1.1

[Charles Plessy]

Le Wed, Apr 02, 2014 at 07:10:23PM +1100, Aníbal Monsalve Salazar a écrit :
 
 I just submitted Aleksandar Zlicic's patch to upstream.
 
 https://sourceforge.net/p/staden/bugs/105/

Thanks a lot for this !

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: [Debian-med-packaging] Bug#736565: Bug#736565: FTBFS on non-PC architectures: FAIL: scram_mt.test

[Charles Plessy]

Le Mon, Mar 31, 2014 at 06:03:12PM +1100, Aníbal Monsalve Salazar a écrit :
 
 Do you have the upstream email address?

Hi again, and thanks to you and Dejan for your prompt answers.

You can contact James Bonfield j...@sanger.ac.uk directly, but he is also
responsive through the upstream bug tracker on SourceForge:
http://sourceforge.net/p/staden/bugs/, which is a better place for providing
patches.

Have a nice day,

Charles

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: [Debian-med-packaging] Bug#736565: FTBFS on non-PC architectures: FAIL: scram_mt.test

[Charles Plessy]

Dear Aníbal and mips-port team,

staden-io-lib is going to be removed from Testing because of a RC bug that is
solved in Sid but can not migrate as long as the package still fails to build
o non-PC architectures.

My original plan was to remove staden-io-lib from [armel armhf mips mipsel
powerpc s390x ia64], but this was cancelled as you voluntered to fix
the build failure (http://bugs.debian.org/736565#10).

Do you know when you will be able to fix the package ?  If it is not likely to
happen in the short term, I would like to follow my original plan and remove it
from the architectures where it does not build.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Need more (legal) information

[Charles Plessy]

Le Tue, Mar 25, 2014 at 12:06:53PM +0100, Thibaut Varène a écrit :
 
 The kanjidic documentation states (emphasis is mine):
 
  The following people have granted permission for material for which they
  hold copyright to be included in the files, _and distributed under the
  above conditions_, while retaining their copyright over that material:
  
  Jack HALPERN: The SKIP codes in the KANJIDIC file.
 
 As I understand this, kanjidic and the SKIP codes it embeds are freely
 redistributable under the licensing terms of kanjidic.
 
 That other licensing provisions for the SKIP codes may be made in other use
 cases (as detailed in Appendix F of the same document) seems quite irrelevant
 to me: you are questioning the DFSG-compliance of kanjidic (and by extension
 the package that includes it: tagainijisho) and as far as I can see, the
 whole content of the file `tagainijisho-[version
 number]/3rdparty/kanjidic2.xml', including the SKIP codes, are covered by the
 license stated at the top of the file: CC-BY-SA, which is DFSG-compliant.

Hi Thibaut,

looking at the link you sent, it seems that the “above conditions” are
“KANJIDIC can be freely used provided satisfactory acknowledgement is made, and
a number of other conditions are met”, which is quite vague.  In addition, just
below the part that you cited (“Jack HALPERN: The SKIP codes in the KANJIDIC
file.”), there is “With regard to the SKIP codes, Mr Halpern draws your
attention to the statement he has prepared on the matter, which is included at
Appendix F.”

To me, it appears that Appendix F, which has non-Free clauses, applies.

Have you tried to contact the authors of KANJIDIC ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: [Debian-med-packaging] Bug#736565: FTBFS on non-PC architectures: FAIL: scram_mt.test

[Charles Plessy]

Le Sat, Mar 15, 2014 at 01:32:40PM +0900, Charles Plessy a écrit :
 Le Mon, Mar 10, 2014 at 12:13:34AM +1100, Aníbal Monsalve Salazar a écrit :
  On Sun, Mar 09, 2014 at 07:58:25PM +0900, Charles Plessy wrote:
   
   Speaking of Upstream, I see a new release, version 1.13.5.  Would you
   like me to upload it ?
  
  Yes, please.
 
 Uploaded !  Sorry for the delay.

By the way, my build log is available here:

https://buildd.debian.org/status/fetch.php?pkg=staden-io-libarch=amd64ver=1.13.5-1stamp=1394935300

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: FTBFS on non-PC architectures: FAIL: scram_mt.test

[Charles Plessy]

Le Mon, Mar 10, 2014 at 12:13:34AM +1100, Aníbal Monsalve Salazar a écrit :
 On Sun, Mar 09, 2014 at 07:58:25PM +0900, Charles Plessy wrote:
  
  Speaking of Upstream, I see a new release, version 1.13.5.  Would you
  like me to upload it ?
 
 Yes, please.

Uploaded !  Sorry for the delay.

Charles

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741288: [Debian-med-packaging] Bug#741288: seqan: FTBFS on many buildds due to RAM exhaustion

[Charles Plessy]

Le Mon, Mar 10, 2014 at 10:31:47PM +0100, Andreas Tille a écrit :
 
 It seems reducing optimisation in d/rules [...] did not really help (perhaps
 even droping -O1 could be tried but I doubt this).

Hello everybody,

I would also recommend to not make the program slower by design, unless you
want public researchers to buy more computers with your tax money.

Have a nice day,

Charles

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736565: FTBFS on non-PC architectures: FAIL: scram_mt.test

[Charles Plessy]

Le Sun, Mar 09, 2014 at 10:10:28AM +, Aníbal Monsalve Salazar a écrit :
 
 The regression test fails because xx#minimal.full.sam has one extra line
 at the end when it's compared to xx#minimal.full.bam.sam.
 
 The extra line is:
 
 A416  yy  4   1   *   *   0   0   *   
 *

Hi Aníbal,

The BAM format is the binary representation of the SAM format, for alignment of
nucleotide sequences on a reference genome.  I guess that the test suite checks
that the tool's output is the same in both formats, by converting BAM to SAM
and comparing the two SAM files.  Debian also distributes the 'samtools'
program, that can do this conversion as well.

$ samtools view -h xx#minimal.full.bam
@PG ID:scramble PN:scramble VN:1.13.3   
CL:/tmp/staden-io-lib-1.13.3/progs/.libs/lt-scramble -t4 ./data/xx#minimal.sam 
test.out/xx#minimal.bam 
@PG ID:scramble.1   PN:scramble PP:scramble VN:1.13.3   
CL:/tmp/staden-io-lib-1.13.3/progs/.libs/lt-scramble -t4 -r ./data/xx.fa 
test.out/xx#minimal.bam test.out/xx#minimal.full.cram 
@PG ID:scramble.2   PN:scramble PP:scramble.1   VN:1.13.3   
CL:/tmp/staden-io-lib-1.13.3/progs/.libs/lt-scramble -t4 -O bam 
test.out/xx#minimal.full.cram 
@SQ SN:xx   LN:20   M5:bbf4de6d8497a119dda6e074521643dc 
UR:/tmp/staden-io-lib-1.13.3/tests/./data/xx.fa
@SQ SN:yy   LN:20   M5:bbf4de6d8497a119dda6e074521643dc 
UR:/tmp/staden-io-lib-1.13.3/tests/./data/xx.fa
a0  16  xx  4   1   10H *   0   0   *   
*
a1  16  xx  4   1   10H *   0   0   *   
*
a2  16  xx  4   1   5H10M5H *   0   0   
AAATTT  *
A0  16  yy  4   1   *   *   0   0   *   
*
A1  16  yy  4   1   *   *   0   0   *   
*
A2  16  yy  4   1   *   *   0   0   *   
*
A3  16  yy  4   1   *   *   0   0   *   
*
A4  16  yy  4   1   *   *   0   0   *   
*

Missing a line on MIPS definitely looks like a bug.  This said, it works on
amd64 (at least the test suite) and I doubt that there are users for the
staden-io-lib on MIPS.  Have you tried to contact the upstream author ?

Speaking of Upstream, I see a new release, version 1.13.5.  Would you like me
to upload it ?

Cheers,

Charles

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739575: [Debian-med-packaging] Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Charles Plessy]

Le Thu, Feb 20, 2014 at 10:08:16AM +0100, Andreas Tille a écrit :
 Hi Andreas,
 
 the directory is intended to be written by the world since the whole
 world should be able to run the test suite there ... this is the purpose
 of this package at all:  Let everybody run the test (including
 autopkgtest) and forget about the directory afterwards.
 
 Do I need to mark this intention to not provoke any errors?

Hi Adreases,

I think that the expectation is that the package provides a directory tree to
be copied in a temporary location; this solves the problem of write
permissions.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739575: [Debian-med-packaging] Bug#739575: Bug#739575: python-pysam-tests: world writable directory tree: /var/lib/pysam/tests

[Charles Plessy]

Le Thu, Feb 20, 2014 at 10:36:57AM +0100, Andreas Tille a écrit :
 
 While I agree that this would solve this formal problem I think
 providing (potentially large chunks of) data which are only to run a
 test and force people to create various copies of them is an insane
 consequence of the requirement to not have world writable directory
 tries.

Hi again,

while I do not have a better solution to propose, I would be surprised if
nobody had a deeper thought on the question before us.  Search engines did not
give me answers, but maybe you can ask for advice on -mentors or -devel ?

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736407: [Debian-med-packaging] Bug#736407: staden-io-lib: FTBFS on non-x86 architectures

[Charles Plessy]

Control: severity -1 wishlist

Le Thu, Jan 23, 2014 at 12:17:40PM +0100, Andreas Beckmann a écrit :
 Package: staden-io-lib
 Version: 1.13.3-2
 Severity: serious
 Justification: fails to build from source
 
 staden-io-lib only built successfully on i386-any and amd64-any, all
 other architectures fail two tests.

Thanks for the report.

I have requested the removal of staden-io-lib on the failing architectures,
so I am pre-emptively setting that bug's severity to wishlist.

Have a nice week-end,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732408: pv-grub-menu: fails to install: /usr/sbin/update-menu-lst: line 116: grub: command not found

[Charles Plessy]

Control: tag -1 normal

Le Thu, Jan 09, 2014 at 07:24:46PM +0100, Andreas Beckmann a écrit :
 Followup-For: Bug #732408
 
 Still fails to install in a piuparts chroot:
 
   Selecting previously unselected package pv-grub-menu.
   (Reading database ... 6909 files and directories currently installed.)
   Preparing to unpack .../pv-grub-menu_1.2.1_all.deb ...
   Unpacking pv-grub-menu (1.2.1) ...
   Setting up pv-grub-menu (1.2.1) ...
   Searching for GRUB installation directory ... found: /boot/grub
   dpkg: error processing package pv-grub-menu (--configure):
subprocess installed post-installation script returned error exit status 1
   Errors were encountered while processing:
pv-grub-menu

Dear Andreas,

it seems that Piuparts is not able to install grub-common, on which
pv-grub-menu depends, but I do not undertand why.  Do you have an explanation ?

In the meantime, I am downgrading the severity of this bug: I have confirmed in
a minimal system (Debian image for the Amazon cloud) that pv-grub-menu is
installable.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732408: pv-grub-menu: fails to install: /usr/sbin/update-menu-lst: line 116: grub: command not found

[Charles Plessy]

Control: tag -1 confirmed

Le Tue, Dec 17, 2013 at 07:59:54PM +0100, Andreas Beckmann a écrit :
 
 during a test with piuparts I noticed your package failed to install. As
 per definition of the release team this makes the package too buggy for
 a release, thus the severity.
 
 From the attached log (scroll to the bottom...):
 
 Selecting previously unselected package pv-grub-menu.
   (Reading database ... 6917 files and directories currently installed.)
   Preparing to unpack .../pv-grub-menu_1.2_all.deb ...
   Unpacking pv-grub-menu (1.2) ...
   Setting up pv-grub-menu (1.2) ...
   Searching for GRUB installation directory ... found: /boot/grub
   /usr/sbin/update-menu-lst: line 116: grub: command not found

Dear Andreas,

thank you for your constant work on piuparts, which uncovered this problem.

When I test the package, the error is there but it does not interrupt the
installation.  Does piuparts pass some special parameters to the shell to make
it more sensible to errors ?

Nevertheless, I will fix this bug anyway.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729276: staden-io-lib-utils: bufferoverflow in index_tar

[Charles Plessy]

Le Sun, Nov 10, 2013 at 09:20:08PM -0500, Sang Kil Cha a écrit :
 Package: staden-io-lib-utils
 Version: 1.12.4-1
 Severity: grave
 Tags: security
 Justification: user security hole
 
 index_tar has a buffer overflow vulnerability. A PoC file is attached.

Hello,

thanks for the report.  Have you also submitted it upstream ?  Do you
have a suggestion on how to solve the problem ?

Cheers,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729276: [Debian-med-packaging] Bug#729276: staden-io-lib-utils: bufferoverflow in index_tar

[Charles Plessy]

Le Sat, Nov 30, 2013 at 04:01:50AM -0500, Sang Kil Cha a écrit :
 
 Yes I think I did submitted it to upstream.

Hi again,

I do not see it in the Upstream bugtracker.  Can you also submit it there ?

http://sourceforge.net/p/staden/bugs/

Have a nice Sunday,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729785: Copyright review for the package libpqxx 4.0.1-2.

[Charles Plessy]

Package: libpqxx
Version: 4.0.1-1
Severity: serious
Control: user debian-le...@lists.debian.org
Control: usertags -1 one-copyright-review

Dear Marcin,

In the hope of speeding up and strenghtening the processing of the NEW queue I
had a look at your package libpqxx 4.0.1-2.  The rationale is explained in
the proposal in the following wiki page.

http://wiki.debian.org/CopyrightReview

I found that libpqxx 4.0.1 contains at least one minified JavaScript file,
doc/html/Reference/jquery.js, for which there is no coresponding source, and
that is mentionned in the Debian copyright file.  If it works, it would be
better to replace this file with a link to the same file provided by
libjs-jquery.  You may find other advices on the debian-mentors mailing list on
how to deal with the situation.

On a more minor side, the copyright statement of Bart Samwel in
tools/template2mak.py is also missing from the Debian copyright file.

Have a nice Sunday,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728650: [Debian-med-packaging] Bug#728650: FTBFS on PowerPC, patch attached.

[Charles Plessy]

Le Sun, Nov 03, 2013 at 12:02:26PM -0700, Adam Conrad a écrit :
 
   * Stop selecting vmx DP implementation on powerpc to resolve FTBFS.

Hi Adam,

at this point, we have to consider the use cases.

Hmmer is a software for scientific computing.  Using it with AltiVec/VMX
disabled on a recent PowerPC platform makes no sense from an economical
point of view.

Also, if building with AltiVec/VMX is broken, it may be the symptom of a bigger
probem.  How do we know if it the program works at all even if it builds with
AltiVec/VMX disabled ?  We have no test suite and no sign of users of the hmmer
Debian packages on PowerPC. 

I would recommend to simply stop distributing it on PowerPC, and invest further
work only if we have a user asking for it.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728650: [Debian-med-packaging] Bug#728650: Bug#728650: FTBFS on PowerPC, patch attached.

[Charles Plessy]

Le Sun, Nov 03, 2013 at 08:44:01PM -0700, Adam Conrad a écrit :
 On Mon, Nov 04, 2013 at 08:36:52AM +0900, Charles Plessy wrote:
 
  I would recommend to simply stop distributing it on PowerPC, and invest 
  further
  work only if we have a user asking for it.
 
 Well, if you make that argument, you may as well stop building it on almost
 all arches, as most use the generic C implementation.  I think there's value
 in building on all arches, even if you think your target audience might not
 care, in that porting to multiple arches keeps the code a bit more clean and
 sane and generally portable, plus if someone comes along on ARM, installs it,
 says man, this is kinda crap, they may well be inclined to do a VFP or NEON
 port and contribute it.  That's a lot less likely if you just shun arches
 that don't have an optimised backend available.

I think that we have to think about what we really want to achieve, and focus
our efforts on that goal.  Source code can be optimised endlessly.  If you have
fun porting hmmer, then you may find doing it valuable, but if your goal is to
make Debian better on architectures other than amd64, then I am sure that there
are more relevant packges to start with.

In doubt, let me re-state that porting hmmer is probably a waste of time,
especially considering that we have hmmer3 in our archive, which makes hmmer
quite historical...

However, if you are intersted in porting on ARM, there was an exciting
discussion last month on the debian-med mailing list, where we learned about a
project of using Raspberry Pis in a practical course of bioinformatics.  This
is not a Debian project, but there can be good synergies where I am sure that
your help will be welcome, not only for fixing bugs, but also for implementing
and running regression tests, in order to detect bugs that are not revealed at
build time.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724138: Future of the wss4j package in Debian.

[Charles Plessy]

Le Wed, Sep 25, 2013 at 07:56:05AM -0700, tony a écrit :
 On Wed, Sep 25, 2013 at 01:32:11PM +0200, Emmanuel Bourg wrote:
  Hi Charles,
  
  I packaged the latest version of wss4j:
  
  http://anonscm.debian.org/gitweb/?p=pkg-java/wss4j.git
  http://mentors.debian.net/package/wss4j
  
  Do you want to sponsor the upload to complete the adoption?
  
  Emmanuel Bourg
 
 Hi Charles,
 
 If you aren't available, I will sponsor the upload.  As a wss4j user,
 I'd like to see it remain in Debian.  It's one of those libraries that I
 think Debian needs to have in order to be a legitimate Java platform.

Thanks Tony for the help, feel free to upload if you are the first to have
time.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724478: umegaya: FTBFS: pandoc errors

[Charles Plessy]

Le Tue, Sep 24, 2013 at 10:10:13AM +0300, Damyan Ivanov a écrit :
 Package: src:umegaya
 Version: 0.13
 Severity: serious
 Justification: FTBFS
 
 umegaya fails to build in a current clean sid pbuilder chroot:
 
  debian/rules build
 dh build
dh_testdir
dh_auto_configure
debian/rules override_dh_auto_build
 make[1]: Entering directory `/tmp/buildd/umegaya-0.13'
 perldoc -o nroff cgi-bin/umegayaman/umegaya.1
 perldoc -o nroff scripts/umegaya-admman/umegaya-adm.1
 for file in man/*.1.mdwn ; do \
   pandoc -s -w man $file  -o man/$(basename $file .mdwn) ; done
 pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
 not exist (No such file or directory)
 pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
 not exist (No such file or directory)
 pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
 not exist (No such file or directory)
 pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
 not exist (No such file or directory)
 pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
 not exist (No such file or directory)
 make[1]: *** [override_dh_auto_build] Error 1

Hi Damyan,

I think that the problem is with pandoc, see http://bugs.debian.org/724102

Have a nice day, and thanks for the rebuilds, they are essential.

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724102: #724102: pandoc misses recommends on pandoc-data

[Charles Plessy]

Le Wed, Sep 25, 2013 at 07:20:27AM +0200, intrigeri a écrit :
 
 Charles Plessy wrote (23 Sep 2013 00:31:50 GMT) :
  I think that pandoc lost by accident its recommendation (via CDBS) on
  pandoc-data.
 
 pandoc 1.11.1-4 does recommend pandoc-data, so perhaps the problem is
 rather that pandoc is not that useful without pandoc-data, and it
 should instead hard-depend on it?

Hi,

Apologies for missing this; I wrongly assumed that sbuild installed recommended
packages by default, and this probably made be blind to the truth as I grepped
apt-cache show pandoc for pandoc-data...  We only see what we want to see :(

The problem is indeed that pandoc-data is not pulled by pandoc at build time,
For the purpose of building manpages with pandoc, the solution is either to
build-depend on pandoc-data, or to make pandoc depend instead of recommend
pandoc-data.

Let me know which solution you prefer.

Bonne journée !

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724138: Future of the wss4j package in Debian.

[Charles Plessy]

Le Mon, Sep 23, 2013 at 08:04:53AM +0200, Emmanuel Bourg a écrit :
 Le 23/09/2013 02:05, Charles Plessy a écrit :
 
   - Is wss4j still needed in Debian ?  Would Eucalyptus 3.0 still use it ?
   - Is the Java team interested by taking it over, in any case ?
 
 The package is probably not needed now, but I'm interested in
 maintaining it as it could be useful for a future package. I just need
 someone to move it under pkg-java on alioth (I don't think I have commit
 rights on pkg-eucalyptus).

Hi Emmanuel,

thanks a lot for the help.

Once you have transferred the package to the Java team, please delete it from
the pkg-eucalyptus repository.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724138: Future of the wss4j package in Debian.

[Charles Plessy]

Dear Eucalyptus and Java teams,

wss4j (Apache WSS4J WS-Security) is a package that was created in order
to build the Eucalyptus packages, which are currently removed.  The
wss4j fails to build from source in Jessie and Unstable.

Current version in Debian is 1.5.8.  On the upstream website, versions 1.5.12
and 1.6.12 are available.  The 1.6 line diverged after 1.5.11.  A version
1.5.13, fixing some extra bugs, is available as a SVN tag but is not advertised
on the upstream website.

The Debian package contains a patch removing some code related to SAML, for a
reason that I do not remember.  This patch does not apply cleanly to version
1.5.12, and I suppose it will be the same for 1.6.12.  For this reason, I could
not test if updating to one of the latest upstream releases will make the wss4j
package build again for source.  Not knowing Java enough, I could not go
further.

My questions are the following:

 - Is wss4j still needed in Debian ?  Would Eucalyptus 3.0 still use it ?
 - Is the Java team interested by taking it over, in any case ?

Here is the extract of the build log that was sent to the bug report.

Le Sun, Sep 22, 2013 at 07:15:37PM +0200, David Suárez a écrit :
 
  make[1]: Entering directory `/«BUILDDIR»/wss4j-1.5.8+svntag'
  /usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk 
  is deprecated - please use source format 3.0 (quilt) instead
  make[1]: Nothing to be done for `update-config'.
  make[1]: Leaving directory `/«BUILDDIR»/wss4j-1.5.8+svntag'
  cd .  /usr/lib/jvm/default-java/bin/java -classpath 
  /usr/share/ant/lib/ant.jar:/usr/share/ant/lib/ant-launcher.jar:/usr/share/java/axis.jar:/usr/share/java/commons-logging.jar:/usr/share/java/xalan2.jar:/usr/share/java/bcprov.jar:/usr/share/java/jaxrpc.jar:/usr/share/java/xmlsec.jar:/usr/lib/jvm/default-java/lib/tools.jar
-Dant.home=/usr/share/ant org.apache.tools.ant.Main -Dcompile.debug=true 
  -Dcompile.optimize=true   -buildfile debian/build.xml  
  Buildfile: /«BUILDDIR»/wss4j-1.5.8+svntag/debian/build.xml
  
  init:
  
  prepare:
  [mkdir] Created dir: /«BUILDDIR»/wss4j-1.5.8+svntag/build
  [mkdir] Created dir: /«BUILDDIR»/wss4j-1.5.8+svntag/build/test-reports
  
  prepare-src:
  [mkdir] Created dir: /«BUILDDIR»/wss4j-1.5.8+svntag/build/classes
  
  compile.library:
  [javac] /«BUILDDIR»/wss4j-1.5.8+svntag/build.xml:340: warning: 
  'includeantruntime' was not set, defaulting to build.sysclasspath=last; set 
  to false for repeatable builds
  [javac] Compiling 98 source files to 
  /«BUILDDIR»/wss4j-1.5.8+svntag/build/classes
  [javac] warning: [options] bootstrap class path not set in conjunction 
  with -source 1.3
  [javac] 
  /«BUILDDIR»/wss4j-1.5.8+svntag/src/org/apache/ws/security/WSSConfig.java:288:
   error: cannot find symbol
  [javac] Transform.init();
  [javac]  ^
  [javac]   symbol:   method init()
  [javac]   location: class Transform
  [javac] Note: Some input files use or override a deprecated API.
  [javac] Note: Recompile with -Xlint:deprecation for details.
  [javac] 1 error
  [javac] 1 warning
  
  BUILD FAILED
  /«BUILDDIR»/wss4j-1.5.8+svntag/build.xml:340: Compile failed; see the 
  compiler error output for details.
  
  Total time: 6 seconds
  make: *** [debian/stamp-ant-build] Error 1
 
 The full build log is available from:

 http://aws-logs.debian.net/ftbfs-logs/2013/09/22/wss4j_1.5.8+svntag-2_unstable.log

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724102: #724102: pandoc misses recommends on pandoc-data (was: Re: Bug#724102: umegaya: FTBFS: pandoc ...)

[Charles Plessy]

Le Sun, Sep 22, 2013 at 09:20:52PM +0200, David Suárez a écrit :
reassign 724102 pandoc
retitle 724102 pandoc: misses Recommends on pandoc-data.
affects 724102 umegaya
thanks

Dear pandoc maintainers,

I think that pandoc lost by accident its recommendation (via CDBS) on
pandoc-data.  As a consequence, some package(s) using pandoc at build time fail
to build from source.  Here is an example with the umegaya package.

  for file in man/*.1.mdwn ; do \
pandoc -s -w man $file  -o man/$(basename $file .mdwn) ; done
  pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
  not exist (No such file or directory)
  pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
  not exist (No such file or directory)
  pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
  not exist (No such file or directory)
  pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
  not exist (No such file or directory)
  pandoc: /usr/share/pandoc/data/templates/default.man: openBinaryFile: does 
  not exist (No such file or directory)
  make[1]: *** [override_dh_auto_build] Error 1

Thanks for your work on pandoc, and have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722982: Broken in Wheezy.

[Charles Plessy]

Package: emboss-explorer
Version: 2.2.0-7
Severity: grave

Hello everybody.

I just tried emboss-explorer on a minimal Wheezy system (7.1), and it
does not work out of the box.  For each item in the menu, the main
frame reports [item name] is not a valid EMBOSS application.

There are patches on SourceForge, that may be related to this issue.

I will try to prepare an update for Wheezy.  Of course, anybody is welcome to
self-appoint and do it instead of me.

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#720618: non-free license statement in /usr/share/inkscape/icons/inkscape.svg

[Charles Plessy]

Package: inkscape
Version: 0.48.4-2
Severity: serious

Hello,

I just found by chance (because the inkscape icon is incorporated in the Sozi
icon, https://github.com/senshu/Sozi/blob/master/editors/inkscape/sozi/icon.svg)
that the Inkscape icon contains a statement suggesting that its license is
CC-BY-SA 2.0.  This is unfortunate, as Debian's FTP team does not consider it
Free.

Perhaps you can clarify this with the Inkscape authors ?  Maybe they intended
GPL-2 anyway...

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718747: [Debian-med-packaging] Bug#718747: phyml: FTBFS on arm* more

[Charles Plessy]

Le Mon, Aug 05, 2013 at 02:22:16AM +0200, Hector Oron a écrit :
 Source: phyml
 Version: 2:20120412-1
 Severity: serious
 Justification: FTBFS
 
 Hello,
 
   Your package fails to build from source on Debian autobuilder network.
 
   Please check your package build logs at:
   https://buildd.debian.org/status/package.php?p=phymlsuite=sid
 
   Consider disabling SSE instructions on non Intel platforms.

Hi Hector,

do you think that you could send a patch for this ?

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718747: [Debian-med-packaging] Bug#718747: phyml: FTBFS on arm* more

[Charles Plessy]

Le Mon, Aug 05, 2013 at 04:23:20AM +0200, Hector Oron a écrit :
 
 2013/8/5 Hector Oron hector.o...@gmail.com:
  2013/8/5 Charles Plessy ple...@debian.org:
 
  do you think that you could send a patch for this ?
 
  Find it attached
 
 Note I have uploaded package to delayed queue 4, please let me know if
 I should delay longer or cancel the upload.

Hi Hector,

thanks for the patch.

Sorry if I overlooked something, but doesn't this patch also disable SSE on
i386 and AMD64 ?

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718120: libbio-primerdesigner-perl: FTBFS: Too early to specify a build action 'vendor'. Do 'Build vendor' instead.

[Charles Plessy]

Le Mon, Jul 29, 2013 at 06:20:19PM +0200, gregor herrmann a écrit :
 On Mon, 29 Jul 2013 00:15:02 +0200, gregor herrmann wrote:
 
dh --buildsystem=perl_build build
   dh_testdir -O--buildsystem=perl_build
   dh_auto_configure -O--buildsystem=perl_build
Unknown option: installdirs
  
  This is caused by the usage of Getopt::Long in Build.PL.
  (In combination with debhelper using --long-options now, #714544).
  
  We've seen this somewhere else, and Dominic came up with a nice
  patch.
  Unfortunately I don't remember the package anymore ...
 
 Here we are:
 https://github.com/OpenGuides/OpenGuides/pull/71
 
 I've now pushed a patch to git along these lines; reviews welcome!

Thanks Gregor.  I just corrected the bug number in the changelog.  (718056 -
718120).

Have a nice week-end,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718120: libbio-primerdesigner-perl: FTBFS: Too early to specify a build action 'vendor'. Do 'Build vendor' instead.

[Charles Plessy]

Le Sat, Aug 03, 2013 at 02:47:56PM +0200, gregor herrmann a écrit :
 On Sat, 03 Aug 2013 21:26:49 +0900, Charles Plessy wrote:
 
 Still, I'd like to have a review from someone who has used
 Devel::CheckLib before ...

Not me, sorry :(

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709173: Debian cloud images for OpenStack?

[Charles Plessy]

Le Mon, Jul 08, 2013 at 12:16:46PM +0200, Juerg Haefliger a écrit :
  On 07/06/2013 08:18 PM, Thomas Goirand wrote:
  Right now we have cloud-init in backports and testing/Jessie (yay! Well 
  done Thomas, Jakub and Charles).
  Thanks, but unfortunately, it is still waiting for FTP masters approval.
 
  It seems I was wrong, cloud-init really is in backports already! :)
  I wonder though why it still doesn't show on packages.debian.org.
 
 I was not able to use that version of cloud-init (from jessie)
 successfully. It seems very broken to me and I filed a bug report a
 while ago but nobody seems to have picked it up yet:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709173. Not sure if I
 did something wrong or filed it incorrectly.

Hi Juerg,

sorry for not answering.

I would really prefer to use the Upstream init scripts, but the patch you sent
seems to install new scripts in the debian directory instead.  Could you give
us a bit more explanations on your patch ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713284: [Debian-med-packaging] Bug#713284: r-other-mott-happy: FTBFS: ERROR: a 'NAMESPACE' file is required

[Charles Plessy]

merge 709190 713284 
thanks

  ERROR: a 'NAMESPACE' file is required

Hi all,

the problem was fixed in a new upstream release.  I hope to upload it
within a week.

Cheers,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701322: [Debian-med-packaging] Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)

[Charles Plessy]

Le Thu, Jun 06, 2013 at 09:22:43AM +0100, Dmitrijs Ledkovs a écrit :
 
 boost-thread, now links/requires against boost-system. And up until
 recently, the dependencies between boost-thread  boost-system
 packages was missing.
 I took, 3.4.0.1-3ubuntu1 from ubuntu, and it compiles correctly in sid.
 I think I'll just upload a fix for this.

Thanks !  Do you think this is something that should be forwarded upstream ?

Cheers,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)

[Charles Plessy]

Le Wed, Jun 05, 2013 at 09:34:04AM +0900, Charles Plessy a écrit :
 
  - there is a patch for building with a recent BOOST in Ubuntu, which looks
needed to build on unstable but is not sufficient.
  - the new stable upstream release need further work on BOOST (maybe something
trivial like updating build dependancies), so I did not have time to see if
the failure related to GCC is still present there.
 
 I also did not have time to try the development version.

Thanks Thorsten for upgrading the package.

I am puzzled by the build failure in Unstable.  Do we miss build-dependancies,
or could it be related to the changes in the default parameters for the C
linker ?


http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries

Cheers,

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)

[Charles Plessy]

Hi all,

I had a brief look this morning:

 - there is a patch for building with a recent BOOST in Ubuntu, which looks
   needed to build on unstable but is not sufficient.
 - the new stable upstream release need further work on BOOST (maybe something
   trivial like updating build dependancies), so I did not have time to see if
   the failure related to GCC is still present there.

I also did not have time to try the development version.

Please feel free to take the lead on this issue: I am still very busy and
next weekend I may be away from the keyboard as well.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709773: Wrong handling of debconf

[Charles Plessy]

Le Sat, May 25, 2013 at 06:31:35PM +0800, Thomas Goirand a écrit :
 Package: cloud-init
 Version: 0.7.1-3
 Severity: serious
 
 Cloud-init has a debconf thing to handle which type of API should be
 supported. Though it is done wrong:
 
 1/ Preseeding doesn't work
 2/ If /etc/cloud/cloud.cfg.d/90_dpkg.cfg exists, then the currently
 configured avlue doesn't seem to be read in the config script.

Hi Thomas,

this might (or might not) be solved already in Ubuntu's package, which is ahead
(0.7.2~bzr809).  Now that upstream version 0.7.2 is out, we can probably
attempt to merge changes related to debconf from Ubuntu.

I have done the boring part (updated debian/copyright after finding three new
copyright notices and one new license), so if you or somebody else want to work
on an update to 0.7.2 that would solve this bug and #709173, please go ahead,
the road is clear.

(But I need to add that on my system, the package builds only with sudo, not
with fakeroot)

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: Redistribution of Pathway ontology inside EMBOSS suite packaged for Debian

[Charles Plessy]

Dear Victoria,

I am Charles Plessy from the Debian project, working with Andreas Tille on
packaging and distributing software relevant to medecine and bioinformatics.

Thank you for your answers about Pathway Ontology (PW) and sorry to bother you
again.  It would tremendously help us if we could have a confirmation that PW
is released under the Creative Commons license 3.0, because in our experience,
there are often misundersandings about what is meant by free.  In particular,
in Debian's point of view, it is necessary to allow a work to be sold in order
to be called free.  One of the reasons is that Debian is often distributed on
DVDs that are sold, and that requires the right to commercially use each of the
~30,000 programs that we redistribute.

The CC 3.0 license (http://creativecommons.org/licenses/by/3.0/) would give us
that right.  Given that it already been adopted for other ontologies, in
particular Gene Ontology, I hope that it would be possible for RGD to release
PW under this license or a similarly free one.  In that case, could you for 
instance
drop a LICENSE file in 
ftp://rgd.mcw.edu/pub/data_release/ontology_obo_files/pathway/ or
answer us at 694...@bugs.debian.org (where I have sent a carbon copy of this 
message).

Many thanks for the time you are giving us,

Charles

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699260: [Debian-med-packaging] Bug#699260: Help (Was: Bug#699260: r-cran-genabel: FTBFS: error: subscript out of bounds)

[Charles Plessy]

tag 699260 confirmed
severity 699260 grave
thanks

Le Tue, Jan 29, 2013 at 01:28:36PM -0600, Dirk Eddelbuettel a écrit :
 
 Also, CRAN has 1.7-3, you guys are at 1.7-0 of GenABEL.  Maybe this even
 changed upstream...

Indeed :)

+***  v. 1.7-3 (2013.01.09)
+
+(2013.01.09)
+Commented the parts related to non-additive GC in qtscore
+Removed calls to 'attach' from multiple procedures
+Decrease of running time for long-running examples 
(GC_ovdom,GC,check.marker,Xfix,srdta)
+
+(2013.01.07)
+Fixing the problem which prevents the package from loading while checking the 
version on CRAN

I confirm that 1.7-0 fails and 1.7-3 builds.  Also, the error also affects the
binary package (version 1.7-0), rendering it useless.

Our choices are:

 a) distribute 1.7-3 in Wheezy (note that the diff is not small),
 b) backport the correction, and
 c) remove r-cran-genabel from Wheezy.

I volunteer for a), and I am neutral with b) and c).

Have a nice day,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Status update (Was: Bug#694908: Contains non-free data)

[Charles Plessy]

Le Wed, Jan 09, 2013 at 03:32:34PM +0100, Andreas Tille a écrit :
 
 So we have confirmation about the free distribution from three out of
 seven questionable files.  I'm positive we will get more like this and
 would consider it safe to set the bug wheezy-ignore for the moment if
 the release team might share this opinion.

Hi Andreas,

thank you so much for your patience and determination.

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Contains non-free data

[Charles Plessy]

Le Sun, Dec 30, 2012 at 07:46:10PM +0900, Charles Plessy a écrit :
 
 I am contacting Gene Ontology's helpdesk to make sure that we have the right 
 to
 redistribute the datai (copy pasted below).

I received excellent news: Gene Ontology is considering to switch to the
Creative Commons BY (Attribution 3.0 Unported) license in 2013.

Remaining data for which the licence has to be clarified:

 http://www.ebi.ac.uk/chebi/

 http://www.obofoundry.org/cgi-bin/detail.cgi?id=evidence_code

 http://www.obofoundry.org/cgi-bin/detail.cgi?id=pathway

 http://obofoundry.org/ro/

 http://www.sequenceontology.org/

 http://theswo.sourceforge.net/

(all in emboss/data/OBO )

Cheers,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Bug#694908: Contains non-free data

[Charles Plessy]

Le Tue, Jan 01, 2013 at 09:53:09AM +0100, Andreas Tille a écrit :
 
 Could you also somehow publish (if needed internally)
 your e-mail to Gene Ontology to write similar mails to the other
 copyright holders?

Hi Andreas,

It was at the bottom of http://bugs.debian.org/694908#22, and I
just saw that the exchange was public in Upstream's bugtracker.

  http://www.ebi.ac.uk/panda/jira/browse/GOHELP-147

Cheers,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Bug#694908: Contains non-free data

[Charles Plessy]

Le Mon, Dec 31, 2012 at 04:32:29PM +0100, Andreas Tille a écrit :
 
 I could imagine to use the Debian Med sprint to work on this issue.

Hi Andreas,

very good idea: there would definitely need the energy of a Sprint to solve the
problem, as there are half a dozen different sources of external data, all
potentially non-free.

 
http://anonscm.debian.org/gitweb/?p=debian-med/emboss.git;a=tree;f=emboss/data/OBO;hb=HEAD

This year again I will not have opportunity to join the Sprint as I have taken
a lot of holidays for Christmas (I am just leaving Europe for Japan, greetings
from Frankfurt airport !).  But you have all my blessing to make major changes
to the package if needed.

Enjoy the End of Year !

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Bug#694908: Contains non-free data

[Charles Plessy]

Le Sat, Dec 29, 2012 at 08:42:41PM +0100, Steffen Möller a écrit :
  
  The GO license I read as scientific integrity. Yes, as a consequence you
  cannot modify the database at will or it is not GO any more and you cite it
  where you use it. IIRC some two GO terms or so I had at some point suggested
  myself, so changes _can_ be made and one is even helped to get it done
  consistently. For other views on the world, have all the freedom of the
  world to start your own ontologies, and many are doing so.

Hi Steffen,

The problem would definitely be solved if license terms would allow to modify
the data provided that the name is changed, in line with DFSG#4, but I could
not find such a permission on GO's website.

I considered proposing this in the message I sent to GO, but in the end, this
is a practice that I do not want to recommend, as things would become very
impractical if such clauses would become the norm for for software and data
(this is why I am also very sceptical with trademark restrictions).  I think
that clauses requiring proeminent notices are a good compromise, and data
integrity checks (signed checksums, etc.) are the best way to prevent potential
problems.

But I expect quite a variety of opinons on the subject, even within Debian Med.
We should better speak of one voice, not only with GO, but also with the other
ontology providers, so to the other developers: please express yourself if you
wish, so that we can build a consensus.

Cheers,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: [Debian-med-packaging] Bug#694908: Contains non-free data

[Charles Plessy]

 On Sun, Dec  2, 2012 at 09:39:14 +0900, Charles Plessy wrote:
  
  As discussed in the following message, EMBOSS contains non-free data.
  
https://lists.debian.org/20120918045219.ga26...@falafel.plessy.net
  
  We need to consider short- and long-term solutions to this problem.  For the
  short-term solution, I think that I will not have time to split free and
  non-free parts of EMBOSS, so we need again to consider to move it 
  altogether to
  non-free.  In contrary to the UniProt files which were in the test suite, 
  the
  Gene Ontology files are needed by EMBOSS to run some of its programs.

Le Sat, Dec 29, 2012 at 06:46:20PM +0100, Julien Cristau a écrit :
 
 Does that mean emboss and embassy-* need to be removed from wheezy?

I am contacting Gene Ontology's helpdesk to make sure that we have the right to
redistribute the datai (copy pasted below).  Once this is confirmed, this bug
can be addressed by ignoring, downgrading, removing, or re-uploading to
non-free (sorted by increasing amounts of work).

I think that the release team has to decide which way to take: if I understand
correctly you are tagging wheezy-ignore other license issues (GFDL, non-free
PostScript code), but I do not know what are the criterion you follow, so I can
not decide for you.

Please let me know if you need further information.  Also, I would be
interested to hear the opinion of Debian Med's members about moving EMBOSS to
non-free.

Bon dimanche,

-- Charles



-- Message posted this morining on GO's contact page 

Dear GO consortium,

I found on the page http://www.geneontology.org/GO.cite.shtml of your website 
some instructions on how to use GO without license.  However, I have not found 
an explicit right to redistribute the data.

The Debian operating system is currently redistributing some files from GO 
indirectly, as we redistribute the EMBOSS package, which incorporates some GO 
files since its version 6.4 (http://packages.debian.org/wheezy/emboss).

Debian considers copyrights and licenses very seriously, and our system only 
contains Free software, that is, materials that our users can freely use, 
modify and redistribute themselves. In addition to our system, we have a 
non-free archive in which, as a convenience for our users, we redistribute 
works that give less freedoms to our users.

In order to evaluate if works containing GO files can at least be distributed 
in our non-free area, I would like to know if GO is available under other 
terms of use or licenses, that allow redistributing GO files.

Lastly, have you considered distributing GO under less restrictive terms, to 
ease its use in Free software projects ?

Best regards,

-- 
Charles Plessy
Debian Med team
http://www.debian.org/devel/debian-med


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694908: Contains non-free data

[Charles Plessy]

Package: emboss
Version: 6.4.0-4
Severity: serious

As discussed in the following message, EMBOSS contains non-free data.

  https://lists.debian.org/20120918045219.ga26...@falafel.plessy.net

We need to consider short- and long-term solutions to this problem.  For the
short-term solution, I think that I will not have time to split free and
non-free parts of EMBOSS, so we need again to consider to move it altogether to
non-free.  In contrary to the UniProt files which were in the test suite, the
Gene Ontology files are needed by EMBOSS to run some of its programs.

For the long-term solution, does anybody here have good contacts with the Gene
Ontology community, and would have chances to advocate for a relicensing ?

Have a nice Sunday,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681654: #681654 kstars-data-extra-tycho2: undistributable

[Charles Plessy]

 On Miércoles, 14 de noviembre de 2012 17:35:44 Timo Juhani Lindfors wrote:
  
  if
  
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681654#52
  
  is correct and the issue is commercial use (and not nondistributability)
  how about just moving kstars-data-extra-tycho2 to non-free instead of
  having this bug delay wheezy release? You can always reintroduce it back
  to main if the issue is solved.

Le Wed, Nov 14, 2012 at 05:44:42PM +, Noel David Torres Taño a écrit :
 I agree, iff debian-legal agrees so

Hello everybody,

Here is the statement in 681654#52

  Catalogues available at CDS contain scientific data distributed
  for free, for a scientific usage.
  Companies including such data in their commercial products cannot
  charge their clients for the data. Furthermore, users must be informed
  of the origin of the data: this means an explicit reference to the service
  provided by the CDS and also to the original author(s) of each catalogue.

For me, it looks reminescent of the SIL Open Font License, which
states:

  The OFL allows the licensed fonts to be used, studied, modified and
  redistributed freely as long as they are not sold by themselves.

If one considers that in the statement in 681654#52, cannot charge for the
data means the same as not sold by themselves in the OFL, then it would be
consistent to keep kstars-data-extra-tycho2 in Debian, as SIL-OFL-licensed
works are allowed.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692946: cdd-dev: copyright file missing after upgrade (policy 12.5)

[Charles Plessy]

Le Sun, Nov 11, 2012 at 02:57:45PM +0100, Andreas Tille a écrit :
 
 it is true that /usr/share/doc/cdd-dev does not contain a copyright file
 because it is simply a symlink to /usr/share/doc/blends-dev and the
 transitional (=empty) package cdd-dev depends from blends-dev.  So while
 the report is correct I would consider an upload at current time simply
 causing work for several people just to follow some rules with no profit
 for anybody.  I'd suggest to lower the priority of the bug and leave the
 package as is.
 
 What do you think?

Hi Andreas,

if /usr/share/doc/cdd-dev were a symlink to /usr/share/doc/blends-dev,
then piuparts would have found the copyright file.

I think that what piuparts seems to have found, is that when upgrading
from lenny to squeeze to wheezy, /usr/share/doc/cdd-dev does
not become a symlink :

MISSING COPYRIGHT FILE: /usr/share/doc/cdd-dev/copyright
drwxr-xr-x 2 root root 40 Nov 10 07:33 /usr/share/doc/cdd-dev
total 0
drwxr-xr-x   2 root root   40 Nov 10 07:33 .
drwxr-xr-x 126 root root 2660 Nov 10 07:35 ..

This really looks like an empty directory.

I would agree to downgrade the bug (cdd-dev is transitional and native,
there is anyway not copyrighted work to look for in this package),
but is the breakage limited to /usr/share/doc/cdd-dev/ ?

Cheers,

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


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691900: [pkg-eucalyptus-maintainers] Bug#691900: gwt: CVE-2012-4563

[Charles Plessy]

Le Fri, Nov 02, 2012 at 07:43:19AM +0100, Thomas Koch a écrit :
 Charles Plessy:
  
  In particular I do not know if the best resolution for this bug is to
  upgrade to 2.5.0 or to patch, so I am reluctant to take action by myself,
  worrying that I might complicate your work on Gerrit.
 
 Hi Charles,
 
 thank you for pinging me. I've just spend three days on Debian work. Could 
 you 
 deal with it by updating to 2.5.0 and also set the maintainer to the java 
 packaging team?

Hi Thomas,

I have updated the source package to 2.5.0 (checked copyrights, refreshed the
patches), but unfortunately it does not build.  I suppose that some ground work
is needed on the Java side, but I am not able to do it.

I committed all my changes to the Git repository.

Cheers,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691900: [pkg-eucalyptus-maintainers] Bug#691900: gwt: CVE-2012-4563

[Charles Plessy]

Le Wed, Oct 31, 2012 at 07:47:07AM +0100, Moritz Muehlenhoff a écrit :
 Package: gwt
 Severity: grave
 Tags: security
 Justification: user security hole
 
 Please see 
 https://developers.google.com/web-toolkit/release-notes#Release_Notes_2_4_0
 under Security vulnerability in GWT 2.4.
 
 This was assigned CVE-2012-4563

Dear Thomas and Java team

In http://bugs.debian.org/684453, you have suggested to transfer the gwt
package under the debian-java umbrella.  We agreed, and action was delayed by a
technical problem on the Dpkg side.

It is a bit embarassing to ping you with a grave bug, but if you would like to
take over the package, this is the good moment...

In particular I do not know if the best resolution for this bug is to upgrade
to 2.5.0 or to patch, so I am reluctant to take action by myself, worrying that
I might complicate your work on Gerrit.

Please let me know if I can help,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691900: [pkg-eucalyptus-maintainers] Bug#691900: gwt: CVE-2012-4563

[Charles Plessy]

Le Wed, Oct 31, 2012 at 07:47:07AM +0100, Moritz Muehlenhoff a écrit :
 Package: gwt
 Severity: grave
 Tags: security
 Justification: user security hole
 
 Please see 
 https://developers.google.com/web-toolkit/release-notes#Release_Notes_2_4_0
 under Security vulnerability in GWT 2.4.

Hi all,

is there a volunteer to step in ?  Otherwise, can I try to solve that bug
by upgrading to 2.5.0 ?

Cheers,

-- 
Charles


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688630: Bug#688630: t-coffee-doc: empty package

[Charles Plessy]

severity 688630 normal
thanks

Dear Release team,

the t-coffee-doc package in Wheezy and Sid is empty, as Upstream removed
documentation from the source package without us noticing.

The work on t-coffee continued in our VCS since the freeze, and we already
accumulated some other changes not related to the release.

I propose to either ignore the emptiness of t-coffee-doc, or to make an upload
to testing-proposed-updates, where the t-coffee-doc package would be discarded.

Please let us know if you would like this to happen.

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688630: [Debian-med-packaging] Bug#688630: t-coffee-doc: empty package

[Charles Plessy]

Le Mon, Sep 24, 2012 at 08:40:12PM +0900, Charles Plessy a écrit :
 
 Le Mon, Sep 24, 2012 at 11:57:54AM +0200, Vincent Fourmond a écrit :
  
t-coffee-doc is empty:
 
 the problem is that it is empty upstream as well.
 
 Would you like to ask Upstream to add it back ?  Otherwise, I will need
 to copy it from http://www.tcoffee.org/Projects/tcoffee/#DOCUMENTATION
 (assuming that the MS-Word documents are the source).

Bonjour Vincent,

in the absence of answer from Upstream, I propose to remove the tcoffe-doc
altogether.  For a long term solution, one could propose Upstream to convert
the T-COFFEE manual from the MS-Word format to DocBook or another markup
language, for instance under the umbrella of the Open Bioinformatics Fundation
if it participates to the Google Code-in or the Google Doc Sprint.

Bon dimanche,

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


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689951: Package appears to be non-free

[Charles Plessy]

Le Mon, Oct 08, 2012 at 11:56:52AM +0200, Mathieu Malaterre a écrit :
 Package: camitk
 Severity: serious
 Tags: upstream
 Justification: Policy 2.1
 
 The camitk source code contains tetgen. Which is non-free license:
 
 $ cat ./actions/mesh/meshprocessing/tetgen1.4.3/LICENSE 
 ...
 Distribution of  modified  versions  of this code is permissible UNDER
 THE CONDITION THAT  THIS CODE AND ANY MODIFICATIONS  MADE TO IT IN THE
 SAME SOURCE FILES  tetgen.h AND tetgen.cxx  REMAIN UNDER  COPYRIGHT OF
 THE  ORIGINAL AUTHOR,  BOTH  SOURCE AND OBJECT  CODE  ARE MADE  FREELY
 AVAILABLE  WITHOUT   CHARGE,   AND  CLEAR   NOTICE  IS  GIVEN  OF  THE 
 MODIFICATIONS.
 ...

Bonjour Mathieu,

the above clause would require a copyright transfer, which is not directly
mentionned.

Perhaps it is worth asking the author of tetgen if he just clumsily wanted to
require that his copyright notice must not be removed ?

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689951: Package appears to be non-free

[Charles Plessy]

Le Mon, Oct 08, 2012 at 12:12:35PM +0200, Mathieu Malaterre a écrit :
 
 Actually all I did noticed is that tetgen is in non-free in debian already:
 http://packages.qa.debian.org/t/tetgen.html

Ah, nevermind, the next clause is non-free as well, and the next-next answers
my first question.

  Distribution of this code for  any  commercial purpose  is permissible
  ONLY BY DIRECT ARRANGEMENT WITH THE COPYRIGHT OWNER.
  
  The  above  copyright  notice  and  this permission  notice  shall  be
  included in all copies or substantial portions of the Software.

Cheers,

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


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#645487: [Debian-med-packaging] Bug#645487: Bug#645487: ensembl: includes GPL code without source

[Charles Plessy]

Le Mon, Sep 24, 2012 at 01:01:44PM +0900, Charles Plessy a écrit :
 Le Sun, Sep 23, 2012 at 07:00:23PM -0700, Jonathan Nieder a écrit :
  
  This seems to be fixed in the packaging repo.  What is left to do
  before the updated package is uploaded?  Would you be terribly
  offended if I requested removal of the current package in the
  meantime, so we could continue to set a good example by not asking
  mirrors to violate the GPL?
 
 Hi all,
 
 I can upload if needed.

Ping.

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


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688630: [Debian-med-packaging] Bug#688630: t-coffee-doc: empty package

[Charles Plessy]

found 688630 9.02.r1228-1
thanks

Le Mon, Sep 24, 2012 at 11:57:54AM +0200, Vincent Fourmond a écrit :
 
   t-coffee-doc is empty:

Bonjour Vincent,

the problem is that it is empty upstream as well.

Would you like to ask Upstream to add it back ?  Otherwise, I will need
to copy it from http://www.tcoffee.org/Projects/tcoffee/#DOCUMENTATION
(assuming that the MS-Word documents are the source).

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#645487: [Debian-med-packaging] Bug#645487: ensembl: includes GPL code without source

[Charles Plessy]

Le Sun, Sep 23, 2012 at 07:00:23PM -0700, Jonathan Nieder a écrit :
 
 This seems to be fixed in the packaging repo.  What is left to do
 before the updated package is uploaded?  Would you be terribly
 offended if I requested removal of the current package in the
 meantime, so we could continue to set a good example by not asking
 mirrors to violate the GPL?

Hi all,

I can upload if needed.

Cheers

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


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670945: [php-maint] Bug#670945: About the media types text/x-php and text/x-php-source

[Charles Plessy]

Dear Ondřej and everybody,

I would like to keep separate the two following issues.

 1) Whether or not to give a private media type to PHP files in Debian, and
if yes, which one.

 2) Provide a smooth upgrade to our users who use Apache's mod_negociation in a 
way
that is different to what is recommended in PHP (where the FAQ suggests to 
associate
the media type text/html to .php files).

http://www.php.net/manual/en/faq.installation.php#faq.installation.apache.multiviews

Point 2) can be solved by adding two lines (plus explanatory comments) in 
/etc/apache2/mods-available/php5.conf (http://bugs.debian.org/670945#26).

Ondřej, I would appreciate if you solved #670945 this way.  I understand that it
puts the work burden on your shoulders and that php5 is a much heavier package
than mime-support, but I think that it is the cleanest solution.  For the moment
I have not received any message saying that a media type needs to be provided by
mime-support in order for PHP to work in other contexts.

To everybody:

we are periodically reminded that the core teams in Debian are dramatically 
understaffed.
Given the number of Debian systems serving content to the world using PHP, 
please consider
that the PHP maintainers team is one of them.  They need your help !  The time 
you will
give will directly help Debian to stay among the top distributions.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org