On Jun 26, 2011, at 1:17 PM, august wrote:
Hans,
are the 'upstream' and 'pristine-tar' naming conventions of debian? do you have branches for the tarballs?
These branches are Debian naming conventions that the git-buildpackage
tools handle for you with tools like git-import-orig.
What is a pristine-tar ?
pristine-tar is a utility for regenerating the pristine tarball of the
release. That's the purpose of the pristine-tar branch too.
I'd like to learn the packaging stuff, so I will try to go through the process myself. Maybe I can solicit your help every now and then, if possible.
Yup, of course. The Debian pkg-multimedia team is also a very good
place to learn, get help, and find uploaders. There is a reference
wiki that I find useful too:
http://wiki.debian.org/DebianMultimedia/DevelopPackaging
We need to think however about the versioning and the SONAME of the .so files. Any ideas on how this will (or should) work? I have the SONAME set to libpd.so.0 for now. I think that fits. If there are ABI changes, we can up it to libpd.so.1
I think that makes sense.
.hc
-august.
Cool, I think this then means that libpd bindings for python, etc. can be also packaged up. Once this package is ready, I'm happy to take it thru the Debian submission process via pkg-multimedia and get it into Debian. Or even better, you can easily do it yourself via pkg-multimedia and start the process of becoming some kind of Debianista (Debian Maintainer or Debian Developer).
One detail about which files go into which git repo: libpd.pc should definitely be in the official libpd repo, but the debian/ files generally should not. They key part is to not include the debian/ files in the official tarball. But packaging is much easier if the upstream tarballs are imported and everything is done in the git- buildpackage workflow with 'upstream' and 'pristine-tar' branches.
.hc
On Jun 24, 2011, at 6:27 PM, august wrote:
okay, here is a test package of the libpd git repo.
I think it would be safe to merge the Makefile and the libpd.pc into upstream.
please have a look:
https://launchpad.net/~august-alien/+archive/ppa
best -august.
I suggest you stick to the central repository of libpd because you can expect it to be actively maintained and documented. If other repositories contain material that you'd like to see in the main branch, you can create a merge request at Gitorious. Cheers, Peter
On Wed, Jun 22, 2011 at 6:38 PM, august august@alien.mur.at
wrote:well, I just made my first PPA. It's waiting to build on
launchpad.I have the Makefile copy pd.pc to libpd.pc. libpd.pc is then installed instead of pd.pc
Not sure if I should be using the aalex repo or not. What are the differences?
I don't think the API needs to be fixed for this personal package. ...however, maybe for official submission to debian or ubuntu.
best -august.
I agree that we should provide a libpd.pc. Let's aim to fold this into
the
main branch of the libpd repository. If the PPA ends up using code from aalex, let's merge that into the main branch as well.
A related question is whether this is the time to declare the libpd API finished, but that's a discussion that we should probably take to pd-everywhere. Cheers, Peter
On Wed, Jun 22, 2011 at 3:04 AM, IOhannes m zmoelnig <zmoelnig@iem.at wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2011-06-22 05:47, august wrote: >> >> >> >> Is there a version number for libpd? >> >> I see you guys have added a pd.pc in >> http://gitorious.org/~aalex/pdlib/aalexs-libpd >> > just to chime in: please note that "pd" also provides a "pd.pc". > i would highly suggest to provide a libpd.pc for libpd. > > fgmasdr > IOhannes > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4BlAoACgkQkX2Xpv6ydvRg+ACeIu70dOUt/Ovz377qW8h4A5jg > wDQAnjVCznEBzDXU6LmdPSm6IrDQisRQ > =A+mM > -----END PGP SIGNATURE----- > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
http://aug.ment.org-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQEVAwUBTgJu9sVXRY8APmlSAQJdYAf+IQVgfwJ7sL9YZ5SLHzq6jeTlh9wVp7bq /4XqmZhiW9b32UOz+everEJ+7IMZxkf0t/JICpfkj/D+r478RicdUyY3D8/B3nLZ qYHGxJ0JMZgYll63kMW1y8aqQsOTq6oW4dJGocs0p9v6fwnflA9tngdKtj33JpjC YBF2fDtgwpqvw1+sHJsevbc7r1zSfOKMxc5T9hvK1lVemmklGw2CkJ61wU4XJSL/ gZXZp/XN/sbc7AbPNG/zf6eSnIC9/qxYg2Da6RH/37JXIM9qip0RNnI+wXdm/r9y cvZzwJsgQsGnGkMD6wGuwnA+g74sKCZ/ItGc5FY2MpWe+BIqomj7QQ== =Koa1 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
--
¡El pueblo unido jamás será vencido!