Bug#822118: RM: fw4spl -- RoQA, unmaintained, RC-buggy, FTBFS, blocks removal of old packages

[Corentin Desfarges]

Hi

As I said to Andreas a few weeks ago, the FW4SPL team is currently
working on a new version of the framework using VTK6, ITK4, and the
new Boost version.
We should be able to remove the dependences to the old versions of
these packages over the next week.

About libpng, I'm not sure to understand. FW4SPL depends on
libpng-dev, and if I refers to the sid packages list, libpng-dev is
related to libpng1.6, not libpng1.2.

Best regards,

Corentin


On Thu, 21 Apr 2016 14:39:26 +0200 Tobias Frost  wrote:
> Package: fw4spl
> Severity: serious
> Justification: blocks-transitions
>
> Dear maintainer / ftp-masters,
>
> fw4spl is RC buggy with 5 bugs:
>  #797475 fw4spl: does not support parallel build
>  #797481 fw4spl: FTBFS - Doesn't support boost 1.58
>  #809935 fw4spl: FTBFS with libpng16
>  #820632 fw4spl: depends on vtk 5
>  #821957 fw4spl: Depends on insighttoolkit, which is about to be removed. 
> Please port to insighttoolkit4
>
> With the first two filed August 2015; both of them did not receive any 
> response from the maintainer, though
> extra triggered again by Andreas in December.
>
> (The other two bugs do not ahve a response too, but they are only a few days 
> old)
>
> The package blocks the boost, libpng and vtk transitions.
>
> As it is now blocking other packages, I raise the question if it should be
> removed from Debian.
>
> Please response to this bug, if there is no response within a week, I will
> reassign this bug to ftp.debian.org.
>
> Please note, that if decide to keep it, you need to fix your pacakge ASAP.
> The removal of libpng1.2 will NOT wait for root-system, and when removed,
> at least the binary packages must go with it. (Which can lead to src removal)
>
> Thanks for your understanding,
>
> --
> tobi
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
>

Bug#817939: RM: fw4spl -- RoQA; RC buggy, NPOASR, depends on to-be-removed package

[Corentin Desfarges]

Hi,

First, I would like to apologize for the delay of my answer.
I have a lot of work in parallel, and my situation won't change before june
or july.

However, I can confirm that the FW4SPL team doesn't want to leave the
Debian Med project.
I think that the packaging of fw4spl 0.9.2 won't be maintained, and that
the team will work on the packaging of an other version. This version
depends on VTK6 and ITK4.

I transmit your messages to the team, and I keep you updated.

Best regards,

Corentin

2016-04-10 22:34 GMT+02:00 Sebastiaan Couwenberg :

> On Thu, 17 Mar 2016 19:13:21 +0100 Andreas Tille wrote:
> > On Fri, Mar 11, 2016 at 07:14:09PM +, Mattia Rizzolo wrote:
> > > On Fri, Mar 11, 2016 at 08:55:42PM +0200, Esa Peuha wrote:
> > > > Package: ftp.debian.org
> > > >
> > > > fw4spl has had only three upload to Debian: the first two a few
> > > > days apart in March 2015, the third in July.
> > >
> > > the fact that a package had the last maintainer upload so "recently"
> > > tell me that it should be good to wait.  though here the maintainer
> > > seems to have disappeared, indeed.
> > >
> > > Please try to at least CC the maintainer when you file a RoQA for the
> > > removal of the full source package, adding $p...@pacakges.debian.org to
> > > X-Debbugs-CC is more than enough.
> >
> > I would like to stress the fact that the Debian Med team would like to
> > keep this package inside Debian.  The package and its dependencies are
> > complex.  The intention is to switch to insighttoolkit4 so it will not
> > really block the removal of insighttoolkit (version 3).
> >
> > Thanks for your patience
> >
> > Andreas.
> >
> > PS: Corentin, it would be good if you would be able to give some rough
> > estimation of the time needed.
>
> Please reconsider your desire to keep this package inside Debian.
> Keeping the package in unstable in its currently shape is hindering
> various other packages in its dependency chain. See #820632 for example.
>
> This package is keeping libvtk5.8 in unstable, and that keeps the old
> netcdf packages around which hinder testing migration of every new
> package revision since two transitions ago (back in October 2015).
>
> fw4spl is likewise keeping the gdcm (2.4.4-4) packages in unstable,
> which have long since been superseded by the 2.6 series. These also keep
> libvtk5.8 in unstable.
>
> This package should be removed from the Debian archive until a new
> release supporting the current versions of the dependencies can
> reintroduce the package in Debian.
>
> It's sad to see that the other reverse dependencies that are keeping
> libvtk5.8 in Debian unstable are all maintained by the Debian Med Team.
> The VTK situation in Debian has been highly annoying for far too long
> already, we should not have to endure that any longer. We should get rid
> of all the badly maintained packages that are prolonging the pain.
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>

Bug#781294: fw4spl: FTBFS: trouble finding HDF5

[Corentin Desfarges]

Normally, the bug you reported is fixed in the latest version of the 
package, which will soon be uploaded.


Thank you for your feedback.

Corentin

