Can anyone tell me how to compile the debs from CVS individually? I am using dpkg-buildpackage and it dies on the footils package, leaving me with no .debs for the rest.
.hc
zen \ \ \[D[D[D[D
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone tell me how to compile the debs from CVS individually? I am using dpkg-buildpackage and it dies on the footils package, leaving me with no .debs for the rest.
Temporarily removing the footils-entry from debian/control probably helps.
What is the error message?
ciao
On Tue, 29 Apr 2003, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone tell me how to compile the debs from CVS individually? I am using dpkg-buildpackage and it dies on the footils package, leaving me with no .debs for the rest.
Temporarily removing the footils-entry from debian/control probably helps.
Well, you have to remove the footils lines in debian/rules too, ... but a better idea would be if we get this fixed.
What is the error message?
yes, this and which version of Debian are you working on. (There is no build depend on fluidsynth included in the packageing yet)
Guenter
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
I did just comment stuff out to get it working, but I thought there might be something like: debuild --package=pd-externals
yes, this and which version of Debian are you working on. (There is no build depend on fluidsynth included in the packageing yet)
I am using Debian stable (Woody) with DeMuDI, and GNOME 2.2/XF86 4.2 from Sid. I attached my sources.list.
The first error I get is to do with oggamp~. I fixed this by adding -DUNIX to build/linux/Makefile (I just commited this fix):
gcc -DPD -O2 -funroll-loops -fomit-frame-pointer -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I. -I.. -I../include -o "oggamp~.o" -c "../src/oggamp~.c" In file included from ../src/oggamp~.c:1: ../src/../../pdogg/oggamp~/oggamp~.c:55: io.h: No such file or directory ../src/../../pdogg/oggamp~/oggamp~.c:56: winsock.h: No such file or directory ../src/../../pdogg/oggamp~/oggamp~.c:57: winbase.h: No such file or directory make[1]: *** [oggamp~.pd_linux] Error 1 make[1]: Leaving directory `/tmp/externals/build/linux' make: *** [build-stamp] Error 2
then I got this, which I got around by deleting oggread~.c from build/src:
gcc -DPD -DUNIX -O2 -funroll-loops -fomit-frame-pointer -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I. -I.. -I../include -o "oggread~.o" -c "../src/oggread~.c" In file included from ../src/oggread~.c:1: ../src/../../pdogg/oggread~/oggread~.c: In function `oggread_decode_input': ../src/../../pdogg/oggread~/oggread~.c:123: warning: passing arg 3 of `ov_read_float' makes pointer from integer without a cast ../src/../../pdogg/oggread~/oggread~.c:123: too many arguments to function `ov_read_float' ../src/../../pdogg/oggread~/oggread~.c:115: warning: `ret' might be used uninitialized in this function ../src/../../pdogg/oggread~/oggread~.c: In function `oggread_open': ../src/../../pdogg/oggread~/oggread~.c:295: warning: ordered comparison of pointer with integer zero make[1]: *** [oggread~.pd_linux] Error 1 make[1]: Leaving directory `/tmp/externals/build/linux' make: *** [build-stamp] Error 2
But with fix you just submitted, plus compiling and installing fluidsynth from source, it compiles now. It would be nice to be able to compile pd-externals .deb without having to install fluidsynth, but I can live with commenting out things to make it work.
.hc
zen \ \ \[D[D[D[D
On Tue, 29 Apr 2003, Hans-Christoph Steiner wrote:
But with fix you just submitted, plus compiling and installing fluidsynth from source, it compiles now. It would be nice to be able to compile pd-externals .deb without having to install fluidsynth, but I can live with commenting out things to make it work.
Yes, but the question is if we can live with it :)
I have been thinking more than once about splitting the "externals" directory and provide a set of independend externals. I'm not sure though ..
The problem is that Debian does not have a notion of "compiling only half of the package", which makes it hard for me to include the whole set in Debian, because things break on every odds and ends, and we do not have something like a "common release". This too makes it harder to assure the quality of the system, because at every time some part of the packages could be in a "transition state".
Greetings
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Tue, 29 Apr 2003, Hans-Christoph Steiner wrote:
But with fix you just submitted, plus compiling and installing fluidsynth from source, it compiles now. It would be nice to be able to compile pd-externals .deb without having to install fluidsynth, but I can live with commenting out things to make it work.
Yes, but the question is if we can live with it :)
I have been thinking more than once about splitting the "externals" directory and provide a set of independend externals. I'm not sure though ..
In the case of fluidsynth, this would make sense. I talked about this with Peter Hanappe ad the LAD-conference, who proposed pitting fluid~ into the fluidsynth-CVS, but then we would have a dependency of fluidsynth to Pd so nothing gets better. fluid~ might be one of those cases, where the dreaded "1 external packages" makes sense.
ciao
On Tue, 29 Apr 2003, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone tell me how to compile the debs from CVS individually? I am using dpkg-buildpackage and it dies on the footils package, leaving me with no .debs for the rest.
Temporarily removing the footils-entry from debian/control probably helps.
What is the error message?
Ah, I know, the FLUISYNTH path is the problem. I think it would be better to use
FLUIDLIB=-L/usr/local/lib -lfluidsynth instead of FLUIDLIB=/usr/local/lib/libfluidsynth.a
I have fixed that temporarily in the debian build system now. Another question is what to do with iiwu ? (Can we get rid of that, now that fluidsynth is in Debian)
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Ah, I know, the FLUISYNTH path is the problem. I think it would be better to use
FLUIDLIB=-L/usr/local/lib -lfluidsynth instead of FLUIDLIB=/usr/local/lib/libfluidsynth.a
Yes, but it didn't work here, when I tried it this way. :( I have to try again, with the libfluid Debian packages, and if it works, we can change it.
I have fixed that temporarily in the debian build system now. Another question is what to do with iiwu ? (Can we get rid of that, now that fluidsynth is in Debian)
I had a lenghty email discussion on this topic with Eric, the iiwu and now fluid maintainer. His first fluidsynth-packages "Provide" iiwu, "Replace" it and "Conflict" with it in the Debian sense.
I wrote to him, that I think that this is technically (and practically) not correct, because there is no libiiwusynth.so in the libfluidsynth package. OTOH Peter Hanappe and the fluid team will probably not fix bugs in iiwu anymore, so Eric cannot have iiwu available in the next Debian anymore (three years from now ;)
I don't know, what the current decision is, I proposed to keep the "Replace: iiwu" but ditch the "Provide" and "Conflict" in the fluidsynth packages with regard to iiwu, because fluid doesn't provide iiwu and doesn't need to conflict with the iiwu package.
I didn't file a bug report, because this seems to be more a question of policy, and I don't know, how the Debian policy handles renamed packages.
In the end, (f)iiwu will vanish together with iiwusynth from Debian and the Sourceforge-CVS and be replaced by fluidsynth and fluid~
ciao
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner