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