On 09/28/2012 03:24 PM, Hans-Christoph Steiner wrote: > On 09/28/2012 12:10 PM, András Murányi wrote: >>> It could be a useful way to provide Debian/squeeze packages. >>>>> If you want to try my new Pd-extended proper debian support, run: >>>>> >>>>> $ >>> ~/auto-build/pd-extended/scripts/auto-build/pd-extended-source-tarball.sh >>>>> $ mv /tmp/Pd-extended_0.43.1~20120926-source.tar.bz2 >>>>> ~/auto-build/pd-extended_0.43.1~20120926.orig.tar.bz2 >>>>> $ cd ~/auto-build/pd-extended >>>>> $ debuild -S -uc -us >>>>> >>>> Hm, I don't have this script yet in ~auto-build/ ... It seems it doesn't >>>> work if I just download it to any place along with its whole folder, but >>> I >>>> cannot run it from the main run-automated-builder script either, because >>>> rsync cannot reach the server. >>> you need to get them from SVN: >>> >>> cd ~/auto-build/pd-extended/scripts >>> svn up >>> cd .. >>> svn up >>> >> That did the trick! >> The script itself didn't succeed at the first run but the third run >> completed clean. >> And it deletes the file at the end so I needed to copy it before it >> finished :o) > I just committed some fixes for that. :) But you can also get a source > tarball that's generated each night: > > http://blinky.at.or.at/auto-build/2012-09-28/ > > >>> The rsync method is gone for now, and perhaps permanently. I'm trying >>> to see if I can make the cleaning process work without rsync. >>> >>>>> (the -uc -us) means ignore the whole signing procedure, including the >>>>> name in the debian/changelog) >>>>> Also, its great that you are taking on the spec file for RPMs! Once you >>>> get 'puredata' working, then it would be very handy if you could make >>>>> one for the externals/template. Then it'll be easy to make RPMs for >>>>> most of the libraries in Pd-extended, just like what's in Debian. >>>>> >>>>> I've never made RPMs before, but I've done a lot of other packaging, so >>>>> I'll help where I can. >>>>> >>>> Well, the deb thing is stuck at this line now: >>>> >>>>> dpkg-source: error: unrecognized file for a v1.0 source package: >>>>> Pd-0.42.5-extended.tar.gz >>>>> >>>> The file is pulled from >>>> >>> http://sourceforge.net/projects/pure-data/files/pd-extended/0.42.5/Pd-0.42.5-extended.tar.gz >>>> (It has a packages/linux_make/debian folder but still no good.) >>>> Is there a .tar.gz for pd-extended online which is suitable for deb >>>> packaging and I could link to it? I don't want to reinvent the wheel... >>>> BTW, Is there a Pd-0.42.5-extended-dev.deb (or alike) that I could study >>> or >>>> use for parts? >>>> >>>> The rpm is losing it here: >>>> >>>>> `test -f >>>>> >>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs >>>>> && cat >>>>> >>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs` >>>>> /usr/bin/ld: cannot find -lmp3lame >>>>> >>>> As far as I understood lame-devel is not available in Fedora. How do I >>>> proceed? >>>> >>>> András >>>> >>> For Debian/squeeze, we rely on the libmp3lame-dev that's in >>> squeeze-backports. Previously, it was required that people downloaded >>> it from deb-multimedia.org. I guess you'd need to get it from somewhere >>> else, but I don't know enough about Fedora to say. Does PlanetCCRMA >>> include lame? I think that would be the best place for dependencies. >>> >> Planet CCRMA does have lame, but the OBS doesn't have Planet CCRMA. >> It is possible to fetch and build the lame sources into with pd but then we >> would have the lame binary bundled into pd which is not something we want, >> do we? >> So my best idea right now is to disable the external(s) that use lame. > That's easiest for now. I think only 'unauthorized' and maybe 'iemlib' > require lame. > >>> I think it'll be a lot easier if you start with just 'puredata' and the >>> libs based on the Library Template. Then once you get the hang of basic >>> RPM packaging, you can take on the whole pd-extended, which can be >>> painful. Also, I think that Pd-extended 0.43.1 will be a lot easier to >>> package since I've fixed all of the problems that came up during the >>> proper debian packaging. >>> >>> >> Well... I'm actually enjoying RPM packaging, it's a nice compact thing with >> everything controlled from a single spec file, and at the moment the >> simpler way for me is to try to get pd-extended build, and to get into the >> Library Template, which I'm completely unfamiliar with, at a later point. >> The problems which I'm having are with some individual externals, but this >> way when I solve one, the next one comes up, so it's easy to go through all >> of them. At least I hope so. >> I'd even say: let me finish packaging 0.42.5-extended as a monolith now >> (according to the original topic), and let's do 0.43 with the Library >> Template approach later. Is that OK? >> >> Again, I'm focusing more on the RPM side and I'd by happy if I could feed a >> debian-ready source tar.gz to the OBS, and I'd provide only the dsc. The >> less cool way is to upload a static file (like the one generated by >> pd-extended-source-tarball.sh), the more cool way would be to link to one >> which is online somewhere. Is there one? > You should do it how you want to do it. I suggested starting with the > library template because I think it would be a lot easier, since the > Makefile was custom made to work well with Debian packaging by providing > very standard names for commands "make clean", "make", "make install", > "make dist", etc. > > .hc
Also, I started a wiki page to document the whole procesure of doing this using the new source tarballs: http://puredata.info/docs/developer/BuildingYourOwnDebianPackage .hc _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
