Bug#629798: pd-plugin: FTBFS: plugin~.h:2:18: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a couple weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629799: pd-pmpd: FTBFS: iAmbient2D.c:1:18: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a few weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629800: pd-sigpack: FTBFS: chop~.c:6:18: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a few weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629801: pd-smlib: FTBFS: defines.h:1:18: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a few weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629802: pd-vbap: FTBFS: vbap.h:5:24: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a few weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629803: pd-windowing: FTBFS: bartlett~.c:22:18: fatal error: m_pd.h: No such file or directory (missing B-D on puredata-dev)
Tags: wheezy sid pending help I am the packager and lead maintainer on this package. I have fixed this bug and pushed the fixes to the git.debian.org repo listed in the Vcs-* lines. The package is ready for upload, but I am a DM without upload permissions on this package. I have been looking for a sponsor on pkg-multimedia for a few weeks now, so I'd appreciate it if anyone could upload this package, either NMU or from pkg-multimedia. .hc ___ 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: request for sponsorship for pd-hid
On Wed, 09 Feb 2011 17:41 -0300, Felipe Sateler fsate...@debian.org wrote: On Mon, Jan 31, 2011 at 21:55, Felipe Sateler fsate...@debian.org wrote: On Fri, Jan 21, 2011 at 19:08, Felipe Sateler fsate...@debian.org wrote: On Fri, Jan 21, 2011 at 03:37, Hans-Christoph Steiner h...@at.or.at wrote: On Fri, 24 Dec 2010 15:37 -0800, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 24, 2010, at 9:19 AM, Felipe Sateler wrote: On Wed, Dec 22, 2010 at 21:13, Hans-Christoph Steiner h...@at.or.at wrote: Just ITPed, packaged and uploaded pd-hid to git.debian.org. It is an object for Pure Data that allows you to use USB HID devices in Pd. The build system is similar in structure to pd-plugin and pd-freeverb, plus it includes the kFreeBSD and Hurd updates, so it should build on all platforms. It depends on pd-mapping and recommends pd-pddp, which are both in NEW. http://git.debian.org/?p=pkg-multimedia/pd-hid.git;a=summary There is some code that is not yours, please add Jan Truetzschler Falkenstein to the debian/copyright file (ftpmaster may reject the package for this missing information). Thanks for spotting that, I pushed the fix. Ping. Anyone willing to sponsor this one? Sorry, I lost track of this. I will try to get to this (and your other packages) during the weekend. I clearly didn't do this when promised, and this week I couldn't either. I've been extremely busy. I'm sorry about that. If someone else can look into these packages, please upload them, since I'm not likely to get any debian time anytime soon. I will, if nobody else gets to these packages, still review them as time permits. It seems that this package never got uploaded. It needs its git-dch done and the changelog finalized and then uploaded. I can finalize the changelog if that makes it easier. It seems some people want to do it themselves when uploading. .hc ___ 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: please upload: puredata-import
Thanks! The bonus is that I'm a DM now, so once this is uploaded, I won't need to bother you any more with it ;) .hc On Jun 7, 2011, at 2:28 PM, Felipe Sateler wrote: I've been a bit busy, I'll try to get to this during the week. On Tue, Jun 7, 2011 at 13:28, Hans-Christoph Steiner h...@at.or.at wrote: Just a little ping on this. I saw that pd-comport got uploaded, thanks for that. This is currently my most urgent pending upload. .hc On May 25, 2011, at 2:52 PM, Hans-Christoph Steiner wrote: The 'puredata' package has been split into a suite of packages, and now installs its files into /usr/lib/puredata. I updated the 'puredata-import' package to work with this new suite of packages. The old package will not work properly. Also, I added DM-Upload- Allowed: yes since I'm now a DM, so this will be the last time I need to bother anyone to get an upload for this package ;) The changes are all up in git.debian.org. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: please upload: puredata-import
Just a little ping on this. I saw that pd-comport got uploaded, thanks for that. This is currently my most urgent pending upload. .hc On May 25, 2011, at 2:52 PM, Hans-Christoph Steiner wrote: The 'puredata' package has been split into a suite of packages, and now installs its files into /usr/lib/puredata. I updated the 'puredata-import' package to work with this new suite of packages. The old package will not work properly. Also, I added DM-Upload-Allowed: yes since I'm now a DM, so this will be the last time I need to bother anyone to get an upload for this package ;) The changes are all up in git.debian.org. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ 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: please upload pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
And a gentle ping on these packages... but for me puredata-import is a higher prioity for uploading. Thanks in advance! .hc On May 25, 2011, at 11:07 AM, Hans-Christoph Steiner wrote: After the 'hold', these have all been reviewed and are just awaiting upload. They all include bug fixes so they build on kFreeBSD and Hurd. There is an extra bonus in that I'm now a DM, so I'm setting DM- Upload: yes, then they won't need sponsored uploads any more :) IOhannes sent an email per package originally, I'm now just pinging again on these packages so they get uploaded. pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg .hc A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ 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: openni package for Debian
On Jun 1, 2011, at 6:57 AM, Cosimo Alfarano wrote: On 31/05/11 03:49, Hans-Christoph Steiner wrote: Ah, cool, so we have an uploader :) I'm just a DM. I'm not sure about Cosimo. I'm a DD. BTW, update to the pkgs status: I tried yesterday the three repos, they worked. I just pushed a couple of patches to fix small (but necessary) things. I just realized that we need to fix the .ini file for Kinect, I had to change InputFormat=1 which was commented, to make it work. Also, udev rules, does anybody know if we need OWNER=root or it can be xxx as set by upstream? I don't know, but it shouldn't be too hard to test. Next steps: - Enable Mono in openni so that it can be re-enabled in NITE. - the Makefile for NITE OpenNI relies on the presence of the mono exec to compile mono, which means that in a chroot env it compiles without problems, but when build outside in an env which has mono installed it will fail. The reason of the failure is that the upstream install.sh script do not detach the build from the (post) installation process. As per my mono understanding (noob) we need to compile GAC in postinst, while create the DLL at build time. Until we split this behaviour (should be easy) we cannot build mono package and both openni and NITE are inherently broken. I guess currently, if we want to use the packages as-is without fixing the Mono stuff, we could add a Build-Conflicts. But having the Mono stuff sorted out would be nicer. I just know next to nothing about Mono/C#/.NET. - Re-enable quilt, so that we can patch the Samples to be able to find their XML in a different location than ../../../../Data, and package it as openni-samples, the same for nite and kinect IIRC. Sounds good, we might want to name the package that hints that they are kind of like utilities/debug tools too. Things like a depth camera viewer, etc. - Fix all the lintian complaints and the .ini :) - Fix the SONAME and .so versioning issue, it depends on the email I still have to send to upstream about their build system :) So far this is not a real problem, until we'll have more than one version we need to be able to link at the same time. After that we might be able to consider an upload to unstable, IMHO. Yup, glad to see progress. .hc “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
openni and primesense/kinect status
Ok, here's my work transcript from yesterday. It looks like we still need to sort out the Mono/OpenNI.dll building and installing. But this is some of what I did and the errors I was trying to fix in primesense-nite-nonfree: added mono-gmcs and libmono-winforms2.0-cil as depends since the package building done by update-primesense-nite script needs them. first build attempt failed because it was missing libopenni --- /tmp/primesense-nite.6105 /tmp/primesense-nite-nonfree.UyPwDp8h5m /tmp/primesense-nite.6105/openni-modules-primesense-nite-nonfree /tmp/primesense-nite.6105 /tmp/primesense-nite-nonfree.UyPwDp8h5m dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions dpkg-buildpackage: source package primesense-nite-nonfree dpkg-buildpackage: source version 1.3.1.5-1 dpkg-buildpackage: source changed by Cosimo Alfarano ka...@debian.org dpkg-source --before-build openni-modules-primesense-nite-nonfree dpkg-buildpackage: host architecture i386 dpkg-checkbuilddeps: Unmet build dependencies: libopenni (= 1.1.0.41) dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) debuild: fatal error at line 1335: dpkg-buildpackage -rfakeroot -D -us -uc failed second attempt failed at missing quilt -- third attempt failed at missing libopenni-dev - g++ -g -O2 -malign-double -O3 -fno-tree-pre -fno-strict-aliasing -DNDEBUG -msse3 -mssse3 -I../Players -I/usr/include/nite -I/usr/include/ni -DUSE_GLUT -DXN_SSE -M -MF Release/main.d -MT ./Release/main.o Release/main.d ../Players/main.cpp ../Players/main.cpp:8:22: fatal error: XnOpenNI.h: No such file or directory fourth attempt was downloading the 64-bit tarball on a 32-bit machine - g++ -o ../Bin/Sample-Players ./Release/main.o ./Release/SceneDrawer.o ./Release/kbhit.o ./Release/signal_catch.o -L../../Bin -lGL -L../Bin -lglut -lOpenNI -lXnVNite_1_3_1 /usr/bin/ld: skipping incompatible ../../Bin/libXnVNite_1_3_1.so when searching for -lXnVNite_1_3_1 /usr/bin/ld: cannot find -lXnVNite_1_3_1 collect2: ld returned 1 exit status last attempt today failed on missing OpenNI.net.dll --- gmcs -out:../Bin/Sample-Boxes.net.exe -target:winexe -unsafe -o+ -r:OpenNI.net.dll -r:System.Windows.Forms.dll -r:System.Drawing.dll -r:../Bin/XnVNite.net_1_3_1.dll ../Boxes.net/*.cs ../Res/AssemblyInfo-NITE.cs error CS0006: cannot find metadata file `OpenNI.net.dll' Compilation failed: 1 error(s), 0 warnings make[3]: *** [../Bin/Sample-Boxes.net.exe] Error 1 I think there is a way to stop the primesense-nite installer from building the examples. Those are the Mono C# .NET things, so we could start by leaving the Sample apps out. .hc ___ 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: openni and primesense/kinect status
On May 30, 2011, at 12:45 PM, Jonas Smedegaard wrote: On 11-05-30 at 12:22pm, Hans-Christoph Steiner wrote: third attempt failed at missing libopenni-dev - g++ -g -O2 -malign-double -O3 -fno-tree-pre -fno-strict-aliasing -DNDEBUG -msse3 -mssse3 -I../Players -I/usr/include/nite -I/usr/include/ni -DUSE_GLUT -DXN_SSE -M -MF Release/main.d -MT ./Release/main.o Release/main.d ../Players/main.cpp ../Players/main.cpp:8:22: fatal error: XnOpenNI.h: No such file or directory Beware of the optimizations: Debian Policy mandates ability to disable optimizations, so if above -O3 is applied by upstream (or hardcoded in your build rules) then it is most likely done wrong. I cloned the project to try have a closer look, but apparently picked the wrong one (openni) - no O3 mentioned anywhere in source code. But doing so I noticed several tarballs inside the git - that looks bad! Yeah, the upstream source is a mess for all this, there are mostly no official release tarballs, except for the binary one. The free software library and modules are only in git, but they don't develop out of that git. They post different versions into different branches, like the 'stable' version is only in the master branch, and the 'unstable' version is in an 'unstable' branch, but that 'unstable' branch does not included the 'stable' release. So, on that note, the optimization flags are in the upstream build system. .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: OpenNI debs
From my earlier conversation about Cosimo about these packages, it gets worse. They don't even set the SONAME: Debian wants /usr/lib/libOpenNI.so to be a link to /usr/lib/libOpenNI.so.0.0.0 (or whatever the SONAME and major version is). First problem, the .so files are created not versioned. Second problem, I do not see any SONAME with objdump, but I might be mistaken I gave a quick look at it. I propose to upload them to experimental until we sort out the SONAME problem with upstream, either understand if they want to add a SONAME or it's actually their intention to leave the library without (which would be difficult for us to keep compatibility when API/ABI changes). .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ 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: openni and primesense/kinect status
On May 30, 2011, at 2:01 PM, Cosimo Alfarano wrote: On 30/05/11 18:53, Hans-Christoph Steiner wrote: Yeah, the upstream source is a mess for all this, there are mostly no [...] So, on that note, the optimization flags are in the upstream build system. It's on my TODO list to contact upstream and ask the rationale behind the current build system. I'll write the email in the next days, but if someone is planning to do the same please put me in CC. Yes, good idea, please do! Hopefully they'll be willing to accept some changes. .hc Access to computers should be unlimited and total. - the hacker ethic ___ 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: please upload pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
On Thu, 2011-05-26 at 22:24 +0200, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/25/2011 05:07 PM, Hans-Christoph Steiner wrote: pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg do you plan to get rid of those lintian warnings as well? W: pd-cxc: description-synopsis-starts-with-article W: pd-markex: description-synopsis-starts-with-article W: pd-smlib: description-synopsis-starts-with-article W: pd-cxc source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-ekext source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-markex source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-maxlib source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-mjlib source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-sigpack source: out-of-date-standards-version 3.9.1 (current is 3.9.2) W: pd-smlib source: out-of-date-standards-version 3.9.1 (current is 3.9.2) These should all be fixed now. .hc signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
please upload pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
After the 'hold', these have all been reviewed and are just awaiting upload. They all include bug fixes so they build on kFreeBSD and Hurd. There is an extra bonus in that I'm now a DM, so I'm setting DM-Upload: yes, then they won't need sponsored uploads any more :) IOhannes sent an email per package originally, I'm now just pinging again on these packages so they get uploaded. pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-maxlib, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
please upload: puredata-import
The 'puredata' package has been split into a suite of packages, and now installs its files into /usr/lib/puredata. I updated the 'puredata-import' package to work with this new suite of packages. The old package will not work properly. Also, I added DM-Upload-Allowed: yes since I'm now a DM, so this will be the last time I need to bother anyone to get an upload for this package ;) The changes are all up in git.debian.org. .hc ___ 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
adding Pure Data section to DebianMultimedia/Policy wiki
Now that we have some clear ideas about how to package things for Pure Data/Pd, 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 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/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
puredata package changes
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
Bug#625954: puredata-import: inconsistent installation locations
On May 7, 2011, at 6:19 AM, IOhannes m zmoelnig (gpg-key at iem) wrote: Package: puredata-import Version: 1.3-2 Severity: normal i noticed that puredata-import installs mostly into /usr/lib/pd/ extra, only the LICENSE.txt get's installed into /usr/lib/puredata/extra. this leads to weird warnings in the pd-0.43 help-browser, claiming that import is double installed. i guess, installing to 2 locations is just an oversight. since the package is named puredata-import and explicitely claims that it is targeted at puredata only (and not the other pd providers), i assume that it is meant to be installed into /usr/lib/puredata/extra. the attached patch should fix this. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages puredata-import depends on: ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii puredata 0.43.0-1 realtime computer music and graphi Versions of packages puredata-import recommends: ii pd-libdir 1.9-2 provides support for the libdir li puredata-import suggests no packages. -- no debconf information You are correct, it should install into /usr/lib/puredata. I think I was waiting for the 'puredata' package to install into /usr/lib/ puredata, or just messed it up ;). I'll include this once I switch the package to build against the new puredata-* 0.43 packages. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: hold uploading pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
Ok, I reviewed IOhannes' changes, made some tweaks and pushed my commits. These are all ready for uploading, including pd-maxlib which I forgot to add to the list of packages in the subject. .hc signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: please upload: pd-pdogg
On Apr 25, 2011, at 1:44 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/25/2011 06:13 PM, Hans-Christoph Steiner wrote: I'd like to keep the short-form dh packages i think everybody now agrees that what we are discussing should be irrelevant of whether a specific package uses dh or cdbs or whatever. that I've done as they are, rather not, as some of those packages have an RC-bug filed (FTBFS), so we should fix that. using this same Makefile. I've spent a lot of time building up a whole unfortunately the upstream Makefile of the said packages is broken. since the upstream Makefile is essentially the same for all (your) packages (though their are different generations, with recent enough upstream Makefiles not exposing the problem) it would make sense to further centralize this Makefile, so any problem could be fixed by fixing this Makefile, rather than fixing 10 identical ones. it would be good to find a workflow that fits both your needs and allows for easy fixes of 'important' bugs. I am not saying the same version of the same Makefile, obviously bugs should be fixed, and this Makefile can be, should be, and is often updated. What made the current thing hard to fix? This HURD/kFreeBSD build issue was going to be fixed upstream anyway, so I don't see the need to have a Debian-specific fix. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: hold uploading pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
On Apr 26, 2011, at 1:31 AM, Jonas Smedegaard wrote: On 11-04-26 at 11:12am, IOhannes m zmoelnig wrote: On 2011-04-25 23:10, IOhannes m zmölnig wrote: go ahead. But you also changed other things as well. apart from the ominous change from Depend to Suggest, the other other changes were fixes for lintian warnings and adding Vcs-stanzas to debian/control anyhow, nobody uploaded the packages yet and all changes are documented in git. if you indeed insist in Depending on pd-libdir, reverting this specific change should be trivial. Yes, this is a team, but... It seems to me that it is not our policy (or social style - we need not have policies about everything IMO) that anyone works on anything here - without prior coordination. It is always nice to ask _before_ messing with packages you are not directly involved in. Not sure if that was the case here, but from the reaction it seems so. In the Perl team we us the Uploaders field as a hint about who in the team is directly involved with maintaining it. We might do the same (if not policy here already?). I see teamwork not as all of us eating directly from the same big plate, but sitting in the same room eating together - being more directly inspired by work of each other than in big Debian, and some of us sharing some plates - but asking nicely before tasting treats from the plates of each other. So, instead of saying that it is easy to roll back I suggest that you roll it back yourself, IOhannes, since you did the change that is clearly disliked - technically correct or not. Afterwards, when not distracted by a social issue, it is easier discuss the technical issue of what package relation makes best sense for that particular package. I think you said it very well, Jonas. Since I started this thread, I feel I should also respond, but not to beat a dead horse. I'd sum it up in short American style as communication is essential to teamwork. ;) All of the changes might have been perfectly good, my problem is that I didn't hear anything of any of it until the upload request. I think its always best to ask before touching a repo that I have not touched before. I'm fine with direct commits, since reverting is easy, as long as I get a chance to review the commits before it gets uploaded. .hc [T]he greatest purveyor of violence in the world today [is] my own government. - 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: pd-cyclone: versioning scheme?
On Apr 21, 2011, at 4:39 AM, Jonas Smedegaard wrote: On 11-04-21 at 01:34pm, IOhannes m zmoelnig wrote: On 2011-04-21 12:56, Jonas Smedegaard wrote: On 11-04-21 at 11:10am, IOhannes m zmoelnig wrote: looking through potential problems of packages in my area of interest, i stumbled across pd-cyclone, which seems to have an incorrect debian/watch file: debian package is 0.1~alpha55-2 while uscan finds the upstream 0.1-alpha53-src to be more recent.. i added a versionmangler to get rid of the trailing -src part, but the real problem is of course the -alpha. personally i would suggest to replace -alpha by . (or .alpha), using a versionmangle clause. i'm wondering though, why the debian package version uses ~, which kind of clashes with the upstream version scheme, esp. as it is not taken care of in debian/watch. I don't know who did this particular changelog, but what I often do is treat alpha and beta releases as lower than the actual version number, to leave room for the eventual(!) case of upstream deciding to not bump the version number when dropping the alpha/beta flag (a.k.a. doing the final release). good point. however, in this specific case, there is no active upstream development anymore, so it is unlikely that upstream will make a release that breaks the version mangle (though of course, you never know). what is currently released as upstream, is a tgz put together by hans. Great that Hans is involved - but irrelevant for my point: When mangling versions for Debian, I generally avoid taking into account predictions of the future. This includes knowledge of upstream author or potential future release manager or whatever. I see no evidence from past releases that the version numbering scheme of that project cannot contain final releases with same digits as prereleases. That's all. I set the version with a ~ for the reasons that Jonas described. There will be another release of cyclone in the not-to-distant future, there are already changes committed to the upstream SVN (I'm the upstream maintainer). Also, after having discussions with the original author, the next release will probably be 0.1 with no prefix. There are others who might be interested in working on it more, so then there could be 0.2 in the works. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: please upload: pd-pdogg
On Apr 24, 2011, at 9:16 AM, Felipe Sateler wrote: On Sun, Apr 24, 2011 at 13:02, IOhannes m zmoelnig zmoel...@iem.at wrote: I see that some bugs (buils system, mostly) will require uploading all (or most) of the pd externals. Can we do something to avoid that? hmm, i'm not sure if i understand what you mean: i thought bugs can only be fixed by providing fixed versions. if a package is FTBFS because of broken bulid system, then the only solution i see is to fix the build system and re-upload the package. the only alternative i see, would be to centralize the build system, e.g. by providing a common makefile snippet that would be used instead of upstream's build system. i started centralizing once with a pd-pkg-tools library, but it ended up as a cdbs snippet (while almost all of the packages in question right now use shortform dh). also the cdbs snippet does not replace upstream build system, but rather fixes debian specifics (e.g. make shlibdeps work nicely with the non- standard extension) i'm not opposed at all to using a central (separately maintained) makefile, but hans has spent a lot of time crafting the current (upstream) makefile to make it work with a wide range of systems. the current template for the (upstream) Makefile already fixes the kFreeBSD/hurd problems, but the packages in question have not been updated (upstream) to use the new template, so i decided to fix the problem using packaging possibilities. This is the key part: for most pd externals, the makefile is essentially the same. Does it make sense to centralize that? What do others think? I'd like to keep the short-form dh packages that I've done as they are, using this same Makefile. I've spent a lot of time building up a whole workflow to fit well into dh style, which is the dominant system of Debian-NYC which I'm part of, and the upstream workflow. Its great that there is also CDBS stuff, but for the stuff I maintain, I don't want to switch. .hc If you are not part of the solution, you are part of the problem. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
hold uploading pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg
Hey IOhannes, Thanks for fixing these bugs. I'd appreciate it if you would talk to me as the maintainer of these packages before committing change and asking for them to be uploaded. Please give me a chance to review your changes even. pd-cxc, pd-ekext, pd-bsaylor, pd-markex, pd-mjlib, pd-sigpack, pd-smlib, pd-windowing, and pd-pdogg. It would have been one thing if you just fixed the kFreeBSD build issue in the bug reports, then I'd say go ahead. But you also changed other things as well. For example, it is not appropriate to change the Depends to Suggests. That will break things for some people. So you can use these packages without having pd-libdir installed, but many others will see it as broken if pd-libdir is not installed since the library won't load. What's the problem with Depending on pd-libdir? Its tiny, and builds everywhere, and only takes effect if you explicitly use features related to it. Otherwise its just a file on the filesystem. .hc On Apr 20, 2011, at 8:31 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 some of the pd-packages have an FTBFS bug reported. i fixed all of those packages (i knew of), and would appreciate if somebody could upload the package, as given in the subject (i admit i don't type this entire letter for each of the packages). Other changes in the package: - - added (short) Vcs stanzas (if there was none) - - Suggest pd-libdir rather than Depend on it, since each of those packages can be used perfectly well without pd-libdir installed; the latter only adds a bit more comfort - - minor cosmetic fixes to the package description (to keep lintian happy) i have NOT added myself to the uploaders, but i upated debian/ changelog, so this gives some NMU-lintian warnings (which will go away if the real uploader touches the changelog, so i didn't bother), but apart from that the package appears to be lintian clean. the package has been build without problems in a pbuilder chroot. i pushed everything to [1]. please have a look and eventually upload (or comment) fgmasdr IOhannes [1] git://git.debian.org/pkg-multimedia/pd-cxc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2u/F8ACgkQkX2Xpv6ydvQbxwCg2UaW4sQNFy6HJZyhRRtKIRi5 LuEAoLtH6idA76pjU0Ng/ZRdII2QWviD =C3Ub -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Debian Maintainer application
Hey all, I've just posted my application to debian-newmaint for Debian Maintainer status. I have two DDs who have said they'd advocate my application. I'd appreciate any other support people are willing to offer. You can find my application on the debian-newmaint list: http://lists.debian.org/debian-newmaint/2011/03/msg0.html And here are the instructions how to officially advocate my application (check step 3): http://wiki.debian.org/DebianMaintainer .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-list-abs
On Wed, 2011-02-09 at 17:44 -0300, Felipe Sateler wrote: On Fri, Jan 21, 2011 at 03:35, Hans-Christoph Steiner h...@at.or.at wrote: pd-list-abs is a collection of objects for working with lists pd-list-abs is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends or Depends http://git.debian.org/?p=pkg-multimedia/pd-list-abs.git;a=summary This package will work on all platforms, since its just scripts, no compilation. Please update the changelog date. For shame, I did it again... sorry about that. It's updated and pushed. For some reason when I start a new pkg, I forget to do that. I guess I didn't need to add anything to the changelog, so I didn't run dch. It would be nice to have a changelog mode in emacs that automatically updated the timestamp when I edit a debian/changelog even when running 'emacs debian/changelog', not just 'dch'. This package should now truly be ready for upload! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-list-abs
pd-list-abs is a collection of objects for working with lists pd-list-abs is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends or Depends http://git.debian.org/?p=pkg-multimedia/pd-list-abs.git;a=summary This package will work on all platforms, since its just scripts, no compilation. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: new package pd-readanysf
Works for me. .hc On Wed, 19 Jan 2011 00:12 +0100, Roman Haefeli reduz...@gmail.com wrote: Hi all Now since gmerlin-avdecoder is in 'New', I think pd-readanysf is ready for upload, too. If anyone wants to have a look? BTW: It uses short-form dh. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: request for sponsorship for pd-hid
On Fri, 24 Dec 2010 15:37 -0800, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 24, 2010, at 9:19 AM, Felipe Sateler wrote: On Wed, Dec 22, 2010 at 21:13, Hans-Christoph Steiner h...@at.or.at wrote: Just ITPed, packaged and uploaded pd-hid to git.debian.org. It is an object for Pure Data that allows you to use USB HID devices in Pd. The build system is similar in structure to pd-plugin and pd-freeverb, plus it includes the kFreeBSD and Hurd updates, so it should build on all platforms. It depends on pd-mapping and recommends pd-pddp, which are both in NEW. http://git.debian.org/?p=pkg-multimedia/pd-hid.git;a=summary There is some code that is not yours, please add Jan Truetzschler Falkenstein to the debian/copyright file (ftpmaster may reject the package for this missing information). Thanks for spotting that, I pushed the fix. Ping. Anyone willing to sponsor this one? .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: gmerlin-avdecoder ready (2nd try)
On Jan 16, 2011, at 3:18 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2011 12:24 PM, Alessio Treglia wrote: 2011/1/14 IOhannes zmölnig zmoel...@iem.at: i think i fixed the remaining issues with gmerlin-avdecoder. package appears to be lintian clean. Should not we upload gmerlin first? yes of course. but this doesn't mean that i don't consider gmerlin-avdecoder ready :-) AFAIK, gmerlin-avdecoder does not require gmerlin, only libgavl of the gmerlin suite. At least when I packaged gmerlin-avdecoder for Fink, that was the case. .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: build-depend version with dfsg
On Jan 12, 2011, at 1:21 PM, Jonas Smedegaard wrote: On Wed, Jan 12, 2011 at 05:28:54PM +0100, IOhannes m zmoelnig wrote: while packaging gmerlin-avdecoder i noticed a slight problem with the build-depends: it used to be libgmerlin-dev (= 1.0.0) but since gmerlin has to be repackaged (to be dfsg compliant), the actually installed version is 1.0.0~dfsg-1 now i don't understand, why =1.0.0 is not satisfied with 1.0.0~dfsg-1 everything works fine, if i build-depend on (= 1.0.0~dfsg) am i missing something? and if gmerlin makes a bugfix release that gets rid of the dfsg problems, so we will be able to create libgmerlin-dev_1.0.1-1, will (=1.0.0~dfsg) be satisfied? The special char ~ means just below in Debian-version-speak. So it makes good sens that a dependency on =1.0.0 is not satisfied by =1.0.0~anything-at-all, and that is just below 1.0.0. Hope that helps. I think you could Build-Dep on (= 1.0.0~) just to be safe. That'd be the lowest version of 1.0.0 with a tilde version as far as I understand it. .hc I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: gmerlin-avdecoder ready?
I'm just going to be a cheerleader here a bit, and say: go go GO! It'll be great when we can have pd-readanysf in Debian, which uses gmerlin-avdecoder. I'm sure there are others as well (gem?). .hc On Jan 12, 2011, at 2:54 PM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 afaict, gmerlin-avdecoder is ready! anybody interested, please check out: git+ssh://git.debian.org/git/pkg-multimedia/gmerlin-avdecoder the package depends on the new version of libgmerlin which is not yet uploaded (nor 100% ready afaict), but to me that's the only hurdle. f gadmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0uBuwACgkQkX2Xpv6ydvTyUQCeMApyF2xK1wrqjHh5Ssh9KCty mqIAoIJKSpyal/SRgIkX685BLlIvmk9C =Ms3N -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers 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
Bug#609431: pd-maxlib: FTBFS on kfreebsd-*: undefined references
Yeah, all of these pd-* libraries that I submitted use the same Makefile, more or less. I updated the Makefile so the more recently submitted packages already include the required fixes. Now its just a matter of updating the rest. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-moonlib_0.2-1_amd64.changes REJECTED
On Wed, 2011-01-05 at 12:51 +0100, Jonas Smedegaard wrote: On Wed, Jan 05, 2011 at 12:08:20AM -0500, Hans-Christoph Steiner wrote: Ok, I updated the debian/copyright and pushed the changes to git.debian.org. Its ready for re-upload. I just wanted to add that the previous condition was legal, LGPL-2.1 files can be incorporated into a GPL-2 project, so it was correct to say that the whole project could be used under the GPL-2. It is not correct to say that the whole library could be used under the LGPL-2.1 though, only some of the files, if used in isolation. Legal, yes: The licenses are indeed compatible. The issue, though, is about Policy compliance: §4.5 requires including verbatim copies of licensing - meaning that even if we legally are allowed to relicense under different compatible terms, we limit ourselves to only _reuse_ upstream licensing. The library as a whole is licensed using GPL-2 by upstream in the LICENSE.txt file. The relicensing was done upstream. More info is good, no argument there, but rejecting the package seems harsh. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-moonlib_0.2-1_amd64.changes REJECTED
Ok, I updated the debian/copyright and pushed the changes to git.debian.org. Its ready for re-upload. I just wanted to add that the previous condition was legal, LGPL-2.1 files can be incorporated into a GPL-2 project, so it was correct to say that the whole project could be used under the GPL-2. It is not correct to say that the whole library could be used under the LGPL-2.1 though, only some of the files, if used in isolation. .hc On Tue, 2011-01-04 at 20:56 +, Torsten Werner wrote: Hi Maintainer, I have found several LGPL licensed files but this license is not documented. Torsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Dec 31, 2010, at 8:11 AM, Jonas Smedegaard wrote: On Fri, Dec 31, 2010 at 12:51:47AM -0500, Hans-Christoph Steiner wrote: On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. If you mean to say that the control.in annoys you, then fine. If, on the other hand, you mean to say that you guess noone use the .in file then you're wrong: I use it (as long as noone is annoyed by it). Currently @cdbs@ resolves to cdbs, debhelper (= 6), dh-buildinfo. As an example, if at some point debhelper compat level is bumped to 7, I bet manual build-dependency handling would be to just tighten to debhelper (= 7) but that is wrong - cdbs needs to be tightened too due to a bug in early implementations of debhelper 7 support in CDBS, and also (still in dispute, though - Joy disagrees with this!) build-dependency on debhelper itself is tightened further than just 7 as well, because not all of the core debhelper 7 features was implemented initially. For the record, I'm not saying that no one uses the file, or that the automatic Build-Depends handling isn't useful. I'm saying I think in this package, the benefits of the control.in are smaller than the disadvantages. .hc From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. I disagree. Some files make sense only to autogenerate by the respective code developers, and then (normally) shipped with the code and treated as source by users of the code. Examples of this is Makefile files (when automake is used), Makefile.in files and configure (when autoconf is used) and debian/control (when CDBS dependency-resolving is used). For autotools it is possible to help distinguish between user and maintainer modes of operation with an optional configure flag -- maintainer-mode, and similarly CDBS has DEB_MAINTAINER_MODE. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-jmmmp
On Dec 31, 2010, at 11:46 AM, Felipe Sateler wrote: On Wed, Dec 29, 2010 at 19:03, Hans-Christoph Steiner h...@at.or.at wrote: pd-jmmmp is a collection of GUI controls pd-jmmmp is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg- multimedia. It is a library without any special Build-Depends. It does Depend on 'pd- zexy', that's been in Debian for a good long time, and http://git.debian.org/?p=pkg-multimedia/pd-jmmmp.git;a=summary Also, this package should be a test for the new Makefile to see if it'll build properly on GNU/kFreeBSD and GNU/Hurd. This is an arch:all package so it will only be built in the uploader's machine. The license linked in the pd libdir is the BSD license. It will probably go away (the one in common-licenses), so it should not be used. Plus, the license should cover the GPL parts too, I believe (since it is the equivalent of debian's copyright file), so I think it is correct in this case to ship the LICENSE.txt file in the pd libdir. Yeah, that makes sense. I pushed the changes. I originally thought the library was just BSD when I first packaged it, but upon tracking down the included images, I realized those were GPL since they are from Ardour. .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: adding a binary package to pd-cyclone
On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting upload for pd-libdir
On Sun, 2010-12-19 at 15:17 -0500, Hans-Christoph Steiner wrote: So I added a patch to pd-libdir to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605828 .hc Ping! Anyone have a moment to upload this? Its the last open bug for my packages :) Happy New Year! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-jmmmp
pd-jmmmp is a collection of GUI controls pd-jmmmp is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does Depend on 'pd- zexy', that's been in Debian for a good long time, and http://git.debian.org/?p=pkg-multimedia/pd-jmmmp.git;a=summary Also, this package should be a test for the new Makefile to see if it'll build properly on GNU/kFreeBSD and GNU/Hurd. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Dec 24, 2010, at 9:41 AM, Jonas Smedegaard wrote: On Fri, Dec 24, 2010 at 02:10:27PM -0300, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? A search engine, perhaps? It would be useful to Max/MSP users separate from Pd. And perhaps also useful to other computer music people. The binary file format is really only for Max/MSP, but the text file format is quite old, and used by a number of other members of the Max family. Pd and jMax for example, which are free software, and Max/FTS and Max/ISPW which are specialty proprietary versions of Max. .hc A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: request for sponsorship for pd-hid
On Dec 24, 2010, at 9:19 AM, Felipe Sateler wrote: On Wed, Dec 22, 2010 at 21:13, Hans-Christoph Steiner h...@at.or.at wrote: Just ITPed, packaged and uploaded pd-hid to git.debian.org. It is an object for Pure Data that allows you to use USB HID devices in Pd. The build system is similar in structure to pd-plugin and pd-freeverb, plus it includes the kFreeBSD and Hurd updates, so it should build on all platforms. It depends on pd-mapping and recommends pd-pddp, which are both in NEW. http://git.debian.org/?p=pkg-multimedia/pd-hid.git;a=summary There is some code that is not yours, please add Jan Truetzschler Falkenstein to the debian/copyright file (ftpmaster may reject the package for this missing information). Thanks for spotting that, I pushed the fix. .hc “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/mailman/listinfo/pkg-multimedia-maintainers
request for sponsorship for pd-hid
Just ITPed, packaged and uploaded pd-hid to git.debian.org. It is an object for Pure Data that allows you to use USB HID devices in Pd. The build system is similar in structure to pd-plugin and pd-freeverb, plus it includes the kFreeBSD and Hurd updates, so it should build on all platforms. It depends on pd-mapping and recommends pd-pddp, which are both in NEW. http://git.debian.org/?p=pkg-multimedia/pd-hid.git;a=summary .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
adding a binary package to pd-cyclone
I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd- cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd- cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-earplug
Package: src:pd-earplug I added a patch to pd-earplug to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605825 .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-comport
I added a patch to pd-comport to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605823 .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-beatpipe
I added a patch to pd-beatpipe to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605822 .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-bassemu
I added a patch to pd-bassemu to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605821 .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-plugin
I added a patch to pd-plugin to make it build on kFreeBSD and Hurd. Its been tested now, so its ready for upload. It closes this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605829 .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
request for upload for puredata-import
Though there wasn't a bug report filed against it, I updated puredata-import also. I added a patch to make it build on kFreeBSD and Hurd. Its ready for upload! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
request for upload for pd-motex
Though there wasn't a bug report filed against it, I updated pd-motex also. I added a patch to make it build on kFreeBSD and Hurd. Its ready for upload! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-arraysize_0.1-1_amd64.changes REJECTED
Right now, all of the Pd library packages in Debian are one-package- per-library. This is how Pd libraries are packaged and distributed on all platforms. Introducing a pd-goodies means introducing some kind of packaging that only exists in Debian, not anywhere upstream. That just adds confusion for no real gain that I can see. Yes, pd-arraysize is a tiny bit of code. Its been distributed this way for 8+ years and is widely used this way. Its basically the only thing like this in the set of standard Pd libraries, so the pd-goodies package will end up only being pd-arraysize. .hc On Dec 10, 2010, at 5:18 PM, Luca Falavigna wrote: Hi, code is really trivial to be included in a single source package. I talked with Alessio, he mentioned this source might be included into a pd-goodies package, including similar pieces of code. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-mapping
On Dec 3, 2010, at 7:58 AM, Felipe Sateler wrote: On Tue, Nov 30, 2010 at 20:45, Hans-Christoph Steiner h...@at.or.at wrote: pd-mapping is a library of techniques for manipulating sensor data, and mapping them to the desired controls. pd-mapping is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does depend on pd-purepd and pd-cyclone, which are on git.debian.org awaiting finalization of sponsorship, and pd-pddp and pd-ggee which are in NEW. And pd-cyclone, which unfortunately still has some issues that Jonas caught. Ok, pd-cyclone, pd-ggee, pd-pddp, pd-purepd, and pd-zexy are all in unstable or NEW now. So hopefully pd-mapping is next! .hc kill your television ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting upload for pd-pmpd
So I added a patch to pd-pmpd to make it build on kFreeBSD and Hurd. Its been tested now, so I think its ready to upload. Once pd-pmpd goes thru and builds on all platforms, I use the patch on the rest of my packages in unstable which are affected by the kFreeBSD/ Hurd bug. .hc There is no way to peace, peace is the way. -A.J. Muste ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
package name prefix for Pd docs?
hey all, I'd like to start packaging some of the interactive documentation projects for Pure Data. Currently we are using the pd-* prefix for Pd libraries, now I am wondering whether we should have a separate prefix for Pd documentation. I think there are currently four projects that I'd like to package: pd-msg, playnow, messageoddness, pddp tutorials. So these are not like -doc packages because they are standalone projects not associated with a lib or app. They are more like books, but they are all interactive, runnable scripts. I could see these names: pd-msg playnow messageoddness pddp-tutorials -or- pd-msg-doc playnow-doc messageoddness-doc pddp-tutorials-doc Here are some similar packages that I found: perlprimer-doc rubybook Thoughts, suggestions, comments? .hc Access to computers should be unlimited and total. - the hacker ethic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] pd-cyclone/master: Rewrite copyright file: Main licensing changed; Authors dropped; Lack of licensing added!!!
On Dec 10, 2010, at 4:14 AM, Jonas Smedegaard wrote: On Fri, Dec 10, 2010 at 12:08:15AM -0500, Hans-Christoph Steiner wrote: On Fri, 2010-12-03 at 11:14 +0100, Jonas Smedegaard wrote: The grandfathered licensing terms include this: The authors hereby grant permission [...], provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. We therefore need to involve upstream and request them to include above licensing, as their granted license was violated when the header was stripped, and they therefore cannot pass on a license to us (or anyone else) for that file. All of the code in that library, borrowed or not, is under the same license: the Tcl/Tk license. Is it still necessary to include multiple copies of the Tcl/Tk license as long as we have the copyrights listed in debian/copyright? Maybe if you can suggest an alternative interpretation of provided that existing copyright notices are retained in all copies. I can only come up with one interpretation, which means the licensing upstream passed to us is bogus, since they lost _their_ license! I do see notice of copyright in debian/copyright with each line marked Copyright: I know the proprietary software Cycling '74 Max/MSP uses code from Pd, which is BSD licensed. They do include the line of credit in their own copyright statement, but they don't include the actual BSD license file that I could find. So I'm not the only one to have that opinion. http://en.wikipedia.org/wiki/Copyright_notice If e.g. IOhannes m. zmoelnig is mentioned due to Debian packaging, I suggest to add a copyright (and licensing! they always go together) statement in ebian/rules, and keep debian/copyright as a reference file rather than containing unique info on its own. You don't want to claim copyright for the Debian packaging? Personally, I always consider my own packaging work either public domain, or part of the copyright of the upstream software itself. I see no benefit to adding copyright complexity. Ok, I updated the copyright based on this thread, deleted copyright_hints, and pushed my changes. I think that should sort out the copyright issues. As far I am concerned, this ready for upload. Agreed. I'm working on it now. Excellent, thanks! .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] pd-cyclone/master: Rewrite copyright file: Main licensing changed; Authors dropped; Lack of licensing added!!!
On Dec 10, 2010, at 12:12 PM, Jonas Smedegaard wrote: On Fri, Dec 10, 2010 at 11:19:39AM -0500, Hans-Christoph Steiner wrote: On Dec 10, 2010, at 4:14 AM, Jonas Smedegaard wrote: On Fri, Dec 10, 2010 at 12:08:15AM -0500, Hans-Christoph Steiner wrote: On Fri, 2010-12-03 at 11:14 +0100, Jonas Smedegaard wrote: The grandfathered licensing terms include this: The authors hereby grant permission [...], provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. We therefore need to involve upstream and request them to include above licensing, as their granted license was violated when the header was stripped, and they therefore cannot pass on a license to us (or anyone else) for that file. All of the code in that library, borrowed or not, is under the same license: the Tcl/Tk license. Is it still necessary to include multiple copies of the Tcl/Tk license as long as we have the copyrights listed in debian/copyright? Maybe if you can suggest an alternative interpretation of provided that existing copyright notices are retained in all copies. I can only come up with one interpretation, which means the licensing upstream passed to us is bogus, since they lost _their_ license! I do see notice of copyright in debian/copyright with each line marked Copyright: I know the proprietary software Cycling '74 Max/ MSP uses code from Pd, which is BSD licensed. They do include the line of credit in their own copyright statement, but they don't include the actual BSD license file that I could find. So I'm not the only one to have that opinion. Two wrongs don't make a right. I was just illustrating that it is common practice, tho its not 100% correct according to the letter of license. Duplicating the copyright notice alone does certainly fully respect the spirit of the license, IMHO. http://en.wikipedia.org/wiki/Copyright_notice It is not obvious to me why did you referenced that page. Was it because it mentions copyright notices no longer required in USA jurisdiction? Well, that is irrelevant for my point, as I am not talking about claiming copyright, but about obeying a license: the _license_ requires copyrigh notices to be reserved IN ALL COPIES. I was trying to point out that the notice is not the license, its just the Copyright 2000, Hans-Christoph Steiner line. .hc If e.g. IOhannes m. zmoelnig is mentioned due to Debian packaging, I suggest to add a copyright (and licensing! they always go together) statement in ebian/rules, and keep debian/ copyright as a reference file rather than containing unique info on its own. You don't want to claim copyright for the Debian packaging? Personally, I always consider my own packaging work either public domain, or part of the copyright of the upstream software itself. I see no benefit to adding copyright complexity. Ah, yes. I remmeber now that you made that point earlier on too. Sorry for bothering you with that once more. I do respect your standpoint. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-purepd
On Fri, 2010-12-03 at 09:54 -0300, Felipe Sateler wrote: On Fri, Dec 3, 2010 at 09:54, Felipe Sateler fsate...@debian.org wrote: On Tue, Nov 30, 2010 at 20:44, Hans-Christoph Steiner h...@at.or.at wrote: pd-purepd is a library of common operations implemented in Pd rather than C. Its a fledgling effort somewhat akin to the pypy implementation of Python in Python. pd-purepd is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does depend on pd-pddp which is in NEW. And also in pd-list-abs. And remember to upadte the changelog! Hehe, thanks for the reminder! I made a new upstream release 0.1.1 to get rid of the list-abs dependency, and imported into the pd-purepd git. I think this one is ready to go! (and I even updated the changelog and its timestamp!) .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] pd-cyclone/master: Rewrite copyright file: Main licensing changed; Authors dropped; Lack of licensing added!!!
On Fri, 2010-12-03 at 11:14 +0100, Jonas Smedegaard wrote: On Fri, Dec 03, 2010 at 09:56:41AM +, j...@users.alioth.debian.org wrote: Rewrite copyright file: Main licensing changed; Authors dropped; Lack of licensing added!!! -Copyright: 1997-2005, Miller Puckette - 1997-2007, Krzysztof Czaja - 2003-2010, Hans-Christoph Steiner - 2004-2005, Carmen Rocco - 2009, IOhannes m. zmoelnig +Copyright: 1997-2005, 2007, krzYszcz +1997-2005, Miller Puckette Please note that I dropped authors (or more accurately: copyright holders) not mentioned anywhere else as such. If e.g. IOhannes m. zmoelnig is mentioned due to Debian packaging, I suggest to add a copyright (and licensing! they always go together) statement in ebian/rules, and keep debian/copyright as a reference file rather than containing unique info on its own. NB! This is a kind suggestion only. It is not mandated by Debian Policy AFAIK. But it really helps for things like semi-automated copyright checking if separated like that. +Copyright: cycling'74; +License: NONE + FIXME + +Files: ./bin/pddp/pddpserver.tcl +Copyright: 1996-1997, Sun Microsystems +License: NONE + FIXME Above two must be fixed! I did not update changelog, as I am uncertain if current entry was already released or not. Ok, I updated the copyright based on this thread, deleted copyright_hints, and pushed my changes. I think that should sort out the copyright issues. As far I am concerned, this ready for upload. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] gmerlin-avdecoder/master: Update copyright (still BSD-4 flaws to workout, though).
On Fri, 2010-12-10 at 00:23 -0300, Felipe Sateler wrote: On Thu, Dec 9, 2010 at 14:20, IOhannes m zmoelnig zmoel...@iem.at wrote: On 2010-11-23 13:17, Alessio Treglia wrote: Hi Burkhard, We've imported the sources of gmerlin_avdecoder from your CVS repository and we've found another licensing issue: On Sat, Nov 20, 2010 at 10:28 AM, j...@users.alioth.debian.org wrote: -Files: ./include/bgav_sem.h -Copyright: 1996-1997, HD Associates, Inc. - 2001-2010, Members of the Gmerlin project -License: BSD-4 and GPL-2+ +Files: ./lib/os_inet_aton.c +Copyright: 1983, 1990, 1993, The Regents of the University of California +License: BSD-4 FIXME As reported above, the file lib/os_inet_aton.c [1] is licensed as 4-clause BSD and it's not compatible with GPL-2. Would you fix this? now that gmerlin seems to apporach the next release, this becomes an issue for use again. however, in an older email of mine i discovered: - lib/os.c has the BSD-code moved away into lib/os_inet_aton.c (which can be excluded by us) so we could just filter the lib/os_inet_aton.c out, patch the MakefileS to not build this file and be done (looking at the offending file it is totally protected by ifndef HAVE_INET_ATON, and i think we can safely assume that we _do have_ inet_aton, no? Does having it sit in the source (and not build it) present any problems? I don't think so, since the BSD-4 stuff does not mix with the GPL-2 stuff. Its kind of grey if this is ok. The license seems to say that the advertising clause would only take effect if the file is used in the software, not just distributed as is. But its not very clear to me. Much better would be if upstream (Burkhard) used one of the New BSD or GPL'ed version of this file, like: http://svn.freebsd.org/viewvc/base/head/sys/libkern/inet_aton.c http://doxygen.postgresql.org/inet__aton_8c-source.html .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#605830: pd-pmpd: FTBFS on non-Linux: undefined references
I just pushed the relevant changes to the git repo for this package, pkg-multimedia/pd-pmpd.git. It is based on a patch that worked for a closely related package, pd-iemnet, where it worked. I don't have access to a kFreeBSD or Hurd machine, can anyone try building this on those platforms? If it works, then I'll lobby to have it uploaded. .hc On Fri, 2010-12-03 at 21:30 +0100, Cyril Brulebois wrote: Source: pd-pmpd Version: 0.9-2 Severity: important Hi, your package FTBFS on non-Linux with undefined references: | cc -o iAmbient2D. iAmbient2D.o | /usr/lib/gcc/x86_64-kfreebsd-gnu/4.4.5/../../../../lib/crt1.o: In function `_start': | (.text+0x23): undefined reference to `main' | iAmbient2D.o: In function `iAmbient2D_bang': | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:103: undefined reference to `gensym' | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:103: undefined reference to `pd_typedmess' | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:105: undefined reference to `gensym' | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:105: undefined reference to `outlet_anything' | iAmbient2D.o: In function `iAmbient2D_new': | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:110: undefined reference to `pd_new' | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:112: undefined reference to `atom_getsymbolarg' | /build/buildd-pd-pmpd_0.9-2-kfreebsd-amd64-gyqrxF/pd-pmpd-0.9/iAmbient2D.c:114: undefined reference to `outlet_new' | […] Full build logs: https://buildd.debian.org/status/package.php?p=pd-pmpd Mraw, KiBi. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-ggee
On Nov 30, 2010, at 6:20 PM, Hans-Christoph Steiner wrote: On Sun, 2010-11-28 at 15:01 -0300, Felipe Sateler wrote: On Thu, Nov 18, 2010 at 14:16, Hans-Christoph Steiner h...@at.or.at wrote: On Wed, 2010-11-17 at 16:11 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:23, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 14, 2010, at 12:16 PM, Hans-Christoph Steiner wrote: On Nov 13, 2010, at 9:12 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:18, Hans-Christoph Steiner h...@at.or.at wrote: pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg- multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary I'm not quite comfortable with the license, and I am no legalese person so I try to stick to standard-licensed software... Could you please run this license through the debian-legal list to get some input on it? My concern is specifically about the last paragraph. Yeah, the license is a bit weird, I don't know what its officially called, but it is the same text as the [incr Tcl] license, which is included in Debian: http://packages.debian.org/changelogs/pool/main/i/itcl3/ itcl3_3.4~b1-2/itcl3.copyright The only difference is that the GOVERNMENT USE section is more verbose in the itcl license, but they reference the same regulation numbers. It seems to be the Tcl/Tk license: http://www.tcl.tk/software/tcltk/license.html Indeed. Please add the pristine-tar data to the repository, so I can generate the appropriate tarball. Oops, sorry, I forgot to push the tags and branches I suppose. They should be up there now. The changelog was not correctly dated. In order to avoid even more delays I updated it myself. Uploaded. Sorry for my continuing lameness on that timestamp. Once I make updates to these packages, it'll become part of the natural flow since dch is the easiest way to update the changelog. Thanks for uploading, time to dig up a couple more! :-D .hc Hey Felipe, It seems that there was something wrong with the pd-ggee upload, its complaining about NMU stuff. I'm guessing this is because the changelog has your name/email at the bottom: http://ftp-master.debian.org/new/pd-ggee_0.26-1.html#source-lintian W: pd-ggee source: changelog-should-mention-nmu W: pd-ggee source: source-nmu-has-incorrect-version-number 0.26-1 .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-cyclone
On Sun, 2010-11-28 at 16:26 -0300, Felipe Sateler wrote: On Thu, Nov 18, 2010 at 14:03, Hans-Christoph Steiner h...@at.or.at wrote: On Wed, 2010-11-17 at 16:50 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:33, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 13, 2010, at 8:37 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:17, Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 2010-11-11 at 09:19 +0100, Jonas Smedegaard wrote: On Thu, Nov 11, 2010 at 12:15:05AM -0500, Hans-Christoph Steiner wrote: pd-cyclone is a huge library of all sorts of objects that are clones of objects in Max/MSP4.5, Pd's proprietary cousin. It also includes utilities for importing Max files. pd-cyclone is a long-form dh package that is a wrapper to a very complicated Make build system. pd-cxc is in git.debian.org/pkg-multimedia. It is a library without depends that are new packages. It builds on my i386, but it did not build on the launchpad amd64 build machine, it died on this error, which has stumped me: dpkg-genchanges -B -mUbuntu/amd64 Build Daemon bui...@titanium.ppa ../pd-cyclone_0.1~alpha55-1~maverick_amd64.changes dpkg-genchanges: arch-specific upload - not including arch-independent packages dpkg-genchanges: error: cannot read files list file: No such file or directory It looks odd to me that you use no debhelper tools in the binary-arch target - only in the binary-indep one. Thanks, that was the key. This now builds on i386 and amd64 and is ready to go. The git repository is not fixed. I am not sure I understand. What I see on git.debian.org is the same as what I have on my machine, and I used git-buildpackage to make the source package to submit to Launchpad: http://launchpad.net/~eighthave/+archive/libdirs/+sourcepub/1362005/+listing-archive-extra Oh it was fixed, my bad. But there is a large commit that changes many things at once (d634143), and the change was hidden there. Also, why do you use long-form debhelper? Because I didn't see a way to do it with short-form. This library has a very elaborate build system that I've tried for years to figure out. Instead I've found the best way is to wrap it into something more understandable, and long-form seemed the easiest way to do that. Indeed, the makefile is quite convoluted. It also can't handle it when the user passes CFLAGS and other variables. Also, it sets -j4 unconditionally. On further inspection, the package seems to bundle the pddp source. Are riddle, sickle and ViCious more code copies? We should not use code copies. We need to avoid using them. This is how cyclone is released. The code in 'pddp', 'riddle', and 'ViCious' are unused. The 'pddp' code shared some code with pd-pddp, but not all. The code in 'sickle' is fully part of pd-cyclone and used. OK. Are you willing to look into a switch to cdbs (using long-form debhelper does not make much sense, and I personally prefer cdbs over dh)? I have pushed a cdbs branch to the git repository for you to look at. If you are willing to give cdbs a try, we can merge into the master branch and I can continue the review and upload. I just checked out it, it looks more straightforward to use cdbs for pd-cyclone, so I say go for it! One thing I noticed is that there isn't a Build-Depend on cdbs. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-ggee
On Sun, 2010-11-28 at 15:01 -0300, Felipe Sateler wrote: On Thu, Nov 18, 2010 at 14:16, Hans-Christoph Steiner h...@at.or.at wrote: On Wed, 2010-11-17 at 16:11 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:23, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 14, 2010, at 12:16 PM, Hans-Christoph Steiner wrote: On Nov 13, 2010, at 9:12 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:18, Hans-Christoph Steiner h...@at.or.at wrote: pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg-multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary I'm not quite comfortable with the license, and I am no legalese person so I try to stick to standard-licensed software... Could you please run this license through the debian-legal list to get some input on it? My concern is specifically about the last paragraph. Yeah, the license is a bit weird, I don't know what its officially called, but it is the same text as the [incr Tcl] license, which is included in Debian: http://packages.debian.org/changelogs/pool/main/i/itcl3/itcl3_3.4~b1-2/itcl3.copyright The only difference is that the GOVERNMENT USE section is more verbose in the itcl license, but they reference the same regulation numbers. It seems to be the Tcl/Tk license: http://www.tcl.tk/software/tcltk/license.html Indeed. Please add the pristine-tar data to the repository, so I can generate the appropriate tarball. Oops, sorry, I forgot to push the tags and branches I suppose. They should be up there now. The changelog was not correctly dated. In order to avoid even more delays I updated it myself. Uploaded. Sorry for my continuing lameness on that timestamp. Once I make updates to these packages, it'll become part of the natural flow since dch is the easiest way to update the changelog. Thanks for uploading, time to dig up a couple more! :-D .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-purepd
pd-purepd is a library of common operations implemented in Pd rather than C. Its a fledgling effort somewhat akin to the pypy implementation of Python in Python. pd-purepd is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does depend on pd-pddp which is in NEW. http://git.debian.org/?p=pkg-multimedia/pd-purepd.git;a=summary Also, this package should build properly on GNU/kFreeBSD and GNU/Hurd. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-mapping
pd-mapping is a library of techniques for manipulating sensor data, and mapping them to the desired controls. pd-mapping is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does depend on pd-purepd and pd-cyclone, which are on git.debian.org awaiting finalization of sponsorship, and pd-pddp and pd-ggee which are in NEW. http://git.debian.org/?p=pkg-multimedia/pd-mapping.git;a=summary Also, this package should build properly on GNU/kFreeBSD and GNU/Hurd. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-boids
Wow, fast, thanks! .hc On Nov 24, 2010, at 6:09 AM, Reinhard Tartler wrote: uploaded -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers 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/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-vbap
'vbap' is a library for sound spatialization using the Vector Base Amplitude Panning algorithm. pd-vbap is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does Recommend pd-cyclone for some of the help and example files. http://git.debian.org/?p=pkg-multimedia/pd-vbap.git;a=summary Also, this package should be a test for the new Makefile to see if it'll build properly on GNU/kFreeBSD and GNU/Hurd. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-boids
pd-boids is a Pd library that implements the 'boids' algorithm for flocking. pd-boids is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. It is on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does Recommend 'gem' for some of the help and example files, but that's been in Debian for a good long time. http://git.debian.org/?p=pkg-multimedia/pd-boids.git;a=summary Also, this package should be a test for the new Makefile to see if it'll build properly on GNU/kFreeBSD and GNU/Hurd. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-cyclone
On Nov 19, 2010, at 5:30 PM, Felipe Sateler wrote: On Thu, Nov 18, 2010 at 14:03, Hans-Christoph Steiner h...@at.or.at wrote: On Wed, 2010-11-17 at 16:50 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:33, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 13, 2010, at 8:37 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:17, Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 2010-11-11 at 09:19 +0100, Jonas Smedegaard wrote: On Thu, Nov 11, 2010 at 12:15:05AM -0500, Hans-Christoph Steiner wrote: pd-cyclone is a huge library of all sorts of objects that are clones of objects in Max/MSP4.5, Pd's proprietary cousin. It also includes utilities for importing Max files. pd-cyclone is a long-form dh package that is a wrapper to a very complicated Make build system. pd-cxc is in git.debian.org/pkg-multimedia. It is a library without depends that are new packages. It builds on my i386, but it did not build on the launchpad amd64 build machine, it died on this error, which has stumped me: dpkg-genchanges -B -mUbuntu/amd64 Build Daemon bui...@titanium.ppa ../pd-cyclone_0.1~alpha55-1~maverick_amd64.changes dpkg-genchanges: arch-specific upload - not including arch- independent packages dpkg-genchanges: error: cannot read files list file: No such file or directory It looks odd to me that you use no debhelper tools in the binary-arch target - only in the binary-indep one. Thanks, that was the key. This now builds on i386 and amd64 and is ready to go. The git repository is not fixed. I am not sure I understand. What I see on git.debian.org is the same as what I have on my machine, and I used git-buildpackage to make the source package to submit to Launchpad: http://launchpad.net/~eighthave/+archive/libdirs/+sourcepub/1362005/+listing-archive-extra Oh it was fixed, my bad. But there is a large commit that changes many things at once (d634143), and the change was hidden there. Also, why do you use long-form debhelper? Because I didn't see a way to do it with short-form. This library has a very elaborate build system that I've tried for years to figure out. Instead I've found the best way is to wrap it into something more understandable, and long-form seemed the easiest way to do that. Indeed, the makefile is quite convoluted. It also can't handle it when the user passes CFLAGS and other variables. Also, it sets -j4 unconditionally. On further inspection, the package seems to bundle the pddp source. Are riddle, sickle and ViCious more code copies? We should not use code copies. We need to avoid using them. This is how cyclone is released. The code in 'pddp', 'riddle', and 'ViCious' are unused. The 'pddp' code shared some code with pd-pddp, but not all. The code in 'sickle' is fully part of pd-cyclone and used. .hc I am open to changing it to short-form, but I don't see a clear way to do it I don't really prefer short form, but it is just a matter of using override_dh_foo targets. It looks like it's going to be a busy week. I'll continue checking pd packages (hopefully) late next week. No problem, thanks for uploading all these packages! .hc “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/mailman/listinfo/pkg-multimedia-maintainers
Re: Licensing of gmerlin-avdecoder regression tests
On Nov 19, 2010, at 4:48 AM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2010 10:18 PM, Hans-Christoph Steiner wrote: Looking back at the log of this discussion, I think we just need to patch mentioned below and a DFSG tarball. Perhaps Berkhard, the upstream author, has already included the patch and stripped out the non-DFSG stuff from his CVS, so a 1.0.3~cvs package would be easier: the reason why i did not start packaging the CVS-snapshot is, that burkhard develops gavl and gmerlin-avdec in parallel, meaning that a CVS-snapshot of gmerlin-avdec _most likely_ (not confirmed though) will not compile with the last released version of gavl. so we would have to package gavl-CVS as well. i hoped that burkhard would do a proper release of gmerlin-avdecoder, which has not happened yet. I guess Alessio missed my Perhaps, I was just saying it was worth checking. I may be wrong, but I was under the impression that it was only the last release of gmerlin-avdecoder that needed a very specific version of libgavl. I believe there was a bug in libgavl that was causing problems in gmerlin-avdecoder. So unless you have specific words from Berkhard saying that this is generally the case, I think this is worth trying. .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/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-cyclone
On Wed, 2010-11-17 at 16:50 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:33, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 13, 2010, at 8:37 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:17, Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 2010-11-11 at 09:19 +0100, Jonas Smedegaard wrote: On Thu, Nov 11, 2010 at 12:15:05AM -0500, Hans-Christoph Steiner wrote: pd-cyclone is a huge library of all sorts of objects that are clones of objects in Max/MSP4.5, Pd's proprietary cousin. It also includes utilities for importing Max files. pd-cyclone is a long-form dh package that is a wrapper to a very complicated Make build system. pd-cxc is in git.debian.org/pkg-multimedia. It is a library without depends that are new packages. It builds on my i386, but it did not build on the launchpad amd64 build machine, it died on this error, which has stumped me: dpkg-genchanges -B -mUbuntu/amd64 Build Daemon bui...@titanium.ppa ../pd-cyclone_0.1~alpha55-1~maverick_amd64.changes dpkg-genchanges: arch-specific upload - not including arch-independent packages dpkg-genchanges: error: cannot read files list file: No such file or directory It looks odd to me that you use no debhelper tools in the binary-arch target - only in the binary-indep one. Thanks, that was the key. This now builds on i386 and amd64 and is ready to go. The git repository is not fixed. I am not sure I understand. What I see on git.debian.org is the same as what I have on my machine, and I used git-buildpackage to make the source package to submit to Launchpad: http://launchpad.net/~eighthave/+archive/libdirs/+sourcepub/1362005/+listing-archive-extra Oh it was fixed, my bad. But there is a large commit that changes many things at once (d634143), and the change was hidden there. Also, why do you use long-form debhelper? Because I didn't see a way to do it with short-form. This library has a very elaborate build system that I've tried for years to figure out. Instead I've found the best way is to wrap it into something more understandable, and long-form seemed the easiest way to do that. Indeed, the makefile is quite convoluted. It also can't handle it when the user passes CFLAGS and other variables. Also, it sets -j4 unconditionally. On further inspection, the package seems to bundle the pddp source. Are riddle, sickle and ViCious more code copies? We should not use code copies. We need to avoid using them. This is how cyclone is released. The code in 'pddp', 'riddle', and 'ViCious' are unused. The 'pddp' code shared some code with pd-pddp, but not all. The code in 'sickle' is fully part of pd-cyclone and used. .hc I am open to changing it to short-form, but I don't see a clear way to do it I don't really prefer short form, but it is just a matter of using override_dh_foo targets. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-ggee
On Wed, 2010-11-17 at 16:11 -0300, Felipe Sateler wrote: On Sun, Nov 14, 2010 at 14:23, Hans-Christoph Steiner h...@at.or.at wrote: On Nov 14, 2010, at 12:16 PM, Hans-Christoph Steiner wrote: On Nov 13, 2010, at 9:12 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:18, Hans-Christoph Steiner h...@at.or.at wrote: pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg-multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary I'm not quite comfortable with the license, and I am no legalese person so I try to stick to standard-licensed software... Could you please run this license through the debian-legal list to get some input on it? My concern is specifically about the last paragraph. Yeah, the license is a bit weird, I don't know what its officially called, but it is the same text as the [incr Tcl] license, which is included in Debian: http://packages.debian.org/changelogs/pool/main/i/itcl3/itcl3_3.4~b1-2/itcl3.copyright The only difference is that the GOVERNMENT USE section is more verbose in the itcl license, but they reference the same regulation numbers. It seems to be the Tcl/Tk license: http://www.tcl.tk/software/tcltk/license.html Indeed. Please add the pristine-tar data to the repository, so I can generate the appropriate tarball. Oops, sorry, I forgot to push the tags and branches I suppose. They should be up there now. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-pddp
pd-pddp is a short-form dh package that uses the same standard Makefile as pd-motex, pd-maxlib, etc. pd-pddp in on git.debian.org/pkg-multimedia. It is a library without any special Build-Depends. It does depend on pd-ggee for some of the help files. A number of other packages depend on pd-pddp, mostly for the helpfiles. http://git.debian.org/?p=pkg-multimedia/pd-pddp.git;a=summary .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Licensing of gmerlin-avdecoder regression tests
On Tue, 2010-11-16 at 11:42 +0100, Alessio Treglia wrote: Hello guys, please take a look at this temporary repository and let me know what you think [1]. Cheers. [1] http://git.debian.org/?p=collab-maint/gmerlin-avdecoder.git I get 404 - No such project. I would really like to see this lib in Debian. There is a really great library for Pd, pd-readanysf, that is based on it. Roman has already packaged it and I believe its just waiting on this package. As I remember, we just need to have a DFSG tarball, right? .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-windowing
On Nov 10, 2010, at 1:27 PM, Hans-Christoph Steiner wrote: is in git.debian.org/pkg-multimedia and ready for upload. It is a simple library for Pd without depends that are new packages. Thanks! Phew, I think I'll pause here for now... .hc It seems that this one got lost in the fray. Its a simple package, short form dh with no special Build-Depends or Depends. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsorship for pd-ggee
On Nov 13, 2010, at 9:12 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:18, Hans-Christoph Steiner h...@at.or.at wrote: pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg- multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary I'm not quite comfortable with the license, and I am no legalese person so I try to stick to standard-licensed software... Could you please run this license through the debian-legal list to get some input on it? My concern is specifically about the last paragraph. Yeah, the license is a bit weird, I don't know what its officially called, but it is the same text as the [incr Tcl] license, which is included in Debian: http://packages.debian.org/changelogs/pool/main/i/itcl3/itcl3_3.4~b1-2/ itcl3.copyright The only difference is that the GOVERNMENT USE section is more verbose in the itcl license, but they reference the same regulation numbers. .hc 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: requesting sponsorship for pd-ggee
On Nov 14, 2010, at 12:16 PM, Hans-Christoph Steiner wrote: On Nov 13, 2010, at 9:12 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:18, Hans-Christoph Steiner h...@at.or.at wrote: pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg- multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary I'm not quite comfortable with the license, and I am no legalese person so I try to stick to standard-licensed software... Could you please run this license through the debian-legal list to get some input on it? My concern is specifically about the last paragraph. Yeah, the license is a bit weird, I don't know what its officially called, but it is the same text as the [incr Tcl] license, which is included in Debian: http://packages.debian.org/changelogs/pool/main/i/itcl3/ itcl3_3.4~b1-2/itcl3.copyright The only difference is that the GOVERNMENT USE section is more verbose in the itcl license, but they reference the same regulation numbers. It seems to be the Tcl/Tk license: http://www.tcl.tk/software/tcltk/license.html .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-cyclone
On Nov 13, 2010, at 8:37 PM, Felipe Sateler wrote: On Thu, Nov 11, 2010 at 23:17, Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 2010-11-11 at 09:19 +0100, Jonas Smedegaard wrote: On Thu, Nov 11, 2010 at 12:15:05AM -0500, Hans-Christoph Steiner wrote: pd-cyclone is a huge library of all sorts of objects that are clones of objects in Max/MSP4.5, Pd's proprietary cousin. It also includes utilities for importing Max files. pd-cyclone is a long-form dh package that is a wrapper to a very complicated Make build system. pd-cxc is in git.debian.org/pkg-multimedia. It is a library without depends that are new packages. It builds on my i386, but it did not build on the launchpad amd64 build machine, it died on this error, which has stumped me: dpkg-genchanges -B -mUbuntu/amd64 Build Daemon bui...@titanium.ppa ../pd-cyclone_0.1~alpha55-1~maverick_amd64.changes dpkg-genchanges: arch-specific upload - not including arch- independent packages dpkg-genchanges: error: cannot read files list file: No such file or directory It looks odd to me that you use no debhelper tools in the binary- arch target - only in the binary-indep one. Thanks, that was the key. This now builds on i386 and amd64 and is ready to go. The git repository is not fixed. I am not sure I understand. What I see on git.debian.org is the same as what I have on my machine, and I used git-buildpackage to make the source package to submit to Launchpad: http://launchpad.net/~eighthave/+archive/libdirs/+sourcepub/1362005/+listing-archive-extra Also, why do you use long-form debhelper? Because I didn't see a way to do it with short-form. This library has a very elaborate build system that I've tried for years to figure out. Instead I've found the best way is to wrap it into something more understandable, and long-form seemed the easiest way to do that. I am open to changing it to short-form, but I don't see a clear way to do it .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Nov 12, 2010, at 4:43 AM, IOhannes zmölnig wrote: On 11/11/2010 08:30 PM, Hans-Christoph Steiner wrote: I'd like to have my packages work on all Debian platforms, but I have never worked with hurd or kfreebsd, nor have had any feedback that there are problems. As far as I can tell, my packages build on all Debian platforms. just call the build-logs for any of those packages. e.g. https://buildd.debian.org/status/package.php?p=pd-motex but this was just meant as an example for the added benefit of using a common cdbs/dh/.. snippet. Ah yes, still learning my way around all the Debian tools, they are pretty large. A common snippet would be great, no argument here. About the HURD/kFreeBSD issue, it seems to be a linking issue, do we have to handle the linking differently with those kernels? I guess the Makefile is lacking uname detection for those kernels, since its looking for 'Linux'. Hopefully just using the same settings for the other two kernels will work. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Nov 12, 2010, at 12:30 PM, IOhannes zmölnig wrote: On 11/12/2010 06:10 PM, Hans-Christoph Steiner wrote: Ah yes, still learning my way around all the Debian tools, they are pretty large. A common snippet would be great, no argument here. so now, we only have to do it :-) About the HURD/kFreeBSD issue, it seems to be a linking issue, do we have to handle the linking differently with those kernels? I guess the Makefile is lacking uname detection for those kernels, since its looking for 'Linux'. Hopefully just using the same settings for the other two kernels will work. yes, i think the only problem is that the Makefile thinks that it is compiling for an unknown target os (because uname returns something unknown), thus no CFLAGS, LDFLAGS,... are defined which means the defaults: the .c files are compiled as applications, which obviously won't work at all. and yes, you should be able to use the very same flags as on linux (and see the other thread why it might be a good idea to keep pd_linux as the filename extension for all debian) Works for me. I have a bunch of deadlines so I won't be able to touch this for a while. That's why I just had a big rush of work: I wanted to get it in before I was saddled with lots of things. .hc [T]he greatest purveyor of violence in the world today [is] my own government. - 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: requesting sponsor for pd-cxc
On Wed, 2010-11-10 at 20:05 -0300, Felipe Sateler wrote: On Wed, Nov 10, 2010 at 15:25, Hans-Christoph Steiner h...@at.or.at wrote: pd-cxc is in git.debian.org/pkg-multimedia and ready for upload. It is a simple library without depends that are new packages. I'm not quite sure the description is OK... Some comments: 1- Please avoid the use of I (as in the description for counter). 2- I have no idea what markex is, nor what counter or reson do. 3- I don't know what internal does either. Sigh... yeah, I'm working off of a lot of the upstream READMEs, hence the bad descriptions. I hopefully improved it. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
I'd like to have my packages work on all Debian platforms, but I have never worked with hurd or kfreebsd, nor have had any feedback that there are problems. As far as I can tell, my packages build on all Debian platforms. All I can say is: patches welcome. .hc On Nov 11, 2010, at 3:49 AM, IOhannes m zmoelnig wrote: On 2010-11-11 09:09, Jonas Smedegaard wrote: include /usr/share/cdbs/1/rules/standard-pd-object.mk What do you think? That looks very handy, but I think the given library template is well tuned. well, i think the template library Makefile fails on the the kfreebsd and hurd platforms (at least according to the build logs). i understand that these platforms are not the main targets, but since we are on debian, there is no good reason to not include them. a common makefile snippet could help a lot (also on debian-derivatives that have x86 derived architectures (e.g. i686), that could benefit from enabling optimzations globally (think SIMD)) sidenote the above looks a bit ironic to me... within the pd-community i guess that i was (and am) one of the stronger advocates of self-contained build-systems (there has been loads of discussion on whether it is better to use a single Makefile for all (or most) libraries or whether each library should have there own cloned makefile. the library template Makefile is basically the outcome of the latter, and allows each library to build without having to download the entire repository. however, i think that those problems mainly arose because there is no way to define build-dependency in a cross-platform way for ordinary Pd-packages. since now we are in the good position that we are talking about debian, we actually have the possibility to use build-dependencies and i don't see a reason to not do that. /sidenote For me the problem would be then learning cdbs for special cases. But since there are still at least 30 unpackaged Pd libraries, I think having this as option makes sense. I'd call it something like standard-pd-library.mk well, one practical problem would obviously be, that there currently is no puredata-dev package yet, and it is unlikely to come before the upstream release of Pd-0.43 (which was due in august, but was delayed since then). would it make sense to create a separate package (e.g. puredata-debian-dev) for the sole purpose of centralizing the makefile snippets? this package could then include cdbs, dh,... so people could have their pick. fgmasdr IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
lame in new queue
Anyone know the story behind the 'lame' package in the NEW queue? will it get included? did the patent stuff change? I'd like to package some stuff that depends on it. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: requesting sponsor for pd-cyclone
On Thu, 2010-11-11 at 09:19 +0100, Jonas Smedegaard wrote: On Thu, Nov 11, 2010 at 12:15:05AM -0500, Hans-Christoph Steiner wrote: pd-cyclone is a huge library of all sorts of objects that are clones of objects in Max/MSP4.5, Pd's proprietary cousin. It also includes utilities for importing Max files. pd-cyclone is a long-form dh package that is a wrapper to a very complicated Make build system. pd-cxc is in git.debian.org/pkg-multimedia. It is a library without depends that are new packages. It builds on my i386, but it did not build on the launchpad amd64 build machine, it died on this error, which has stumped me: dpkg-genchanges -B -mUbuntu/amd64 Build Daemon bui...@titanium.ppa ../pd-cyclone_0.1~alpha55-1~maverick_amd64.changes dpkg-genchanges: arch-specific upload - not including arch-independent packages dpkg-genchanges: error: cannot read files list file: No such file or directory It looks odd to me that you use no debhelper tools in the binary-arch target - only in the binary-indep one. Thanks, that was the key. This now builds on i386 and amd64 and is ready to go. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-ggee
pd-ggee is a short-form dh package that is a lightly modified version of the standard Makefile. pd-ggee in on git.debian.org/pkg-multimedia. It is a library without depends that are new packages but a couple of other ITP'ed packages depend on it. http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsorship for pd-pddp
On Wed, 2010-11-10 at 14:01 -0300, Felipe Sateler wrote: On Wed, Nov 10, 2010 at 03:00, Hans-Christoph Steiner h...@at.or.at wrote: On Tue, 2010-11-09 at 18:51 -0300, Felipe Sateler wrote: On Mon, Nov 8, 2010 at 20:24, Hans-Christoph Steiner h...@at.or.at wrote: pd-pddp The changelog needs to be updated. There is no need for the BSD file reference, it will be going away, and you already copied the entire license. Same comment on the lintian warning as in the prevoius package. Updated timestamp in changelog. Same issue, please revert the moving around of the jpeg file. Ok, these should all be fixed, and the missing Depends, pd-ggee, is on git.debian.org now too. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] pd-ext13/master: updated changelog with fixes
On Wed, 2010-11-10 at 10:24 -0300, Felipe Sateler wrote: On Wed, Nov 10, 2010 at 04:20, Jonas Smedegaard d...@jones.dk wrote: On Wed, Nov 10, 2010 at 04:23:44AM +, eighthave-gu...@users.alioth.debian.org wrote: updated changelog with fixes diff --git a/debian/changelog b/debian/changelog index 1cd698f..a95db68 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,8 @@ pd-ext13 (0.17.1-1) unstable; urgency=low * Initial release (Closes: #591844) + * expanded description to include object listing + * removed mistakenly commited build log + * added linux-libc-dev as Build-Dep for cdrom.h and soundcard.h An initial packaging release really contains no changes, except the fact that it is released, and related info (bug closure and perhaps mentioning which Debian suite is targeted). I have no strong opinion on this, other than the trailer line should be updated to (as Reinhardt mentioned before) the point where you believe the package is ready to be uploaded. This is because, if someone did the most work, I prefer to keep that name in the trailer line instead of mine (yes, I know I can do it manually, but lets define the process correctly). Also, VCS-only juggling back and forth is irrelevant to pass on to the changelog for the resulting source package. In other words: Even if this was not an initial release, the note on removing (a.k.a. reverting the addition of) build log should be stripped. This I agree with. Ok, I like how Jacob describes it, so I purged all change comments from this initial release and pushed. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsor for pd-bsaylor
pd-bsaylor is in git.debian.org/pkg-multimedia and ready for upload. It is a simple object without depends that are new packages. (Felipe requested one email per package, so here goes!) Thanks! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsor for pd-cxc
pd-cxc is in git.debian.org/pkg-multimedia and ready for upload. It is a simple library without depends that are new packages. Thanks! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsor for pd-markex
pd-markex is in git.debian.org/pkg-multimedia and ready for upload. It is a simple library without depends that are new packages. Thanks! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
requesting sponsor for pd-mjlib
pd-mjlib is in git.debian.org/pkg-multimedia and ready for upload. It is a simple library for Pd without depends that are new packages. Thanks! .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
