Re: Any hints about maven libs from Debian Java team (Was: IGV update - any takers?)
Am 14.11.19 um 14:28 schrieb Olivier Sallou: [...] >> Try to disable the build-dependency and analyze how much code is >> depending on it. Maybe it is not necessary to get a functional IGV >> package, otherwise someone ™ must package it. > > > the pb is to know what is "functional". We may patch code to remove deps > and see the final GUI but would not work for everythings And we > do not know software enough to validate it in such case You have to determine what is essential for IGV and what is rather optional. In some cases there are features which are rarely required for most uses cases or where you have just one or two classes that depend on a specific build-dependency. Then it is often sensible to patch the code instead of starting to package yet another project. [...] >> That sounds like some cloud dependency. Do you really need it? > > Amazon sdk for storage indeed. Do we need it ? Well it is part of code. > Removing it, again, would imply to also remove references in menu etc... > (or wherever is used). > > Lots of work to remove features, or more difficult to maintain afterward. It's your call. Whatever is easier for you. It always boils down to packaging a new (build-)dependency or patching the code. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#944735: RM: rapmap [arm64 mips64el ppc64el] -- ANAIS; non-amd64 not supported by upstream
Package: ftp.debian.org Severity: normal Thanks!
Re: Any hints about maven libs from Debian Java team (Was: IGV update - any takers?)
On 11/14/19 2:10 PM, Markus Koschany wrote: > Hi, > > Am 14.11.19 um 09:44 schrieb Andreas Tille: >> Hi, >> >> I'd be very happy if Debian Java team could comment on the analysis >> of libs done by Olivier to enable us upgrading IGV. >> >> On Thu, Nov 14, 2019 at 09:34:51AM +0100, Olivier Sallou wrote: >>> I had a quick look at latest version. It seems to be have been rewritten >>> a lot, a lots of dependency differences. >>> >>> Several java (maven) libs are not available in debian or older (may work >>> or not): >>> >>> >>> Not available [group: 'org.campagnelab.goby', name: 'goby-io', >>> version: '3.3.1'] >>> Not available [group: 'org.campagnelab.icb', name: 'icb-utils', >>> version: '2.0.2'] > Try to disable the build-dependency and analyze how much code is > depending on it. Maybe it is not necessary to get a functional IGV > package, otherwise someone ™ must package it. the pb is to know what is "functional". We may patch code to remove deps and see the final GUI but would not work for everythings And we do not know software enough to validate it in such case > >>> older version in debian (libjsap-java) [group: >>> 'org.campagnelab.ext', name: 'jsap', version: '3.0.0'] >>> >>> older version in debian (libnb-absolutelayout-java) [group: >>> 'org.netbeans.external', name: 'AbsoluteLayout', version: 'RELEASE110'] > I believe the current version of libnb-absolutelayout-java should just > work, if not let me know, upgrading the package should be doable. > libjsap-java hasn't been updated for three years now. The older version > could still work, if not, the same applies as for org.campagnelab.* > > >>> Not available [group: 'software.amazon.awssdk', name: >>> 'http-client-spi', version: '2.8.5'], >>> Not available [group: 'software.amazon.awssdk', name: >>> 'cognitoidentity', version: '2.8.5'], >>> Not available [group: 'software.amazon.awssdk', name: 'sts', >>> version: '2.8.5'], >>> Not available [group: 'software.amazon.awssdk', name: 's3', >>> version: '2.8.5'] > That sounds like some cloud dependency. Do you really need it? Amazon sdk for storage indeed. Do we need it ? Well it is part of code. Removing it, again, would imply to also remove references in menu etc... (or wherever is used). Lots of work to remove features, or more difficult to maintain afterward. > > Regards, > > Markus > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Re: Any hints about maven libs from Debian Java team (Was: IGV update - any takers?)
Hi, Am 14.11.19 um 09:44 schrieb Andreas Tille: > Hi, > > I'd be very happy if Debian Java team could comment on the analysis > of libs done by Olivier to enable us upgrading IGV. > > On Thu, Nov 14, 2019 at 09:34:51AM +0100, Olivier Sallou wrote: >> >> I had a quick look at latest version. It seems to be have been rewritten >> a lot, a lots of dependency differences. >> >> Several java (maven) libs are not available in debian or older (may work >> or not): >> >> >> Not available [group: 'org.campagnelab.goby', name: 'goby-io', >> version: '3.3.1'] >> Not available [group: 'org.campagnelab.icb', name: 'icb-utils', >> version: '2.0.2'] Try to disable the build-dependency and analyze how much code is depending on it. Maybe it is not necessary to get a functional IGV package, otherwise someone ™ must package it. >> >> older version in debian (libjsap-java) [group: >> 'org.campagnelab.ext', name: 'jsap', version: '3.0.0'] >> >> older version in debian (libnb-absolutelayout-java) [group: >> 'org.netbeans.external', name: 'AbsoluteLayout', version: 'RELEASE110'] I believe the current version of libnb-absolutelayout-java should just work, if not let me know, upgrading the package should be doable. libjsap-java hasn't been updated for three years now. The older version could still work, if not, the same applies as for org.campagnelab.* >> Not available [group: 'software.amazon.awssdk', name: >> 'http-client-spi', version: '2.8.5'], >> Not available [group: 'software.amazon.awssdk', name: >> 'cognitoidentity', version: '2.8.5'], >> Not available [group: 'software.amazon.awssdk', name: 'sts', >> version: '2.8.5'], >> Not available [group: 'software.amazon.awssdk', name: 's3', >> version: '2.8.5'] That sounds like some cloud dependency. Do you really need it? Regards, Markus signature.asc Description: OpenPGP digital signature
Any hints about maven libs from Debian Java team (Was: IGV update - any takers?)
Hi, I'd be very happy if Debian Java team could comment on the analysis of libs done by Olivier to enable us upgrading IGV. On Thu, Nov 14, 2019 at 09:34:51AM +0100, Olivier Sallou wrote: > > I had a quick look at latest version. It seems to be have been rewritten > a lot, a lots of dependency differences. > > Several java (maven) libs are not available in debian or older (may work > or not): > > > Not available [group: 'org.campagnelab.goby', name: 'goby-io', > version: '3.3.1'] > Not available [group: 'org.campagnelab.icb', name: 'icb-utils', > version: '2.0.2'] > > older version in debian (libjsap-java) [group: > 'org.campagnelab.ext', name: 'jsap', version: '3.0.0'] > > older version in debian (libnb-absolutelayout-java) [group: > 'org.netbeans.external', name: 'AbsoluteLayout', version: 'RELEASE110'] > > Not available [group: 'software.amazon.awssdk', name: > 'http-client-spi', version: '2.8.5'], > Not available [group: 'software.amazon.awssdk', name: > 'cognitoidentity', version: '2.8.5'], > Not available [group: 'software.amazon.awssdk', name: 'sts', > version: '2.8.5'], > Not available [group: 'software.amazon.awssdk', name: 's3', > version: '2.8.5'] > > > Olivier -- http://fam-tille.de
Re: IGV update - any takers?
On 11/13/19 1:42 PM, Steffen Möller wrote: > Hello, > > One of the packages that Debian should really shine with is IGV - it is > used throughout the world to inspect RNAseq data. And the ones running > IGV are not the ones who ran the analysis, so there should be tons of > folks out there using it who are not already installing conda in > routine. Admittedly, those will mostly be Windows/MacOS users, but hey, > also some Debianers. Popcon only lists one installation. Something must > be wrong. We are a bit behind with its version (2.4) with 2.7 being the > latest, but also conda only has 2.5 to offer, so that is likely not the > reason. I had a quick look at latest version. It seems to be have been rewritten a lot, a lots of dependency differences. Several java (maven) libs are not available in debian or older (may work or not): Not available [group: 'org.campagnelab.goby', name: 'goby-io', version: '3.3.1'] Not available [group: 'org.campagnelab.icb', name: 'icb-utils', version: '2.0.2'] older version in debian (libjsap-java) [group: 'org.campagnelab.ext', name: 'jsap', version: '3.0.0'] older version in debian (libnb-absolutelayout-java) [group: 'org.netbeans.external', name: 'AbsoluteLayout', version: 'RELEASE110'] Not available [group: 'software.amazon.awssdk', name: 'http-client-spi', version: '2.8.5'], Not available [group: 'software.amazon.awssdk', name: 'cognitoidentity', version: '2.8.5'], Not available [group: 'software.amazon.awssdk', name: 'sts', version: '2.8.5'], Not available [group: 'software.amazon.awssdk', name: 's3', version: '2.8.5'] Olivier > > I just found it to be in conflict with R libraries I had on my system > because of dependencies on different versions of libhdf-dev - somewhat > unexpected. The changelog found Sascha, Andreas and Olivier as past > active maintainers. Do you have further insights for me? And - is IGV a > reasonable package to be backported? > > Regards, > Steffen > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: How to be with SINA that has non-free dependency
Hi again,
I wonder whether you understood that we are waiting for some signal of
yours whether the attempt to package libarb works with sina. So far we
are running into trouble and I'm just waiting for your input how to get
sina build with libarb. Further work on the libarb package is stalled
until you will answer the mail below.
Kind regards
Andreas.
On Wed, Jul 31, 2019 at 02:25:36PM +0200, Andreas Tille wrote:
> Ping again.
> I do not see any sense to continue with libarb packaging as long
> as there is no way to build sina smoothly with what we have.
>
> So can you please comment (in public on list) about the issue
>
> /usr/bin/ld: src/sina.o: undefined reference to symbol
> '_ZN5boost15program_options29options_description_easy_initclEPKcS3_'
>
> /usr/bin/ld: //usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0:
> error adding symbols: DSO missing from command line
>
> Kind regards
>Andreas.
>
> On Wed, Jul 10, 2019 at 10:25:54PM +0200, Andreas Tille wrote:
> > Ping?
> >
> > On Thu, Jun 20, 2019 at 10:19:34PM +0200, Andreas Tille wrote:
> > > Hi Elmar,
> > >
> > > On Thu, Jun 20, 2019 at 10:41:10AM -0600, Elmar Pruesse wrote:
> > > > > > > make lib/arb_tcp.dat
> > > > > > This target does not exist.
> > > >
> > > > Just
> > > >
> > > > cp $SRCDIR/lib/arb_tcp_org.dat $DESTDIR/.../lib/arb_tcp.dat
> > > >
> > > > The Makefile in lib/ just does a cp as well. No processsing.
> > >
> > > Sure. My point was that before I repackaged the libarb tarball not even
> > > lib/arb_tcp_org.dat was included. But now I changed the Files-Excluded
> > > rules and its now not removed any more. So that's a solved problem.
> > >
> > > > Alternatively, just put this data into the file:
> > > >
> > > >
> > > >
> > > >
> > > > ARB_TCP_DAT_VERSION 2
> > > > ARB_DB_SERVER :/tmp/arb_db_$(USER)_$(ARB_PID)
> > > > ARB_NAME_SERVER localhost:3020 arb_name_server
> > > > -d$(ARBHOME)/lib/nas/names.dat
> > > > ARB_NAME_SERVER_START localhost:3021 arb_name_server
> > > > -d$(ARBHOME)/lib/nas/names_start.dat -fstart=1
> > > >
> > > > ARB_PT_SERVER0 :$(HOME)/.arb_pts/$(USER)1.socket arb_pt_server
> > > >
> > > > -D$(HOME)/.arb_pts/$(USER)1.arb
> > > >
> > > > ARB_PT_SERVER1 :$(HOME)/.arb_pts/$(USER)1.socket arb_pt_server
> > > > -D$(HOME)/.arb_pts/$(USER)2.arb
> > > >
> > > > ARB_PT_SERVER2 :$(HOME)/.arb_pts/$(USER)1.socket arb_pt_server
> > > > -D$(HOME)/.arb_pts/$(USER)3.arb
> > > >
> > >
> > > I'll keep this hint in Debian Med mailing list archive in case there
> > > will be issues with the license from ARB upstream.
> > >
> > > > > > > arb-pt-server.install:
> > > > > > >
> > > > > > > bin/arb_pt_server usr/bin
> > > > > > >
> > > > > > > lib/arb_tcp.dat /etc/arb
> > > > > > >
> > > > > > >
> > > > > > > arb-pt-server.links:
> > > > > > >
> > > > > > > etc/arb/arb_tcp.dat usr/lib/${DEB_HOST_MULTIARCH}/arb
> > > > > > Do you think this link is only needed inside the arb-pt-server
> > > > > > package
> > > > > > or is it better in libarb package? (I implemented the latter in the
> > > > > > latest packages.)
> > > >
> > > > It is needed for arb_pt_server and arb_name_server. It is parsed by
> > > > libARBDB
> > > > and the stuff in SERVERCONTROL. Could go in either.
> > >
> > > OK, may be I'll leave it in libarb.
> > >
> > > > Since I'd prefer as much as possible tests I added the package.
> > > > > > Regarding SINA packaging: Do you think a Recommends: arb-pt-server
> > > > > > or a
> > > > > > Suggests would be appropriate?
> > > >
> > > > Yes, sounds good. Either will do. Guess 'suggests' is enough. Mostly,
> > > > you'd
> > > > want it constrained to the right version if it does get installed by the
> > > > user.
> > >
> > > I added it as Suggests. What would be the "right version"?
> > > (Feel free to commit what you consider correct - that's probably faster
> > > than
> > > you explain here in detail and I do it according to your advise.)
> > >
> > > > > > when using the Debian packaged spdlog (version 1.3.1). In the
> > > > > > packaging
> > > > > > we have removed the spdlog code copy (as per Debian policy) and try
> > > > > > to
> > > > > > link against the Debian packaged version. In several other projects
> > > > > > I
> > > > > > realised problems with this approach and it seems spdlog is a moving
> > > > > > target. Do you think you can adapt SINA to latest spdlog or should
> > > > > > we
> > > > > > rather stick to the code copy?
> > > >
> > > > Use the vendored one if that is permissible. I have patched it to
> > > > include a
> > > > progress monitor, but the patch was rejected upstream. See
> > > > https://github.com/gabime/spdlog/issues/1030#issuecomment-499979592. I
> > > > will
> > > > have to turn it into a separate package. Problem is that I would
> > > > want/need
>
