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

[Hans-Christoph Steiner]

On 10/16/2012 06:23 PM, András Murányi wrote:
> On Fri, Sep 28, 2012 at 9:24 PM, Hans-Christoph Steiner <hans at at.or.at>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/
>>
> 
> Cool. The only inconvenience is that the folder and the file name has the
> date so I cannot have the OBS pull the freshest one automatically. An url
> without "variables", like
> /auto-build/latest/Pd-extended_0.43.4-source.debian.tar.bz2 would do the
> trick...

I do this with a script in Jenkins:

#!/bin/sh

VERSION=0.43.4
DEBIAN_SOURCE_DATE=`date +%Y%m%d`
URL_DATE=`date +%Y-%m-%d`
ORIG=Pd-extended_${VERSION}~$DEBIAN_SOURCE_DATE-source.tar.bz2
DEBIAN=Pd-extended_${VERSION}~$DEBIAN_SOURCE_DATE-source.debian.tar.bz2

wget http://blinky.at.or.at:8888/auto-build/$URL_DATE/${ORIG}
wget http://blinky.at.or.at:8888/auto-build/$URL_DATE/${ORIG}.md5
wget http://blinky.at.or.at:8888/auto-build/$URL_DATE/${DEBIAN}
wget http://blinky.at.or.at:8888/auto-build/$URL_DATE/${DEBIAN}.md5
md5sum -c ${ORIG}.md5
md5sum -c ${DEBIAN}.md5
ln -s $ORIG `echo $ORIG | sed 's,^P,p,' | sed 's,-source,.orig,'`
tar xjf ${ORIG}
cd pd-extended
tar xjf ../${DEBIAN}
debuild -uc -us



> BTW, would it be possible to make up the tar.gz which comes from
> sourceforge in a way that it has the proper /debian folder instead of the
> seemingly less proper /packages/linux_make/debian/? Why cannot it have all
> the superpower that the one from the auto-build repo has? Sorry, perhaps
> there is a reason, I'm just too dumb for this source package business yet.

Done :)  That's what the Pd-extended*-source.debian.tar.bz2 tarball is.
 Its also checked into pure-data SVN in the pd-extended/0.43 branch, and
will ultimately wind up in trunk/debian.


> Btw, /packages/redhat_rpm/pd-extended.spec in the source package seems
> outdated (Version: 0.39.2)... It's an earlier (2006) version of the spec
> file by Fernando Lopez-Lezcano. However, it has the advantage that it
> generates separate packages for the externals (if it still works), while
> the last (2010) version generated a core and an extra package only.

yeah, that's quite old. Can you get the latest from Fernando?



>>>> 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've tried this in /externals/unauthorized/Makefile:
> 
>> TARGETS=$(filter-out $(wildcard mp3*/*.*),$(TARGETS))
>>
> but it doesn't work. How can I effectively disable building
> /externals/unauthorized/mp3* ?


Try adding a test target to see why its not working:

showtargets:
	echo "TARGETS $(TARGETS)"
	echo "filter-out: $(filter-out $(wildcard mp3*/*.*),$(TARGETS))"
	echo "mp3:  $(wildcard mp3*/*.*)"




>>>> 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.
>>
>>
> I've started to set up 0.43 too on the OBS and I'll definitely try to go
> into separating packages when I'm there.
> 
> I'll have to figure out how to handle the source (and MD5s!) for the debian
> builds and then I can evolve them along with the RPMs.
> 
> If anyone wants to join the party, of course I'll be happy to add them as
> admins.


Is there a link to the OBS service so we can see it?

.hc