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 <aug...@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 <zmoel...@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
--
-------------------
http://aug.ment.org
_______________________________________________
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
--
-------------------
http://aug.ment.org
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
