[PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Hans-Christoph Steiner]

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