On Thu, 26 Mar 2015 23:39:51 -0400 Aaron M. Ucko u...@debian.org wrote:
 Source: fw4spl
 Version: 0.9.2-1
 Severity: serious
 Justification: fails to build from source

 Automated builds of fw4spl have been failing to detect HDF5 fully:

 -- Configuring fwAtomsHdf5IO: /«PKGBUILDDIR»/SrcLib/io/fwAtomsHdf5IO
 CMake Warning (dev) at CMakeLists.txt:135 (get_target_property):
 Policy CMP0026 is not set: Disallow use of the LOCATION target property.
 Run cmake --help-policy CMP0026 for policy details. Use the 
cmake_policy

 command to set the policy and suppress this warning.

 The LOCATION property should not be read from target fwAtomsHdf5IO. Use
 the target name directly with add_custom_command, or use the generator
 expression $TARGET_FILE, as appropriate.

 Call Stack (most recent call first):
 CMakeLists.txt:300 (configureProject)
 CMakeLists.txt:537 (fwLib)
 SrcLib/io/fwAtomsHdf5IO/CMakeLists.txt:1 (fwLoadProperties)
 This warning is for project developers. Use -Wno-dev to suppress it.

  : /usr/include/hdf5/serial
 -- Found HDF5: 
HDF5_LIBRARY-NOTFOUND;/usr/lib/i386-linux-gnu/libhdf5_cpp.so


 I'm not sure what the problem is, since fw4spl properly declares a
 build dependency on libhdf5-dev, and CMake is able to locate
 libhdf5_cpp.so.

 Could you please take a look?

 Incidentally, there are a lot of warnings about the LOCATION property
 cluttering up CMake's output; please also consider either addressing
 or at least suppressing them.

 Thanks!




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

Bug#781298: missing Built-Using: qt4-x11

[Corentin Desfarges]

Hi Helmut,

Normally, the bug you reported is fixed in the latest version of the 
package, which will soon be uploaded.


I added rdfind and symlinks to my Build-Depends, and these lines in 
d/rules (in override_dh_auto_install) :


   rdfind -outputname /dev/null -makesymlinks true debian/fw4spl/
   symlinks -r -s -c debian/fw4spl

Does everything looks right for you ?

Thank you for your feedback.

Corentin


On Fri, 27 Mar 2015 08:00:46 +0100 Helmut Grohne hel...@subdivi.de wrote:
 Package: fw4spl
 Version: 0.9.2-1
 Severity: serious
 Justification: policy 7.8

 fw4spl copies parts of libqt4-qt3support during build:

 http://dedup.debian.net/compare/fw4spl/libqt4-qt3support

 It therefore must list qt4-x11 in Built-Using according to the Debian
 policy section 7.8.

 Of course, the better solution here is not to copy libraries
 libqt4-qt3support in the first place. You may be able to do with
 symbolic links and a suitable dependency.

 If you choose to keep that copy, please also register your embedded copy
 with the security tracker:

 https://wiki.debian.org/EmbeddedCodeCopies

 Helmut


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

Bug#779632: ITP: fw4spl -- FrameWork for Software Production Line

[Corentin Desfarges]

Package: wnpp
Severity: wishlist
Owner: Corentin Desfarges corentin.desfarges@gmail.com

* Package name: fw4spl
  Version : 0.9.2
  Upstream Author : Johan Moreau johan.mor...@gmail.com
* URL : https://github.com/fw4spl-org/fw4spl
* License : LGPL
  Programming Lang: C++
  Description : FrameWork for Software Production Line

FW4SPL consists of a set of cross-platform C++ libraries. For 
now, FW4SPL focuses on the problem of medical images processing 
and visualization, and propose an open-source application called 
VRRender, which is able to load a series of images stored in 
DICOM format (uncompressed and JPEG) and 3D-modeled patients for 
medical review.


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

Bug#759244: ITP: camp -- C++ multi-purpose reflection library

[Corentin Desfarges]

Package: wnpp
Severity: wishlist
Owner: Corentin Desfarges corentin.desfarges@gmail.com

* Package name: camp
  Version : 0.7.1
  Upstream Author : Laurent Gomila laurent@gmail.com
* URL : https://github.com/tegesoft/camp
* License : LGPL3, GPL3
  Programming Lang: C++
  Description : C++ multi-purpose reflection library

  CAMP is a multi-purpose reflection library developped by Technogerma Systems 
France
(http://www.tegesoft.com).

It provides an abstraction for most of the high-level concepts of C++:
- Classes
- Enumerations
- Properties
- Functions
- Objects
- Variables

By wrapping all these concepts into abstract structures, CAMP provides an extra 
layer of
flexibility to programs, and allow them to fully expose their data structures 
at runtime.

Many applications can take advantage of CAMP, in order to automate tasks which 
would
otherwise require a huge amount of work. For example, CAMP can be used to 
expose and edit
objects' attributes into a graphical user interface. It can also be used to do
automatic binding of C++ classes to script languages such as Python or Lua.
Another possible application would be the serialization of objects to XML, text 
or
binary formats. Or you can even combine all these examples to provide a powerful
and consistent interface for manipulating your objects outside C++ code.


I need to pack Camp to use it for a most important package, fw4spl 
(http://code.google.com/p/fw4spl/)


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