Bug#862198: ITP: python-bayespy -- variational Bayesian inference tools for Python

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-bayespy
  Version : 0.5.6
  Upstream Author : Jaakko Luttinen 
* URL : https://www.bayespy.org/
* License : Expat
  Programming Lang: Python
  Description : variational Bayesian inference tools for Python

Long-Description:
 BayesPy provides tools for Bayesian inference with Python. The user constructs
 a model as a Bayesian network, observes data and runs posterior inference. The
 goal is to provide a tool which is efficient, flexible and extendable enough
 for expert use but also accessible for more casual users.

This package will be co-maintained by the Debian Science Team.

Forward porting a package

[Boylan, Ross]

I am trying to build db4.2 in jessie, although the package is from wheezy.  I 
only need db4.2-util.  I got the source and modified changed tcl8.4 to tcl8.6 
in rules and control.  But the build (invoked with dpkg-buildpackage) fails 
while running configure with
checking size of char *... 0
checking for off_t... no
configure: error: No off_t type.
debian/rules:64: recipe for target 'build' failed
make: *** [build] Error 1

There are also earlier warnings about some headers that are present but can not 
be compiled, as well as an apparent failure to find any of the standard types
checking for inttypes.h... (cached) yes
checking for char... no
checking size of char... 0
checking for unsigned char... no
checking size of unsigned char... 0
checking for short... no
checking size of short... 0
checking for unsigned short... no
checking size of unsigned short... 0
checking for int... no
checking size of int... 0
checking for unsigned int... no
checking size of unsigned int... 0
checking for long... no
checking size of long... 0
checking for unsigned long... no
checking size of unsigned long... 0
checking for size_t... no
checking size of size_t... 0
checking for char *... no
checking size of char *... 0

Any suggestions?  Would rerunning autoconf be likely to help?

The help for "present but could not be compiled" indicates the relevant macros 
should be invoked with additional arguments, though I'm not sure what the 
missing files are.

Context: I'm trying to migrate an old installation of cyrus and the upgrade 
process needs to use tools that match the bdb version it uses.

Thanks for any assistance.  cc's appreciated.
Ross Boylan

Re: Forward porting a package

[Ben Hutchings]

On Tue, 2017-05-09 at 19:41 +, Boylan, Ross wrote:
> I am trying to build db4.2 in jessie, although the package is from
> wheezy.  I only need db4.2-util.  I got the source and modified
> changed tcl8.4 to tcl8.6 in rules and control.  But the build
> (invoked with dpkg-buildpackage) fails while running configure with
> checking size of char *... 0
> checking for off_t... no
> configure: error: No off_t type.
> debian/rules:64: recipe for target 'build' failed
> make: *** [build] Error 1

There's apparently something very wrong with the test code that
autoconf is trying to compile.

[...]
> Any suggestions?  Would rerunning autoconf be likely to help?
[...]

Something like that.  You might need to use autoreconf, or
./autogen.sh, rather than invoking autoconf directly.

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your
sig.



signature.asc
Description: This is a digitally signed message part

Re: Forward porting a package

[Chris Lamb]

Ben Hutchings wrote:

> > Any suggestions?  Would rerunning autoconf be likely to help?
> [...]
> 
> Something like that.  You might need to use autoreconf, or
> ./autogen.sh, rather than invoking autoconf directly.

See  for more in this area.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Forward porting a package

[Boylan, Ross]

Thanks Ben and Chris for your suggestions.  I tried auto(re)conf and have 
worked through quite a few issues, though it seems many remain.  Maybe time for 
another approach, like running the old cyrus in a chroot.

1. The macros in the project aclocal directory were not being included because 
a) missing AC_INCLUDE directive; b) they had extensions .ac instead of .m4; c) 
aclocal (the command) needs to be told about the directory explicitly even if 
it's in configure.ac (!?)--the manual says  to put a macro in the automake 
file, but since this project doesn't have one, I invoked aclocal from the 
command line with -I.

With all those changes aclocal (command) kind of works, though I get warnings 
about underquoted macros and things like
warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, 
must contain _cv_ to be cached
and
warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

2. autoconf also runs, producing (at a quick glance) the same warnings.

3. config fails at an earlier point than before with
checking if /usr/lib/jvm/java-gcj/bin/javac works... yes
checking for uudecode... no
configure: WARNING: I have to compile Test.class from scratch
checking if /usr/lib/jvm/java-gcj/bin/java works... yes
checking for /usr/lib/jvm/java-gcj/bin/javac... no
configure: error: cannot find JDK; try setting $JAVAC or $JAVA_HOME
debian/rules:64: recipe for target 'build' failed
make: *** [build] Error 1
So /usr/lib/jvm/java-gcj/bin/javac works (first line above), but then fails at 
the end of the test.  The actual file is 
/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/bin/javac while the rules file has
JAVA_BIN = /usr/lib/jvm/java-gcj/bin

