Orthanc and all its plugins are getting removed from testing

2020-08-09 Thread Sébastien Jodogne
Dear all,

Because of the bug #966655 [1], and because of the fact that
orthanc-1.7.2+dfsg-2 is pending in the NEW queue [2], I cannot commit
the fix regarding the missing build dependency on tzdata until the NEW
packages get accepted.

But, as #966655 is tagged as serious, the entire Orthanc ecosystem was
removed from Debian testing during this week-end.

Is there anything I can do to prevent this?

Many thanks in advance for your help,
Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966655
[2]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-July/082973.html



Re: fix for #966470: biobambam2 autopkgtest failures

2020-08-09 Thread Étienne Mollier
Hi Steffen,

Steffen Möller, on 2020-08-09 21:44:23 +0200:
> On 09.08.20 18:23, Étienne Mollier wrote:
> > Steffen Möller, on 2020-08-08 23:41:18 +0200:
> >> Sidenote: How is your Debian Maintainership doing?
> > Since the question as been raised during last Friday's
> > videoconference meeting, I contacted a DD in my city yesterday.
> > I'll see what are his availabilities, if he is available.  Since
> > it's vacation time these days, he may not be around.
> 
> You may then also have discussed that thread (on -devel?) started by
> Enrico Zini iirc about avoiding f2f key signing during these (should-be)
> lockdown-times.
> 
> https://lists.debian.org/debian-project/2020/08/msg0.html
> 
> Since we have met per video already ... I tend to think that it would be
> fine. Over here we are asking those who return from vacation to stay in
> quarantine, so - I think there may be a way around you meeting up locally.

Ouch, no I missed it.  Thank you for the pointers; I believe
that there are still several lists I've yet to subscribe.
Thanks also for the overall status on the covid-19 situation;
asking to see a DD in person does not sound responsible at all.
I suppose that meeting should be postponed for better days.

> Andreas, Michael, Alex, ...?

Take care
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature


Re: libgclib - symbol file - please kindly educate me

2020-08-09 Thread Alex Mestiashvili

Hi Steffen,

I've pushed the new version of symbols file to the repository.
As far as I see in the new version of libgclib the 3 symbols ( the ones 
in the diff you provided) are removed. This is quite bad and probably it 
makes sense to discuss that with upstream, since software using these 
symbols will be broken.
Luckily none of the reverse deps of libgclib in Debian are using the 
removed symbols.


Best regards,
Ale

On 8/9/20 4:33 PM, Steffen Möller wrote:

Hi Alex, hi Andreas,

This is what I get when I remove the -1

make[1]: Leaving directory '.../med-team/libgclib'
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_dwz -a
   dh_strip -a
   dh_makeshlibs -a
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libgclib2/DEBIAN/symbols doesn't match
completely debian/libgclib2.symbols
--- debian/libgclib2.symbols (libgclib2_0.11.10-1_amd64)
+++ dpkg-gensymbolsGWl6pJ   2020-08-09 14:16:35.796448318 +0200
@@ -25,7 +25,7 @@
  _Z10g2bit2baseh@Base 0.11.4
  _Z10gcdb_allocj@Base 0.11.4
  _Z10getFileExtPKc@Base 0.11.4
- _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10
+#MISSING: 0.11.10-1# _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10
  _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10
  _Z10parseFloatRPcRf@Base 0.11.4
  _Z10replaceStrRPcS_@Base 0.11.4
@@ -79,13 +79,13 @@
  _Z14gfo_cmpRefByIDPvS_@Base 0.11.4
  _Z14translateCodonPKc@Base 0.11.4
  _Z15printEditScriptP12GXEditScript@Base 0.11.4
- _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10
+#MISSING: 0.11.10-1# _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10
  _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10
  _Z15uint32_pack_bigPcj@Base 0.11.4
  _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4
  _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4
  _Z16gthreads_errExitiPKc@Base 0.11.4
- _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10
+#MISSING: 0.11.10-1# _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10
  _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10
  _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4
  _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base
0.11.4
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:13: binary] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2

?

Steffen

On 09.08.20 07:00, Andreas Tille wrote:

Hi Steffen,

the patch you get from dh_makeshlibs needs to be edited.  You simply

 sed -i 's/-1$//' debian/libgclib2.symbols

should do the trick.

Hope this helps

   Andreas.

On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote:

Hello,

to get the build process to first not fail and then be quiet, I changed
the .symbols file as follows:

diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols
index 6bef43a..aef012c 100644
--- a/debian/libgclib2.symbols
+++ b/debian/libgclib2.symbols
@@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER#
  _Z10g2bit2baseh@Base 0.11.4
  _Z10gcdb_allocj@Base 0.11.4
  _Z10getFileExtPKc@Base 0.11.4
- _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4
+ _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1
+ _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1
  _Z10parseFloatRPcRf@Base 0.11.4
  _Z10replaceStrRPcS_@Base 0.11.4
  _Z10startsWithPKcS0_@Base 0.11.4
@@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER#
  _Z14gfo_cmpRefByIDPvS_@Base 0.11.4
  _Z14translateCodonPKc@Base 0.11.4
  _Z15printEditScriptP12GXEditScript@Base 0.11.4
- _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4
+ _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1
+ _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
  _Z15uint32_pack_bigPcj@Base 0.11.4
  _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4
  _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4
  _Z16gthreads_errExitiPKc@Base 0.11.4
- _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4
+ _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1
+ _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1
+ _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
  _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4
  _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base
0.11.4
  _Z17gcvt_endian_setupv@Base 0.11.4

I have no idea why there is now a -1 attached to the version. I just
know that it does not work without it.

Can I upload as is?

Best,

Steffen








Re: fix for #966470: biobambam2 autopkgtest failures

2020-08-09 Thread Steffen Möller
Hi Étienne,

On 09.08.20 18:23, Étienne Mollier wrote:
> Steffen Möller, on 2020-08-08 23:41:18 +0200:
>> Local build initiated.
> Thanks for the upload, although, if I read my emails properly,
> you've been beaten by Andreas at it.
Yup.
> I received a message from
> him some time before about missing git tags in side branches
> (again), so should have warned about it.  Sorry if there was
> some duplicate work.
>
>> Sidenote: How is your Debian Maintainership doing?
> Since the question as been raised during last Friday's
> videoconference meeting, I contacted a DD in my city yesterday.
> I'll see what are his availabilities, if he is available.  Since
> it's vacation time these days, he may not be around.

You may then also have discussed that thread (on -devel?) started by
Enrico Zini iirc about avoiding f2f key signing during these (should-be)
lockdown-times.

https://lists.debian.org/debian-project/2020/08/msg0.html

Since we have met per video already ... I tend to think that it would be
fine. Over here we are asking those who return from vacation to stay in
quarantine, so - I think there may be a way around you meeting up locally.

Andreas, Michael, Alex, ...?

Steffen



Re: RFS: Bug#957360: insighttoolkit4: ftbfs with GCC-10

2020-08-09 Thread Étienne Mollier
Hi Steven,

Steven Robbins, on 2020-08-08 17:25:05 -0500:
> On Saturday, August 8, 2020 4:34:39 P.M. CDT Étienne Mollier wrote:
> > > 2. I wonder whether some of the older patches (dating from 2016) should be
> > > dropped; in particular:
> > > 
> > > atomic_load.patch
> > 
> > I'm missing context, and the issue tracker pointed to by the URL
> > in the header does not seem to have migrated to the current
> > platform unfortunately.  :/
> 
> I managed to find it here: https://insightsoftwareconsortium.atlassian.net/
> browse/ITK-3413
> 
> But that doesn't shed a lot of light.  The only thing I see relevant is "Make 
> the Load operation truly atomic - doesn't change anything on amd64 or i386, 
> but it may be of interest for other archs. "   However, the patch removes one 
> usage of __sync_synchronize, but leaves another in the Store() function, 
> which 
> seems suspect.  I would believe that there may have been a bug in the x86 
> codegen in 2016, but we've got 4 years of compiler fixes since then, so I am 
> of 
> the opinion to remove this on that basis.  And the basis that upstream ITK 
> has 
> not incorporated this change in 4 years.

Okay, I guess this might be removed then.

> > > itk4.10.0-python-wrapping.patch
> > 
> > I have the impression that this second one is needed to avoid
> > use of included third party libraries and use the one provided
> > by Debian.
> 
> You must be looking at a different patch.

Indeed I erroneously had a look at the nifti patch; let's say
that it was late in my TZ.  :)

> This one is:
> 
> --- a/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap
> +++ b/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap
> @@ -8,6 +8,7 @@
>foreach(d ${ITK_WRAP_IMAGE_DIMS})
>  foreach(t ${to_types})
>itk_wrap_template("${ITKM_VI${t}${d}}${ITKM_VI${t}${d}}" "${ITKT_VI${t}
> ${d}},${ITKT_VI${t}${d}}")
> +  itk_wrap_template("${ITKM_I${t}${d}}${ITKM_I${t}${d}}" "${ITKT_I${t}$
> {d}},${ITKT_I${t}${d}}")
>  endforeach()
>endforeach()
>  
> I don't see any motivation to adding the extra wrapping.  This patch was 
> added 
> in 2016, along with itk4.10.0_itkTriangleHelper.h.patch (since removed) to 
> fix 
> a build failure on amd64 (see #835761).  The bug traces to ITK issue https://
> insightsoftwareconsortium.atlassian.net/browse/ITK-3466 which was said to be 
> addressed in 4.10.1 with this commit: https://github.com/
> InsightSoftwareConsortium/ITK/commit/be1e9f88ff036048148d4b8b887b8671739307d4
> This commit amounts to the content of the former 
> itk4.10.0_itkTriangleHelper.h.patch.  
> 
> I have run the build with this patch removed to no noticable effect -- only 
> test failure remains Test #2625: PythonExtras.
> 
> This seems safe to remove.

Agreed, assuming upstream fixed the corresponding issue somehow.

> > > itk4.12.0-resource_cprobe.patch
> > 
> > This last one seems needed for i386 support, but might require
> > to check how behaves the targeted equipment before drop.  Maybe
> > I can attempt a build without the patch on my i386 alarm clock.
> 
> I ran the build with this patch removed to no noticable effect -- only test 
> failure remains Test #2625: PythonExtras.  But this was amd64.  I'll do it 
> again on x86 before comitting the removal.

I triggered a build on i386 without those patches, will see how
it goes.  I'm doing it on real hardware, so it smells like it
will take quite a long time, hope it won't melt with these days'
heat.

About the Test #2625: PythonExtras, I failed to reproduce any
issue at build time.  Actually I see no such test there, as if
something might have been missing on my side.  I triggered an
autopkgtest, in case I haven't been looking at the proper
location.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature


Re: fix for #966470: biobambam2 autopkgtest failures

2020-08-09 Thread Étienne Mollier
Hi Steffen,

Steffen Möller, on 2020-08-08 23:41:18 +0200:
> Local build initiated.

Thanks for the upload, although, if I read my emails properly,
you've been beaten by Andreas at it.  I received a message from
him some time before about missing git tags in side branches
(again), so should have warned about it.  Sorry if there was
some duplicate work.

> Sidenote: How is your Debian Maintainership doing?

Since the question as been raised during last Friday's
videoconference meeting, I contacted a DD in my city yesterday.
I'll see what are his availabilities, if he is available.  Since
it's vacation time these days, he may not be around.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature


[RFS] wtdbg2

2020-08-09 Thread Nilesh Patra
Hi,
I've added autopkgtests for wtdbg2,
since this uses extra data which blows up in size, I created a new binary
for the same.
Hence, this needs to go through the NEW queue.
My changes are pushed to the team-repo here[1].
Needs review and sponsorship.

[1]: https://salsa.debian.org/med-team/wtdbg2

Thanks and regards
Nilesh


Re: libgclib - symbol file - please kindly educate me

2020-08-09 Thread Steffen Möller
Hi Alex, hi Andreas,

This is what I get when I remove the -1

make[1]: Leaving directory '.../med-team/libgclib'
  dh_perl
  dh_link
  dh_strip_nondeterminism
  dh_compress
  dh_fixperms
  dh_missing
  dh_dwz -a
  dh_strip -a
  dh_makeshlibs -a
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libgclib2/DEBIAN/symbols doesn't match
completely debian/libgclib2.symbols
--- debian/libgclib2.symbols (libgclib2_0.11.10-1_amd64)
+++ dpkg-gensymbolsGWl6pJ   2020-08-09 14:16:35.796448318 +0200
@@ -25,7 +25,7 @@
 _Z10g2bit2baseh@Base 0.11.4
 _Z10gcdb_allocj@Base 0.11.4
 _Z10getFileExtPKc@Base 0.11.4
- _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10
+#MISSING: 0.11.10-1# _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10
 _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10
 _Z10parseFloatRPcRf@Base 0.11.4
 _Z10replaceStrRPcS_@Base 0.11.4
@@ -79,13 +79,13 @@
 _Z14gfo_cmpRefByIDPvS_@Base 0.11.4
 _Z14translateCodonPKc@Base 0.11.4
 _Z15printEditScriptP12GXEditScript@Base 0.11.4
- _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10
+#MISSING: 0.11.10-1# _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10
 _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10
 _Z15uint32_pack_bigPcj@Base 0.11.4
 _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4
 _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4
 _Z16gthreads_errExitiPKc@Base 0.11.4
- _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10
+#MISSING: 0.11.10-1# _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10
 _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10
 _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4
 _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base
0.11.4
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:13: binary] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2

?

Steffen

On 09.08.20 07:00, Andreas Tille wrote:
> Hi Steffen,
>
> the patch you get from dh_makeshlibs needs to be edited.  You simply
>
> sed -i 's/-1$//' debian/libgclib2.symbols
>
> should do the trick.
>
> Hope this helps
>
>   Andreas.
>
> On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote:
>> Hello,
>>
>> to get the build process to first not fail and then be quiet, I changed
>> the .symbols file as follows:
>>
>> diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols
>> index 6bef43a..aef012c 100644
>> --- a/debian/libgclib2.symbols
>> +++ b/debian/libgclib2.symbols
>> @@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER#
>>  _Z10g2bit2baseh@Base 0.11.4
>>  _Z10gcdb_allocj@Base 0.11.4
>>  _Z10getFileExtPKc@Base 0.11.4
>> - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4
>> + _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1
>> + _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1
>>  _Z10parseFloatRPcRf@Base 0.11.4
>>  _Z10replaceStrRPcS_@Base 0.11.4
>>  _Z10startsWithPKcS0_@Base 0.11.4
>> @@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER#
>>  _Z14gfo_cmpRefByIDPvS_@Base 0.11.4
>>  _Z14translateCodonPKc@Base 0.11.4
>>  _Z15printEditScriptP12GXEditScript@Base 0.11.4
>> - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4
>> + _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1
>> + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
>>  _Z15uint32_pack_bigPcj@Base 0.11.4
>>  _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4
>>  _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4
>>  _Z16gthreads_errExitiPKc@Base 0.11.4
>> - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4
>> + _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1
>> + _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1
>> + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
>>  _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4
>>  _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base
>> 0.11.4
>>  _Z17gcvt_endian_setupv@Base 0.11.4
>>
>> I have no idea why there is now a -1 attached to the version. I just
>> know that it does not work without it.
>>
>> Can I upload as is?
>>
>> Best,
>>
>> Steffen
>>
>>



Re: libgclib - symbol file - please kindly educate me

2020-08-09 Thread Alex Mestiashvili

Also, there is no need to update symbols version, only add the new symbols.

Symbols file is needed to track down the ABI changes.

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

"A symbols file documents, for each symbol exported by a library, the 
minimal version of the package any binary using this symbol will need. 
This is typically the version of the package in which the symbol was 
introduced."


I am on a vac and most of the time Afk.

Best regards,
Alex

On 8/9/20 7:00 AM, Andreas Tille wrote:

Hi Steffen,

the patch you get from dh_makeshlibs needs to be edited.  You simply

 sed -i 's/-1$//' debian/libgclib2.symbols

should do the trick.

Hope this helps

   Andreas.

On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote:

Hello,

to get the build process to first not fail and then be quiet, I changed
the .symbols file as follows:

diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols
index 6bef43a..aef012c 100644
--- a/debian/libgclib2.symbols
+++ b/debian/libgclib2.symbols
@@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER#
  _Z10g2bit2baseh@Base 0.11.4
  _Z10gcdb_allocj@Base 0.11.4
  _Z10getFileExtPKc@Base 0.11.4
- _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4
+ _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1
+ _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1
  _Z10parseFloatRPcRf@Base 0.11.4
  _Z10replaceStrRPcS_@Base 0.11.4
  _Z10startsWithPKcS0_@Base 0.11.4
@@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER#
  _Z14gfo_cmpRefByIDPvS_@Base 0.11.4
  _Z14translateCodonPKc@Base 0.11.4
  _Z15printEditScriptP12GXEditScript@Base 0.11.4
- _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4
+ _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1
+ _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
  _Z15uint32_pack_bigPcj@Base 0.11.4
  _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4
  _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4
  _Z16gthreads_errExitiPKc@Base 0.11.4
- _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4
+ _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1
+ _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1
+ _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1
  _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4
  _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base
0.11.4
  _Z17gcvt_endian_setupv@Base 0.11.4

I have no idea why there is now a -1 attached to the version. I just
know that it does not work without it.

Can I upload as is?

Best,

Steffen