Re: puredata package changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-05-23 00:59, Hans-Christoph Steiner wrote:
Would it make sense to also add the versions since it won't build with
the 'puredata' package 0.43 or newer, something like:
puredata-dev | puredata 0.43
i believe this is a bug in the packaging, and is fixed in current git
(solution: make puredata _depend_ on puredata-dev as well)
i was only waiting to ping paul to upload the package, but afaik he is
currently on a sailing trip.
Also about puredata-core, it has a menu item set by puredata-core.menu.
That means that you could have puredata-core installed without the GUI,
but having it launched from the Menu. Since the .desktop file is
puredata.desktop, I propose moving the .menu item to puredata.menu
also. I think it would be confusing and not useful to have a menu item
that used to launch a GUI, but now might launch something that might not
have a GUI.
right now puredata does not provide any files itself, only
dependencies to it's sub-packages.
lintian will not like it, if there is a binary in the .menu/.desktop
files that is not provided by the package itself. given the dependency
structure, we could do a lintian override though.
i'm wondering whether it wouldn't be better to put the menu into
puredata-gui and launch pd-gui instead.
About puredata-extra, I am planning on making the 'pdextended' package
Recommend: puredata-extra instead of including the same source and
binaries. Would it be ok to change the Depends: for puredata-extra to:
puredata-core (= ${binary:Version}) | pd
hmm, the split is mainly there because you elaborated on having extra/
separately. what made you change your mind?
apart from that: puredata-extra would have to be reworked into pd-extra,
in order to make it useable by pd without breaking the pd vs puredata
separation. (if you want to make pdx search objects in
/usr/lib/puredata/extra, then we could have simply left everything in
/usr/lib/pd/)
furthermore: i think that the above depends stanza sounds like a bad
idea, as it would allow to have puredata-extra_0.43.0-4 to be installed
with either exactly puredata-core_0.43.0-4 or with pdextended-0.39.4-1;
so if we change, i think it should be:
Depends: pd
finally: actually there is no need to fuddle around with the
dependencies. if pdextended _recommends_ puredata-extra, you can
install pdextended just fine, even with puredata-extra. puredata-extra
would pull in some more dependencies (that is: puredata-core) but i
guess that pdextended will by default pull in a thousand packages anyhow :-)
fmas
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3bZf4ACgkQkX2Xpv6ydvRSAACgnMIv4zUn0b2b6AmNtmh5+60E
HLwAn2i8Y0BAx/YBN37ptyoqizNsZ+oH
=/Fc4
-END PGP SIGNATURE-
smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-05-24 10:02, IOhannes m zmoelnig wrote: On 2011-05-23 00:59, Hans-Christoph Steiner wrote: Also about puredata-core, it has a menu item set by puredata-core.menu. That means that you could have puredata-core installed without the GUI, but having it launched from the Menu. Since the .desktop file is puredata.desktop, I propose moving the .menu item to puredata.menu also. I think it would be confusing and not useful to have a menu item that used to launch a GUI, but now might launch something that might not have a GUI. two more remarks: - - while the desktop-files is named puredata.desktop, it is actually installed by puredata-core (whether this is good is debatable; i only wanted to say that - despite it's name - it is not installed by puredata, so it's not a good candidate for analogies here) - - puredata.menu could (and should) provide more dependency information, e.g: ?package(puredata-core,puredata-gui) so it will only show up if puredata-core _and_ puredata-gui are installed (even if puredata itself is not) fmgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3bdXQACgkQkX2Xpv6ydvR5lQCgjF2RCiYeOrs7erhLNpj+irWm vVkAn16z3XfXrhywMkoZj+/YjiJjNsNG =upU9 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
On May 24, 2011, at 4:02 AM, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-05-23 00:59, Hans-Christoph Steiner wrote:
Would it make sense to also add the versions since it won't build
with
the 'puredata' package 0.43 or newer, something like:
puredata-dev | puredata 0.43
i believe this is a bug in the packaging, and is fixed in current git
(solution: make puredata _depend_ on puredata-dev as well)
i was only waiting to ping paul to upload the package, but afaik he is
currently on a sailing trip.
I think if he's away for a while, this would be a good case for a NMU,
once we get everything sorted out. Piem does seem to disappear for
long stretches. I think we could probably get someone in pkg-
multimedia to do it.
Also about puredata-core, it has a menu item set by puredata-
core.menu.
That means that you could have puredata-core installed without the
GUI,
but having it launched from the Menu. Since the .desktop file is
puredata.desktop, I propose moving the .menu item to puredata.menu
also. I think it would be confusing and not useful to have a menu
item
that used to launch a GUI, but now might launch something that
might not
have a GUI.
right now puredata does not provide any files itself, only
dependencies to it's sub-packages.
lintian will not like it, if there is a binary in the .menu/.desktop
files that is not provided by the package itself. given the dependency
structure, we could do a lintian override though.
i'm wondering whether it wouldn't be better to put the menu into
puredata-gui and launch pd-gui instead.
Yes! That's the best way to handle it. I forgot that part of the
idea of pd 0.43 was to make it so when you launch Pd using 'pd-gui',
it will not launch an new instance for files opened via file
associations/double-clicking. It does this automatically if the files
are associated to open using 'pd-gui' rather than 'pd'. So the .menu
and file associations should all use 'pd-gui'.
Also, FYI, I pushed a commit adding Comment= fields to puredata.desktop.
About puredata-extra, I am planning on making the 'pdextended'
package
Recommend: puredata-extra instead of including the same source and
binaries. Would it be ok to change the Depends: for puredata-extra
to:
puredata-core (= ${binary:Version}) | pd
hmm, the split is mainly there because you elaborated on having extra/
separately. what made you change your mind?
apart from that: puredata-extra would have to be reworked into pd-
extra,
in order to make it useable by pd without breaking the pd vs
puredata
separation. (if you want to make pdx search objects in
/usr/lib/puredata/extra, then we could have simply left everything in
/usr/lib/pd/)
furthermore: i think that the above depends stanza sounds like a bad
idea, as it would allow to have puredata-extra_0.43.0-4 to be
installed
with either exactly puredata-core_0.43.0-4 or with
pdextended-0.39.4-1;
so if we change, i think it should be:
Depends: pd
finally: actually there is no need to fuddle around with the
dependencies. if pdextended _recommends_ puredata-extra, you can
install pdextended just fine, even with puredata-extra. puredata-extra
would pull in some more dependencies (that is: puredata-core) but i
guess that pdextended will by default pull in a thousand packages
anyhow :-)
OK, makes sense, let's leave puredata-extra as it is. Thanks for
reminding me of what I said before :)
.hc
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone. --Bjarne Stroustrup (creator of C++)
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
On Tue, 2011-05-24 at 10:43 -0400, Hans-Christoph Steiner wrote:
On May 24, 2011, at 4:02 AM, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-05-23 00:59, Hans-Christoph Steiner wrote:
Would it make sense to also add the versions since it won't build
with
the 'puredata' package 0.43 or newer, something like:
puredata-dev | puredata 0.43
i believe this is a bug in the packaging, and is fixed in current git
(solution: make puredata _depend_ on puredata-dev as well)
i was only waiting to ping paul to upload the package, but afaik he is
currently on a sailing trip.
I think if he's away for a while, this would be a good case for a NMU,
once we get everything sorted out. Piem does seem to disappear for
long stretches. I think we could probably get someone in pkg-
multimedia to do it.
Also about puredata-core, it has a menu item set by puredata-
core.menu.
That means that you could have puredata-core installed without the
GUI,
but having it launched from the Menu. Since the .desktop file is
puredata.desktop, I propose moving the .menu item to puredata.menu
also. I think it would be confusing and not useful to have a menu
item
that used to launch a GUI, but now might launch something that
might not
have a GUI.
right now puredata does not provide any files itself, only
dependencies to it's sub-packages.
lintian will not like it, if there is a binary in the .menu/.desktop
files that is not provided by the package itself. given the dependency
structure, we could do a lintian override though.
i'm wondering whether it wouldn't be better to put the menu into
puredata-gui and launch pd-gui instead.
Yes! That's the best way to handle it. I forgot that part of the
idea of pd 0.43 was to make it so when you launch Pd using 'pd-gui',
it will not launch an new instance for files opened via file
associations/double-clicking. It does this automatically if the files
are associated to open using 'pd-gui' rather than 'pd'. So the .menu
and file associations should all use 'pd-gui'.
Also, FYI, I pushed a commit adding Comment= fields to puredata.desktop.
I should add, I have all the file associations stuff worked out for the
pdextended package. If you want, I can integrate it into the
puredata-gui package so that .pd files are double-clickable.
.hc
About puredata-extra, I am planning on making the 'pdextended'
package
Recommend: puredata-extra instead of including the same source and
binaries. Would it be ok to change the Depends: for puredata-extra
to:
puredata-core (= ${binary:Version}) | pd
hmm, the split is mainly there because you elaborated on having extra/
separately. what made you change your mind?
apart from that: puredata-extra would have to be reworked into pd-
extra,
in order to make it useable by pd without breaking the pd vs
puredata
separation. (if you want to make pdx search objects in
/usr/lib/puredata/extra, then we could have simply left everything in
/usr/lib/pd/)
furthermore: i think that the above depends stanza sounds like a bad
idea, as it would allow to have puredata-extra_0.43.0-4 to be
installed
with either exactly puredata-core_0.43.0-4 or with
pdextended-0.39.4-1;
so if we change, i think it should be:
Depends: pd
finally: actually there is no need to fuddle around with the
dependencies. if pdextended _recommends_ puredata-extra, you can
install pdextended just fine, even with puredata-extra. puredata-extra
would pull in some more dependencies (that is: puredata-core) but i
guess that pdextended will by default pull in a thousand packages
anyhow :-)
OK, makes sense, let's leave puredata-extra as it is. Thanks for
reminding me of what I said before :)
.hc
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone. --Bjarne Stroustrup (creator of C++)
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
Would it make sense to also add the versions since it won't build with
the 'puredata' package 0.43 or newer, something like:
puredata-dev | puredata 0.43
Also about puredata-core, it has a menu item set by puredata-
core.menu. That means that you could have puredata-core installed
without the GUI, but having it launched from the Menu. Since
the .desktop file is puredata.desktop, I propose moving the .menu item
to puredata.menu also. I think it would be confusing and not useful
to have a menu item that used to launch a GUI, but now might launch
something that might not have a GUI.
About puredata-extra, I am planning on making the 'pdextended' package
Recommend: puredata-extra instead of including the same source and
binaries. Would it be ok to change the Depends: for puredata-extra to:
puredata-core (= ${binary:Version}) | pd
.hc
On May 11, 2011, at 4:26 AM, Paul Brossier wrote:
indeed, you can loosen the Build-depends to be:
puredata-dev | puredata | pd
Hth, piem
On 09/05/11 06:19, Hans-Christoph Steiner wrote:
There are a lot of changes, so I'm wondering if we could get a
summary
of what we should do to update our packages, and whether there
might be
any pitfalls. It seems that we should now build pd libs against
puredata-dev instead of puredata, for example.
.hc
On May 8, 2011, at 2:46 PM, Paul Brossier wrote:
Hi Hans,
I guess the 'git log' and debian/changelog are the best place to
look
at. Any specific questions about these changes?
Cheers, piem
On 08/05/11 18:13, Hans-Christoph Steiner wrote:
Hey IOhannes and piem,
I wonder if you could update us on all the changes to the puredata
package setup, and what we need to do with our puredata-related
packages.
(There are 35+ puredata-related packages and 4+ pd devs in
pkg-multimedia, so it seemed a good venue).
.hc
Making boring techno music is really easy with modern tools, but
with live coding, boring techno is much harder. - Chris McCormick
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their
minds, and
dignity, equality and freedom for their spirits. - Martin Luther
King, Jr.
“We must become the change we want to see. - Mahatma Gandhi
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
indeed, you can loosen the Build-depends to be: puredata-dev | puredata | pd Hth, piem On 09/05/11 06:19, Hans-Christoph Steiner wrote: There are a lot of changes, so I'm wondering if we could get a summary of what we should do to update our packages, and whether there might be any pitfalls. It seems that we should now build pd libs against puredata-dev instead of puredata, for example. .hc On May 8, 2011, at 2:46 PM, Paul Brossier wrote: Hi Hans, I guess the 'git log' and debian/changelog are the best place to look at. Any specific questions about these changes? Cheers, piem On 08/05/11 18:13, Hans-Christoph Steiner wrote: Hey IOhannes and piem, I wonder if you could update us on all the changes to the puredata package setup, and what we need to do with our puredata-related packages. (There are 35+ puredata-related packages and 4+ pd devs in pkg-multimedia, so it seemed a good venue). .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola, given that i have done most of the packaging, i guess i'll try to answer the question :-) On 2011-05-09 06:19, Hans-Christoph Steiner wrote: There are a lot of changes, so I'm wondering if we could get a summary of what we should do to update our packages, and whether there might be any pitfalls. It seems that we should now build pd libs against puredata-dev instead of puredata, for example. hopefully there are no pitfalls, but like always they will only show up once you are trapped. anyhow, the main change is, that puredata is now split into a number of binary packages. the binary package puredata is now only a meta-package depending on all it's components (for backwards compat). # puredata-core the main binary package is puredata-core which provides pd. puredata-core is only the dsp-engine, without any GUI components, so you can now install Pd (with externals) on a headless system. externals that don't depend on pd but only on puredata might need to have their Depends adapted, if they want to support headless installs (i just realize that puredata-import is probably the only package that is currently affected by this). # puredata-dev as hans has rightly said, there is now a puredata-dev package, which installs the headers (and a pkg-config file), for compiling externals. this should be everything that is needed to compile Pd-related packages. given that the package only provides header-files and a pkg-config snippet, this greatly reduces the build-dependencies (build-bots don't need to install tk and jack anymore, in order to compile a network-related Pd-package) # puredata-gui, puredata-doc, puredata-extra, puredata-utils from a pd external packager's pov, those are probably not so interesting. puredata-gui holds (as the name suggests) all GUI related stuff. it can be installed without puredata-core (given that puredata-core and puredata-gui can run on different machines). Thus: general Pd-externals should Build-depend: puredata-dev and Depend: pd for backporting compatibility, i'd suggest to Build-depend: puredata-dev | puredata if the package contains only ordinary (as in: non-graphical) objects and is only for puredata (and not all providers of pd), it should probably depend on puredata-core rather than puredata. mfgsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3KTvUACgkQkX2Xpv6ydvRPpgCfe1/fdoP+o5fVUyrZY03lTT3k iGkAnR/UU3Kfki6jxL1p2VHB7iEpIhfz =w9ey -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
On May 11, 2011, at 4:55 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola, given that i have done most of the packaging, i guess i'll try to answer the question :-) On 2011-05-09 06:19, Hans-Christoph Steiner wrote: There are a lot of changes, so I'm wondering if we could get a summary of what we should do to update our packages, and whether there might be any pitfalls. It seems that we should now build pd libs against puredata-dev instead of puredata, for example. hopefully there are no pitfalls, but like always they will only show up once you are trapped. anyhow, the main change is, that puredata is now split into a number of binary packages. the binary package puredata is now only a meta-package depending on all it's components (for backwards compat). # puredata-core the main binary package is puredata-core which provides pd. puredata-core is only the dsp-engine, without any GUI components, so you can now install Pd (with externals) on a headless system. externals that don't depend on pd but only on puredata might need to have their Depends adapted, if they want to support headless installs (i just realize that puredata-import is probably the only package that is currently affected by this). # puredata-dev as hans has rightly said, there is now a puredata-dev package, which installs the headers (and a pkg-config file), for compiling externals. this should be everything that is needed to compile Pd-related packages. given that the package only provides header-files and a pkg-config snippet, this greatly reduces the build-dependencies (build-bots don't need to install tk and jack anymore, in order to compile a network-related Pd-package) # puredata-gui, puredata-doc, puredata-extra, puredata-utils from a pd external packager's pov, those are probably not so interesting. puredata-gui holds (as the name suggests) all GUI related stuff. it can be installed without puredata-core (given that puredata-core and puredata-gui can run on different machines). Thus: general Pd-externals should Build-depend: puredata-dev and Depend: pd for backporting compatibility, i'd suggest to Build-depend: puredata-dev | puredata if the package contains only ordinary (as in: non-graphical) objects and is only for puredata (and not all providers of pd), it should probably depend on puredata-core rather than puredata. Thank you, IOhannes, that was very useful. It would be good to add key bits of this to the Debian Multimedia wiki. I'm thinking we could have a Pure Data policy section here: http://wiki.debian.org/DebianMultimedia/Policy Is there any procedure to adding stuff beyond just coming up with something that we agree on? .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
Hi Hans, I guess the 'git log' and debian/changelog are the best place to look at. Any specific questions about these changes? Cheers, piem On 08/05/11 18:13, Hans-Christoph Steiner wrote: Hey IOhannes and piem, I wonder if you could update us on all the changes to the puredata package setup, and what we need to do with our puredata-related packages. (There are 35+ puredata-related packages and 4+ pd devs in pkg-multimedia, so it seemed a good venue). .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: puredata package changes
There are a lot of changes, so I'm wondering if we could get a summary of what we should do to update our packages, and whether there might be any pitfalls. It seems that we should now build pd libs against puredata-dev instead of puredata, for example. .hc On May 8, 2011, at 2:46 PM, Paul Brossier wrote: Hi Hans, I guess the 'git log' and debian/changelog are the best place to look at. Any specific questions about these changes? Cheers, piem On 08/05/11 18:13, Hans-Christoph Steiner wrote: Hey IOhannes and piem, I wonder if you could update us on all the changes to the puredata package setup, and what we need to do with our puredata-related packages. (There are 35+ puredata-related packages and 4+ pd devs in pkg-multimedia, so it seemed a good venue). .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