So this is starting to look llke a long trip.

Other options that occur to me:
1) Try using the build system from the current db5.3, but with the old 4.2 code.
2) Try limiting the build to what I need, db4.2-util and presumably the 
libraries it needs
3) Try build from upstream source.
4) Revive old system enough to use the 4.2 libraries to either do their part of 
the upgrade or to convert the databases to a non-bdb format. I'm a little 
nervous about doing a chroot when the host system and the one in the chroot are 
from so many generations apart.   I can use some unionfs (aufs?) and mount the 
old stuff read-only for safety.

Option 4 currently seems like the best bet.  Like all the others, it probably 
won't be as easy to do as to contemplate :)

Ross


From: Boylan, Ross
Sent: Tuesday, May 9, 2017 12:41:53 PM
To: debian-devel@lists.debian.org
Subject: Forward porting a package

I am trying to build db4.2 in jessie, although the package is from wheezy.  I 
only need db4.2-util.  I got the source and modified changed tcl8.4 to tcl8.6 
in rules and control.  But the build (invoked with dpkg-buildpackage) fails 
while running configure with
checking size of char *... 0
checking for off_t... no
configure: error: No off_t type.
debian/rules:64: recipe for target 'build' failed
make: *** [build] Error 1

There are also earlier warnings about some headers that are present but can not 
be compiled, as well as an apparent failure to find any of the standard types
checking for inttypes.h... (cached) yes
checking for char... no
checking size of char... 0
checking for unsigned char... no
checking size of unsigned char... 0
checking for short... no
checking size of short... 0
checking for unsigned short... no
checking size of unsigned short... 0
checking for int... no
checking size of int... 0
checking for unsigned int... no
checking size of unsigned int... 0
checking for long... no
checking size of long... 0
checking for unsigned long... no
checking size of unsigned long... 0
checking for size_t... no
checking size of size_t... 0
checking for char *... no
checking size of char *... 0

Any suggestions?  Would rerunning autoconf be likely to help?

The help for "present but could not be compiled" indicates the relevant macros 
should be invoked with additional arguments, though I'm not sure what the 
missing files are.

Context: I'm trying to migrate an old installation of cyrus and the upgrade 
process needs to use tools that match the bdb version it uses.

Thanks for any assistance.  cc's appreciated.
Ross Boylan

Re: Forward porting a package

[Simon McVittie]

On Tue, 09 May 2017 at 22:48:23 +, Boylan, Ross wrote:
> I'm a little nervous about doing a chroot when the host system and
> the one in the chroot are from so many generations apart.

wheezy (Debian 7) to jessie (Debian 8) is only one release cycle. I would
expect a wheezy chroot to run well on a jessie kernel. I'd suggest
using some chroot wrapper like schroot, or perhaps a more elaborate
OS-container like lxc.

However, if you're concerned about using chroots, a wheezy virtual
machine on a jessie host is definitely something that can work well.
There are several approaches to this; I like libvirt-bin and its
virt-manager GUI.

Working with a copy of your valuable data rather than the original is
usually also a good idea :-)

S

Re: Forward porting a package

[Boylan, Ross]

Oops, I misspoke, the old system is Debian 5, lenny.
The system the disks are on is running Debian 7, wheezy.
And the system I am targetting is Debian 8, jessie.

So the chroot would be lenny while the real system wouldl be wheezy.

The wheezy system already hosts VM's with libvirt.  But getting things working 
as a VM seems a bit tricky.  I can't simply hand the disks over to the VM 
because the host is using them too.  And I'm concerned that anything I give to 
the VM will end up with vm control info written to it, at least if I'm not 
careful.

Ross

Re: Forward porting a package

[Ben Hutchings]

On Wed, 2017-05-10 at 00:38 +0100, Simon McVittie wrote:
> On Tue, 09 May 2017 at 22:48:23 +, Boylan, Ross wrote:
> > I'm a little nervous about doing a chroot when the host system and
> > the one in the chroot are from so many generations apart.
> 
> wheezy (Debian 7) to jessie (Debian 8) is only one release cycle. I would
> expect a wheezy chroot to run well on a jessie kernel.
[...]

It even works on a stretch kernel (but will crash on a buster kernel,
if you don't use the right kernel parameter).

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your
sig.



signature.asc
Description: This is a digitally signed message part

Bug#862235: ITP: node-dot -- Concise and fast javascript templating

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-dot
  Version : 1.1.1
  Upstream Author : Laura Doktorova 
* URL : http://github.com/olado/doT
* License : Expat
  Programming Lang: JavaScript
  Description : Concise and fast javascript templating

 This library provides concise and fast javascript templating compatible
with
 nodejs and other javascript environments.
 .
 This library is a build dependency of ajv, a JSON Schema Validator.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature