Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
./pure-data-svn/externals/iem/iem_ambi/src/ambi_decode2.c:7:20: fatal error: iemlib.h: No such file or directory ./pure-data-svn/externals/iemlib/iemlib1/src/biquad_freq_resp.c:8:20: fatal error: iemlib.h: No such file or directory ./pure-data-svn/externals/iem/iem_delay/src/block_delay~.c:7:20: fatal error: iemlib.h: No such file or directory loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory gem: TextBase.h:38:22: fatal error: FTFont.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
This is on Xubuntu 14.04.1 LTS x86_64
Fred Jan
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb < http://autobuild.puredata.info/auto-build/2015-01-04/Pd- 0.44.0-extended-20150104-debian-wheezy-amd64.deb>. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
...
loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies
LUA_CFLAGS = -I/usr/include/lua
and LUA_LIBS = -llua
pdlua.c will compile against lua versions 5.1 and 5.2, it uses the LUA_VERSION_NUM from lua.h to determine which one. As it's possible to have both versions installed on a given machine, I don't know how the pd-extended build is supposed to decide which one to use.
I'm guessing that the build farm machines use symlinks in /usr/include/lua and /usr/lib to point to the header and library.
There are some differences between the versions which mean some of the examples won't run, as the "sandbox" only works in 5.1.
Martin
Hi Martin,
Thanks for the reply,
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> wrote:
Hi, After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb <http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb>. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail: ... loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies LUA_CFLAGS = -I/usr/include/lua and LUA_LIBS = -llua pdlua.c will compile against lua versions 5.1 and 5.2, it uses the LUA_VERSION_NUM from lua.h to determine which one. As it's possible to have both versions installed on a given machine, I don't know how the pd-extended build is supposed to decide which one to use. I'm guessing that the build farm machines use symlinks in /usr/include/lua and /usr/lib to point to the header and library.
There is a /usr/include/lua/lua.h which points to usr/include/lua5.1/lua.h and a /usr/bin/lua pointing to /usr/bin/lua5.1. Nothing lua in /usr/lib, that was just me being confused.
The lua.h is still not found, but I will look into it later. It is not essential, just nice to have it working or understand why it doesn't.
There are some differences between the versions which mean some of the examples won't run, as the "sandbox" only works in 5.1.
Martin
Fred Jan
If anyone wants to take over the pool of auto-build machines from me, there are 3 Debian VMs still up and running. I think the Windows one is still going too.
.hc
On Jan 5, 2015, at 8:17 PM, Fred Jan Kraan wrote:
Hi Martin,
Thanks for the reply,
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> wrote:
Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
...
loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies LUA_CFLAGS = -I/usr/include/lua and LUA_LIBS = -llua pdlua.c will compile against lua versions 5.1 and 5.2, it uses the LUA_VERSION_NUM from lua.h to determine which one. As it's possible to have both versions installed on a given machine, I don't know how the pd-extended build is supposed to decide which one to use. I'm guessing that the build farm machines use symlinks in /usr/include/lua and /usr/lib to point to the header and library.
There is a /usr/include/lua/lua.h which points to usr/include/lua5.1/lua.h and a /usr/bin/lua pointing to /usr/bin/lua5.1. Nothing lua in /usr/lib, that was just me being confused.
The lua.h is still not found, but I will look into it later. It is not essential, just nice to have it working or understand why it doesn't.
There are some differences between the versions which mean some of the examples won't run, as the "sandbox" only works in 5.1.
Martin
Fred Jan
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Why to not move to an online continuous integration service like travis.ci ? I'm building some pd lib there for Windows, Linux (i86_64 and arm (rpi)) and Mac OS. And I may setup an automatic upload to deken on git tag as soon as I will be ready for deployment.
Best
Antoine
Le mer. 25 nov. 2015 09:50, Hans-Christoph Steiner hans@at.or.at a écrit :
If anyone wants to take over the pool of auto-build machines from me, there are 3 Debian VMs still up and running. I think the Windows one is still going too.
.hc
On Jan 5, 2015, at 8:17 PM, Fred Jan Kraan wrote:
Hi Martin,
Thanks for the reply,
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan <fjkraan@xs4all.nl
mailto:fjkraan@xs4all.nl> wrote:
Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb <
http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-2015...
.
But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
...
loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies LUA_CFLAGS = -I/usr/include/lua and LUA_LIBS = -llua pdlua.c will compile against lua versions 5.1 and 5.2, it uses the
LUA_VERSION_NUM from lua.h to determine which one.
As it's possible to have both versions installed on a given machine, I
don't know how the pd-extended build is supposed to decide which one to use.
I'm guessing that the build farm machines use symlinks in
/usr/include/lua and /usr/lib to point to the header and library.
There is a /usr/include/lua/lua.h which points to
usr/include/lua5.1/lua.h and a /usr/bin/lua pointing to /usr/bin/lua5.1. Nothing lua in /usr/lib, that was just me being confused.
The lua.h is still not found, but I will look into it later. It is not
essential, just nice to have it working or understand why it doesn't.
There are some differences between the versions which mean some of the
examples won't run, as the "sandbox" only works in 5.1.
Martin
Fred Jan
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-11-25 11:40, Antoine Villeret wrote:
Why to not move to an online continuous integration service like travis.ci ?
well, travis-ci has only very few OSs they support (two outdated flavours of 64bit ubuntu and OSX-10.?)
afaik there's another ci service (appveyor) that allows to do native w32 builds.
and of course: it's a proprietary service, we don't know what really gets used for building (and there *are* ways to generically inject malicious code via a compiler; i don't think that pd autobuilds are a specific target for injecting malicious code, but that doesn't mean we couldn't be affected - e.g. as collateral damage).
mfgadr IOhannes
On 2015-11-25 09:49 AM, Hans-Christoph Steiner wrote:
If anyone wants to take over the pool of auto-build machines from me, there are 3 Debian VMs still up and running. I think the Windows one is still going too.
Looking at http://autobuild.puredata.info/auto-build/latest/ there are only three different packages produced in 2015:
Pd-0.44.0-extended-macosx106-x86_64.dmg 2015-04-04 09:29 39M Pd-0.44.0-extended-debian-wheezy-amd64.deb 2015-11-25 12:56 38M Pd-0.44.0-extended-chaos.dmg 2015-02-23 23:15 39M
At least the Debian wheezy package does not reflect the latest sourceforge changes, as I mentioned in my mail of Januari 5th.
In the planned/current decentralized setup of Pd external libraries, I am not sure which function an auto-build machine should fulfill. Anyone can fork from https://git.puredata.info/cgit/svn2git/ and make and build a library in 'deken/pd-lib-builder' compliant format. At some time I plan to do this for some unsupported but useful libraries.
From the Pd-extended codebase, it would be interesting to extract
patches from the pd-core code to make Pd-vanilla compliant with the Pd-extended help-patches. This could be based on the legendary patch-series, but I don't seem to be able to find them on sourceforge :-(.
.hc
Greetings,
Fred Jan
On Jan 5, 2015, at 8:17 PM, Fred Jan Kraan wrote:
Hi Martin,
Thanks for the reply,
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> wrote:
Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
...
loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies LUA_CFLAGS = -I/usr/include/lua and LUA_LIBS = -llua pdlua.c will compile against lua versions 5.1 and 5.2, it uses the LUA_VERSION_NUM from lua.h to determine which one. As it's possible to have both versions installed on a given machine, I don't know how the pd-extended build is supposed to decide which one to use. I'm guessing that the build farm machines use symlinks in /usr/include/lua and /usr/lib to point to the header and library.
There is a /usr/include/lua/lua.h which points to usr/include/lua5.1/lua.h and a /usr/bin/lua pointing to /usr/bin/lua5.1. Nothing lua in /usr/lib, that was just me being confused.
The lua.h is still not found, but I will look into it later. It is not essential, just nice to have it working or understand why it doesn't.
There are some differences between the versions which mean some of the examples won't run, as the "sandbox" only works in 5.1.
Martin
Fred Jan
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev