Re: uploaded first pkg: pd-motex

2010-08-22 Thread Jonas Smedegaard

On Sat, Aug 21, 2010 at 02:08:58PM -0400, Hans-Christoph Steiner wrote:


Woo hoo, my first package in Debian, (hopefully)!


Congratulations!! :-)

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-21 Thread Hans-Christoph Steiner


On Aug 20, 2010, at 10:41 PM, Felipe Sateler wrote:


(No need to CC me)

On 20/08/10 22:35, Hans-Christoph Steiner wrote:


Ready for uploading :)


Uploaded.



Woo hoo, my first package in Debian, (hopefully)!

.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: uploaded first pkg: pd-motex

2010-08-20 Thread IOhannes m zmölnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/19/2010 08:01 PM, Hans-Christoph Steiner wrote:
 
 That would make sense if the big tarball wasn't going to change. The
 problem is that upstream (me, mostly) is going to stop distributing a
 lot of these libraries in the big tarball.  Also, as a community, Pd is
 moving towards separately bundled and distributed libraries as we
 develop better a library format and support for loading them.
 

being part of that community, i also strongly support multiple packages.
pd-libraries have different release cycles (at least those, that
actually have releases), which make the big tarball unnecessary hard to
maintain (in trunk some libraries are always unstable while others are
stable at any given time)

mfga
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxuUmAACgkQkX2Xpv6ydvTGaQCfa1psjGgBsSZdzrr+baigjrEr
5lEAoPWpMOLcyKv7Gz2/Yvz+rr8PqqR4
=DvqX
-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


Re: uploaded first pkg: pd-motex

2010-08-20 Thread Felipe Sateler
On 19/08/10 21:42, Hans-Christoph Steiner wrote:
 
 On Aug 19, 2010, at 8:02 PM, Felipe Sateler wrote:
 
 On 19/08/10 13:36, Hans-Christoph Steiner wrote:
 On Tue, 2010-08-17 at 23:14 +0200, Jonas Smedegaard wrote:
 On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner wrote:

 On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:

 On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
 On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner
 wrote:
 README.txt and LICENSE.txt are part of the Pd library format.
 They are part of the library, and the Help Browser (aka the
 library browser) looks for them to display them.  The library
 format is basically a directory with files in it, and a subdir
 called 'examples'.  That install target actually serves to
 enforce that all the standard files are there.


 In this library, I could replace the file with a symlink to
 ../../../ common-licenses/GPL-2, but other libraries might have
 different licenses so this wouldn't always be the case.

 I guess that both the license and the README.txt actually belongs
 to /usr/share/doc/$package, that's what debian policy tells us to
 do. IIRC, documentation browsers like dhelp and the default
 webserver's configurations publish /usr/share/doc so that users
 can browse package documentation.

 So moving these files and symlink them to where the package
 expect them seems to me the right thing to do.

 This is wrong, actually:

 Code must not depend on /usr/share/doc existing on the machine, so
 when a file is needed both by runtime and below /usr/share/doc then
 the actual file should be placed elsewhere and a symlink be placed
 below /usr/share/doc.

 Not sure if this is explicitly clarified in Debian Policy or only a
 result of close-reading FHS (File Hierarchy Standard) or some such.
 Perhaps look for sections regarding example scripts.


 In this context, I think the above suggestion makes the most sense.
 So here's my plan:

 - make the LICENSE.txt file into a symlink, if GPL, BSD or other
 common license
 - make usr/share/doc/pd-motex/README.txt a symlink to the one in the
 library

 I'd need to remove LICENSE.txt then make the symllnk.  What's the
 best way to remove the file?  I could patch the Makefile to remove
 the line in 'make install' that installs LICENSE.txt the add a link
 in debian/links.  Is there some easy/proper way in debhelper to just
 remove an installed file?

 Your questions makes me suspect that you did not notice my earier
 response in this thread (even earlier than above quoted one).

 Date: Tue, 17 Aug 2010 11:54:32 +0200
 Message-ID: 20100817095432.gg7...@jones.dk

 There I describe how I do similarly with Sugar packages.

 To answer more directly to your questions: No, I believe there is no
 debhelper routine specifically for this.  Possibly you can make dh_link
 force overwrite existing object, but I find my proposed approach of
 replacing only if identical safer.

 Ok, I did it with an 'rm' in debian/rules, hope that's ok.  I pushed the
 commit.

 So, pd-motex should be ready?
 
 
 Everything is ready from my end. :-)  Its feeling quite polished, plus
 all the rest too.

OK, please update the changelog (I believe installing stuff as symlinks
to /usr/share/doc should be noted), and the signature. I can upload it then.


-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-20 Thread Hans-Christoph Steiner


On Aug 20, 2010, at 6:03 PM, Felipe Sateler wrote:


On 19/08/10 21:42, Hans-Christoph Steiner wrote:


On Aug 19, 2010, at 8:02 PM, Felipe Sateler wrote:


On 19/08/10 13:36, Hans-Christoph Steiner wrote:

On Tue, 2010-08-17 at 23:14 +0200, Jonas Smedegaard wrote:
On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner  
wrote:


On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:

On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler  
wrote:

On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner
wrote:

README.txt and LICENSE.txt are part of the Pd library format.
They are part of the library, and the Help Browser (aka the
library browser) looks for them to display them.  The library
format is basically a directory with files in it, and a subdir
called 'examples'.  That install target actually serves to
enforce that all the standard files are there.


In this library, I could replace the file with a symlink to
../../../ common-licenses/GPL-2, but other libraries might  
have

different licenses so this wouldn't always be the case.


I guess that both the license and the README.txt actually  
belongs
to /usr/share/doc/$package, that's what debian policy tells  
us to

do. IIRC, documentation browsers like dhelp and the default
webserver's configurations publish /usr/share/doc so that users
can browse package documentation.

So moving these files and symlink them to where the package
expect them seems to me the right thing to do.


This is wrong, actually:

Code must not depend on /usr/share/doc existing on the  
machine, so
when a file is needed both by runtime and below /usr/share/doc  
then
the actual file should be placed elsewhere and a symlink be  
placed

below /usr/share/doc.

Not sure if this is explicitly clarified in Debian Policy or  
only a
result of close-reading FHS (File Hierarchy Standard) or some  
such.

Perhaps look for sections regarding example scripts.



In this context, I think the above suggestion makes the most  
sense.

So here's my plan:

- make the LICENSE.txt file into a symlink, if GPL, BSD or other
common license
- make usr/share/doc/pd-motex/README.txt a symlink to the one  
in the

library

I'd need to remove LICENSE.txt then make the symllnk.  What's the
best way to remove the file?  I could patch the Makefile to  
remove
the line in 'make install' that installs LICENSE.txt the add a  
link
in debian/links.  Is there some easy/proper way in debhelper to  
just

remove an installed file?


Your questions makes me suspect that you did not notice my earier
response in this thread (even earlier than above quoted one).

Date: Tue, 17 Aug 2010 11:54:32 +0200
Message-ID: 20100817095432.gg7...@jones.dk

There I describe how I do similarly with Sugar packages.

To answer more directly to your questions: No, I believe there  
is no
debhelper routine specifically for this.  Possibly you can make  
dh_link
force overwrite existing object, but I find my proposed approach  
of

replacing only if identical safer.


Ok, I did it with an 'rm' in debian/rules, hope that's ok.  I  
pushed the

commit.


So, pd-motex should be ready?



Everything is ready from my end. :-)  Its feeling quite polished,  
plus

all the rest too.


OK, please update the changelog (I believe installing stuff as  
symlinks
to /usr/share/doc should be noted), and the signature. I can upload  
it then.




Ok, I added notes about the symlinks to the changelog, updated the  
timestamp, and pushed the changes.  Ready for uploading :)


.hc



I spent 33 years and four months in active military service and during  
that period I spent most of my time as a high class muscle man for Big  
Business, for Wall Street and the bankers.  - General Smedley Butler




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-20 Thread Felipe Sateler
(No need to CC me)

On 20/08/10 22:35, Hans-Christoph Steiner wrote:
 
  Ready for uploading :)

Uploaded.


-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-19 Thread Hans-Christoph Steiner
On Tue, 2010-08-17 at 23:14 +0200, Jonas Smedegaard wrote:
 On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner wrote:
 
 On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:
 
 On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
 On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner 
 wrote:
 README.txt and LICENSE.txt are part of the Pd library format.  
 They are part of the library, and the Help Browser (aka the 
 library browser) looks for them to display them.  The library 
 format is basically a directory with files in it, and a subdir 
 called 'examples'.  That install target actually serves to 
 enforce that all the standard files are there.
 
 
 In this library, I could replace the file with a symlink to 
 ../../../ common-licenses/GPL-2, but other libraries might have 
 different licenses so this wouldn't always be the case.
 
 I guess that both the license and the README.txt actually belongs 
 to /usr/share/doc/$package, that's what debian policy tells us to 
 do. IIRC, documentation browsers like dhelp and the default 
 webserver's configurations publish /usr/share/doc so that users 
 can browse package documentation.
 
 So moving these files and symlink them to where the package 
 expect them seems to me the right thing to do.
 
 This is wrong, actually:
 
 Code must not depend on /usr/share/doc existing on the machine, so 
 when a file is needed both by runtime and below /usr/share/doc then 
 the actual file should be placed elsewhere and a symlink be placed 
 below /usr/share/doc.
 
 Not sure if this is explicitly clarified in Debian Policy or only a 
 result of close-reading FHS (File Hierarchy Standard) or some such.  
 Perhaps look for sections regarding example scripts.
 
 
 In this context, I think the above suggestion makes the most sense.  
 So here's my plan:
 
 - make the LICENSE.txt file into a symlink, if GPL, BSD or other 
 common license
 - make usr/share/doc/pd-motex/README.txt a symlink to the one in the 
 library
 
 I'd need to remove LICENSE.txt then make the symllnk.  What's the 
 best way to remove the file?  I could patch the Makefile to remove 
 the line in 'make install' that installs LICENSE.txt the add a link 
 in debian/links.  Is there some easy/proper way in debhelper to just 
 remove an installed file?
 
 Your questions makes me suspect that you did not notice my earier 
 response in this thread (even earlier than above quoted one).
 
 Date: Tue, 17 Aug 2010 11:54:32 +0200
 Message-ID: 20100817095432.gg7...@jones.dk
 
 There I describe how I do similarly with Sugar packages.
 
 To answer more directly to your questions: No, I believe there is no 
 debhelper routine specifically for this.  Possibly you can make dh_link 
 force overwrite existing object, but I find my proposed approach of 
 replacing only if identical safer.

Ok, I did it with an 'rm' in debian/rules, hope that's ok.  I pushed the
commit.  

Also, FYI, I've been making all these changes to the other 25ish
packages that I'm working on, so they should be pretty tight once I
submit them.  Once pd-motex is in, I am thinking of running one more
thru individually, then once that's done, I'll submit the whole batch.
Does that work?

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-19 Thread Felipe Sateler
On 19/08/10 13:36, Hans-Christoph Steiner wrote:
 Once pd-motex is in, I am thinking of running one more
 thru individually, then once that's done, I'll submit the whole batch.
 Does that work?

I'm still not convinced that having one source package for all these
extensions is the best move (as opposed to making 1 big source package
that builds several binary packages)...


-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-19 Thread Hans-Christoph Steiner
On Thu, 2010-08-19 at 13:49 -0400, Felipe Sateler wrote:
 On 19/08/10 13:36, Hans-Christoph Steiner wrote:
  Once pd-motex is in, I am thinking of running one more
  thru individually, then once that's done, I'll submit the whole batch.
  Does that work?
 
 I'm still not convinced that having one source package for all these
 extensions is the best move (as opposed to making 1 big source package
 that builds several binary packages)...

That would make sense if the big tarball wasn't going to change. The
problem is that upstream (me, mostly) is going to stop distributing a
lot of these libraries in the big tarball.  Also, as a community, Pd is
moving towards separately bundled and distributed libraries as we
develop better a library format and support for loading them.

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-19 Thread Felipe Sateler
On 19/08/10 13:36, Hans-Christoph Steiner wrote:
 On Tue, 2010-08-17 at 23:14 +0200, Jonas Smedegaard wrote:
 On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner wrote:

 On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:

 On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
 On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner 
 wrote:
 README.txt and LICENSE.txt are part of the Pd library format.  
 They are part of the library, and the Help Browser (aka the 
 library browser) looks for them to display them.  The library 
 format is basically a directory with files in it, and a subdir 
 called 'examples'.  That install target actually serves to 
 enforce that all the standard files are there.


 In this library, I could replace the file with a symlink to 
 ../../../ common-licenses/GPL-2, but other libraries might have 
 different licenses so this wouldn't always be the case.

 I guess that both the license and the README.txt actually belongs 
 to /usr/share/doc/$package, that's what debian policy tells us to 
 do. IIRC, documentation browsers like dhelp and the default 
 webserver's configurations publish /usr/share/doc so that users 
 can browse package documentation.

 So moving these files and symlink them to where the package 
 expect them seems to me the right thing to do.

 This is wrong, actually:

 Code must not depend on /usr/share/doc existing on the machine, so 
 when a file is needed both by runtime and below /usr/share/doc then 
 the actual file should be placed elsewhere and a symlink be placed 
 below /usr/share/doc.

 Not sure if this is explicitly clarified in Debian Policy or only a 
 result of close-reading FHS (File Hierarchy Standard) or some such.  
 Perhaps look for sections regarding example scripts.


 In this context, I think the above suggestion makes the most sense.  
 So here's my plan:

 - make the LICENSE.txt file into a symlink, if GPL, BSD or other 
 common license
 - make usr/share/doc/pd-motex/README.txt a symlink to the one in the 
 library

 I'd need to remove LICENSE.txt then make the symllnk.  What's the 
 best way to remove the file?  I could patch the Makefile to remove 
 the line in 'make install' that installs LICENSE.txt the add a link 
 in debian/links.  Is there some easy/proper way in debhelper to just 
 remove an installed file?

 Your questions makes me suspect that you did not notice my earier 
 response in this thread (even earlier than above quoted one).

 Date: Tue, 17 Aug 2010 11:54:32 +0200
 Message-ID: 20100817095432.gg7...@jones.dk

 There I describe how I do similarly with Sugar packages.

 To answer more directly to your questions: No, I believe there is no 
 debhelper routine specifically for this.  Possibly you can make dh_link 
 force overwrite existing object, but I find my proposed approach of 
 replacing only if identical safer.
 
 Ok, I did it with an 'rm' in debian/rules, hope that's ok.  I pushed the
 commit.  

So, pd-motex should be ready?

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-19 Thread Hans-Christoph Steiner


On Aug 19, 2010, at 8:02 PM, Felipe Sateler wrote:


On 19/08/10 13:36, Hans-Christoph Steiner wrote:

On Tue, 2010-08-17 at 23:14 +0200, Jonas Smedegaard wrote:
On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner  
wrote:


On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:


On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:

On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner
wrote:

README.txt and LICENSE.txt are part of the Pd library format.
They are part of the library, and the Help Browser (aka the
library browser) looks for them to display them.  The library
format is basically a directory with files in it, and a subdir
called 'examples'.  That install target actually serves to
enforce that all the standard files are there.


In this library, I could replace the file with a symlink to
../../../ common-licenses/GPL-2, but other libraries might have
different licenses so this wouldn't always be the case.


I guess that both the license and the README.txt actually belongs
to /usr/share/doc/$package, that's what debian policy tells us to
do. IIRC, documentation browsers like dhelp and the default
webserver's configurations publish /usr/share/doc so that users
can browse package documentation.

So moving these files and symlink them to where the package
expect them seems to me the right thing to do.


This is wrong, actually:

Code must not depend on /usr/share/doc existing on the machine, so
when a file is needed both by runtime and below /usr/share/doc  
then

the actual file should be placed elsewhere and a symlink be placed
below /usr/share/doc.

Not sure if this is explicitly clarified in Debian Policy or  
only a
result of close-reading FHS (File Hierarchy Standard) or some  
such.

Perhaps look for sections regarding example scripts.



In this context, I think the above suggestion makes the most sense.
So here's my plan:

- make the LICENSE.txt file into a symlink, if GPL, BSD or other
common license
- make usr/share/doc/pd-motex/README.txt a symlink to the one in  
the

library

I'd need to remove LICENSE.txt then make the symllnk.  What's the
best way to remove the file?  I could patch the Makefile to remove
the line in 'make install' that installs LICENSE.txt the add a link
in debian/links.  Is there some easy/proper way in debhelper to  
just

remove an installed file?


Your questions makes me suspect that you did not notice my earier
response in this thread (even earlier than above quoted one).

Date: Tue, 17 Aug 2010 11:54:32 +0200
Message-ID: 20100817095432.gg7...@jones.dk

There I describe how I do similarly with Sugar packages.

To answer more directly to your questions: No, I believe there is no
debhelper routine specifically for this.  Possibly you can make  
dh_link

force overwrite existing object, but I find my proposed approach of
replacing only if identical safer.


Ok, I did it with an 'rm' in debian/rules, hope that's ok.  I  
pushed the

commit.


So, pd-motex should be ready?



Everything is ready from my end. :-)  Its feeling quite polished, plus  
all the rest too.


.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: uploaded first pkg: pd-motex

2010-08-18 Thread Reinhard Tartler
On Tue, Aug 17, 2010 at 20:40:09 (CEST), Hans-Christoph Steiner wrote:

 In this context, I think the above suggestion makes the most sense.  So
 here's my plan:

 - make the LICENSE.txt file into a symlink, if GPL, BSD or other common
 license
 - make usr/share/doc/pd-motex/README.txt a symlink to the one in the
 library

makes sense to me!

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-17 Thread Reinhard Tartler
On Tue, Aug 17, 2010 at 07:37:11 (CEST), Reinhard Tartler wrote:

 On Tue, Aug 17, 2010 at 00:22:25 (CEST), Felipe Sateler wrote:

 On 16/08/10 17:47, Hans-Christoph Steiner wrote:

 It seems that this thread gets easily hijacked ;)  Returning to the
 Subject, I think pd-motex is ready for upload, thanks all for the
 feedback!

 How are you editing debian/changelog? The timestamp is old!

 Also, there is no need to ship the GPL text in the package. It seems
 like no patch or file tries to read the license, so no need to ship it
 (we already have the copyright file).

 Uh, why do you want to have the LICENSE.txt file removed from the
 upstream tarball? That seems rather blunt to me.

Ah no, you meant to not ship it in the binary package, not to remove it
from the orig.tar.gz. Yes, that's a valid concern. This patch to the
Makefile should fix this:

diff --git a/Makefile b/Makefile
index acbd0da..11feccf 100644
--- a/Makefile
+++ b/Makefile
@@ -192,8 +192,6 @@ install-doc:
test -z $(strip $(PDOBJECTS)) || \
$(INSTALL_FILE) $(PDOBJECTS:.pd=-help.pd) \
$(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)
-   $(INSTALL_FILE) README.txt 
$(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/README.txt
-   $(INSTALL_FILE) LICENSE.txt 
$(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/LICENSE.txt
 
 install-examples:
test -z $(strip $(EXAMPLES)) || \


Hans, what do you think about removing these two lines upstream? Users
are very unlikely to look these two files up in those places anyway.

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-17 Thread Hans-Christoph Steiner


On Aug 17, 2010, at 4:35 AM, Reinhard Tartler wrote:


On Tue, Aug 17, 2010 at 07:37:11 (CEST), Reinhard Tartler wrote:


On Tue, Aug 17, 2010 at 00:22:25 (CEST), Felipe Sateler wrote:


On 16/08/10 17:47, Hans-Christoph Steiner wrote:


It seems that this thread gets easily hijacked ;)  Returning to the
Subject, I think pd-motex is ready for upload, thanks all for the
feedback!


How are you editing debian/changelog? The timestamp is old!

Also, there is no need to ship the GPL text in the package. It seems
like no patch or file tries to read the license, so no need to  
ship it

(we already have the copyright file).


Uh, why do you want to have the LICENSE.txt file removed from the
upstream tarball? That seems rather blunt to me.


Ah no, you meant to not ship it in the binary package, not to remove  
it

from the orig.tar.gz. Yes, that's a valid concern. This patch to the
Makefile should fix this:

diff --git a/Makefile b/Makefile
index acbd0da..11feccf 100644
--- a/Makefile
+++ b/Makefile
@@ -192,8 +192,6 @@ install-doc:
test -z $(strip $(PDOBJECTS)) || \
$(INSTALL_FILE) $(PDOBJECTS:.pd=-help.pd) \
$(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)
-	$(INSTALL_FILE) README.txt $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/ 
README.txt
-	$(INSTALL_FILE) LICENSE.txt $(DESTDIR)$(objectsdir)/$ 
(LIBRARY_NAME)/LICENSE.txt


install-examples:
test -z $(strip $(EXAMPLES)) || \


Hans, what do you think about removing these two lines upstream? Users
are very unlikely to look these two files up in those places anyway.



README.txt and LICENSE.txt are part of the Pd library format.  They  
are part of the library, and the Help Browser (aka the library  
browser) looks for them to display them.  The library format is  
basically a directory with files in it, and a subdir called  
'examples'.  That install target actually serves to enforce that all  
the standard files are there.


In this library, I could replace the file with a symlink to  ../../../ 
common-licenses/GPL-2, but other libraries might have different  
licenses so this wouldn't always be the case.


I'll read up on the emacs changelog mode, I already have dpkg-dev-el  
installed already I guess I didn't realize I needed to trigger the  
timestamp manually.


.hc





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: uploaded first pkg: pd-motex

2010-08-17 Thread Reinhard Tartler
On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote:
 README.txt and LICENSE.txt are part of the Pd library format.  They are
 part of the library, and the Help Browser (aka the library  browser)
 looks for them to display them.  The library format is  basically a
 directory with files in it, and a subdir called  'examples'.  That
 install target actually serves to enforce that all  the standard files
 are there.


 In this library, I could replace the file with a symlink to  ../../../
 common-licenses/GPL-2, but other libraries might have different licenses
 so this wouldn't always be the case.

I guess that both the license and the README.txt actually belongs to
/usr/share/doc/$package, that's what debian policy tells us to do. IIRC,
documentation browsers like dhelp and the default webserver's
configurations publish /usr/share/doc so that users can browse package
documentation.

So moving these files and symlink them to where the package expect them
seems to me the right thing to do.

 I'll read up on the emacs changelog mode, I already have dpkg-dev-el
 installed already I guess I didn't realize I needed to trigger the
 timestamp manually.

Yeah, I've really got used to that mode. :-)

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-17 Thread Jonas Smedegaard

On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:

On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote:
README.txt and LICENSE.txt are part of the Pd library format.  They 
are part of the library, and the Help Browser (aka the library 
browser) looks for them to display them.  The library format is 
basically a directory with files in it, and a subdir called 
'examples'.  That install target actually serves to enforce that all 
the standard files are there.



In this library, I could replace the file with a symlink to ../../../ 
common-licenses/GPL-2, but other libraries might have different 
licenses so this wouldn't always be the case.


I guess that both the license and the README.txt actually belongs to 
/usr/share/doc/$package, that's what debian policy tells us to do. 
IIRC, documentation browsers like dhelp and the default webserver's 
configurations publish /usr/share/doc so that users can browse package 
documentation.


So moving these files and symlink them to where the package expect them 
seems to me the right thing to do.


This is wrong, actually:

Code must not depend on /usr/share/doc existing on the machine, so when 
a file is needed both by runtime and below /usr/share/doc then the 
actual file should be placed elsewhere and a symlink be placed below 
/usr/share/doc.


Not sure if this is explicitly clarified in Debian Policy or only a 
result of close-reading FHS (File Hierarchy Standard) or some such.  
Perhaps look for sections regarding example scripts.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-17 Thread IOhannes m zmoelnig
On 2010-08-17 17:39, Jonas Smedegaard wrote:
 On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
 On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote:
 README.txt and LICENSE.txt are part of the Pd library format.  They

this should read: are part of a Pd library format under discussion.

 are part of the library, and the Help Browser (aka the library
 browser) looks for them to display them.  The library format is
 basically a directory with files in it, and a subdir called
 'examples'.  That install target actually serves to enforce that all
 the standard files are there.


 In this library, I could replace the file with a symlink to ../../../
 common-licenses/GPL-2, but other libraries might have different
 licenses so this wouldn't always be the case.

if other pd-libraries have other licenses, they would obviously either
link to ../../../common-licenses/BSD (or whatever) or if there is no
license in common-licenses leave it as it is.

mfgasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-17 Thread Hans-Christoph Steiner


On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:


On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner  
wrote:
README.txt and LICENSE.txt are part of the Pd library format.   
They are part of the library, and the Help Browser (aka the  
library browser) looks for them to display them.  The library  
format is basically a directory with files in it, and a subdir  
called 'examples'.  That install target actually serves to enforce  
that all the standard files are there.



In this library, I could replace the file with a symlink  
to ../../../ common-licenses/GPL-2, but other libraries might have  
different licenses so this wouldn't always be the case.


I guess that both the license and the README.txt actually belongs  
to /usr/share/doc/$package, that's what debian policy tells us to  
do. IIRC, documentation browsers like dhelp and the default  
webserver's configurations publish /usr/share/doc so that users can  
browse package documentation.


So moving these files and symlink them to where the package expect  
them seems to me the right thing to do.


This is wrong, actually:

Code must not depend on /usr/share/doc existing on the machine, so  
when a file is needed both by runtime and below /usr/share/doc then  
the actual file should be placed elsewhere and a symlink be placed  
below /usr/share/doc.


Not sure if this is explicitly clarified in Debian Policy or only a  
result of close-reading FHS (File Hierarchy Standard) or some such.   
Perhaps look for sections regarding example scripts.



In this context, I think the above suggestion makes the most sense.   
So here's my plan:


- make the LICENSE.txt file into a symlink, if GPL, BSD or other  
common license
- make usr/share/doc/pd-motex/README.txt a symlink to the one in the  
library


I'd need to remove LICENSE.txt then make the symllnk.  What's the best  
way to remove the file?  I could patch the Makefile to remove the line  
in 'make install' that installs LICENSE.txt the add a link in debian/ 
links.  Is there some easy/proper way in debhelper to just remove an  
installed file?


.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: uploaded first pkg: pd-motex

2010-08-17 Thread Jonas Smedegaard

On Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner wrote:


On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote:


On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote:
On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner 
wrote:
README.txt and LICENSE.txt are part of the Pd library format.  
They are part of the library, and the Help Browser (aka the 
library browser) looks for them to display them.  The library 
format is basically a directory with files in it, and a subdir 
called 'examples'.  That install target actually serves to 
enforce that all the standard files are there.



In this library, I could replace the file with a symlink to 
../../../ common-licenses/GPL-2, but other libraries might have 
different licenses so this wouldn't always be the case.


I guess that both the license and the README.txt actually belongs 
to /usr/share/doc/$package, that's what debian policy tells us to 
do. IIRC, documentation browsers like dhelp and the default 
webserver's configurations publish /usr/share/doc so that users 
can browse package documentation.


So moving these files and symlink them to where the package 
expect them seems to me the right thing to do.


This is wrong, actually:

Code must not depend on /usr/share/doc existing on the machine, so 
when a file is needed both by runtime and below /usr/share/doc then 
the actual file should be placed elsewhere and a symlink be placed 
below /usr/share/doc.


Not sure if this is explicitly clarified in Debian Policy or only a 
result of close-reading FHS (File Hierarchy Standard) or some such.  
Perhaps look for sections regarding example scripts.



In this context, I think the above suggestion makes the most sense.  
So here's my plan:


- make the LICENSE.txt file into a symlink, if GPL, BSD or other 
common license
- make usr/share/doc/pd-motex/README.txt a symlink to the one in the 
library


I'd need to remove LICENSE.txt then make the symllnk.  What's the 
best way to remove the file?  I could patch the Makefile to remove 
the line in 'make install' that installs LICENSE.txt the add a link 
in debian/links.  Is there some easy/proper way in debhelper to just 
remove an installed file?


Your questions makes me suspect that you did not notice my earier 
response in this thread (even earlier than above quoted one).


Date: Tue, 17 Aug 2010 11:54:32 +0200
Message-ID: 20100817095432.gg7...@jones.dk

There I describe how I do similarly with Sugar packages.

To answer more directly to your questions: No, I believe there is no 
debhelper routine specifically for this.  Possibly you can make dh_link 
force overwrite existing object, but I find my proposed approach of 
replacing only if identical safer.



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread IOhannes m zmoelnig
On 2010-08-16 03:31, Hans-Christoph Steiner wrote:

 I'm not a pd expert, but if I install some extensions, I expect to be
 able to use them right away, without having to invoke pd with special
 args. I'm getting the impression that we are not living up to that
 expectation.
 
 You can use them right away the way they are being installed right now.
 Just like in python when you install a library, you still need to tell
 it to import it before using it.  In Pd its similar, but messier.
 There is the [import] and [declare] objects for doing this in the Pd
 patches themselves, and there is the -lib command line option.

and of course you can tell the interpreter to load certain libraries on
startup by the means of a preference system (this is most likely the
most commonly used case).

but it seems like the README.Debian is indeed a bit confusing; maybe
someone with better control of the english language could rephrase it
(ideally somebody with good Pd-knowledge like hans).

the reason why this info is in README.Debian and not in (e.g.) README
is, that upstream's README does not include this information (mea culpa).

the reason why it ought to be mentioned somewhere, is that (upstream)
zexy is special in the way, that is a library consisting of both
binary and interpreter files, and Pd handles these 2 kinds differently.
that's why i make all the fuzz about -path and -lib

mfgasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Jonas Smedegaard

On Sun, Aug 15, 2010 at 08:28:05PM -0400, Alexandre Quessy wrote:

Hello,

2010/8/12 Jonas Smedegaard d...@jones.dk:


 2. Release a tarball (with debian subdir stripped)


I just wanted to stress out the fact that the debian directory need to 
be out of the upstream tarball. (and repository) It took me a few week 
to get that part. Once it's done, packaging is a lot easier... :)


Actually, this is not necessarily true any longer.

For Squeeze and newer releases, it is recommended to use the DKPG source 
format 3.0 (quilt), which ignores an upstream debian subdir.  From the 
manpage of (a recent packaging of) dpkg-source:


The debian tarball is extracted on top of the source directory after 
prior removal of any pre-existing debian directory.



It is still the most elegant way to release an upstream tarball without 
redistribution noise IMO, even if Debian and its derivatives now are 
able to suppress it :-)



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Hans-Christoph Steiner
On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote:
 On 2010-08-16 03:31, Hans-Christoph Steiner wrote:
 
  I'm not a pd expert, but if I install some extensions, I expect to be
  able to use them right away, without having to invoke pd with special
  args. I'm getting the impression that we are not living up to that
  expectation.
  
  You can use them right away the way they are being installed right now.
  Just like in python when you install a library, you still need to tell
  it to import it before using it.  In Pd its similar, but messier.
  There is the [import] and [declare] objects for doing this in the Pd
  patches themselves, and there is the -lib command line option.
 
 and of course you can tell the interpreter to load certain libraries on
 startup by the means of a preference system (this is most likely the
 most commonly used case).
 
 but it seems like the README.Debian is indeed a bit confusing; maybe
 someone with better control of the english language could rephrase it
 (ideally somebody with good Pd-knowledge like hans).
 
 the reason why this info is in README.Debian and not in (e.g.) README
 is, that upstream's README does not include this information (mea culpa).
 
 the reason why it ought to be mentioned somewhere, is that (upstream)
 zexy is special in the way, that is a library consisting of both
 binary and interpreter files, and Pd handles these 2 kinds differently.
 that's why i make all the fuzz about -path and -lib
 
 mfgasdr
 IOhannes

I don't see why this is Debian-specific though.  It really is an
upstream issue, this should be documented as part of zexy, not Debian.

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Felipe Sateler
On 16/08/10 14:24, Hans-Christoph Steiner wrote:
 On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote:
 On 2010-08-16 03:31, Hans-Christoph Steiner wrote:

 I'm not a pd expert, but if I install some extensions, I expect to be
 able to use them right away, without having to invoke pd with special
 args. I'm getting the impression that we are not living up to that
 expectation.

 You can use them right away the way they are being installed right now.
 Just like in python when you install a library, you still need to tell
 it to import it before using it.  In Pd its similar, but messier.
 There is the [import] and [declare] objects for doing this in the Pd
 patches themselves, and there is the -lib command line option.

 and of course you can tell the interpreter to load certain libraries on
 startup by the means of a preference system (this is most likely the
 most commonly used case).

 but it seems like the README.Debian is indeed a bit confusing; maybe
 someone with better control of the english language could rephrase it
 (ideally somebody with good Pd-knowledge like hans).

 the reason why this info is in README.Debian and not in (e.g.) README
 is, that upstream's README does not include this information (mea culpa).

 the reason why it ought to be mentioned somewhere, is that (upstream)
 zexy is special in the way, that is a library consisting of both
 binary and interpreter files, and Pd handles these 2 kinds differently.
 that's why i make all the fuzz about -path and -lib

 
 I don't see why this is Debian-specific though.  It really is an
 upstream issue, this should be documented as part of zexy, not Debian.

I think I understand now, and I agree with Hans. That documentation
should go upstream, not in a debian readme.

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Hans-Christoph Steiner
On Mon, 2010-08-16 at 14:30 -0400, Felipe Sateler wrote:
 On 16/08/10 14:24, Hans-Christoph Steiner wrote:
  On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote:
  On 2010-08-16 03:31, Hans-Christoph Steiner wrote:
 
  I'm not a pd expert, but if I install some extensions, I expect to be
  able to use them right away, without having to invoke pd with special
  args. I'm getting the impression that we are not living up to that
  expectation.
 
  You can use them right away the way they are being installed right now.
  Just like in python when you install a library, you still need to tell
  it to import it before using it.  In Pd its similar, but messier.
  There is the [import] and [declare] objects for doing this in the Pd
  patches themselves, and there is the -lib command line option.
 
  and of course you can tell the interpreter to load certain libraries on
  startup by the means of a preference system (this is most likely the
  most commonly used case).
 
  but it seems like the README.Debian is indeed a bit confusing; maybe
  someone with better control of the english language could rephrase it
  (ideally somebody with good Pd-knowledge like hans).
 
  the reason why this info is in README.Debian and not in (e.g.) README
  is, that upstream's README does not include this information (mea culpa).
 
  the reason why it ought to be mentioned somewhere, is that (upstream)
  zexy is special in the way, that is a library consisting of both
  binary and interpreter files, and Pd handles these 2 kinds differently.
  that's why i make all the fuzz about -path and -lib
 
  
  I don't see why this is Debian-specific though.  It really is an
  upstream issue, this should be documented as part of zexy, not Debian.
 
 I think I understand now, and I agree with Hans. That documentation
 should go upstream, not in a debian readme.

It seems that this thread gets easily hijacked ;)  Returning to the
Subject, I think pd-motex is ready for upload, thanks all for the
feedback!

Also, I think it would be quite helpful if people change the subject
when they hijack threads.  That's my two bits...

.hc




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Hans-Christoph Steiner


On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote:


On 16/08/10 17:47, Hans-Christoph Steiner wrote:


It seems that this thread gets easily hijacked ;)  Returning to the
Subject, I think pd-motex is ready for upload, thanks all for the
feedback!


How are you editing debian/changelog? The timestamp is old!


Ah, oops, I forgot dch.  I've been using emacs.  The changelog is  
still something I am somewhat confused by.  I get the idea of course,  
but the not the specifics.  I was under the impression that pkg- 
multimedia uses git-dch to automatically generate the changelog, so I  
stopped editing it.  Also, since this package hasn't been released  
yet, should I still be adding things to the changelog?



Also, there is no need to ship the GPL text in the package. It seems
like no patch or file tries to read the license, so no need to ship it
(we already have the copyright file).



The LICENSE.txt file is part of the standard library format.



[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity.-John Gilmore




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Felipe Sateler
On 16/08/10 19:03, Hans-Christoph Steiner wrote:
 
 On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote:
 
 On 16/08/10 17:47, Hans-Christoph Steiner wrote:

 It seems that this thread gets easily hijacked ;)  Returning to the
 Subject, I think pd-motex is ready for upload, thanks all for the
 feedback!

 How are you editing debian/changelog? The timestamp is old!
 
 Ah, oops, I forgot dch.  I've been using emacs.  The changelog is still
 something I am somewhat confused by.  I get the idea of course, but the
 not the specifics.  I was under the impression that pkg-multimedia uses
 git-dch to automatically generate the changelog, so I stopped editing
 it.  Also, since this package hasn't been released yet, should I still
 be adding things to the changelog?

Well, it depends on how many things you had to do. In this case, it
appears that not much (other than fixing minor mistakes not found in a
previous release). But you should still run dch. Please read the
manpage, specially the section about the release heuristics. I use the
changelog one, which seems to work well for our workflow.

 
 Also, there is no need to ship the GPL text in the package. It seems
 like no patch or file tries to read the license, so no need to ship it
 (we already have the copyright file).
 
 
 The LICENSE.txt file is part of the standard library format.
 

Does anything break if we don't ship it?

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Hans-Christoph Steiner


On Aug 16, 2010, at 8:04 PM, Felipe Sateler wrote:


On 16/08/10 19:03, Hans-Christoph Steiner wrote:


On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote:


On 16/08/10 17:47, Hans-Christoph Steiner wrote:


It seems that this thread gets easily hijacked ;)  Returning to the
Subject, I think pd-motex is ready for upload, thanks all for the
feedback!


How are you editing debian/changelog? The timestamp is old!


Ah, oops, I forgot dch.  I've been using emacs.  The changelog is  
still
something I am somewhat confused by.  I get the idea of course, but  
the
not the specifics.  I was under the impression that pkg-multimedia  
uses

git-dch to automatically generate the changelog, so I stopped editing
it.  Also, since this package hasn't been released yet, should I  
still

be adding things to the changelog?


Well, it depends on how many things you had to do. In this case, it
appears that not much (other than fixing minor mistakes not found in a
previous release). But you should still run dch. Please read the
manpage, specially the section about the release heuristics. I use the
changelog one, which seems to work well for our workflow.


Ok makes sense.  I updated the timestamp with dch and pushed the  
commit.  The last question for me here is what should go into the  
changelog for this initial release?



Also, there is no need to ship the GPL text in the package. It seems
like no patch or file tries to read the license, so no need to  
ship it

(we already have the copyright file).



The LICENSE.txt file is part of the standard library format.



Does anything break if we don't ship it?



On all other platforms/distros it'll have that file there, and its  
visible using the library browser, so it would be only on Debian that  
you didn't see the license file.  I think that sounds like minor but  
actual breakage.


.hc



  ¡El pueblo unido jamás será vencido!



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Reinhard Tartler
On Tue, Aug 17, 2010 at 01:03:57 (CEST), Hans-Christoph Steiner wrote:

 How are you editing debian/changelog? The timestamp is old!

 Ah, oops, I forgot dch.  I've been using emacs. 

You might want to install the 'dpkg-dev-el' package, which features
debian-changelog-mode. Here, you can easily update the timestamp with
C-c C-f. See the mode documentation for details.

 The changelog is still something I am somewhat confused by.  I get the
 idea of course, but the not the specifics.  I was under the impression
 that pkg- multimedia uses git-dch to automatically generate the
 changelog, so I stopped editing it.  Also, since this package hasn't
 been released yet, should I still be adding things to the changelog?

I'm using git-dch to get a template, but most of the time, I end up fine
tuning it with debian-changelog-mode.

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-16 Thread Reinhard Tartler
On Tue, Aug 17, 2010 at 00:22:25 (CEST), Felipe Sateler wrote:

 On 16/08/10 17:47, Hans-Christoph Steiner wrote:

 It seems that this thread gets easily hijacked ;)  Returning to the
 Subject, I think pd-motex is ready for upload, thanks all for the
 feedback!

 How are you editing debian/changelog? The timestamp is old!

 Also, there is no need to ship the GPL text in the package. It seems
 like no patch or file tries to read the license, so no need to ship it
 (we already have the copyright file).

Uh, why do you want to have the LICENSE.txt file removed from the
upstream tarball? That seems rather blunt to me.

However, It is indeed formatted in an unusual way and lacks the preamble,
as well as the section How to Apply These Terms to Your New Programs.
Hans, maybe you can include the full text of the GPL-2 as found in
/usr/share/common-licenses/GPL-2 in a file named 'COPYING' in the next
release tarball? That's what the FSF commonly does.


-- 
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


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Reinhard Tartler
On Sat, Aug 14, 2010 at 23:03:33 (CEST), Hans-Christoph Steiner wrote:

 The example should go into /usr/share/doc/pd-motex/examples.

 The 'examples' folder is part of the standard library format for Pd
 libraries, so it needs to be in the library.  A .pd file is something
 like a .svg or a .ps: it is a text file, but its not human
 readable/editable in a useful way.  Really a .pd file is more like a
 binary like .elc or .pyc than a text file.  So I am not sure it is so
 useful in the /usr/share/doc/pd-motex/examples directory.

If you think these files help users to get started with the package,
then it should go there. If it doesn't help, leave it.

 Also, Pd users will expect the examples to show up in the Pd library
 browser.  Do you think it would be useful to
 make /usr/share/doc/pd-motex/examples a link to the examples in the
 library folder?

Yes, that makes sense to me. The format (html, text, pdf) doesn't really
matter.

 Similar to the discussion on pd-zexy, is something needed to use motex?
 If so, you should document that in README.Debian.

 The instructions in pd-zexy/README.Debian are not Debian-specific and
 nothing about the Debian packages require users to load libraries
 differently than on other platforms.  IMHO, Pd users are better off
 using the official Pd docs on how to load libraries rather than
 maintaining many different README files for each library that can easily
 get out of date.

Would it be possible to install a copy of the official documentation in
the package? This way debian users could also read it offline.

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Reinhard Tartler
On Sun, Aug 15, 2010 at 02:23:59 (CEST), Felipe Sateler wrote:

 On 14/08/10 11:08, Reinhard Tartler wrote:
 On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:
 
 On 14/08/10 06:13, Reinhard Tartler wrote:
 debhelper maintains a history of very stable interfaces, called compat
 levels. I'd really love to see something similar to cdbs. And this very
 strict commitment to stable interfaces and semantics help a lot for
 backporting packages.

 How does maintaining several API versions (compat levels) help
 backporting?
 
 You can pretty much rely on the exact behavior of debhelper
 commands. future improvements and addition are still possible at higher
 levels, but for the sake of compatibility, they are not used until you
 bump the debhelper compat level.

 But that is forward-porting, not backporting.

if you always use the most recent debhelper compat level, then yes. If
you leave your package at the highest compat level that is in the oldest
release you care about, then it helps backporting.

for stable this would mean to avoid the short form 'dh' forms with the
quilt series features.

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Jonas Smedegaard

On Sun, Aug 15, 2010 at 09:16:26AM +0200, Reinhard Tartler wrote:

On Sun, Aug 15, 2010 at 02:23:59 (CEST), Felipe Sateler wrote:


On 14/08/10 11:08, Reinhard Tartler wrote:

On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:


On 14/08/10 06:13, Reinhard Tartler wrote:
debhelper maintains a history of very stable interfaces, called 
compat levels. I'd really love to see something similar to cdbs. 
And this very strict commitment to stable interfaces and semantics 
help a lot for backporting packages.


How does maintaining several API versions (compat levels) help 
backporting?


You can pretty much rely on the exact behavior of debhelper 
commands. future improvements and addition are still possible at 
higher levels, but for the sake of compatibility, they are not used 
until you bump the debhelper compat level.


But that is forward-porting, not backporting.


if you always use the most recent debhelper compat level, then yes. If 
you leave your package at the highest compat level that is in the 
oldest release you care about, then it helps backporting.


for stable this would mean to avoid the short form 'dh' forms with the 
quilt series features.


Do I understand you correctly here in that you really are not talking 
about the ABI levels at all, but minor version numbers of debhelper?


Or do you suggest to stick to debhelper compat level 6 for now, to not 
accidentally use features introduced in e.g. 7.2?


Or do you somehow mean to say that the fine ABI handling of debhelper 
also cover the changes between 7.0 and 7.2?



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Reinhard Tartler
On Sun, Aug 15, 2010 at 13:19:19 (CEST), Jonas Smedegaard wrote:

 On Sun, Aug 15, 2010 at 09:16:26AM +0200, Reinhard Tartler wrote:
On Sun, Aug 15, 2010 at 02:23:59 (CEST), Felipe Sateler wrote:

 On 14/08/10 11:08, Reinhard Tartler wrote:
 On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:

 On 14/08/10 06:13, Reinhard Tartler wrote:
 debhelper maintains a history of very stable interfaces, called
 compat levels. I'd really love to see something similar to
 cdbs. And this very strict commitment to stable interfaces and
 semantics help a lot for backporting packages.

 How does maintaining several API versions (compat levels) help
 backporting?

 You can pretty much rely on the exact behavior of debhelper
 commands. future improvements and addition are still possible at
 higher levels, but for the sake of compatibility, they are not used
 until you bump the debhelper compat level.

 But that is forward-porting, not backporting.

 if you always use the most recent debhelper compat level, then yes. If
 you leave your package at the highest compat level that is in the
 oldest release you care about, then it helps backporting.

 for stable this would mean to avoid the short form 'dh' forms with the
 quilt series features.

 Do I understand you correctly here in that you really are not talking
 about the ABI levels at all, but minor version numbers of debhelper?

What's an ABI level?

ABI (== application binary interface) in general means something
completely different than we are discussing here.

 Or do you suggest to stick to debhelper compat level 6 for now, to not
 accidentally use features introduced in e.g. 7.2?

stable ships debhelper version 7.0.15, I don't think we'd need to
support any version earlier than that.

Just curious, what features have been introduced in 7.2?

 Or do you somehow mean to say that the fine ABI handling of debhelper
 also cover the changes between 7.0 and 7.2?

Jonas, please avoid the term ABI in the context of debhelper. I had to
read your question 3 times and still don't get it. Let me explain why:

ABI is often called the (Machine) Application Binary Interface. This
is what the processor manufacturer defines how various details how
applications, functions, syscalls, etc. work on *assembly* level.

What we in terms of packaging often discuss is the *library* ABI, which
again means something completely different (and has IMO a pretty
unfortunate name) . The *library* ABI is broken iff an updated version
of a library breaks the externally visible behavior of previously
existing interfaces.

So if you consider debhelper as a library for makefiles, then we could
of course discuss the stability of interfaces.  So if we consider
backporting packages to stable releases as a goal that we should aim for
(and I think we should), then yes, I think we should avoid features that
are not found in debian/stable. Demanding for more is IMO not worth the
effort, but I won't certainly stop anyone from stepping up to make a
package build in oldstable as well.

-- 
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


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Jonas Smedegaard

On Sun, Aug 15, 2010 at 10:44:40PM +0200, Reinhard Tartler wrote:

What's an ABI level?


Sorry.

I shall do my best to never ever again use the term ABI except when I 
really really mean it.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Jonas Smedegaard

On Sun, Aug 15, 2010 at 09:16:26AM +0200, Reinhard Tartler wrote:

On Sun, Aug 15, 2010 at 02:23:59 (CEST), Felipe Sateler wrote:


On 14/08/10 11:08, Reinhard Tartler wrote:

On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:


On 14/08/10 06:13, Reinhard Tartler wrote:
debhelper maintains a history of very stable interfaces, called 
compat levels. I'd really love to see something similar to cdbs. 
And this very strict commitment to stable interfaces and semantics 
help a lot for backporting packages.


How does maintaining several API versions (compat levels) help 
backporting?


You can pretty much rely on the exact behavior of debhelper 
commands. future improvements and addition are still possible at 
higher levels, but for the sake of compatibility, they are not used 
until you bump the debhelper compat level.


But that is forward-porting, not backporting.


if you always use the most recent debhelper compat level, then yes. If 
you leave your package at the highest compat level that is in the 
oldest release you care about, then it helps backporting.


for stable this would mean to avoid the short form 'dh' forms with the 
quilt series features.


You stated (in topmost quote above) that history of very stable 
interfaces as a counter-argument to cdbs being more backport-friendly.


Now when elaborating, you talk about avoiding some quilt feature.

I agree with you that avoiding recent features of *any* dependent tool 
improves backport-friendliness.


I still fail to understand how compat levels help with that.

If you say that using debhelper compat level 6 or below is 
backport-friendly then I agree with you.


If you say that using debhelper compat level 7 is backport-friendly then 
I disagree with you.  Also I then fail to understand your latest point 
above about avoiding some specific feature - why is special care like 
that needed when the very strict commitment to stable interfaces and 
semantics [provided by compat levels] help a lot for backporting 
packages.?



Regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Alexandre Quessy
Hello,

2010/8/12 Jonas Smedegaard d...@jones.dk:

  2. Release a tarball (with debian subdir stripped)

I just wanted to stress out the fact that the debian directory need to
be out of the upstream tarball. (and repository) It took me a few week
to get that part. Once it's done, packaging is a lot easier... :)

Best,

-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Hans-Christoph Steiner
On Sat, 2010-08-14 at 21:31 -0400, Felipe Sateler wrote:
 (No need to CC me)
 
 On 14/08/10 17:03, Hans-Christoph Steiner wrote:
  On Fri, 2010-08-13 at 14:43 -0400, Felipe Sateler wrote:
  On 13/08/10 14:12, Hans-Christoph Steiner wrote:
 
  Now that there is a separate thread on cdbs vs dh, perhaps someone could
  give me some feedback on my pd-motex package which happens to use dh.
  I'm ready to fix whatever needs fixing.
  
  First off, thanks for the feedback, quite useful!  I've also applied
  these changes to the other packages I ITP'ed.
  
  THe changelog mentions that it is a non-maintainer upload. That is
  certainly an error.
  
  Removed.
 
 The version number is still incorrect (x.y debian revisions are used for
 NMUs).
 
  
  Make sure that the names in debian/control and
  debian/changelog are byte-for-byte identical.
  
  They were as far as I could tell, did you see a difference?
 
 No, but usually dch uses the NMU template when the names differ.
 
  
  The short description should give an indication of what the externals do.
  
  Some of these old Pd libraries are random grabbags of things that are
  just collections created by the same author.
 
 OK. But the new description now in place is better.
 
  The example should go into /usr/share/doc/pd-motex/examples.
  
  The 'examples' folder is part of the standard library format for Pd
  libraries, so it needs to be in the library.  A .pd file is something
  like a .svg or a .ps: it is a text file, but its not human
  readable/editable in a useful way.  Really a .pd file is more like a
  binary like .elc or .pyc than a text file.  So I am not sure it is so
  useful in the /usr/share/doc/pd-motex/examples directory.
  
  Also, Pd users will expect the examples to show up in the Pd library
  browser.  Do you think it would be useful to
  make /usr/share/doc/pd-motex/examples a link to the examples in the
  library folder?
 
 Where is that library browser? I can't find such a thing in my installed
 copy of pd (debian's).

Its under the Help menu, the item Browser  In the 0.42 version of
puredata, it doesn't dynamically generate the listing of libraries.  In
the 0.43 version, it does.  These packages are largely oriented towards
recent library support work that's included in 0.43.
 
  Similar to the discussion on pd-zexy, is something needed to use motex?
  If so, you should document that in README.Debian.
  
  The instructions in pd-zexy/README.Debian are not Debian-specific and
  nothing about the Debian packages require users to load libraries
  differently than on other platforms.  IMHO, Pd users are better off
  using the official Pd docs on how to load libraries rather than
  maintaining many different README files for each library that can easily
  get out of date.
 
 So, maybe the pd-zexy README should be removed?
 
 I'm not a pd expert, but if I install some extensions, I expect to be
 able to use them right away, without having to invoke pd with special
 args. I'm getting the impression that we are not living up to that
 expectation.

You can use them right away the way they are being installed right now.
Just like in python when you install a library, you still need to tell
it to import it before using it.  In Pd its similar, but messier.
There is the [import] and [declare] objects for doing this in the Pd
patches themselves, and there is the -lib command line option.

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-15 Thread Hans-Christoph Steiner
On Sun, 2010-08-15 at 09:12 +0200, Reinhard Tartler wrote:
 On Sat, Aug 14, 2010 at 23:03:33 (CEST), Hans-Christoph Steiner wrote:
 
  The example should go into /usr/share/doc/pd-motex/examples.
 
  The 'examples' folder is part of the standard library format for Pd
  libraries, so it needs to be in the library.  A .pd file is something
  like a .svg or a .ps: it is a text file, but its not human
  readable/editable in a useful way.  Really a .pd file is more like a
  binary like .elc or .pyc than a text file.  So I am not sure it is so
  useful in the /usr/share/doc/pd-motex/examples directory.
 
 If you think these files help users to get started with the package,
 then it should go there. If it doesn't help, leave it.

  Also, Pd users will expect the examples to show up in the Pd library
  browser.  Do you think it would be useful to
  make /usr/share/doc/pd-motex/examples a link to the examples in the
  library folder?
 
 Yes, that makes sense to me. The format (html, text, pdf) doesn't really
 matter.


Ok, I added a debian/links file to provide usr/share/doc/pd-motex/README
and usr/share/doc/pd-motex/examples.


  Similar to the discussion on pd-zexy, is something needed to use motex?
  If so, you should document that in README.Debian.
 
  The instructions in pd-zexy/README.Debian are not Debian-specific and
  nothing about the Debian packages require users to load libraries
  differently than on other platforms.  IMHO, Pd users are better off
  using the official Pd docs on how to load libraries rather than
  maintaining many different README files for each library that can easily
  get out of date.
 
 Would it be possible to install a copy of the official documentation in
 the package? This way debian users could also read it offline.

Yes, the documentation is already included in the 'puredata' package.

.hc



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Jonas Smedegaard

On Fri, Aug 13, 2010 at 04:42:28PM -0400, Felipe Sateler wrote:

On 13/08/10 15:15, Jonas Smedegaard wrote:
Backporting a recent debhelper requires backporting dpkg which I 
wouldn't dare do...


While I don't want to get in the dh/cdbs debate (I'm fine with either), 
this statement is not true. debhelper requires dpkg-dev = 1.14.19, and 
stable has 1.14.29.


If limiting to backports targeted stable, I completely agree.


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Reinhard Tartler
On Fri, Aug 13, 2010 at 21:15:26 (CEST), Jonas Smedegaard wrote:

 On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:

 Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
 of that at debconf 10 ;-)

 The best way to keep a thread alive(!) is to feed it new arguments, as
 you do below.

 I honestly tried to not do side-by-side comparison between dh7 and CDBS,
 but stick to facts about CDBS itself.

 I shall try my best to keep at that, and leave it to others throwing
 questions or counter-arguments to decide if this thread should be kept
 alive or not.


On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:

 CDBS is more backports-friendly (beyond backports.org too!).

 It is only more backports-friendly if you also always backport the
 very latest version of cdbs, which does not match my definition of
 backport' at all.

 You are completely right that ideal backportability means no dependency
 on other backports.  Which is the reason I counted backports.org out!

These two sentences doesn't make sense to me together. Either you or I
have misunderstood backports.org. That repo does not build by default
against packages also in backports.org, unless explicitly requested by
the build-depends, exactly like experimental is currently handled.

 And yes, CDBS is *genuinely* backportable more than short-form dh!

if your copy of cdbs is recent enough, sure. but the same argument
counts for dh7 as well, which has a 7.0.15 in stable. The only thing
that doesn't work in stable by itself is the quilt series trick.

Moreover, These are the used versions in ubuntu:

  cdbs | 0.4.51ubuntu1 | hardy | source, all
  cdbs | 0.4.52ubuntu18 |jaunty | source, all
  cdbs | 0.4.59ubuntu4 |karmic | source, all
  cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all
  cdbs | 0.4.83ubuntu1 |  maverick | source, all

 And I've already shown you a case where a package failed to build with
 lucid's cdbs and you just told me that ubuntu where shipping broken
 cdbs package. Sorry, that does not help me at all with backporting
 packages.

1) Demonstrating a case does not undermine more backportable.

sure, but already this thread gives me enough reason to not even try
this further.

2) Releasing testing packages as stable is flawed: Ubuntu is flawed!

because they want to build packages that require newer CDBS? come on,
they just take what's available in unstable. OK, they switched now to
testing, IIRC, but now we're really offtopic.

 With more backportable I mean to say that CDBS in more cases than
 short-form dh is it possible to compile packages in an older Debian
 environment either a) as-is or b) with minor adjustments - e.g. changing
 or removing build-dependencies.

more cases? Sorry, this does not match my experiences with cdbs so far.

debhelper maintains a history of very stable interfaces, called compat
levels. I'd really love to see something similar to cdbs. And this very
strict commitment to stable interfaces and semantics help a lot for
backporting packages.

 Oh, and if you are lazy (or don't want to touch those weird CDBS-using
 debian/control files) then CDBS itself is backportable as its
 dependencies is fulfilled even on Etch (and, if I recall correctly,
 Sarge too!).  Backporting a recent debhelper requires backporting dpkg
 which I wouldn't dare do...

as already pointed, hardly anyone cares about oldstable (or earlier)
anymore. What I care much more would be to backport to previous ubuntu
releases, particularily those that ship broken releases of cdbs.

needless to say that dh packages make much fewer problems there...

 If all of that does not help [you] at all then too bad: I dare say
 that any narrower definition of more backportable won't get you very
 far with most backporting efforts.

yes, that is the bottom line I get from this thread: Your ideas of
backporting and stable interfaces clearly don't match mine.


 CDBS provides routines to fetch and repackage upstream tarballs

 CDBS provides routines to track copyright and licensing info of
 sources.

 What is the technical reasoning for needing to integrate these logics
 into debian/rules? I think as developer I'm much more flexible if they
 are implemented in seperate, reusable stand-alone tools. This way:

 a) more packages would use the same code to do these tasks
 b) these helper tools could be maintained and backported independently
of cdbs
 c) they have really nothing to do with the act of building packages,
but are more general maintenance tasks

 Yes, and this is a noble goal for the future.  As I already told you at
 debconf I plan to do that for the copyright  licensing part.

Right! And I'm really looking forward to that! Thanks!

 I think this is the thing that makes me dislike cdbs, too many
 maintenance tasks are integrated into debian/rules and therefore, are
 implemented in make, which is a fine language that I also like to
 

Re: uploaded first pkg: pd-motex

2010-08-14 Thread Jonas Smedegaard

On Fri, Aug 13, 2010 at 08:37:36PM -0400, Andres Mejia wrote:

I would like to chime in and say that with the packages I've worked on 
(besides my own), I found that both dh and cdbs get whatever I need 
done. I however prefer dh.


I suspect that you (like Benjamin) mean modern short-form debhelper 
above - not classic debhelper (which is not really comparable to CDBS):


 * Classic debhelper solves certain atomic tasks
 * CDBS offer patterns to invoke external tools, e.g. classic debhelper
 * Modern shortform dh invokes classic debhelper (and more) as patterns


Really the only reason I've stuck with dh over cdbs in my packages is 
because cdbs depends on debhelper. cdbs even build depends on 
debhelper. I've asked myself, what's the point of having 2 build 
dependencies when 1 is all that I need. Because of this, I found that 
I may as well use debhelper directly for packaging, as opposed to using 
debhelper indirectly via cdbs.


I suspect your reasoning to be flawed:

CDBS build-depends on some packages for its regression tests, among 
those debhelper and default-jdk.  No, CDBS neither rely on debhelper nor 
on Java at runtime, despite these build-dependencies.


CDBS depends (at runtime) on debhelper because an exotic feature in the 
optional debhelper.mk snippet needs at least debhelper 5.0.30, but it is 
not possible to express a versioned recommends.



I'm not sure if I'm alone in this kind of reasoning. However, if you 
can somehow remove cdbs dependency on debhelper, I'm sure cdbs would be 
much more interesting.


Actually that dependency _is_ possible to remove.  But what would we 
gain?


NB! CDBS never provided the functionality of classic debhelper.


Now if it's already possible to use cdbs without debhelper, than I'll 
go ahead and admit that I did not know. So far however, I haven't found 
how to use cdbs without debhelper in cdbs documentation or in cdbs 
examples. Also, cdbs dependency and build dependency on debhelper leads 
me to believe that it's not currently possible.


It *is* possible.  But CDBS does not do what classic debhelper does, so 
unless you want to do that yourself, I fail to understand your reasoning 
here.


As I see it, CDBS and classic debhelper is *not* comparable, but works 
together (none of them depending on the other, really).  CDBS and the 
*overlay* provided by newer releases of debhelper - the short-form dh 
tool - an addition, not a replacement, to the classic dh_* tools - are 
comparable, and is what Benjamin asked clarification about earlier in 
this thread.



Hope that helps.

 - Jonas


P.S.

As you no doubt have noticed by now, I really like CDBS.  That does not 
mean, however, that I want to spam all lists with praising it: if you 
consider this topic irrelevant to discuss, then don't!


--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Felipe Sateler
On 14/08/10 05:40, Jonas Smedegaard wrote:
 On Fri, Aug 13, 2010 at 04:42:28PM -0400, Felipe Sateler wrote:
 On 13/08/10 15:15, Jonas Smedegaard wrote:
 Backporting a recent debhelper requires backporting dpkg which I
 wouldn't dare do...

 While I don't want to get in the dh/cdbs debate (I'm fine with
 either), this statement is not true. debhelper requires dpkg-dev =
 1.14.19, and stable has 1.14.29.
 
 If limiting to backports targeted stable, I completely agree.

Yes. I don't consider supporting (or taking into account) releases older
than stable worth the time of any developer (except, maybe, during the
few months following a stable release).

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Felipe Sateler
On 14/08/10 06:13, Reinhard Tartler wrote:
 debhelper maintains a history of very stable interfaces, called compat
 levels. I'd really love to see something similar to cdbs. And this very
 strict commitment to stable interfaces and semantics help a lot for
 backporting packages.

How does maintaining several API versions (compat levels) help
backporting? If the compat level you are using doesn't exist on current
stable (or other Ubuntu release), then you are as much out of luck as
without the compat levels. Or am I missing something?


-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Jonas Smedegaard

On Sat, Aug 14, 2010 at 12:13:52PM +0200, Reinhard Tartler wrote:

On Fri, Aug 13, 2010 at 21:15:26 (CEST), Jonas Smedegaard wrote:

On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:

On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:

CDBS is more backports-friendly (beyond backports.org too!).


It is only more backports-friendly if you also always backport the 
very latest version of cdbs, which does not match my definition of 
backport' at all.


You are completely right that ideal backportability means no 
dependency on other backports.  Which is the reason I counted 
backports.org out!


These two sentences doesn't make sense to me together. Either you or I 
have misunderstood backports.org. That repo does not build by default 
against packages also in backports.org, unless explicitly requested by 
the build-depends, exactly like experimental is currently handled.


Official Debian packages are compiled in a Debian unstable environment.

A backport to me is the task of recompiling package(s) in an older 
Pure Debian environment, either officially released or a snapshot of a 
staging area.  Examples of backporting targets are Debian/Lenny, 
Debian Etch and Debian testing as of noon 2010-08-14.


Recompiling packages for something else than an older Debian environment 
is sideporting to me.  Examples of sideports are Ubuntu Jaunty, 
Skolelinux Etch and the mixture of Debian Lenny + Lenny branch of 
backports.org as of noon 2010-08-14.


Packages not requiring things recently introduced into Debian I call 
backports-friendly.  The further back the requirements are satisfied, 
the more backports-friendly that particular package is.



It seems that your use of the term bacporting is what I would describe 
as sideporting to the mixture of Debian stable + a few packages 
cherry-picked from stable branch of backports.org as of now.



With your use of the term (if I got it correctly) we might reach a 
different conclusion regarding which packages are backport-friendly, 
depending on which dependencies happens to be offered that particular 
day at backports.org.  Right?




And yes, CDBS is *genuinely* backportable more than short-form dh!


if your copy of cdbs is recent enough, sure. but the same argument
counts for dh7 as well, which has a 7.0.15 in stable. The only thing
that doesn't work in stable by itself is the quilt series trick.


If the cdbs package in the target build environment do not satisfy 
requirements of the package being built, then that package is less 
backport-friendly as either the packaging needs some hacking or a newer 
cdbs needs to be backported (by yourself or someone else via e.g. 
backports.org). However done the target environment becomes slightly 
contaminated thus slightly less reliable.


jackd2 and bitmeter use CDBS and are backport-friendly: They compile in 
plain Lenny without contaminating it with any other bacported packages, 
neither locally built nor e.g. backports.org.


calf use CDBS and is less backport-friendly: it requires a recent cdbs. 

ffmpeg use short-form dh and is backport-friendly: it uses only features 
also available in stable.


Bitmeter is *more* backport-friendly than ffmpeg because its 
build-dependencies are (mostly if not fully) satisfied even in 
oldstable.


You may judge oldstable as obsolete for your purposes. So do I these 
days, but I did not 6 months ago, and I most likely will not render 
Lenny obsolete as soon as it enters oldstable but only some time after 
that.  The very aim (for me, at least) of backport-friendliness is to 
ease use in unusual environments.




   1) Demonstrating a case does not undermine more backportable.


sure, but already this thread gives me enough reason to not even try 
this further.


So you do not disagree that CDBS is more backportable but dislike it 
for other reasons.  Fair enough: Benjamin asked about reasons for using 
CDBS over short-form dh - not reasons to avoid it.



   2) Releasing testing packages as stable is flawed: Ubuntu is 
  flawed!


because they want to build packages that require newer CDBS? come on, 
they just take what's available in unstable. OK, they switched now to 
testing, IIRC, but now we're really offtopic.


No, because that particular CDBS release was broken.  Earlier versions 
worked, and later versions worked.


The case you referred to concerned a FTBFS on Ubuntu due to a broken 
release of CDBS on that system.  Same things occur in Debian if not 
properly tracking the branch used.  This is not tied to CDBS at all.


I can elaborate more if you do not understand my point.

Ubuntu bashing is off-topic, agreed.


With more backportable I mean to say that CDBS in more cases than 
short-form dh is it possible to compile packages in an older Debian 
environment either a) as-is or b) with minor adjustments - e.g. 
changing or removing build-dependencies.


more cases? Sorry, this does not match my experiences with cdbs so 
far.


I find that 

Re: uploaded first pkg: pd-motex

2010-08-14 Thread Jonas Smedegaard

On Sat, Aug 14, 2010 at 10:19:23AM -0400, Felipe Sateler wrote:

On 14/08/10 05:40, Jonas Smedegaard wrote:

On Fri, Aug 13, 2010 at 04:42:28PM -0400, Felipe Sateler wrote:

On 13/08/10 15:15, Jonas Smedegaard wrote:
Backporting a recent debhelper requires backporting dpkg which I 
wouldn't dare do...


While I don't want to get in the dh/cdbs debate (I'm fine with 
either), this statement is not true. debhelper requires dpkg-dev = 
1.14.19, and stable has 1.14.29.


If limiting to backports targeted stable, I completely agree.


Yes. I don't consider supporting (or taking into account) releases 
older than stable worth the time of any developer (except, maybe, 
during the few months following a stable release).


Do you consider the lenny branch of backports.org part as part of 
stable?


Would you if that initiative was renamed to backports.debian.org?

I would not.


How about recompilation for e.g. latest stable release of Ubuntu.  Is 
that stable too, or irrelevant?



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Hans-Christoph Steiner
On Fri, 2010-08-13 at 14:43 -0400, Felipe Sateler wrote:
 On 13/08/10 14:12, Hans-Christoph Steiner wrote:
  
  Now that there is a separate thread on cdbs vs dh, perhaps someone could
  give me some feedback on my pd-motex package which happens to use dh.
  I'm ready to fix whatever needs fixing.

First off, thanks for the feedback, quite useful!  I've also applied
these changes to the other packages I ITP'ed.

 THe changelog mentions that it is a non-maintainer upload. That is
 certainly an error.

Removed.

 Make sure that the names in debian/control and
 debian/changelog are byte-for-byte identical.

They were as far as I could tell, did you see a difference?

 Also, as we are a team, we set the maintainer field to the list, and
 your own name as Uploaders.

Done.

 The descriptions formatting is a bit ugly, and you might want to use
 double space before each element of the list of math functions (to
 preserve formatting).

fixed.

 The short description should give an indication of what the externals do.

Some of these old Pd libraries are random grabbags of things that are
just collections created by the same author.

 Also, somewhere in the description should the pd name be expanded into
 puredata (for people searching for puredata and people not knowing what
 pd is).

done.

 For debian/copyright.. has motex really been untouched since 2001?

Besides the random little build tweaks I've done, yes.  I added myself
to the copyright file just to make it clear.  I consider my work on
these libs to be public domain.

 The example should go into /usr/share/doc/pd-motex/examples.

The 'examples' folder is part of the standard library format for Pd
libraries, so it needs to be in the library.  A .pd file is something
like a .svg or a .ps: it is a text file, but its not human
readable/editable in a useful way.  Really a .pd file is more like a
binary like .elc or .pyc than a text file.  So I am not sure it is so
useful in the /usr/share/doc/pd-motex/examples directory.

Also, Pd users will expect the examples to show up in the Pd library
browser.  Do you think it would be useful to
make /usr/share/doc/pd-motex/examples a link to the examples in the
library folder?

 Similar to the discussion on pd-zexy, is something needed to use motex?
 If so, you should document that in README.Debian.

The instructions in pd-zexy/README.Debian are not Debian-specific and
nothing about the Debian packages require users to load libraries
differently than on other platforms.  IMHO, Pd users are better off
using the official Pd docs on how to load libraries rather than
maintaining many different README files for each library that can easily
get out of date.

.hc




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Felipe Sateler
On 14/08/10 11:08, Reinhard Tartler wrote:
 On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:
 
 On 14/08/10 06:13, Reinhard Tartler wrote:
 debhelper maintains a history of very stable interfaces, called compat
 levels. I'd really love to see something similar to cdbs. And this very
 strict commitment to stable interfaces and semantics help a lot for
 backporting packages.

 How does maintaining several API versions (compat levels) help
 backporting?
 
 You can pretty much rely on the exact behavior of debhelper
 commands. future improvements and addition are still possible at higher
 levels, but for the sake of compatibility, they are not used until you
 bump the debhelper compat level.

But that is forward-porting, not backporting.

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Felipe Sateler
On 14/08/10 11:14, Jonas Smedegaard wrote:
 On Sat, Aug 14, 2010 at 10:19:23AM -0400, Felipe Sateler wrote:
 On 14/08/10 05:40, Jonas Smedegaard wrote:
 On Fri, Aug 13, 2010 at 04:42:28PM -0400, Felipe Sateler wrote:
 On 13/08/10 15:15, Jonas Smedegaard wrote:
 Backporting a recent debhelper requires backporting dpkg which I
 wouldn't dare do...

 While I don't want to get in the dh/cdbs debate (I'm fine with
 either), this statement is not true. debhelper requires dpkg-dev =
 1.14.19, and stable has 1.14.29.

 If limiting to backports targeted stable, I completely agree.

 Yes. I don't consider supporting (or taking into account) releases
 older than stable worth the time of any developer (except, maybe,
 during the few months following a stable release).
 
 Do you consider the lenny branch of backports.org part as part of
 stable?
 
 Would you if that initiative was renamed to backports.debian.org?
 
 I would not.
 
 
 How about recompilation for e.g. latest stable release of Ubuntu.  Is
 that stable too, or irrelevant?

I'm not quite sure what you mean... If I can make life easier for
someone trying to backport a package to stable with reasonable effort, I
will. I will not, however, spend any effort in making life easier for
someone trying to backport to oldstable. Same for ubuntu releases (which
generally, although not always, tend to be = debian stable in terms of
package versions).

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-14 Thread Felipe Sateler
(No need to CC me)

On 14/08/10 17:03, Hans-Christoph Steiner wrote:
 On Fri, 2010-08-13 at 14:43 -0400, Felipe Sateler wrote:
 On 13/08/10 14:12, Hans-Christoph Steiner wrote:

 Now that there is a separate thread on cdbs vs dh, perhaps someone could
 give me some feedback on my pd-motex package which happens to use dh.
 I'm ready to fix whatever needs fixing.
 
 First off, thanks for the feedback, quite useful!  I've also applied
 these changes to the other packages I ITP'ed.
 
 THe changelog mentions that it is a non-maintainer upload. That is
 certainly an error.
 
 Removed.

The version number is still incorrect (x.y debian revisions are used for
NMUs).

 
 Make sure that the names in debian/control and
 debian/changelog are byte-for-byte identical.
 
 They were as far as I could tell, did you see a difference?

No, but usually dch uses the NMU template when the names differ.

 
 The short description should give an indication of what the externals do.
 
 Some of these old Pd libraries are random grabbags of things that are
 just collections created by the same author.

OK. But the new description now in place is better.

 The example should go into /usr/share/doc/pd-motex/examples.
 
 The 'examples' folder is part of the standard library format for Pd
 libraries, so it needs to be in the library.  A .pd file is something
 like a .svg or a .ps: it is a text file, but its not human
 readable/editable in a useful way.  Really a .pd file is more like a
 binary like .elc or .pyc than a text file.  So I am not sure it is so
 useful in the /usr/share/doc/pd-motex/examples directory.
 
 Also, Pd users will expect the examples to show up in the Pd library
 browser.  Do you think it would be useful to
 make /usr/share/doc/pd-motex/examples a link to the examples in the
 library folder?

Where is that library browser? I can't find such a thing in my installed
copy of pd (debian's).

 
 Similar to the discussion on pd-zexy, is something needed to use motex?
 If so, you should document that in README.Debian.
 
 The instructions in pd-zexy/README.Debian are not Debian-specific and
 nothing about the Debian packages require users to load libraries
 differently than on other platforms.  IMHO, Pd users are better off
 using the official Pd docs on how to load libraries rather than
 maintaining many different README files for each library that can easily
 get out of date.

So, maybe the pd-zexy README should be removed?

I'm not a pd expert, but if I install some extensions, I expect to be
able to use them right away, without having to invoke pd with special
args. I'm getting the impression that we are not living up to that
expectation.


-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Jonas Smedegaard

On Thu, Aug 12, 2010 at 11:43:51PM +0200, Benjamin Drung wrote:

Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
[1] or agree to repackage using cdbs - I just won't you to get the 
impression that I lured you into this: most people in the multimedia 
team are fine with - yeah, even prefer - short-form dh, it is just me 
being obnoxious.


I prefer dh over cdbs over long debhelper form. Are there any technical 
reasons for not using dh?


Good question. Thanks for asking!

CDBS is more backports-friendly (beyond backports.org too!).

CDBS provides routines to fetch and repackage upstream tarballs

CDBS provides routines to track copyright and licensing info of sources.

CDBS is less invasive - e.g. can be used with manually run dh_* commands

CDBS is written in make (short-form dh somewhat reinvents make in Perl)


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Reinhard Tartler

Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
of that at debconf 10 ;-)

On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:

 On Thu, Aug 12, 2010 at 11:43:51PM +0200, Benjamin Drung wrote:
Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
 [1] or agree to repackage using cdbs - I just won't you to get the
 impression that I lured you into this: most people in the multimedia
 team are fine with - yeah, even prefer - short-form dh, it is just me
 being obnoxious.

 I prefer dh over cdbs over long debhelper form. Are there any
 technical reasons for not using dh?

 Good question. Thanks for asking!

 CDBS is more backports-friendly (beyond backports.org too!).

It is only more backports-friendly if you also always backport the very
latest version of cdbs, which does not match my definition of 'backport'
at all. cdbs itself does not seem to be available on backports.org at
all. Moreover, These are the used versions in ubuntu:

  cdbs | 0.4.51ubuntu1 | hardy | source, all
  cdbs | 0.4.52ubuntu18 |jaunty | source, all
  cdbs | 0.4.59ubuntu4 |karmic | source, all
  cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all
  cdbs | 0.4.83ubuntu1 |  maverick | source, all

And I've already shown you a case where a package failed to build with
lucid's cdbs and you just told me that ubuntu where shipping broken cdbs
package. Sorry, that does not help me at all with backporting packages.

 CDBS provides routines to fetch and repackage upstream tarballs

 CDBS provides routines to track copyright and licensing info of sources.

What is the technical reasoning for needing to integrate these logics
into debian/rules? I think as developer I'm much more flexible if they
are implemented in seperate, reusable stand-alone tools. This way:

 a) more packages would use the same code to do these tasks
 b) these helper tools could be maintained and backported independently
of cdbs
 c) they have really nothing to do with the act of building packages,
but are more general maintenance tasks

I think this is the thing that makes me dislike cdbs, too many
maintenance tasks are integrated into debian/rules and therefore, are
implemented in make, which is a fine language that I also like to
program with, but for these tasks, 'make' doesn't really help much.

Jonas, would it be an option to you to implement them in a language
other than make? Ideally, we could try (again) to push at least some of
these tasks into the devscripts package, which is more the place I think
they belong to.

 CDBS is less invasive - e.g. can be used with manually run dh_* commands

as indicated above, the integration of all kinds of maintenance tasks
fits my understanding of more invasive, because more unrelated tasks
are implemented into a single program: debian/rules.

 CDBS is written in make (short-form dh somewhat reinvents make in
 Perl)

it reinvents much logic that cdbs chooses to implement in make, but also
most of cdbs, espc. the tasks that you indicated above, don't really
benefit from the properties of the make language.

And now for context of everyone that has not attended Jonas and my real
life flamefest at debconf 10, yes, Jonas and I had (at least one?) long
real-life conversation about cdbs. It's not that I really disklike it or
something, au contraire, I do think that cdbs does have benefit for some
groups of packages. E.g. I know that the gnome and kde package
consolidate a lot of build logic into cdbs, and this really makes sense
to me.


-- 
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


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Hans-Christoph Steiner

Now that there is a separate thread on cdbs vs dh, perhaps someone could
give me some feedback on my pd-motex package which happens to use dh.
I'm ready to fix whatever needs fixing.

.hc

On Fri, 2010-08-13 at 17:20 +0200, Reinhard Tartler wrote:
 Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
 of that at debconf 10 ;-)
 
 On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:
 
  On Thu, Aug 12, 2010 at 11:43:51PM +0200, Benjamin Drung wrote:
 Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
  [1] or agree to repackage using cdbs - I just won't you to get the
  impression that I lured you into this: most people in the multimedia
  team are fine with - yeah, even prefer - short-form dh, it is just me
  being obnoxious.
 
  I prefer dh over cdbs over long debhelper form. Are there any
  technical reasons for not using dh?
 
  Good question. Thanks for asking!
 
  CDBS is more backports-friendly (beyond backports.org too!).
 
 It is only more backports-friendly if you also always backport the very
 latest version of cdbs, which does not match my definition of 'backport'
 at all. cdbs itself does not seem to be available on backports.org at
 all. Moreover, These are the used versions in ubuntu:
 
   cdbs | 0.4.51ubuntu1 | hardy | source, all
   cdbs | 0.4.52ubuntu18 |jaunty | source, all
   cdbs | 0.4.59ubuntu4 |karmic | source, all
   cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all
   cdbs | 0.4.83ubuntu1 |  maverick | source, all
 
 And I've already shown you a case where a package failed to build with
 lucid's cdbs and you just told me that ubuntu where shipping broken cdbs
 package. Sorry, that does not help me at all with backporting packages.
 
  CDBS provides routines to fetch and repackage upstream tarballs
 
  CDBS provides routines to track copyright and licensing info of sources.
 
 What is the technical reasoning for needing to integrate these logics
 into debian/rules? I think as developer I'm much more flexible if they
 are implemented in seperate, reusable stand-alone tools. This way:
 
  a) more packages would use the same code to do these tasks
  b) these helper tools could be maintained and backported independently
 of cdbs
  c) they have really nothing to do with the act of building packages,
 but are more general maintenance tasks
 
 I think this is the thing that makes me dislike cdbs, too many
 maintenance tasks are integrated into debian/rules and therefore, are
 implemented in make, which is a fine language that I also like to
 program with, but for these tasks, 'make' doesn't really help much.
 
 Jonas, would it be an option to you to implement them in a language
 other than make? Ideally, we could try (again) to push at least some of
 these tasks into the devscripts package, which is more the place I think
 they belong to.
 
  CDBS is less invasive - e.g. can be used with manually run dh_* commands
 
 as indicated above, the integration of all kinds of maintenance tasks
 fits my understanding of more invasive, because more unrelated tasks
 are implemented into a single program: debian/rules.
 
  CDBS is written in make (short-form dh somewhat reinvents make in
  Perl)
 
 it reinvents much logic that cdbs chooses to implement in make, but also
 most of cdbs, espc. the tasks that you indicated above, don't really
 benefit from the properties of the make language.
 
 And now for context of everyone that has not attended Jonas and my real
 life flamefest at debconf 10, yes, Jonas and I had (at least one?) long
 real-life conversation about cdbs. It's not that I really disklike it or
 something, au contraire, I do think that cdbs does have benefit for some
 groups of packages. E.g. I know that the gnome and kde package
 consolidate a lot of build logic into cdbs, and this really makes sense
 to me.
 
 



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Felipe Sateler
On 13/08/10 14:12, Hans-Christoph Steiner wrote:
 
 Now that there is a separate thread on cdbs vs dh, perhaps someone could
 give me some feedback on my pd-motex package which happens to use dh.
 I'm ready to fix whatever needs fixing.

THe changelog mentions that it is a non-maintainer upload. That is
certainly an error. Make sure that the names in debian/control and
debian/changelog are byte-for-byte identical.
Also, as we are a team, we set the maintainer field to the list, and
your own name as Uploaders.

The descriptions formatting is a bit ugly, and you might want to use
double space before each element of the list of math functions (to
preserve formatting).
The short description should give an indication of what the externals do.
Also, somewhere in the description should the pd name be expanded into
puredata (for people searching for puredata and people not knowing what
pd is).


For debian/copyright.. has motex really been untouched since 2001?


The example should go into /usr/share/doc/pd-motex/examples.

Similar to the discussion on pd-zexy, is something needed to use motex?
If so, you should document that in README.Debian.

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Jonas Smedegaard

On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:


Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough 
of that at debconf 10 ;-)


The best way to keep a thread alive(!) is to feed it new arguments, as 
you do below.


I honestly tried to not do side-by-side comparison between dh7 and CDBS, 
but stick to facts about CDBS itself.


I shall try my best to keep at that, and leave it to others throwing 
questions or counter-arguments to decide if this thread should be kept 
alive or not.




On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:



CDBS is more backports-friendly (beyond backports.org too!).


It is only more backports-friendly if you also always backport the very 
latest version of cdbs, which does not match my definition of 
'backport' at all.


You are completely right that ideal backportability means no dependency 
on other backports.  Which is the reason I counted backports.org out!


And yes, CDBS is *genuinely* backportable more than short-form dh!



cdbs itself does not seem to be available on backports.org at all.


I dislike[1] backports.org so do not contribute to that myself.

Others apperently don't either - most likely due to it not being 
important: See above!




Moreover, These are the used versions in ubuntu:

 cdbs | 0.4.51ubuntu1 | hardy | source, all
 cdbs | 0.4.52ubuntu18 |jaunty | source, all
 cdbs | 0.4.59ubuntu4 |karmic | source, all
 cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all
 cdbs | 0.4.83ubuntu1 |  maverick | source, all

And I've already shown you a case where a package failed to build with 
lucid's cdbs and you just told me that ubuntu where shipping broken 
cdbs package. Sorry, that does not help me at all with backporting 
packages.


   1) Demonstrating a case does not undermine more backportable.

   2) Releasing testing packages as stable is flawed: Ubuntu is flawed!

With more backportable I mean to say that CDBS in more cases than 
short-form dh is it possible to compile packages in an older Debian 
environment either a) as-is or b) with minor adjustments - e.g. changing 
or removing build-dependencies.


Oh, and if you are lazy (or don't want to touch those weird CDBS-using 
debian/control files) then CDBS itself is backportable as its 
dependencies is fulfilled even on Etch (and, if I recall correctly, 
Sarge too!).  Backporting a recent debhelper requires backporting dpkg 
which I wouldn't dare do...


If all of that does not help [you] at all then too bad: I dare say 
that any narrower definition of more backportable won't get you very 
far with most backporting efforts.




CDBS provides routines to fetch and repackage upstream tarballs

CDBS provides routines to track copyright and licensing info of 
sources.


What is the technical reasoning for needing to integrate these logics 
into debian/rules? I think as developer I'm much more flexible if they 
are implemented in seperate, reusable stand-alone tools. This way:


a) more packages would use the same code to do these tasks
b) these helper tools could be maintained and backported independently
   of cdbs
c) they have really nothing to do with the act of building packages,
   but are more general maintenance tasks


Yes, and this is a noble goal for the future.  As I already told you at 
debconf I plan to do that for the copyright  licensing part.



I think this is the thing that makes me dislike cdbs, too many 
maintenance tasks are integrated into debian/rules and therefore, are 
implemented in make, which is a fine language that I also like to 
program with, but for these tasks, 'make' doesn't really help much.


I totally agree with you that make is not ideal for all of this.

This is the reason copyright  licensing code is implemented in Perl.

Make is powerful to resolve chains of smaller rules and 
interdependencies betwen them, which is quite useful for other parts 
like the get-orig-source target[2].  When uscan perhaps matures to 
contain more of these routines then newer releases of CDBS can embrace 
that - while stil being backports-frindly :-)





Jonas, would it be an option to you to implement them in a language
other than make? Ideally, we could try (again) to push at least some of
these tasks into the devscripts package, which is more the place I think
they belong to.


As mentioned above (and partly told to you in person already at Debconf) 
this is slowly happening already.


And really I feel that this is sliding far quite away from the original 
question: Are there any technical reasons for not using dh [but stick 
with CDBS]? as asked by Benjamin[3].





CDBS is less invasive - e.g. can be used with manually run dh_* commands


as indicated above, the integration of all kinds of maintenance tasks 
fits my understanding of more invasive, because more unrelated tasks 
are implemented into a single program: debian/rules.


Ok, so you interpret the term invasive 

Re: uploaded first pkg: pd-motex

2010-08-13 Thread Felipe Sateler
On 13/08/10 15:15, Jonas Smedegaard wrote:
 Backporting a recent debhelper requires backporting dpkg which I
 wouldn't dare do...

While I don't want to get in the dh/cdbs debate (I'm fine with either),
this statement is not true. debhelper requires dpkg-dev = 1.14.19, and
stable has 1.14.29.

-- 
Saludos,
Felipe Sateler



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-13 Thread Andres Mejia
On Friday 13 August 2010 15:15:26 Jonas Smedegaard wrote:
 On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:
 Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
 of that at debconf 10 ;-)
 
 The best way to keep a thread alive(!) is to feed it new arguments, as
 you do below.
 
 I honestly tried to not do side-by-side comparison between dh7 and CDBS,
 but stick to facts about CDBS itself.
 
 I shall try my best to keep at that, and leave it to others throwing
 questions or counter-arguments to decide if this thread should be kept
 alive or not.
 
 On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:
  CDBS is more backports-friendly (beyond backports.org too!).
 
 It is only more backports-friendly if you also always backport the very
 latest version of cdbs, which does not match my definition of
 'backport' at all.
 
 You are completely right that ideal backportability means no dependency
 on other backports.  Which is the reason I counted backports.org out!
 
 And yes, CDBS is *genuinely* backportable more than short-form dh!
 
 cdbs itself does not seem to be available on backports.org at all.
 
 I dislike[1] backports.org so do not contribute to that myself.
 
 Others apperently don't either - most likely due to it not being
 important: See above!
 
 Moreover, These are the used versions in ubuntu:
   cdbs | 0.4.51ubuntu1 | hardy | source, all
   cdbs | 0.4.52ubuntu18 |jaunty | source, all
   cdbs | 0.4.59ubuntu4 |karmic | source, all
   cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all
   cdbs | 0.4.83ubuntu1 |  maverick | source, all
 
 And I've already shown you a case where a package failed to build with
 lucid's cdbs and you just told me that ubuntu where shipping broken
 cdbs package. Sorry, that does not help me at all with backporting
 packages.
 
 1) Demonstrating a case does not undermine more backportable.
 
 2) Releasing testing packages as stable is flawed: Ubuntu is flawed!
 
 With more backportable I mean to say that CDBS in more cases than
 short-form dh is it possible to compile packages in an older Debian
 environment either a) as-is or b) with minor adjustments - e.g. changing
 or removing build-dependencies.
 
 Oh, and if you are lazy (or don't want to touch those weird CDBS-using
 debian/control files) then CDBS itself is backportable as its
 dependencies is fulfilled even on Etch (and, if I recall correctly,
 Sarge too!).  Backporting a recent debhelper requires backporting dpkg
 which I wouldn't dare do...

I would like to chime in and say that with the packages I've worked on 
(besides my own), I found that both dh and cdbs get whatever I need done. I 
however prefer dh. Really the only reason I've stuck with dh over cdbs in my 
packages is because cdbs depends on debhelper. cdbs even build depends on 
debhelper. I've asked myself, what's the point of having 2 build dependencies 
when 1 is all that I need. Because of this, I found that I may as well use 
debhelper directly for packaging, as opposed to using debhelper indirectly via 
cdbs.

I'm not sure if I'm alone in this kind of reasoning. However, if you can 
somehow remove cdbs dependency on debhelper, I'm sure cdbs would be much more 
interesting.

Now if it's already possible to use cdbs without debhelper, than I'll go ahead 
and admit that I did not know. So far however, I haven't found how to use cdbs 
without debhelper in cdbs documentation or in cdbs examples. Also, cdbs 
dependency and build dependency on debhelper leads me to believe that it's not 
currently possible.

 If all of that does not help [you] at all then too bad: I dare say
 that any narrower definition of more backportable won't get you very
 far with most backporting efforts.
 
  CDBS provides routines to fetch and repackage upstream tarballs
  
  CDBS provides routines to track copyright and licensing info of
  sources.
 
 What is the technical reasoning for needing to integrate these logics
 into debian/rules? I think as developer I'm much more flexible if they
 
 are implemented in seperate, reusable stand-alone tools. This way:
  a) more packages would use the same code to do these tasks
  b) these helper tools could be maintained and backported independently
  
 of cdbs
  
  c) they have really nothing to do with the act of building packages,
  
 but are more general maintenance tasks
 
 Yes, and this is a noble goal for the future.  As I already told you at
 debconf I plan to do that for the copyright  licensing part.
 
 I think this is the thing that makes me dislike cdbs, too many
 maintenance tasks are integrated into debian/rules and therefore, are
 implemented in make, which is a fine language that I also like to
 program with, but for these tasks, 'make' doesn't really help much.
 
 I totally agree with you that make is not ideal for all of this.
 
 This is the reason copyright  licensing code is implemented in Perl.
 
 Make 

Re: uploaded first pkg: pd-motex

2010-08-12 Thread Jonas Smedegaard

On Wed, Aug 11, 2010 at 04:40:54PM -0400, Hans-Christoph Steiner wrote:


Ok, I uploaded my first package from the list of ITPs that I posted 
(pd-*).  Once I get this one thru the whole process, I'll fix whatever 
needs fixing and upload the rest.


Then I'll remove the 'debian' folder from the upstream SVN so that the 
git.debian.org one becomes canonical.


http://git.debian.org/?p=pkg-multimedia/pd-motex.git;a=summary


It seems you've put everything into the master branch.  This is bad - 
and becomes tricky to clean up later, so much better if you do it 
properly from the beginning:


  1. Take your upstream hat on
  2. Release a tarball (with debian subdir stripped)
  3. Take your Debian distributor hat on
  4. Rename tarball to LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
  5. Create a folder LOWERCASE-UPSTREAM-PROJECT
  6. Enter that folder
  7. Initialize git: git init
  8. Import renamed tarball:
 git-import-orig --pristine-tar --sign-tags 
../LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
  9. Add debian subdir
 10. create empty git at Alioth...
 11. push all local data: git push --all; git push --tags


Hope that helps :-)


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Hans-Christoph Steiner
On Thu, 2010-08-12 at 12:11 +0200, Jonas Smedegaard wrote:
 On Wed, Aug 11, 2010 at 04:40:54PM -0400, Hans-Christoph Steiner wrote:
 
 Ok, I uploaded my first package from the list of ITPs that I posted 
 (pd-*).  Once I get this one thru the whole process, I'll fix whatever 
 needs fixing and upload the rest.
 
 Then I'll remove the 'debian' folder from the upstream SVN so that the 
 git.debian.org one becomes canonical.
 
 http://git.debian.org/?p=pkg-multimedia/pd-motex.git;a=summary
 
 It seems you've put everything into the master branch.  This is bad - 
 and becomes tricky to clean up later, so much better if you do it 
 properly from the beginning:
 
1. Take your upstream hat on
2. Release a tarball (with debian subdir stripped)
3. Take your Debian distributor hat on
4. Rename tarball to LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
5. Create a folder LOWERCASE-UPSTREAM-PROJECT
6. Enter that folder
7. Initialize git: git init
8. Import renamed tarball:
   git-import-orig --pristine-tar --sign-tags 
 ../LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
9. Add debian subdir
   10. create empty git at Alioth...
   11. push all local data: git push --all; git push --tags

Ah ok, I just found the right instructions, I was using something else
which I can't find now. I don't know how I missed this one, sorry.
http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Uploadingproposedpackagetotheteamgitrepository

Is git-import-orig preferred over git-import-dsc?  I already have the
whole source package.

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Jonas Smedegaard

On Thu, Aug 12, 2010 at 12:26:41PM -0400, Hans-Christoph Steiner wrote:

On Thu, 2010-08-12 at 12:11 +0200, Jonas Smedegaard wrote:

On Wed, Aug 11, 2010 at 04:40:54PM -0400, Hans-Christoph Steiner wrote:

Ok, I uploaded my first package from the list of ITPs that I posted 
(pd-*).  Once I get this one thru the whole process, I'll fix 
whatever needs fixing and upload the rest.


Then I'll remove the 'debian' folder from the upstream SVN so that 
the git.debian.org one becomes canonical.


http://git.debian.org/?p=pkg-multimedia/pd-motex.git;a=summary

It seems you've put everything into the master branch.  This is bad - 
and becomes tricky to clean up later, so much better if you do it 
properly from the beginning:


   1. Take your upstream hat on
   2. Release a tarball (with debian subdir stripped)
   3. Take your Debian distributor hat on
   4. Rename tarball to LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
   5. Create a folder LOWERCASE-UPSTREAM-PROJECT
   6. Enter that folder
   7. Initialize git: git init
   8. Import renamed tarball:
  git-import-orig --pristine-tar --sign-tags 
../LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
   9. Add debian subdir
  10. create empty git at Alioth...
  11. push all local data: git push --all; git push --tags


Ah ok, I just found the right instructions, I was using something else 
which I can't find now. I don't know how I missed this one, sorry. 
http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Uploadingproposedpackagetotheteamgitrepository


Is git-import-orig preferred over git-import-dsc?  I already have the 
whole source package.


Both are used: git-import-orig is used to import new upstream source. 
git-import-dsc is used to import older(!) full packages, whether or not 
that includes new upstream source or not.


If you mean that you have some older packages lying around that you want 
to inject as basis for our future collaborative work, then yes, use 
git-import-dsc for that.


If you mean that you already have built the package that you intend to 
upload in the future to Debian, then no - don't use git-import-dsc for 
that, as we might spot some improvements before actual final release :-)



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread IOhannes m zmölnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/12/2010 06:26 PM, Hans-Christoph Steiner wrote:
 Is git-import-orig preferred over git-import-dsc?  I already have the
 whole source package.

with git-import-dsc you start from an already packaged deb, whereas with
git-import-orig you start with the upstream source.
if you are using dsc and the package was somewhat sane, it shouldn't
make a difference.

fmwaer
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxkMJ4ACgkQkX2Xpv6ydvR2hACgnKanr+IKFuA1Xo5+UwLNlr9j
0lMAnjonmhk2jEARP8bH5pl84+S+uW7A
=XxnB
-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


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Hans-Christoph Steiner
On Thu, 2010-08-12 at 19:44 +0200, Jonas Smedegaard wrote:
 On Thu, Aug 12, 2010 at 12:26:41PM -0400, Hans-Christoph Steiner wrote:
 On Thu, 2010-08-12 at 12:11 +0200, Jonas Smedegaard wrote:
  On Wed, Aug 11, 2010 at 04:40:54PM -0400, Hans-Christoph Steiner wrote:
  
  Ok, I uploaded my first package from the list of ITPs that I posted 
  (pd-*).  Once I get this one thru the whole process, I'll fix 
  whatever needs fixing and upload the rest.
  
  Then I'll remove the 'debian' folder from the upstream SVN so that 
  the git.debian.org one becomes canonical.
  
  http://git.debian.org/?p=pkg-multimedia/pd-motex.git;a=summary
 
  It seems you've put everything into the master branch.  This is bad - 
  and becomes tricky to clean up later, so much better if you do it 
  properly from the beginning:
 
 1. Take your upstream hat on
 2. Release a tarball (with debian subdir stripped)
 3. Take your Debian distributor hat on
 4. Rename tarball to LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
 5. Create a folder LOWERCASE-UPSTREAM-PROJECT
 6. Enter that folder
 7. Initialize git: git init
 8. Import renamed tarball:
git-import-orig --pristine-tar --sign-tags 
  ../LOWERCASE-UPSTREAM-PROJECT_VERSION.orig.tar.gz
 9. Add debian subdir
10. create empty git at Alioth...
11. push all local data: git push --all; git push --tags
 
 Ah ok, I just found the right instructions, I was using something else 
 which I can't find now. I don't know how I missed this one, sorry. 
 http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Uploadingproposedpackagetotheteamgitrepository
 
 Is git-import-orig preferred over git-import-dsc?  I already have the 
 whole source package.
 
 Both are used: git-import-orig is used to import new upstream source. 
 git-import-dsc is used to import older(!) full packages, whether or not 
 that includes new upstream source or not.
 
 If you mean that you have some older packages lying around that you want 
 to inject as basis for our future collaborative work, then yes, use 
 git-import-dsc for that.
 
 If you mean that you already have built the package that you intend to 
 upload in the future to Debian, then no - don't use git-import-dsc for 
 that, as we might spot some improvements before actual final release :-)

Ok, I went with git-import-dsc since I've had these packages around for
a while in launchpad.  The git-buildpackage tools are much easier, I
wish I'd seen that before :).  

I deleted pd-motex.git and I uploaded it again.  My only question is the
debian version is currently -0.0.  Is that a problem?  I figure it can
be bumped to -1 by whoever becomes the 'official' sponsor.

.hc




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Jonas Smedegaard

On Thu, Aug 12, 2010 at 02:01:36PM -0400, Hans-Christoph Steiner wrote:

Ok, I went with git-import-dsc since I've had these packages around for 
a while in launchpad.  The git-buildpackage tools are much easier, I 
wish I'd seen that before :).


Yeah, I felt the same when I found git (compared to Subversion) and then 
again when I found git-buildpackage :-)



I deleted pd-motex.git and I uploaded it again.  My only question is 
the debian version is currently -0.0.  Is that a problem?  I figure it 
can be bumped to -1 by whoever becomes the 'official' sponsor.


No problem.

NB! Please de-learn the term sponsor - it is confusing and irrelevant 
in the context of teamwork :-)



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Hans-Christoph Steiner


On Aug 12, 2010, at 3:12 PM, Jonas Smedegaard wrote:

On Thu, Aug 12, 2010 at 02:01:36PM -0400, Hans-Christoph Steiner  
wrote:


Ok, I went with git-import-dsc since I've had these packages around  
for a while in launchpad.  The git-buildpackage tools are much  
easier, I wish I'd seen that before :).


Yeah, I felt the same when I found git (compared to Subversion) and  
then again when I found git-buildpackage :-)



I deleted pd-motex.git and I uploaded it again.  My only question  
is the debian version is currently -0.0.  Is that a problem?  I  
figure it can be bumped to -1 by whoever becomes the 'official'  
sponsor.


No problem.

NB! Please de-learn the term sponsor - it is confusing and  
irrelevant in the context of teamwork :-)



ok, uploader?  ;) Once I get the ok on this one, I'll go ahead and  
start uploading the rest.


.hc



[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity.-John Gilmore




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Jonas Smedegaard

On Thu, Aug 12, 2010 at 03:26:03PM -0400, Hans-Christoph Steiner wrote:


On Aug 12, 2010, at 3:12 PM, Jonas Smedegaard wrote:

On Thu, Aug 12, 2010 at 02:01:36PM -0400, Hans-Christoph Steiner 
wrote:


I deleted pd-motex.git and I uploaded it again.  My only question is 
the debian version is currently -0.0.  Is that a problem?  I figure 
it can be bumped to -1 by whoever becomes the 'official' sponsor.


No problem.

NB! Please de-learn the term sponsor - it is confusing and 
irrelevant in the context of teamwork :-)



ok, uploader?  ;) Once I get the ok on this one, I'll go ahead and 
start uploading the rest.


...hm, or maybe you shouldn't listen to me that much here: For this 
package you use short-form dh 7 which I don't, so you'll need to team up 
with someone else than me[1] - and that someone might call it 
sponsoring :-P



 - Jonas

[1] or agree to repackage using cdbs - I just won't you to get the 
impression that I lured you into this: most people in the multimedia 
team are fine with - yeah, even prefer - short-form dh, it is just me 
being obnoxious.


--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: uploaded first pkg: pd-motex

2010-08-12 Thread Benjamin Drung
Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
 [1] or agree to repackage using cdbs - I just won't you to get the 
 impression that I lured you into this: most people in the multimedia 
 team are fine with - yeah, even prefer - short-form dh, it is just me 
 being obnoxious.

I prefer dh over cdbs over long debhelper form. Are there any technical
reasons for not using dh?

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers