Bug#1032975: Aw: Steffen, please raise your opinion about igdiscover

[Steffen Möller]

Hi Andreas,

I am afraid I cannot put the extra effort into those packages and, admittedly, 
the NCBI software suite is just a bit intimidating, too. Please remove those 
packages from testing and if nobody shows any interest in the required updates 
then eventually those packages should also be removed from unstable.

Thank you tons,
Steffen

Bug#1014100: We should do an update of all qiime2 modules as soon as possible (Was: Bug#1014100: qiime: autopkgtest needs update for new version of python-decorator)

[Steffen Möller]

On 30.06.22 11:51, Andreas Tille wrote:

I'd like to point out to this serious bug.  Steffen, would you mind
koordinating (not doing alone) an upgrade of the qiime infrastructure to
make sure everything will go smoothly?

I added "to be updated" tags to all the qiime2 packages on

https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1986383821

Yes, these updates are overdue. I'll see what I can do, help is of
course much appreciated.

Many thanks!

Steffen

Bug#1012789: linucnc runtime prob with tiff is because of tiff

[Steffen Möller]

The problem is with the tiff library. On
https://github.com/LinuxCNC/linuxcnc/pull/1700 it is explained how to
install an earlier version from snapshot.debian.org

To trigger the problem independently from linuxcnc, try

$ wish
% package require Img

Bug#1012789: tk Img error while importing

[Steffen Möller]

The same error is triggered from within Tcl/Tk. LinuxCNC I do not think
to be to blame.

$ wish
% package require Img
couldn't load file
"/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so":
/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1
.0.so: undefined symbol: _TIFFsetString, version LIBTIFF_4.0^

Bug#999632: r-bioc-isoformswitchanalyzer FTBFS: ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available

[Steffen Möller]

On 14.11.21 08:47, Andreas Tille wrote:

Control: blocked -1 by 995252

Hi Steffen


ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available for package 
‘IsoformSwitchAnalyzeR’

r-bioc-tximeta is in Debian and just needs to be mentioned in
Build-Depends.  However, Git seems not to be up to date so please push.

Seems like we have a race condition. I dumped my local one and
routine-updated what was in salsa.


What is the status of r-bioc-drimseq?  I have not found it in new neither
did I found any mentioning it on the maintainers list.


g...@salsa.debian.org:r-pkg-team/r-bioc-drimseq.git

Seems like I had not uploaded it. Just upgraded it to a newer version
and sent it away.


PS: Please use a chroot when building your packages.


I typically do. For the ones with build dependencies in the NEW queue I
once had my own local repository but at some point stopped doing that.

Steffen

Bug#984243: Help: mothur: ftbfs with GCC-11

[Steffen Möller]

On 21.10.21 20:21, Étienne Mollier wrote:

Hi Andreas,

Andreas Tille, on 2021-10-21:

In file included from addtargets2.cpp:3:
myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:


   176 | byte *ReadAllStdioFile(FILE *f, off_t );
   | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
  from /usr/include/c++/11/bits/char_traits.h:39,
  from /usr/include/c++/11/string:40,
  from myutils.h:8,
  from addtargets2.cpp:3:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":


In file included from addtargets2.cpp:3:
myutils.h:42:23: note: 'typedef unsigned char byte'
42 | typedef unsigned char byte;
   |   ^~~~
myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)


My C++ skills are a bit rosty but would removing the typedef for byte
solve the problem?

Best,
Steffen

Bug#988183: gemma ftbfs on buster, newer version builds fine one bullseye

[Steffen Möller]

Would a regular backport be the way to go?

Bug#980972: xxsds-dynamic: Changelog entry missing trailer line

[Steffen Möller]

Thank you, Logan.

I just fixed that and uploaded. Nothing new from upstream.

Steffen

Bug#948919: sambama FTBFS: asked htslib about missing patch

[Steffen Möller]

https://github.com/samtools/htslib/issues/1098

Bug#948919: sambamba - htslib needs patch - guix - has the answer

[Steffen Möller]

http://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics/src/commit/a2a200402b91a352dbdede01eec85accb892b8e1/htslib-add-cram_to_bam.patch

That patch just makes the cram_to_bam routine visible and should be
adopted without danger.

Steffen

Bug#949730: python -> python3 done in new upload

[Steffen Möller]

A new version 5.7.3 is out, so I have addressed the "python" in the test
routines and wherever I encountered them.

Some tests still fail since files are written to the install folder
where they are not tested. Other comparisons now fail since there is a
linebreak in the help output where there was none before if I interpret
this right. If someone could send a patch for that this would be much
appreciated.

Steffen

Bug#855494: Last chance to fix mgltools-pmv

[Steffen Möller]

I am too busy to chase this all up, I am afraid.

On 07.12.19 09:04, Andreas Tille wrote:

Hi,

I just removed mgltools-pmv from debian-med metapackages to prepare its
removal.  I realised that autodocktools depends mgltools-pmv so this has
to go as well.  Since there is no sign that this 2.5 year old critical
bug is fixed and there is no Python3 port anyway those package should go
and might be re-introduced later.

Steffen, Tony, any thoughts?

Kind regards

   Andreas.

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Steffen Möller]

Hello,

On 08.11.19 23:14, Andreas Tille wrote:

On Fri, Nov 08, 2019 at 06:00:08PM +0100, Michael Crusoe wrote:

I got farther, but now the "dashboard" module won't load (no traceback).
The tests still fail spectacularly.

This is very old and non-free code. I suggest that all mglools* and
autodocktools* packages be removed.

I'm all for this - but as far as I understood Steffen he does not like
this idea.  I decided personally not invest any time into these
packages any more.


if the autodocktools are blocking something else then they have to go.
If not, well, I admit these packages are close to me but if this works
nowhere else than with me then there is no point, really.

Resistance weakens. I somehow keep doing things that are more important
than chasing the mgltools up. Maybe this all needs a new start, indeed.

Steffen

Bug#903762: BOINC server experimental package python 2-3 transition error: Upstream is aware of it

[Steffen Möller]

Hi Andreas,

thank you for the report. A "once worked" patch is part of
https://github.com/BOINC/boinc/pull/3259. No exact idea what this is
waiting for but I remain confident that it will eventually be accepted.

Cheers,
Steffen

Bug#913369: pluto-jpl-eph: diff for NMU version 0.0~git20180228-1.1

[Steffen Möller]

Hi Adrian,

On 08.01.19 13:00, Adrian Bunk wrote:

Control: tags 913369 + patch
Control: tags 913369 + pending

I've prepared an NMU for pluto-jpl-eph (versioned as 0.0~git20180228-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it.


Thank you for your interest in the pluto-* packages.

The package is team maintained on

https://salsa.debian.org/debian-astro-team/pluto-jpl-eph

I would appreciate if that resource would be used and I cordially invite 
you to help with co-maintenance. The package is a bit tricky in that 
Upstream only evolves over time to get his bits separated to independent 
parts and some circular dependencies are ambiguous to dissect and may 
even have changed over time. That is why first uploads of pluto-* went 
to experimental. Support in transitioning it all to unstable is very 
welcome.


Best,

Steffen

Bug#907624: What ffindex do we want to package

[Steffen Möller]

Heya, I have replied, at least I had typed it :o/

So, yes, I had chosen that version of ffsort_index to get hhsuite to 
compile. I have no idea if there are other reverse dependencies on 
ffindex, my priority is on hhsuite.


Cheers,

Steffen

On 04.01.19 18:17, Michael Crusoe wrote:
I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent 
FTBFS of hhsuite: https://bugs.debian.org/917495 as our packaged 
version is missing the "ffsort_index" function.


The hh-suite github repo contains a submodule pointing at their fork 
of ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib → 
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac


I suggest that we package it as part of hhsuite until another package 
needs it.


hhsuite does provide  "*-Source*" packages that include ffindex, so we 
wouldn't need a multi-source build.




În joi, 20 dec. 2018 la 11:59, Andreas Tille > a scris:


Ping?
Steffen, if you did not had a specific reason I assume it was by
mistake and will replace the Segfaulting code by the original one.
If I do not hear from you I assume you will agree.
Kind regards, Andreas.

On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> Hi,
>
> after reading
https://github.com/soedinglab/ffindex_soedinglab/issues/4
> I came to the conclusion that we somehow picked the wrong fork of
> ffindex.  For me it seems very probable that if we pick the old
codebase
> bug #907624 which was introduced when choosing this will vanish
if we
> revert to the previously packaged code base.  I have a local commit
> which is doing this:
>
>
> diff --git a/debian/changelog b/debian/changelog
> index 6a26115..c409f4f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED;
urgency=medium
> +
> +  * The previous location on Github was an improperly choosen fork
> +    (see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> +    Here the version is now named "0.9.9.7+sog" (Saved On Github)
> +    to make it alphabethically later than the previous one.
> +
> + -- Andreas Tille mailto:ti...@debian.org>>
Wed, 19 Dec 2018 09:16:09 +0100
> +
>  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
urgency=medium
>
>    * Fix watch file (version should actually be
+git20171201.74550c8 but
> diff --git a/debian/watch b/debian/watch
> index 91b4f38..b47f123 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
>
> -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> - https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> + https://github.com/ahcm/ffindex.git HEAD
>
>
>
> Upstream at github.com/ahcm/ffindex
 was extremely quick to tag a
> release and so it is at least active.
>
> Steffen, was your pick intentional or did you just stumbled by
chance
> over the other fork?  Are you OK with reverting to the old code?
>
> Kind regards
>
>       Andreas.
>
> PS: I reported the segfault issue to the according fork anyway
> https://github.com/soedinglab/ffindex_soedinglab/issues/7
>
>
> --
> http://fam-tille.de
>
>

-- 
http://fam-tille.de




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 
+1 480 627 9108 / +370 653 11125

Bug#907624: What ffindex do we want to package

[Steffen Möller]

Hi Andreas,

the reverse dependency HH-suite failed to compile with the ffindex 
version Debian shipped.


I have no feelings about it. It should just work :)  The HH-suite is 
about structure prediction from sequence homology, which I found we 
should continue to offer in our distribution 
https://en.wikipedia.org/wiki/HH-suite 
https://tracker.debian.org/pkg/hhsuite . Are there other reverse 
dependencies for ffindex in our distribution?


Priority is the HH-suite. Then ffindex. If difficulties surface anywhere 
then we have initiate some head scratching / banging. If there is 
nothing happening somewhere that I don't know about then I would leave 
it as it is.


Cheers,

Steffen

On 19.12.18 09:53, Andreas Tille wrote:

Hi,

after reading https://github.com/soedinglab/ffindex_soedinglab/issues/4
I came to the conclusion that we somehow picked the wrong fork of
ffindex.  For me it seems very probable that if we pick the old codebase
bug #907624 which was introduced when choosing this will vanish if we
revert to the previously packaged code base.  I have a local commit
which is doing this:


diff --git a/debian/changelog b/debian/changelog
index 6a26115..c409f4f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED; urgency=medium
+
+  * The previous location on Github was an improperly choosen fork
+(see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
+Here the version is now named "0.9.9.7+sog" (Saved On Github)
+to make it alphabethically later than the previous one.
+
+ -- Andreas Tille   Wed, 19 Dec 2018 09:16:09 +0100
+
  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable; urgency=medium
  
* Fix watch file (version should actually be +git20171201.74550c8 but

diff --git a/debian/watch b/debian/watch
index 91b4f38..b47f123 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
  version=4
  
-opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \

-https://github.com/soedinglab/ffindex_soedinglab.git HEAD
+opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
+https://github.com/ahcm/ffindex.git HEAD



Upstream at github.com/ahcm/ffindex was extremely quick to tag a
release and so it is at least active.

Steffen, was your pick intentional or did you just stumbled by chance
over the other fork?  Are you OK with reverting to the old code?

Kind regards

   Andreas.

PS: I reported the segfault issue to the according fork anyway
 https://github.com/soedinglab/ffindex_soedinglab/issues/7

Bug#887880: Different results for g++-4/5 vs g++-6/7

[Steffen Möller]

Dear Aurelien,

The package compiles just fine with the later gcc version. But - and 
this is a big but - about 10 to 25 percent of results produced with the 
newer versions give slightly different results, i.e. different enough 
that the difference between the g++ versions is bigger than the 
difference between platforms (ARM, 32bit annd 64bit Intel and AMD 
machines, ARM and Intel with an OpenCL implementation).


I would not have found that compiler dependency if g++-5 had already 
been completely removed from the distribution. So, I am really thankful 
for that. It was not expected. I can see that you want to remove that 
older gcc, but I think it would be a mistake. I do not say that the 
newer version has an issue, that may or may not be the case, just be 
aware that the binaries at hand have been tested against against 
injected known truths and error tolerance thresholds been derived from 
there. This needs more investigation. Please do not remove this package 
or g++-5 yet.


Cheers,

Steffen

Bug#848220: g++-4.9/g++-5 show floating point diff to g++-6/g++-7

[Steffen Möller]

Hello,

I just introduced g++-5 as a build dependency to 
https://packages.qa.debian.org/b/boinc-app-eah-brp.html because of small 
- but very present - runtime differences. It had helped me a lot to have 
g++-5 in unstable so I could just go and test. You certainly have 
reasons to remove it, but please be aware of this downside. I can well 
imagine that for many industrial settings the parallel availability of 
both versions is helping the transition.


Cheers,

Steffen

Bug#867455: python3-shellescape: missing dependencies

[Steffen Möller]

Well spotted, many thanks! If it is easy for you then I happily see you
uploading your fixed package to the distribution.
Steffen

Bug#830984: Do you have resources to look after ball? [progress info]

[Steffen Möller]

Hi,

well done!


On 11/11/2016 13:06, Andreas Tille wrote:
> Hi Danny,
>
> thanks again for your help.
>
> On Fri, Nov 11, 2016 at 12:36:49PM +0100, Danny Edel wrote:
>> Control: block 784451 by 832420
>>
>> that is fine with me.  I'll keep the bugs in CC too.
> :-)
>  
>>> We somehow should target to Qt5 anyway (see #784451) better sooner than
>>> later.
>>>  
>> For now, I have backported the fixes to the released, but Qt4-based
>> 1.4.3~beta1 version, to resolve the current FTBFS with a targeted fix.
>> The changes are uploaded to the debian-med/ball repository on alioth,
>> pending your review and upload.
> Build is just running ...  I'll come back later in case of any issues
> I feel unable to deal with myself.
>  
>> In that process, I tried building various stages of upstream master, and
>> bae96ab4 'Merge branch issue_596' might be a candidate for a snapshot
>> (entire testsuite passes).  However, there is the problem that
>> QtWebEngine is not yet included in Debian, so I could only build recent
>> master if I explicitly disabled support with -DUSE_QTWEBENGINE=OFF.  I
>> am not sure if this would be a good thing for users.
> I admit that I have no idea whether this is a real constraint.  I added
> Steffen in CC who might raise his opinion.
In my opinion, the BALL library is the essential part that is nice to
redistribute
in Debian. BALLView would be a nice application working with that and
certainly
I hope for many more BALL applications to come.

The dynamic web engine would of course be nice to eventually surface in our
distro but if we can get BALL without it then this is just fine as it is
no regression
from what we had before.
>> I added a blocking relationship to the ITP of QtWebEngine, I hope I
>> didn't mix up the numbers.  The changelog contains a Closes: clause on
>> both FTBFS issues, even though I could only test amd64.  Feel free to
>> remove those before uploading if that's an issue.
> I will also test on amd64.  If it turns out that there might be some
> issues on other architectures we possibly need to excluded these.
It would be particularly nice we could come up with ways to help BALL
development in some ways. Attracting fantastic folks like Danny is one
thing.
Another be could become the continuous integration work, such that even
while possibly working with other operating distros Upstream could learn
about upcoming difficulties (like with the QtWebEngine) and we would not
be taken by surprise either.

Best,

Steffen

Bug#817385: Moving Bytecode to Debian Med (or Java) Git

[Steffen Möller]

Go ahead. This pkg-escience was that Taverna collective effort.

Thanks

Steffen


On 20/06/16 15:38, Olivier Sallou wrote:
> I made a quick fix to switch to compat 9 and fix Java version to current
> jdk in sid.
>
> However, i cannot push to pkg-escience / bytecode (permission denied).
>
> It would be best to move package to pkg-java instead of debianmed
> according to me, as it is pure Java package.
>
> Patching is quite easy:
>
> switch d/compat to 9 (no issue)
>
> d/control: update dependencies to use default-jdk and default-jre
> instead of openjdk/sun-jdk/java2-compiler
>
> add a patch to build.xml to add in all javac commands :  source="1.6"
> target="1.6"
>
> build is fine with no specific lintian error
>
>
> Olivier
>
> On 06/20/2016 12:21 PM, Andreas Tille wrote:
>> Hi,
>>
>> the RC bug #817385 affects several Debian Med packages.  IMHO it would
>> be best if the package would be moved to either Debian Med or Debian
>> Jave Git.  The package is currently unmaintained (Steffen, please
>> correct me if I'm wrong) and urgently needs a proper update.  I need
>> to cope with some backlog and can not do this before end of this week.
>>
>> Any volunteer?
>>
>> Kind regards
>>
>>Andreas.
>>

Bug#817385: Moving Bytecode to Debian Med (or Java) Git

[Steffen Möller]

Hi Andreas,

On 20/06/16 12:21, Andreas Tille wrote:
> Hi,
>
> the RC bug #817385 affects several Debian Med packages.  IMHO it would
> be best if the package would be moved to either Debian Med or Debian
> Jave Git.  The package is currently unmaintained (Steffen, please
> correct me if I'm wrong) and urgently needs a proper update.  I need
> to cope with some backlog and can not do this before end of this week.
>
> Any volunteer?
>
I once did this for Taverna and am both happy and suprised to see
reverse dependencies surfacing. If you (or someone else) could adopt
this package it would be very nice, indeed.

Many thanks

Steffen

Bug#787746: Aw: Re: ball: FTBFS, depends on non existant libqt4-gui

[Steffen Möller]

 I would highly appreciate if you can either allow me to push this as an NMU 
 or 
 just build+upload yourself.

Oh, please feel free to NMU - every piece of help is much appreciated.

Best,

Steffen


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

Bug#787746: Aw: Bug#787746: ball: FTBFS, depends on non existant libqt4-gui

[Steffen Möller]

 On Friday 05 June 2015 16:33:45 Lisandro Damián Nicanor Pérez Meyer wrote:
  Mm, no, I'm afraid ball keeps FTBFS due to the same error:
  
  Linking CXX executable ../../../bin/BALLView
  /usr/bin/ld: CMakeFiles/BALLView.dir/main.o: undefined reference to symbol
  'XInitThreads'
  //usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing
  from command line
  collect2: error: ld returned 1 exit status
  make[4]: *** [bin/BALLView] Error 1
 
 The attached patch fixes this but... there is yet another problem further on 
 with some python stuff.

Thank you, Lisandro. I am about to upload an early version of BALL 1.5
and will incorporate your changes over the next days / one/two weeks.

Best,

Steffen


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

Bug#767411: Aw: Bug#767411: torque: should not be released with jessie

[Steffen Möller]

Hello,
  
Von: Dominique Belhachemi domi...@debian.org
I agree that the 2.4 branch is completely outdated. We should switch to a 
newer branch.
The 2.5 and 4.1 branches are not suitable for Debian due to licensing issues.
But the 4.2 branch is licensed under the same license as the 2.4 branch, so I 
suggest we upload the 4.2.9 release to unstable.

I agree.  You? Me? I am too busy for the upcoming weeks, sadly.

Best,

Steffen


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

Bug#728293: libusb-java - acknowledged, no immediate solution

[Steffen Möller]

Thank you for your report. I just fail to understand
it, still.  I just checked the source code and the arch
already comes from dpkg-architecture. The latest
with #711843 this should all be an issue of the past.
I to do not see why it works on amd64 but not for e.g. i386.

I need a mental reset, will look at it later again.

Steffen


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

Bug#720419: Aw: [Debichem-devel] Bug#720419: Openmpi 1.6.5 is freezing under GNU/Linux ia64

[Steffen Möller]

Hello,

 In Debian, we are in the process of switching the default MPI
 implementation from version 1.4 to 1.6.
 
 Every architectures are fine beside ia64. Any program based on OpenMPI
 1.6.5 is freezing.
 
 With a basic test case:
   MPI_Init(NULL, NULL);
   MPI_Finalize();
 
 mpirun -c 4 foo
 = freeze
 The backtrace does not show anything.
 
 Does it ring a bell to anyone ?

Do you observe this on a single machine or via a network? I suggest
editing your nodes list to identify the hosts that make problems.

I also experienced the freeze for heterogeneous setups of 1.4 and 1.6 versions.
In a homogeneous setup, the direct execution e.g. of hostname always works.
But there is something that I have done to a prior working homogeneous 1.6
setup across three nodes that now freezes when I execute GROMACS' mdrun,
if a single particular node is allowed to contribute.

Steffen


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

Bug#687694: Aw: Bug#687694: bouncycastle: 1.44 and 1.46 are not binary compatible

[Steffen Möller]

 Gesendet: Dienstag, 27. August 2013 um 00:47 Uhr
 Von: Emmanuel Bourg ebo...@apache.org
 An: 687...@bugs.debian.org, 687694-submit...@bugs.debian.org
 Betreff: Bug#687694: bouncycastle: 1.44 and 1.46 are not binary compatible

 Quick update on the remaining packages affected by the transition:
 
 jenkins-instance-identity   OK
 1.3 uploaded on 2013-07-27
 
 voms-api-java   PATCHED
 2.0.9-1.1 uploaded on 2013-07-16
 
 jglobus PATCHED, patch applied upstream
 2.0.6-1 uploaded on 2013-08-15
 
 
 All the reverse dependencies have been reviewed/updated, I think this
 bug can be closed now.

We should add that if there is continued demand of bc 1.44 then the package
can be reintroduced as bouncycastle-1.44 . Please speak up.

Steffen


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

Bug#677416: wine-unstable-bin installation works for me

[Steffen Möller]

Hello,

it is admittedly all a bit tedious because of conflicts with the regular Wine 
package. But at least now (Jan 2013) it is
installable. And it works. Also coming from the win 1.4 package.

Steffen


-- 
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

[Steffen Möller]

- Ursprüngliche Nachricht -
Von: Julien Cristau
Gesendet: 29.12.12 18:46 Uhr
An: Charles Plessy, 694...@bugs.debian.org
Betreff: [Debian-med-packaging] Bug#694908: Contains non-free data

 On Sun, Dec 2, 2012 at 09:39:14 +0900, Charles Plessy wrote:  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.  Does 
that mean emboss and embassy-* need to be removed from wheezy?  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.
 In my mind, having it all shipping together is just fine enough for Wheezy. A 
hard core
 alternative would be to substitute it with a mockup GO with the only entries 
explaining
 how to install the real thing. One could also just remove the database and see 
a few tools fail.
 To me, it is a small side issue and I suggest to demote the bug from Serious 
to Wishlist.

 Steffen

Bug#693653: OpenGL function fails and blocks Pmv and Autodocktools

[Steffen Möller]

Hi Andreas,

 any reason not to upload a fixed package incorporating the suggested
 patch?

Upstream did not react, yet. I was hoping for a quick adoption by upstream and 
then a patch-free upload of that package. Need to ask again.

Cheers,

Steffen


-- 
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

[Steffen Möller]

Hello,
On 10/17/2012 04:16 PM, Andreas Tille wrote:
 I admit that an empty package is not nice but from my perspective this
 bug does not qualify as severity grave.  I'm tempted to set this to
 normal - specifically in freeze time this severity might add noise
 we do not really need.
 
 What do you think?

I agree. Another upload fixing just that omitted documentation should be 
accepted by the release team.

Steffen


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

Bug#645487: ensembl: includes GPL code without source

[Steffen Möller]

Hello,

 Andreas Tille ti...@debian.org writes:
  You are mixing up GPL and DFSG.  GPL says that the source code needs to
  be provided at least at request (and it in this case it is pretty easy
  to obtain the source code).
 
 The general rule is, if you distribute binaries, you must distribute
 the complete corresponding source code too.[1]
 
 If you make object code available on a network server, you have to
 provide the Corresponding Source on a network server as well.[2]
 
 And having a jalview package in the archive does not help as this does
 not guarantee we have the source for the exact version of jalview
 bundled with ensembl.
 
 Ansgar
 
 [1] http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary
 [2] http://www.gnu.org/licenses/gpl-faq.html#AnonFTPAndSendSources

Formally speaking there is nothing to argue about. We should remove that .jar. 
To grant us some more time to orchestrate the individuals behind that package 
and get up to speed with the much progressed upstream developments, may I ask 
for an exempt for the Ensembl package, not harming too many in experimental, 
from [1] for another while, please?

Many greetings

Steffen


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

Bug#645487: ensembl: includes GPL code without source

[Steffen Möller]

Hello,

 Original-Nachricht 
 Datum: Mon, 1 Oct 2012 08:49:55 +0200
 Von: Andreas Tille andr...@an3as.eu
 An: Jonathan Nieder jrnie...@gmail.com, 645...@bugs.debian.org
 Betreff: [Debian-med-packaging] Bug#645487: ensembl: includes GPL code
 without source

 Hi,
 
 On Sun, Sep 23, 2012 at 07:00:23PM -0700, Jonathan Nieder wrote:
  tags 645487 + pending
  quit
  
  Hi,
  
  In October, 2011, Jonathan Nieder wrote:
   ensembl's debian/README.source says:
  
   | Since Jalview is not yet part of Debian, its source code is also not
   | yet available through or distribution. To better comply with the
 GPL,
   | the source code of Ensembl also ships the sources for Jalview.
  [...]
   Unfortunately no such file exists --- I guess it disappeared during
   some upgrade.

Luckily, there is now
http://packages.debian.org/sid/jalview

  This seems to be fixed in the packaging repo.  What is left to do
  before the updated package is uploaded?
 
 The new package is not yet ready for an upload.

We need to do some communication and some thinking for bringing the Ensembl 
package up to speed again. Quite some investment was once made for it. It is 
trickier than it seems.

  Would you be terribly
  offended if I requested removal of the current package in the
  meantime,
 
 Yes, we would be terribly offended and I explicitely do not want
 you to request the removal.
 
  so we could continue to set a good example by not asking
  mirrors to violate the GPL?
 
 As I layed out in the ug log I consider your view on this issue
 as wrong and I do not agree - there is no point in overreacting
 in this case.

Indeed.

The particular challenge for this package is some sort of community forming. 
Community here stands both for a suite of software tools and the people with 
particular skills behind them. Don't touch it. You have seen Jalview arriving. 
There is much much more to it all which may well take another few years to 
become complete, expecting some interim update of that experimental package, 
admittedly :o)  The Ensembl package shows us what we are aiming at as a big 
integrator.

Thank you, Andreas, I almost missed this one.

Steffen


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

Bug#663674: ztex-bmp: FTBFS: bmp.pas(309, 20) Error: Call by var for arg no. 1 has to match exactly: Got CMacroBuf expected CTextBuf

[Steffen Möller]

On 07/26/2012 06:24 PM, gregor herrmann wrote:
 On Sat, 12 May 2012 17:05:13 +0200, Steffen Möller wrote:

 Peter, have many thanks.  I see what I can do over the weekend. 
 Seems you're having a long weekend :)
Did I truly write that in May? Strange. I think to have already
mentioned in some other mail that upstream has fixed everything
in a new version when I had reported the issue.
 IOW: Any news on this bug? The patch seems small and reasonable to
 me.
Coming. I had invalidated my gpg key, have just a few days
ago submitted my new key with the two sigs. This bug - and a few
others - will be addressed immediately when the key is in the
keyring.

Steffen


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

Bug#675940: crash is real

[Steffen Möller]

Two HD5770 over here, was configured for two monitors on single device, but 
even the simples variant led to the crash .. and ruined a day. Am back to the 
free driver until the situation gets back to normal.

Steffen



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

Bug#674226: ball: FTBFS in sid: use of deleted function 'BALL::String::String(const BALL::String)'

[Steffen Möller]

Thank you, Samuel.
Upstream is aware of this problem and also knows about next month's freeze.
They will do what they can do.

Steffen



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

Bug#614443: boinc-app-seti patch, added to git repository

[Steffen Möller]

Hello,

I have just added the patch to the git repository and am very happy for
Paul and Ilya having been so proactive on it all. We need a new
maintainer for the boinc-app-seti package. Particularly for the advent
of more and more performant mobile phones, many of which running with
Linux, we should truly think about getting the BOINC apps migrated to
them. I know upstream of BOINC to have addressed such already at their
last user meeting, but they had not thought much about regular
Debian/Ubuntu on various phones or tablets that are not Intel/AMD-based.
Should any of you be running SETI on any such, please edit
http://wiki.debian.org/BOINC/Projects .

There was an earlier effort to update the SETI package to 5.28 which was
never sent to the archive from what I recall. And there is already a
version 6 out there. So, if any reader of this comment would feel like
adopting the SETI package, please speak out.

Kind regards,

Steffen





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

Bug#663674: ztex-bmp: FTBFS: bmp.pas(309, 20) Error: Call by var for arg no. 1 has to match exactly: Got CMacroBuf expected CTextBuf

[Steffen Möller]

Peter, have many thanks.  I see what I can do over the weekend. SZ from 
upstream has rewritten that code and I wanted to address the ztex realm of 
packages over the next days, anyway.

Are you using the ZTEX hardware by any chance? I was hoping for some FPGA 
community to form over time with Debian/Ubuntu.

Cheers,

Steffen



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

Bug#663674: ztex-bmp: FTBFS: bmp.pas(309, 20) Error: Call by var for arg no. 1 has to match exactly: Got CMacroBuf expected CTextBuf

[Steffen Möller]

Fixed upstream. Did not get around to it.




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

Bug#636923: [Debian-med-packaging] RM: libwww5.808-perl -- RC-buggy, NPOASR

[Steffen Möller]

Hello,

On 01/24/2012 09:36 PM, Jonathan Nieder wrote:
 reassign 636923 ensembl 63-1
 severity 636923 serious
 quit
 
 Hi,
 
 Luca Falavigna wrote:
 
 As there's little the FTP Team can do at this point, I'm reassigning
 this bug to libwww5.808-perl source package, pending a proper fix.
 
 Since the original report last April, we haven't heard from the
 libwww5.808-perl maintainers at all.  I have run into this same
 problem on multiple machines now, and no one seems to think the
 package's existence is sane, so I'm tempted to suggest just removing
 it, with ensembl as an unfortunate casualty.

Sigh. Wait, please.

 The ensembl package description explains:
 
   libwww-perl5.808 will conflict with the latest libwww-perl
   installation and thus force a downgrade to 5.808, which will disable
   many other tools on your system. Therefore it is advisable NOT to
   install this package in parallel with any other software, and/or use
   a virtual machine or dedicated machine.
 
 which does not sound like a package that I would expect to find in the
 archive.

But it is not in the archive. It is in experimental, not? Please do
not put too much pressure on us here. Give us time to critical mass
ourselves a bit more.

 However, maybe the ensembl maintainers can come up with some method
 for avoiding this?  E.g., [1] seems to have some ideas that would not
 require such an invasive package.  Cc-ing them.

The package was created for cloud or chroot setups, not for your average
desktop.

We have our Debian Med sprint this week and I take the opportunity to
discuss things there. My personal position is that the change either goes 
through
upstream or it will not happen. If the removal of the package is a consequence,
then so be it. Mysteriously, those folks run more after the science than
after their working for them libraries. So, take note, there are apparently
some communities even more stable than Debian stable :o)

Steffen





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

Bug#636923: [Debian-med-packaging] Bug#636923: RM: libwww5.808-perl -- RC-buggy, NPOASR

[Steffen Möller]

 original
 maintainers just pushed a broken package to experimental and take this
 distribution as an excuse not to care any more.

No really. The current packaging exactly matches the official
build instructions for Ensembl. That is quite a strong point,
at least for me. Any deviation from that will not necessarily
be welcome.

 I also addressed this
 and I will try to actively care about this in the next couple of weeks.
 I think this bug could serve as a handle to make them care more for
 this package which has quite some importance for them.  So please
 stay a bit tuned, we are working on this.

IMO the issue needs talking more than programming. And that takes time.
And this sprint.

Steffen



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

Bug#653626: confirming recompilation bug of ballview

[Steffen Möller]

Hello,

the same machine that previously built the BALL packages now fails in
just the same way you are describing it. I cannot tell what it is.
Upstream is informed and will certainly fix this at some point.

Many thanks for spotting this

Steffen



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

Bug#645487: ensembl: includes GPL code without source

[Steffen Möller]

Hello Jonathan,

Thank you for spotting the omission.

On 11/30/2011 09:58 AM, Andreas Tille wrote:
 Hi,

 On Sun, Oct 16, 2011 at 09:49:25PM +0200, Andreas Tille wrote:
 On Sun, Oct 16, 2011 at 03:51:18AM -0500, Jonathan Nieder wrote:
 Unfortunately no such file exists --- I guess it disappeared during
 some upgrade.  The jars in the source package only contain class
 files, no .java source files.

 Assuming that what debian/copyright says is correct, this would make
 the ensembl package non-distributable:
 In how far would this make the package non-distributable?  Just
 providing the binary without source is OK as long as you can provide
 the source at request.  While you are correct that we should fix the
 package I do not think that we need to take any more drastic action
 like:
  
 notify the admins of snapshot.debian.org so the nondistributable
 versions can be removed. 
 This would be pure overreaction.
 Despite your previous response to my mail I stick to my opinion that
 this is overreaction but if you feel obliged to contact admins of
 snapshot.debian.org to remove files where I actually do not see any need
 for I can not stop you.  IMHO the fact that the files never really were
 distributed in any Debian release but just hanging around in
 non-free/experimental makes your point quite weak and finally the
 sources are there - now even inside Debian.

 Regarding fixing the actual problem I would like to ask those people
 directly involved with ensemble packaging (explicitely in CC) whether
 it is OK, to finally drop the jar files in question from the source
 package and rather symlink to

 jemboss: /usr/share/EMBOSS/jemboss/lib/jalviewApplet.jar
 jalview: /usr/share/java/jalview.jar

 inside the package.  The only missing file would be jalviewAppletOld.jar
 but guessing from the name this file might be unused anyway.  Please
 either confirm that this would properly fix the situation and will not
 break ensembl and if I should go for it or whether you want to fix this
 yourself.
the snapshotting is rather helpful to accomodate legacy installations
of the MySQL databases, which just are not expected to be updated
to often. In that sense, removing the package from the snapshots is
in nobody's interest.

We knew Jalview coming to Debian for long. This limited our motivation
to spend too much time on it but we have rather moved it all to
experimental.
We have upstreams of Jalview with us on our Sprint for this and other
reasons, and contributors to Ensembl are also coming. We shall investigate
it when we are together.

Please contact the admins of Snapshot, but only to praise them for
their service.

Cheers,

Steffen




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

Bug#645487: ensembl: includes GPL code without source

[Steffen Möller]

Hello,

I would not bet on it. Most likely this needs some adjustments to the
Ensembl code since the Jar of Ensembl is considerably older than what is
now in Debian with a much smaller set of dependencies to additional jars.

Please leave it for after the Sprint.

Steffen

On 11/30/2011 10:42 AM, Andreas Tille wrote:
 Hi Steffen,

 could you please answer the more important piece I'm repeating below?

 Thanks

Andreas.

 On Wed, Nov 30, 2011 at 10:37:11AM +0100, Steffen Möller wrote:
 Regarding fixing the actual problem I would like to ask those people
 directly involved with ensemble packaging (explicitely in CC) whether
 it is OK, to finally drop the jar files in question from the source
 package and rather symlink to

 jemboss: /usr/share/EMBOSS/jemboss/lib/jalviewApplet.jar
 jalview: /usr/share/java/jalview.jar

 inside the package.  The only missing file would be jalviewAppletOld.jar
 but guessing from the name this file might be unused anyway.  Please
 either confirm that this would properly fix the situation and will not
 break ensembl and if I should go for it or whether you want to fix this
 yourself.




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

Bug#643018: boinc: FTBFS: missing separator. Stop.

[Steffen Möller]

Hello,

On 09/26/2011 06:01 PM, Christoph Egger wrote:


 Your package failed to build on the kfreebsd-* buildds:
 
 make[1]: Entering directory 
 `/build/buildd-boinc_6.13.1+dfsg-2-kfreebsd-amd64-XCjgHd/boinc-6.13.1+dfsg'
 docbook2x-man debian/manpages/update-boinc-applinks.xml
 
 *
  Making 
 *
 
 /usr/bin/make
 Makefile:190: *** make[2]: Entering directory 
 `/build/buildd-boinc_6.13.1+dfsg-2-kfreebsd-amd64-XCjgHd/boinc-6.13.1+dfsg'
 missing separator.  Stop.

I had this before with the kfreebsd Make build daemons. It auto-repaired itself 
with some later update of the buildds and is not
reproducible with local virtual machines. When you have a look here
https://buildd.debian.org/status/package.php?p=boinc
then it indeed does look strange, no? Maybe it is a kfreebsd issue? I am too 
tired from last time to investigate that again. If
you have access to a kfreebsd machine, please try resolving that one for me.

Many thanks and regards,

Steffen




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

Bug#640262: [Debian-med-packaging] Bug#640262: python-cogent: missing dependency on python-numpy

[Steffen Möller]

ooops,

On 09/03/2011 07:23 PM, Jakub Wilk wrote:
 | import numpy
 | ImportError: No module named numpy

many thanks.  I thought I'd have already fixed that one.

Will do,

Steffen




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

Bug#640262: [Debian-med-packaging] Bug#640262: python-cogent: missing dependency on python-numpy

[Steffen Möller]

I just checked again,

On 09/03/2011 07:23 PM, Jakub Wilk wrote:
 Package: python-cogent
 Version: 1.5.1-1
 Severity: serious
 Justification: Policy 3.5
 
 In a minimal chroot:
 | $ python -c 'import cogent'
 | Traceback (most recent call last):
 |   File string, line 1, in module
 |   File /usr/lib/python2.6/dist-packages/cogent/__init__.py, line 5, in 
 module
 | import numpy
 | ImportError: No module named numpy

python-numpy is on the build-dependencies list for 1.5.1 in our svn and also 
listed
as such here

http://packages.debian.org/source/unstable/python-cogent

And the
packages built successfully on many different platforms

https://buildd.debian.org/status/package.php?p=python-cogent

Jakub, can you please investigate? I'd otherwise close the bug as invalid.

Cheers,

Steffen



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

Bug#637430: [Debian-med-packaging] Licensed only to individuals; not distributable by us?

[Steffen Möller]

Please accept the packages for now. I will be in San Diego for two days
meeting them in October. We get this somehow fixed. Any change to the
license would need to go through their law departments again ... which
had happened before and can happen again ... but we should not allow
ourselves to be interrupted through that now.

I don't know if I have the emails, still. I can check. But if I find
them or not. Do not have any release critical bug to it, please.

Steffen

On 08/11/2011 01:35 PM, Andreas Tille wrote:
 Hi,

 as far as I understood Steffen[1] upstream was previousely contacted and
 the permission is granted.  Steffen, can you find some mail from this
 time which is usable for quoting?

 Kind regards

   Andreas.

 [1] 
 http://lists.alioth.debian.org/pipermail/debian-med-packaging/2011-August/011184.html

 On Thu, Aug 11, 2011 at 12:57:26PM +0200, Alexander Reichle-Schmehl wrote:
 Package: mgltools-pmv
 Version: 1.5.6~rc1+cvs.20110617-2
 Severity: Serious


 [ leaving full quote for the bug log ]

 Hi Andreas!

 Well, seems we did a mistake back than.  Sorry.  However, as we agree
 that the license might not be address Debian, and as the license hasn't
 changed, I open a bug report for the package in the archive.

 I guess the easiest solution would be to contact upstream, and ask
 whether Debian and it's mirrors may distribute the package under these
 license terms, and add the answer to the copyright file.


 Best regards,
   Alexander


 Am 10.08.2011 16:05, schrieb Andreas Tille:
 Hi Alexander,

 hmmm, I can understand your point, but some other ftpmaster of your team
 has considered this differently because the software is just in Debian
 and we just splitted the binaries:

 $ apt-cache policy mgltools-pmv
 mgltools-pmv:
   Installiert: (keine)
   Kandidat:1.5.6~rc1+cvs.20110617-2
   Versionstabelle:
  1.5.6~rc1+cvs.20110617-2 0
 501 http://debian.tu-bs.de/debian/ testing/non-free amd64 Packages
  50 http://ftp.de.debian.org/debian/ unstable/non-free amd64 
 Packages

 or was there some change of the license, Thorsten/Steffen?
 Please clarify this - most favourably with upstream to clear out any doubt.
 I currently do not have time for checking this.

 Kind regards

   Andreas.


 On Wed, Aug 10, 2011 at 01:05:42PM +, Alexander Reichle-Schmehl wrote:
 Hi maintainer(s)!

 I'm sorry, but I have to reject your package.  Citing your
 debian/copyright:

 =
   1. Grant Of Limited License; Software Use Restrictions. The programs
  received by you will be used only for NON COMMERCIAL purposes.
  This license is issued to you as an individual.
 =

 However, the Debian project is not an individual, so this license doesn't
 seem to apply for us, and therefore we have so far no rights to distribute
 it.


 Best regards,
   Alexander



 ===

 Please feel free to respond to this email if you don't understand why
 your files were rejected, or if you upload new files which address our
 concerns.


 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging







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

Bug#629196: boinc: FTBFS: Makefile:189: missing separator. Stop.

[Steffen Möller]

Tags: wontfix
Thanks

Hi Christoph,

I am aware of those failures. PowerPC is new, indeed, the kfreebsd are old. 
Those worked when
I created local virtual images with qemu of those kfreebsds, builing like a 
charm.
It just took me half a weekend. That is why there was a 6.12.27 or so version 
of it.

I don't say that I would not possibly spend another second on this, it just 
hurts too much
for the very moment  I had already sent emails to the buildd maintainers,
except for the new PowerPC platform. It is most likely some sort of 
incompatibility somewhere,
feel free to investigate, would be great to understand what is happending.

With many thanks for your report and best regards,

Steffen



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

Bug#624959: qtdmm: FTBFS: qvaluelist.h:91:13: error: 'ptrdiff_t' does not name a type

[Steffen Möller]

qtdmm will soon be kicked out of the archive with the loss of qt3 ...
have many thanks for your investigation, but,  the day only has 24
hours

Steffen


On 05/02/2011 02:37 PM, Lucas Nussbaum wrote:
 Source: qtdmm
 Version: 0.8.13-3
 Severity: serious
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20110502 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:
 g++ -c -pipe -g -Wall -W -O2 -D_REENTRANT  -DQT_NO_DEBUG -DQT_THREAD_SUPPORT 
 -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I. 
 -Imoc -Ixpm -I/usr/include/qt3 -Imoc/ -o tmp/colorbutton.o colorbutton.cpp
 In file included from /usr/include/qt3/qmap.h:49:0,
  from /usr/include/qt3/qmime.h:46,
  from /usr/include/qt3/qevent.h:48,
  from /usr/include/qt3/qobject.h:48,
  from /usr/include/qt3/qwidget.h:46,
  from /usr/include/qt3/qbutton.h:45,
  from /usr/include/qt3/qpushbutton.h:45,
  from ./colorbutton.h:24,
  from colorbutton.cpp:21:
 /usr/include/qt3/qvaluelist.h:91:13: error: 'ptrdiff_t' does not name a type
 /usr/include/qt3/qvaluelist.h:167:13: error: 'ptrdiff_t' does not name a type
 In file included from /usr/include/qt3/qmap.h:49:0,
  from /usr/include/qt3/qmime.h:46,
  from /usr/include/qt3/qevent.h:48,
  from /usr/include/qt3/qobject.h:48,
  from /usr/include/qt3/qwidget.h:46,
  from /usr/include/qt3/qbutton.h:45,
  from /usr/include/qt3/qpushbutton.h:45,
  from ./colorbutton.h:24,
  from colorbutton.cpp:21:
 /usr/include/qt3/qvaluelist.h:427:13: error: 'ptrdiff_t' does not name a type
 In file included from /usr/include/qt3/qmime.h:46:0,
  from /usr/include/qt3/qevent.h:48,
  from /usr/include/qt3/qobject.h:48,
  from /usr/include/qt3/qwidget.h:46,
  from /usr/include/qt3/qbutton.h:45,
  from /usr/include/qt3/qpushbutton.h:45,
  from ./colorbutton.h:24,
  from colorbutton.cpp:21:
 /usr/include/qt3/qmap.h:110:13: error: 'ptrdiff_t' does not name a type
 /usr/include/qt3/qmap.h:226:13: error: 'ptrdiff_t' does not name a type
 In file included from /usr/include/qt3/qmime.h:46:0,
  from /usr/include/qt3/qevent.h:48,
  from /usr/include/qt3/qobject.h:48,
  from /usr/include/qt3/qwidget.h:46,
  from /usr/include/qt3/qbutton.h:45,
  from /usr/include/qt3/qpushbutton.h:45,
  from ./colorbutton.h:24,
  from colorbutton.cpp:21:
 /usr/include/qt3/qmap.h:607:13: error: 'ptrdiff_t' does not name a type
 In file included from colorbutton.cpp:24:0:
 /usr/include/qt3/qimage.h: In member function 'bool 
 QImageTextKeyLang::operator(const QImageTextKeyLang) const':
 /usr/include/qt3/qimage.h:61:61: warning: suggest parentheses around '' 
 within '||' [-Wparentheses]
 make[2]: *** [tmp/colorbutton.o] Error 1
 The full build log is available from:

 http://people.debian.org/~lucas/logs/2011/05/02/qtdmm_0.8.13-3_lsid64.buildlog

 A list of current common problems and possible solutions is available at 
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.





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

Bug#625162: [Debian-med-packaging] Bug#625162: embassy-domainatrix: FTBFS: configure: error: C compiler cannot create executables

[Steffen Möller]

Hi Lucas,

On 05/02/2011 02:54 PM, Lucas Nussbaum wrote:
 cd .CFLAGS=-g -O2 -g -O2 -Wall -I/usr/lib/emboss/include 
 -I/usr/lib/emboss/include/epcre -I/usr/lib/emboss/include/eplplot 
 -L/usr/lib/emboss/lib -R/usr/lib/emboss/lib CXXFLAGS=-g -O2 -g -O2 -Wall 
 CPPFLAGS= LDFLAGS= -Wl,--as-needed 
 /build/user-embassy-domainatrix_0.1.0+20100721-2-amd64-adoyn8/embassy-domainatrix-0.1.0+20100721/./configure
  --build=x86_64-linux-gnu  --prefix=/usr --includedir=\${prefix}/include 
 --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info 
 --sysconfdir=/etc --localstatedir=/var 
 --libexecdir=\${prefix}/lib/embassy-domainatrix --srcdir=. 
 --disable-maintainer-mode --disable-dependency-tracking 
 --disable-silent-rules   --enable-systemlibs 
[...]
 checking for gcc... gcc
 checking whether the C compiler works... no
 configure: error: in 
 `/build/user-embassy-domainatrix_0.1.0+20100721-2-amd64-adoyn8/embassy-domainatrix-0.1.0+20100721':
 configure: error: C compiler cannot create executables
 See `config.log' for more details.
 make: *** [debian/stamp-autotools] Error 77
 The full build log is available from:

 http://people.debian.org/~lucas/logs/2011/05/02/embassy-domainatrix_0.1.0+20100721-2_lsid64.buildlog

 A list of current common problems and possible solutions is available at 
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
this particular one is hilarious,gven that you are most likely
interested in the gcc update to 4.6. Charles, please save your energy
and do some real science, instead. This, I have some confidence, can
wait for the next update of EMBOSS (due July 15th as usual).

Steffen




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

Bug#618974: [kfreebsd i386 : finzi] FTBFS error non-reproducible on virtual image

[Steffen Möller]

Hello,

I am despaired over an error that was previously seen for both amd64 and i386 kfreebsds, and now remains with the i386 flavour. 
The issue was not reproducible on either platform, squeeze or unstable, when running it virtually under qemu:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618974

Because of my manual labour's success I had flagged #618974 as done. But this needs some further investigation since the problem 
reoccurred with right the next update. Whoever is maintaining that buildd, please kindly get back to me on this ... and maybe 
attempt a


apt-get source --compile boinc

yourself.

Many thanks and regards,

Steffen



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

Bug#543696: new version this summer

[Steffen Möller]

Dear fans of mgltools@Debian/Ubuntu out there,

some few extra weeks down the road there will be another
upstream release. Andreas was already so kind to
perform an update at least on the svn, many thanks
for that, I personally am too busy for an interim
reaction to the glut removal.

So, the summer will bring some relief.
Thanks

Steffen



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

Bug#618974: compiles perfectly with kfreebsd-i386 squeeze

[Steffen Möller]

Hello,

I installed squeeze yesterday for kfreebsd in qemu and (after a long long time) can report that the package is just compiling 
nicely. The problem is most likely not with BOINC but of course we should use that opportunity to locate the bug. I'll see now if 
I can reproduce the problem my updating unstable ...


S



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

Bug#618974: compiles perfectly with kfreebsd-i386 squeeze

[Steffen Möller]

Hello,

CC to io admins.

On 04/10/2011 11:36 AM, Steffen Möller wrote:

I installed squeeze yesterday for kfreebsd in qemu and (after a long long time) 
can report that the package is just compiling
nicely. The problem is most likely not with BOINC but of course we should use 
that opportunity to locate the bug. I'll see now if
I can reproduce the problem my updating unstable ...


I have now updated to unstable and still can again confirm the package to just build nicely. Dear io/asdfasdf admins, please cross 
check on your ends what may be wrong here. I updated my ssh key and somehow this does not get forwarded ... otherwise I would have 
logged in directly. My hunch is that the chroot of the build daemon might not be updated ... otherwise .. donno. For the very 
moment I very much feel like uploading the build from the virtual environment. This should be ok, no? After all I am doing it in a 
complete qemu-run emulation, not with some cross-build magic.


Whatever it is, please just ping me what to try, so we can find out the differences should the buildd against my intuition feature 
a recent unstable and/or still fail on building boinc after the update.


Best,

Steffen



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

Bug#618974: boinc: FTBFS on kfreebsd-*: Makefile:189: *** missing separator. Stop.

[Steffen Möller]

Hi KiBi,

thank you for pointing this out. I already observed this for 6.12.15. The 
package builds on everything except the i386 variant of
kfreebsd. I presume this to be a platform-specific error of the autotools or so.

On 03/20/2011 02:13 AM, Cyril Brulebois wrote:
 Source: boinc
 Version: 6.12.18+dfsg-1
 Severity: serious
 Justification: FTBFS
 
 Hi,
 
 your package no longer builds on kfreebsd-*:
 | docbook2x-man debian/manpages/update-boinc-applinks.xml
 | 
 | *
 |  Making 
 | *
 | 
 | /usr/bin/make
 | make[2]: Entering directory 
 `/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
 | Makefile:189: *** missing separator.  Stop.
 | make[2]: Leaving directory 
 `/build/buildd-boinc_6.12.18+dfsg-1-kfreebsd-i386-gQNKMv/boinc-6.12.18+dfsg'
 | make[1]: *** [override_dh_auto_build] Error 2

For me, the top level Makefile at line 189 is the CPPFLAGS at


CPP = gcc -E
CPPFLAGS =
CXX = g++

so there is not so much that could be wrong, in deep theory.

I'll ask for help on debian-devel.

Many thanks and regards,

Steffen






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

Bug#611008: [Debian-med-packaging] Bug#611008: Bug#611008: does not run with current version of R in squeeze

[Steffen Möller]

On 01/25/2011 09:46 AM, Andreas Tille wrote:
 Hi again,
 
 On Tue, Jan 25, 2011 at 05:00:27PM +0900, Charles Plessy wrote:
 while the bug would be fixed in unstable after a simple rebuild it
 concerns the Squeeze release.  I prepared a fixed version of the package
 (see debdiff).

 Hi Andreas, Steffen and release team,

 are you sure that a rebuild is necessary ? The package seems to work on my 
 system, and
 has already been rebuilt against R 2.10 as I explained in 
 http://bugs.debian.org/611008#10
 
 Ahh, I obviosely missinterpreted your mail.  I can confirm that on an up
 to date squeeze system (amd64) the currently available
 r-other-mott-happy_2.1-4+b1_amd64.deb works until
 
 library(happy)
 
 I have not done further testing of the packag.
 
 Steffen, do you have any hint what exactly is broken?

Hello,

this is weird. I got a complaint when I ran it on a squeeze system the day 
before yesterday.
I then compiled it myself. I suggest to enhance the packaging as Andreas has 
suggested,
with or without the debhelper dependency, I do not care so much, and then 
reupload to
proposed updates, closing that bug again.

Many greetings

Steffen




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

Bug#608639: boinc: FTBFS: No rule to make target `texfont.cpp', needed by `libboinc_graphics2_la-texfont.lo'.

[Steffen Möller]

Hello,

 your package still doesn't build:
 | libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -pthread -g 
 -O2 -g -Wall -O2 -g -Wall -O2 -Wall -MT libboinc_graphics2_la-reduce_lib.lo 
 -MD -MP -MF .deps/libboinc_graphics2_la-reduce_lib.Tpo -c reduce_lib.cpp -o 
 libboinc_graphics2_la-reduce_lib.o /dev/null 21
 | make[4]: *** No rule to make target `texfont.cpp', needed by 
 `libboinc_graphics2_la-texfont.lo'.  Stop.
 | make[4]: Leaving directory 
 `/build/buildd-boinc_6.12.8+dfsg-3-i386-qTMmbV/boinc-6.12.8+dfsg/api'
 | make[3]: *** [all-recursive] Error 1
 
 Full build logs:
   https://buildd.debian.org/status/package.php?p=boincsuite=experimental

somehow the patches are removed, not added. I do not know what this means for 
the very moment, really.

Sorry for your time but have many thanks for your report

Steffen




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

Bug#608530: [Debian-med-packaging] Bug#608530: non-free paml-doc package shows up in main

[Steffen Möller]

On 01/01/2011 01:35 PM, Adam D. Barratt wrote:
 On Fri, 2010-12-31 at 17:08 -0800, Josh Triplett wrote:
 I don't know whether to report this bug against paml-doc or
 ftp.debian.org.
 
 It's definitely a bug in paml.  Arguably dak shouldn't allow the
 situation to occur in the archive, but the package is wrong.
 
 After doing a package list update today, I noticed paml-doc showing up
 in the non-free/doc section.  I don't have non-free in my
 sources.list, just main.  Investigating, I found that paml-doc 4.4c-2
 shows up in http://ftp.us.debian.org/debian/pool/main/p/paml/ and in the
 Packages.gz for main.
 
 This is due to the source package having:
 
 Source: paml
 Section: non-free/science
 [...]
 Package: paml-doc
 Architecture: all
 Section: doc
 
 The binary package should be in non-free/doc.

Fixed in the Debian Med svn now. I'll upload later today.
If I am not errorneous, the assignment of doc was happening
by blindly following a note of lintian that requested the
section doc for a package name ending with -doc. I need
to investigate
http://lintian.debian.org/tags/wrong-section-according-to-package-name.html

It was not clear to me, that the initial assignment of the non-free
distribution could be removed for individual packages.

Many thanks

Steffen




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

Bug#608509: boinc: FTBFS: /bin/sh: libtoolize: not found

[Steffen Möller]

On 12/31/2010 05:38 PM, Cyril Brulebois wrote:
 Source: boinc
 Version: 6.12.8+dfsg-1
 Severity: serious
 Justification: FTBFS
 
 Your package no longer builds:
 | /bin/sh: libtoolize: not found
 
 KiBi.

Thank you, KiBi. As a quick fix, please sudo apt-get install libtool.
I'll have that added as a build dependency ASAP.  As a sidenote,
if you are interested in the server side, the current version in
git is much better. The client side is just working fine with me
in the version you have at hand.

Cheers,

Steffen



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

Bug#592417: [Debian-med-packaging] Bug#592417: [a...@adam-barratt.org.uk: Re: Bug#606911: unblock: mgltools-utpackages/1.5.4.cvs.20100912-1.1]

[Steffen Möller]

Hello,

thank you all for caring for the mgltools,
but I think this is all too late and too uncertain
for us to proceed for squeeze. I already got this
confirmed by the release managers. We should now bet
on backports and I'll have autodocktools and mgltools-*
removed from squeeze. This shall
a) help us by having only the latest versions of the mgltools with Debian
b) prevent us from shipping something that most certainly has more issues, 
still, than the ones now corrected for.

Many greetings

Steffen



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

Bug#594860: [Debian-med-packaging] Bug#594860: Bug#594860: Workaround for #594860

[Steffen Möller]

Hi Gregor, have many thanks! I'll upload later tonight.

Best,

Steffen

On 10/25/2010 12:25 AM, gregor herrmann wrote:
 On Mon, 27 Sep 2010 15:30:57 -0300, Nelson A. de Oliveira wrote:
 
 Configuring the package with --enable-dummy works on powerpc (tested
 on pescetti.debian.org).
 On alpha, armel, hppa, ia64, mips, mipsel, s390 and sparc, the dummy
 implementation is already automatically selected (can be seen on the
 build logs).
 So it shouldn't be that bad to use the dummy implementation also on powerpc.
 
 I've created a patch the uses dummy also on powerpc, and it works
 on i386 and powerpc (meaning that sse is used on my local machine and
 dummy on pescetti.debian.org).
 
 I'm attaching the debdiff, but I guess you can manage the upload
 yourself in the Debian Med team (with our without README.Debian) :)
 
 (I'm also happy to NMU in case you are all busy or I don't hear
 anything.)
 
 Cheers,
 gregor
 
 
 
 
 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging




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

Bug#589582: [pkg-eucalyptus-maintainers] Bug#589582: Bug#589582: Bug #589582 eucalyptus: FTBFS with upcoming Hibernate 3.5

[Steffen Möller]

It also needs the hibernate v 3.3 packages.  Ping me if you want to try
again, I'll place them on an apt repository for you.

Best,
Steffen

On 09/24/2010 03:41 PM, gregor herrmann wrote:
 On Thu, 29 Jul 2010 13:35:35 +0900, Charles Plessy wrote:

   
 no news. Given that Eucalyptus in Debian is still in a testing phase, I 
 propose
 to go ahead and upload the patched package, so that more people can test if 
 it
 works well.
 
 With or without the patch, eucalyptus FTBFS in a sid cowbuilder
 chroot (i386) with:

 ANT_OPTS=-Xmx512m /usr/bin/ant -e build
 Buildfile: /tmp/buildd/eucalyptus-1.6.2/clc/build.xml

 deps:

 download-deps:

 untar:

 build-msgs:

 init:
 Created dir: /tmp/buildd/eucalyptus-1.6.2/clc/modules/msgs/build
 Created dir: /tmp/buildd/eucalyptus-1.6.2/clc/target

 builder:
 builder.target=build-jibx

 build-jibx:

 build-groovy:

 BUILD FAILED
 /tmp/buildd/eucalyptus-1.6.2/clc/build.xml:88: The following error occurred 
 while executing this line:
 /tmp/buildd/eucalyptus-1.6.2/clc/modules/module-inc.xml:132: The following 
 error occurred while executing this line:
 /tmp/buildd/eucalyptus-1.6.2/clc/modules/msgs/build.xml:84: The following 
 error occurred while executing this line:
 /tmp/buildd/eucalyptus-1.6.2/clc/modules/module-inc.xml:147: taskdef class 
 org.codehaus.groovy.ant.Groovyc cannot be found
  using the classloader AntClassLoader[...]

 Cheers,
 gregor
  
   


 ___
 pkg-eucalyptus-maintainers mailing list
 pkg-eucalyptus-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-eucalyptus-maintainers
   

Bug#593050: [pkg-eucalyptus-maintainers] Bug#593050: eucalyptus: FTBFS: Nonexistent build-dependency: libhibernate-entitymanager-java

[Steffen Möller]

Hello,

On 09/17/2010 05:12 PM, Miguel Landaeta wrote:
 On Sun, Aug 15, 2010 at 09:47:01AM +0200, Lucas Nussbaum wrote:
   
 Source: eucalyptus
 Version: 1.6.2-2
 Severity: serious
 Tags: squeeze sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20100815 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 severity 589582 serious
   
severity 589582 mightily annoying
 libhibernate3-java/3.5.4.Final-4 is in squeeze and sid, it
 provides libhibernate-entitymanager-java (see #593254) so
 this package doesn't FTBFS for this reason anymore. This bug
 should be closed.

 However, now eucalyptus FTBFS as I reported in #589582
 so I'm raising the severity for that bug.
   
you are right to do so. Eucalyptus was broken by this update,
i.e. it is not only FTBSing but brought to a complete standstil.
If not updated, then Eucalyptus has to be dropped from testing.

The Eucalyptus developers have released version 2.0 a while
back and wanted to have long gone towards a respective upload.
As an alternative I had prepared a

libhibernate3,3-java

package already. But it would require a rebuilt Ecalyptus suite, too, and 
if the update 2.0 happens then the 3.3 version is obsolete, so I was not overly
motivated to go for that either. The Eucalyptus developers kindly offer Debian
packages from their site, so we don't do too much harm to us.

Many greetings

Steffen






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

Bug#595613: [Debian-med-packaging] Bug#595613: Moving all EMBOSS libraries to /usr/lib/emboss/lib ?

[Steffen Möller]

 Hi Charles,

sounds good to me, too! The Java community has lots of such internal
libraries and your issues seem to be of the same nature. Have many
thanks for your efforts,

Steffen

On 09/13/2010 07:17 AM, Charles Plessy wrote:
 Dear all,

 the EMBOSS libraries sometimes break backwards compatibility, and are not used
 by other packages than emboss and embassy-*, which have the same upstream
 maintainers and are released together the same day.

 In our Debian packages, I propose to move the EMBOSS libraries from /usr/lib,
 for instance in /usr/lib/emboss/lib, and to merge the packages libajax6,
 libajax6-dev, libnucleus6, libnucleus6-dev, into the emboss-lib package. This
 will also prevent package renaming or confusion when versions 7 and higher of
 EMBOSS will be released.

 Together with a change of section, it will also make the EMBOSS libraries
 private from a Debian point of view, and solve our problem with emboss-lib 
 that
 currently does not respect the Policy with the eplplot library (a fork of the
 plplot library that should not be used outside EMBOSS).

 Since I am not very familiar with library packaging, I seek your comments.

 Have a nice day,





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

Bug#594860: [Debian-med-packaging] Bug#594860: hmmer: FTBFS (powerpc): altivec and cast errors

[Steffen Möller]

Hello,
this is somewhat mysterious to me. I presume that altivec is kind of found but 
also not configured at the same time. Charles, I
recall you to be a PowerPC user, could you please test this

--- debian/rules(revision 5197)
+++ debian/rules(working copy)
@@ -3,8 +3,19 @@
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk

+ARCH=`dpkg-architecture -qDEB_BUILD_ARCH_CPU`
+
+ifeq (amd64,$(ARCH))
+DEB_CONFIGURE_EXTRA_FLAGS := --enable-threads --enable-sse 
--mandir=$(CURDIR)/debian/tmp/usr/share/man
+else
+ifeq (powerpc,$(ARCH))
+DEB_CONFIGURE_EXTRA_FLAGS := --enable-threads --enable-vmx 
--mandir=$(CURDIR)/debian/tmp/usr/share/man
+else
+DEB_CONFIGURE_EXTRA_FLAGS := --enable-threads 
--mandir=$(CURDIR)/debian/tmp/usr/share/man
+endif
+endif
+
 #DEB_CONFIGURE_EXTRA_FLAGS := --enable-threads --enable-mpi
-DEB_CONFIGURE_EXTRA_FLAGS := --enable-threads 
--mandir=$(CURDIR)/debian/tmp/usr/share/man
 DEB_MAKE_INSTALL_TARGET := install prefix=$(CURDIR)/debian/tmp/usr
 DEB_MAKE_CHECK_TARGET = check


which is not necessarily nice but it expclicitly switches on vmx on powerpc 
which should then define the flag which then includes
the missing altivec.h. More is on http://m68hc11.serveftp.org/doc/gcc_5.html .

I will commit this to svn as unreleased and then wait for reports. Many thanks

Steffen

On 08/30/2010 10:49 AM, Philipp Kern wrote:
 Source: hmmer
 Version: 3.0-2
 Severity: serious
 

 sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on porpora.debian.org

 ╔══╗
 ║ hmmer 3.0-2 (powerpc)  29 Aug 2010 
 18:06 ║
 ╚══╝
 [...]
 gcc -std=gnu99 -I. -I. -g -O2 -g -Wall -O2 -pthread -maltivec -mabi=altivec  
 -o esl_vmx.o -c esl_vmx.c   
 In file included from esl_vmx.c:38:
 esl_vmx.h: In function 'esl_vmx_set_float':
 esl_vmx.h:30: warning: implicit declaration of function 'vec_lde'
 esl_vmx.h:30: error: incompatible types when assigning to type '__vector 
 float' from type 'int'
 esl_vmx.h:31: warning: implicit declaration of function 'vec_lvsl'
 esl_vmx.h:31: error: incompatible types when assigning to type '__vector 
 unsigned char' from type 'int'
 esl_vmx.h:32: warning: implicit declaration of function 'vec_perm'
 esl_vmx.h:32: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:33: warning: implicit declaration of function 'vec_splat'
 esl_vmx.h:33: error: AltiVec argument passed to unprototyped function
 esl_vmx.h: In function 'esl_vmx_set_s16':
 esl_vmx.h:48: error: incompatible types when assigning to type '__vector 
 signed short' from type 'int'
 esl_vmx.h:49: error: incompatible types when assigning to type '__vector 
 unsigned char' from type 'int'
 esl_vmx.h:50: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:51: error: AltiVec argument passed to unprototyped function
 esl_vmx.h: In function 'esl_vmx_set_u8':
 esl_vmx.h:66: error: incompatible types when assigning to type '__vector 
 unsigned char' from type 'int'
 esl_vmx.h:67: error: incompatible types when assigning to type '__vector 
 unsigned char' from type 'int'
 esl_vmx.h:68: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:69: error: AltiVec argument passed to unprototyped function
 esl_vmx.h: In function 'esl_vmx_hsum_float':
 esl_vmx.h:83: warning: implicit declaration of function 'vec_add'
 esl_vmx.h:83: warning: implicit declaration of function 'vec_sld'
 esl_vmx.h:83: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:83: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:84: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:84: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:85: warning: implicit declaration of function 'vec_ste'
 esl_vmx.h:85: error: AltiVec argument passed to unprototyped function
 esl_vmx.h: In function 'esl_vmx_hsum_s16':
 esl_vmx.h:100: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:100: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:101: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:101: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:102: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:102: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:103: error: AltiVec argument passed to unprototyped function
 esl_vmx.h: In function 'esl_vmx_hmax_float':
 esl_vmx.h:118: warning: implicit declaration of function 'vec_max'
 esl_vmx.h:118: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:118: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:119: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:119: error: AltiVec argument passed to unprototyped function
 esl_vmx.h:120: error: AltiVec argument 

Bug#593331: [pkg-eucalyptus-maintainers] Bug#593331: eucalyptus-cloud: Eucalyptus cloud controller and walrus does not start

[Steffen Möller]

Just a hunch. Could you please reinstall the previous version of
libhibernate? This has been updated to 3.5.4.Final very recently and
while reading hibernate so often in your report below this just kind
of triggers me thinking that we might possibly first search there.

To get there, you'd
sudo apt-get install libhibernate3-java=3.3.2.GA-2

Should that version not be available any more on the Debian servers (it
should) then you'd find it on snapshot.debian.org .

Sorry for the hassle that this update brought and thank you for your report.

Steffen


On 08/17/2010 11:52 AM, Maciej Galkiewicz wrote:
 Package: eucalyptus-cloud
 Version: 1.6.2-2
 Severity: grave
 Justification: renders package unusable

 I have debian squeeze updated today (17.08.2010) with kernel 2.6.32-5. After 
 installation eucalyptus-cloud, eucalyptus-cc and eucalyptus-walrus, 
 eucalyptus-cloud service does not start. Cluster controller seems to work 
 fine (at least it listens on tcp port). Eucalyptus-cloud and walrus do not 
 even listen on their ports (8443, 8773). After the same dist-upgrade 
 (13.08.2010) everything works fine. I have already solved #593254 and #589815.

 Logs from /var/log/eucalyptus/cloud-output.log (cloud-error is empty):
 
  
 
  | Proxool config for general
  | 
 
 10:40:07  INFO LogUtil   | ?:? 
 proxool.eucalyptus_general:org.hsqldb.jdbcDriver:jdbc:hsqldb:hsqls://127.0.0.1:9001/eucalyptus_general
 10:40:07  INFO LogUtil   | ?:? 
 {proxool.simultaneous-build-throttle=16, proxool.minimum-connection-count=16, 
 proxool.maximum-connection-count=128, proxool.house-keeping-test-sql=SELECT * 
 FROM COUNTERS;, user=sa, 
 password=8098246ba3f4774701dea3606fb1cad414dd3eb8af5c2dbd499a82d1e005aed9ff6502008b5d3c6081edc7dfc78fcc0ebd8607e866e086c9333a0b2ad0a5e4f2b63d7e88a583f3ff81e39b9bfec520f1eae37647912b6c050cdbd76aa463a5ad6ae999125bcec9a70a4747c02e1ed15433ca170956fb54c31fdb9e17a038ee5757d9a4e5ad103b3217983968c34ba03b767f623c4c812360bc5269575bdf660d46210244ecf312f72b14c636e59bae3d166f5ab7f88622914902e631ecd66de7f23efba84e4cc040a245acea8eb773c2a3b0ecce9423b7e0aad6a7f5a6b245c5fbfeedf83bc7273d84311c8766189309d2588ca41509ce5c41f2d2d84a716b73}
 10:40:07  INFO ProxoolFacade | ProxoolFacade.java:86 Proxool 
 0.9.1+
 10:40:07  INFO LogUtil   | ?:? 
 
  | Hibernate for general
  | 
 
 10:40:07  INFO LogUtil   | ?:? 
 [hibernate.archive.autodetection:jar, class, hbm, 
 hibernate.show_sql:false, hibernate.format_sql:false, 
 hibernate.connection.autocommit:true, hibernate.hbm2ddl.auto:update, 
 hibernate.generate_statistics:true]
 10:40:07  INFO LogUtil   | ?:? 
 
  | Pool for general
  | 
 
 10:40:07  INFO LogUtil   | ?:? 
 [hibernate.bytecode.use_reflection_optimizer:true, 
 hibernate.cglib.use_reflection_optimizer:true, 
 hibernate.dialect:org.hibernate.dialect.HSQLDialect, 
 hibernate.connection.provider_class:org.hibernate.connection.ProxoolConnectionProvider,
  hibernate.proxool.pool_alias:eucalyptus_general, 
 hibernate.proxool.existing_pool:true]
 10:40:07  INFO LogUtil   | ?:? 
 
  | Cache for general
  | 
 
 10:40:07  INFO LogUtil   | ?:? 
 {hibernate.cache.provider_class=net.sf.ehcache.hibernate.SingletonEhCacheProvider,
  hibernate.cache.region_prefix=eucalyptus_general_cache, 
 hibernate.cache.use_second_level_cache=true, 
 hibernate.cache.use_query_cache=true, 
 hibernate.cache.use_structured_entries=true}
 10:40:08  INFO ReentrantListenerRegistry | ReentrantListenerRegistry.java:26 
 Registering event listener for class 
 com.eucalyptus.event.SystemConfigurationEvent: [Addresses 
 canHas=ReentrantReadWriteLock[Write locks = 0, Read locks = 0] activeMap=[:] 
 disabledMap=[:]]
 10:40:08  INFO GroovyUtil| GroovyUtil.java:80 Trying to load 
 config for edu.ucsb.eucalyptus.cloud.ws.SystemState from 
 //etc/eucalyptus/cloud.d/scripts/vmstate.groovy
 10:40:09  INFO eucalyptus_general| ConnectionPool.java:617 Proxool 
 

Bug#593331: [pkg-eucalyptus-maintainers] Bug#593331: eucalyptus-cloud: Eucalyptus cloud controller and walrus does not start

[Steffen Möller]

On 08/17/2010 02:11 PM, Maciej Gałkiewicz wrote:
 Now it works! Thank you very much.
   
May I just ask what you have done? Was it a restart of the System or any
change of the configuration?

Thanks and regards

Steffen



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

Bug#593254: closed by Torsten Werner twer...@debian.org (Bug#593254: fixed in libhibernate3-java 3.5.4.Final-3)

[Steffen Möller]

On 08/16/2010 11:21 PM, Debian Bug Tracking System wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the libhibernate3-java package:
 
 #593254: conflict with hybernate-entitiymanager-java 3.4.0 on .jar

libhibernate-entitymanager-java

It has not yet arrived on the ftp.de.d.o mirror, just please check
that it is i not y.

Cheers,

Steffen



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

Bug#592544: [pkg-fso-maint] Bug#592544: New license

[Steffen Möller]

Hello,

this license is more liberal than the GPL.  Are you linking
against anything that is purely GPLed? Then we'd need to
do some thinking. I could imagine that you could even
relicense it as it also allows the sublicensing, but this
is beyond my legal understanding. I hope we don't need
to clarify this.

For a redistribution with Debian (this is why you ask, no?)
this is all not a problem. Debian does not require the GPL.
Debian only requires to DFSG compliance - for a
redistribution in 'main' this is. And the DFSG compliance is
just fine with this license.

Cheers,

Steffen


On 08/11/2010 02:32 AM, Scott Howard wrote:
 Upstream has changed their license [1].

 They no longer require the advertising clause: In addition publicly
 documented acknowledgment must be given that this software has been used if no
 source code of this software is made available publicly. Does GPL's
 requiring that the source code be publicly available make this license
 compatible with GPL?



 [1]:
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the Software), to
 deal in the Software without restriction, including without limitation the
 rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
 sell copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:

 The above copyright notice and this permission notice shall be included in
 all copies of the Software and its Copyright notices. In addition publicly
 documented acknowledgment must be given that this software has been used if no
 source code of this software is made available publicly. Making the source
 available publicly means including the source for this software with the
 distribution, or a method to get this software via some reasonable mechanism
 (electronic transfer via a network or media) as well as making an offer to
 supply the source on request. This Copyright notice serves as an offer to
 supply the source on on request as well. Instead of this, supplying
 acknowledgments of use of this software in either Copyright notices, Manuals,
 Publicity and Marketing documents or any documentation provided with anyad
 product containing this software. This License does not apply to any software
 that links to the libraries provided by this software (statically or
 dynamically), but only to the software provided.

 Please see the COPYING-PLAIN for a plain-english explanation of this notice
 and its intent.

 THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
 THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
 IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.



 ___
 pkg-fso-maint mailing list
 pkg-fso-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
   




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

Bug#592417: [Debian-med-packaging] Bug#592417: mgltools-utpackages: ships files in /build

[Steffen Möller]

Hello,

thank you for this pointer. The mgltools packages are all due for an overhaul.
I'll address them all this week.

Have many thanks

Steffen

On 08/09/2010 09:21 PM, Jakub Wilk wrote:
 This is an FHS violation.



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

Bug#589815: [pkg-eucalyptus-maintainers] Bug#589815: groovy does not provide classes needed

[Steffen Möller]

severity 589815 normal
tags 589815 confirmed
thanks

Dominique, great job! I was not aware of the groovy.jar
in /usr/share/eucalyptus.
On 07/24/2010 08:41 PM, Dominique Belhachemi wrote:
 this temporary workaround might help.
 
 mv /usr/share/eucalyptus/groovy.jar /usr/share/eucalyptus/groovy.jar.bckup
 ln -s /usr/share/java/groovy-all.jar /usr/share/eucalyptus/groovy.jar

I can confirm the web interface to be back up. The problem apparently was
the unresolved wildcard in
# ls -l /usr/share/eucalyptus/groovy.jar.bckup
lrwxrwxrwx 1 root root 36 Jul 21 11:16 /usr/share/eucalyptus/groovy.jar.bckup 
- ../groovy/embeddable/groovy-all*.jar


Cheers,

Steffen



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

Bug#586851: [Debian-med-packaging] Bug#586851: mgltools-vision: diff for NMU version 1.5.4.cvs.20090603-1.1

[Steffen Möller]

Hello,
 Dear maintainer,
 
 I've prepared an NMU for mgltools-vision (versioned as
 1.5.4.cvs.20090603-1.1) and
 uploaded it to DELAYED/3. Please feel free to tell me if I
 should delay it longer.

great! Thanks!

 Regards.
 
 PS some tests still fail (same number for Python 2.5 and Python 2.6)
 PPS binary package name should be python-vision

No, it should either be vision or mgltools-vision. I know about the policy, but 
it does not fit here since the vision pakckage is truly for end users, not some 
library, and they don't care how it is implemented.

Cheers,

Steffen




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

Bug#586830: [Debian-med-packaging] Bug#586830: Bug#586830: marked as done (hardcodes Python 2.5)

[Steffen Möller]

On 06/30/2010 09:05 AM, Piotr Ożarowski wrote:
 [Charles Plessy, 2010-06-30]
   
 What makes you think that autodocktools works with python 2.6 if upstream
 hardcoded it for 2.5. Have you tested the package before uploading?

 I understand that you may be disapointed that we have not answered your bug
 report, but please consider that people may be busy, and that the absence of
 answer does not mean that we were not thinking about the question (can 
 autodock
 run with python = 2.5?).

 I am still puzzled why a NMU with no consultation with the maintainer was
 chosen instead of simply removing the package from Testing.
 
 yeah, I did some code reviewing and didn't spot anything that doesn't
 work with 2.6. Could you point me to what is not working so that I can
 fix it since you're busy?
   
You could do me a great favour if you go for the real thing,
i.e. get the packages from upstream CVS of which they know it is
compatible with 2.6. It is also my experience from the 2.5 transition
that there won't be too many packages affected. But it is not
on us to decide that, really, so I think.

If you are actively using the autodocktools then I am happy
for your contribution and expect you to deal with any problems.
If not, then I am too busy to be offended.

Many greetings

Steffen



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

Bug#586839: [Debian-med-packaging] Bug#586839: mgltools-gle: depends on python ( 2.6)

[Steffen Möller]

On 06/30/2010 09:27 AM, Ralf Treinen wrote:
 After the recent transition of phython-2.6 to testing, this makes 
 mgltools-gle also uninstallable in testing.
   
Pjotr, can you please address this one and all the other mgltool-*
packages that are not autobuilt, too?

Many thanks

Steffen





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

Bug#586143: And where do I now get a 64bit DSL rescue disk?

[Steffen Möller]

Hello,

this grub version needs to be removed immediately from unstable. It discourages 
enormously the use of unstable  to filter for testing. 
 
The /boot/grub/stage/stage2 and stage1 files are existing on my system. 

Maybe I was too happy with unstable for too long and have given my 64bit  
rescue USB sticks as presents to too many people (where are those beasts) and I 
just cannot do the chroot with the 3year old 32bit putty that I have come 
across.

Steffen



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

Bug#586143: OT

[Steffen Möller]

Hi Torsten,
 Datum: Sat, 19 Jun 2010 00:23:17 +0200
 Von: Torsten Werner twer...@debian.org

 Am 18.06.2010 21:42, schrieb Steffen Möller:
  this grub version needs to be removed immediately from unstable.
 
 just purge the grub2 related binary packages from your system if you do
 not like them. :)

:)
 
 Removing a package from unstable would remove it from testing too
 because testing tracks unstable. I doubt that this makes sense for the
 grub2 package.

Good point. My intention obviously was not to have more fellows
temporarily brick their systen. How many will it be if this is fixed
within the next day? 100? 250? 500? 1000? Well, if it is just 10 then 
everything just fine how it is. If it is 20 I am not so sure any more.

Cheers,

Steffen



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

Bug#582759: qtdmm: FTBFS: [ -r Makefile ] /usr/bin/make distclean → make: *** [clean] Error 1

[Steffen Möller]

Hello,
 your package FTBFS everywhere:
 | # Add here commands to clean up after the build process.
 | [ -r Makefile ]  /usr/bin/make distclean
 | make: *** [clean] Error 1
   
sorry, it should have been ! -r and ||

Thanks, I'll upload later tonight, please feel free to NMU should you be
using QtDMM yourself.

Steffen



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

Bug#581576: gridengine-client and torque-doc: error when trying to install together

[Steffen Möller]

Hi Ralf,

this is a great service of yours.

On 05/17/2010 08:39 AM, Ralf Treinen wrote:

 this isn't solved yet for torque-doc which still clashes with 
 gridengine-client:
 
 dpkg-deb: subprocess paste killed by signal (Broken pipe)
 Processing triggers for man-db ...
 Errors were encountered while processing:
  /var/cache/apt/archives/torque-doc_2.4.8+dfsg-4_all.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 
 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be
 slightly out of sync):
 
   /usr/share/man/man1/qalter.1.gz
   /usr/share/man/man1/qdel.1.gz
   /usr/share/man/man1/qhold.1.gz
   /usr/share/man/man1/qrls.1.gz
   /usr/share/man/man1/qselect.1.gz
   /usr/share/man/man1/qstat.1.gz
   /usr/share/man/man1/qsub.1.gz

those files need to be moved to the -client package(s).

Many thanks

Steffen



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

Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Charles Plessy schrieb:
 Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit :
   
 I still believe it is best to rename 'plink' to 'puttylink' in
 putty-tools binary package. Anyway, this should be fixed for squeeze
 since in lenny there is no conflict (plink is not included in lenny).
 

 Hi all,

 Upstream documented the renaming on his website, so I think that that is the
 (happy) end of the story :)

   Debian users: PLINK is available as a Debian package, see these notes. 
 Note, the
   executable is named snplink in the Debian plink package.

 http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml
   
To me, the renaming to snplink is an exceptionally unfortunate way to
address the name-conflict we experienced. This way, we render Debian
incompatible with scripts distributed in the community and incompatible
with computational grids, too. I am just writing from a grid conference
and plink was indeed referenced on one slide. I don't want either plink
to be renamed, completely following the points brought up Brian and
definitely prefer a conflict between the two plink packages. Those users
who _really_ need both and _really_ need to work with Debian packages
only, they can have a chroot environment for the bioinformatics-plink.
Besides: there is a SNPLINK already:
http://bioinformatics.oxfordjournals.org/cgi/content/full/21/13/3060

The executable in either package should not be renamed. I don't see a
reasonable way around it. The only problem that I originally understood
from skimming over the thread was that Debian packages would be named
equally and I was too busy to wonder for too long how this could be
allowed by the Debian infrastructure. But embarrassingly, after checking
things manually, I just spotted that putty's plink is not coming as a
package with that name but that it is wrapped up to the package
putty-tools. This is just fine to me. I'll add a Conflicts:
putty-tools to the plink control file, upload plink's new version 1.04
and we are set.

To summarise things up: the renaming of the executable of plink to
snplink renders the plink package inferior to a manual installation of
plink under the proper name. What I'll do now unless I hear some
objections that I am mentally prepared to follow: I'll prepare the new
version, add the conflict to debian/control to close 503367 (won't fix)
and herewith truly apologize for all these emails.

Best,

Steffen



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Hello,

Teodor schrieb:
 On Tue, Oct 28, 2008 at 12:54 PM, Steffen Möller [EMAIL PROTECTED] wrote:
   
 Charles Plessy schrieb:
 
 Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit :
   
 I still believe it is best to rename 'plink' to 'puttylink' in
 putty-tools binary package. Anyway, this should be fixed for squeeze
 since in lenny there is no conflict (plink is not included in lenny).
 

 That was based on the assumption that the project name is well
 established (plink).  I had no idea and I couldn't find on the project
 site what 'p' stands for. A more appropriate and suggestive name for
 the project is this one given by upstream: snplink.
 I have a feeling that upstream will change the project name from plink
 to something more appropriate (like snplink) to avoid the confusion.

   
 Upstream documented the renaming on his website, so I think that that is the
 (happy) end of the story :)
   

 Yes, it is. :)
   
Except that snplink is taken by another program and Debian remains
incompatible for scripts shared in the community. Even if we find
another name, then it seems likely that another later program would have
that name, just having been checked against the real project names. The
iceweasel-icedove solution has the same problem, in principle.
 ...(won't fix)...
 That would be serious bug against 'plink' according to Debian policy.
 Read the whole thread starting at [1] or this specific message [2].


 [1]  http://lists.debian.org/debian-devel/2008/10/msg00633.html
 [2]  http://lists.debian.org/debian-devel/2008/10/msg00644.html
   
I need to thank all your friendly, constructive and informative replies.
As stated before I agree that that putty-tools's plink should not be
renamed (for the same reasons as plink's plink should not be renamed),
and I have now reread and understood what the policy says and following
these lines I share your conclusion that it should be plink's plink that
should be renamed. However, I still think that albeit adhering to the
Debian policy, the decision is inpractical and hence wrong. I personally
see four alternatives:
 a) removing the newly package plink from the archive
 b) add an exception to Debian policy for the case that the two packages
in name-conflict are not in the base distribution and the two
maintainers agree that the conflict in names does not matter enough to
be concerned
 c) add an exception to Debian policy when the two packages are of
different priorities and both are out of base, having optional beating
extra and the two maintainers agree.
 d) have the binary install below /usr/lib rather than /usr/bin and
there is some mechanism to set the path right, which should be executed
prior to the execution of any script that is executing plink.

I personally am happy with any of the four alternatives but obviously
would best like b) or c). With an increasing number of applications in
Debian I am certain that b) or c) will be needed sooner or later, but d)
may be another interesting option for many. What do you think?

Cheers,

Steffen




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503367: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools

[Steffen Möller]

Hello,

plink has just made it to the archive.

Teodor happened to have nicely explained my objections to rename plink.

Dear Colin, if you don't mind too much, or if you could be bribed with a
few beers, please be so kind to rename the plink binary package.

Many thanks and best regards,

Steffen (who should have checked and asked prior to his upload)

Teodor schrieb:
 On Sat, Oct 25, 2008 at 12:24 PM, Charles Plessy [EMAIL PROTECTED] wrote:
   
 Both programs are intended for command line, and could be used in
 scripts. We may even find users who want to install both at the same
 time. Very annoying…

 Since Plink is younger than Putty, I think that the burden of the
 renaming is for us (the Debian Med packaging team). I plan to rename
 /usr/bin/plink to /usr/bin/Plink, that would be a symbolic link to
 /usr/lib/plink/plink so that with an appropriate PATH, users can rescue
 their scripts.
 

 Since renaming seems to be the only solution, than IMO it is more
 appropriate to rename 'plink' in putty-tools than in the plink
 packages since this is exactly the source/binary package name. This
 has been done already in putty-tools for the 'puttygen' binary.

 Thanks


 
 piti:~# dpkg -L putty-tools
 [snip]
 /usr/bin/pscp
 /usr/bin/psftp
 /usr/bin/plink
 /usr/bin/puttygen
   




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]