Re: jackd2 ready to roll

2010-04-06 Thread Free Ekanayaka
Hi,

|--== On Sun, 4 Apr 2010 15:56:24 +0200, Adrian Knoth 
a...@drcomp.erfurt.thur.de said:

  [...]

  AK What I've seen in the team so far: make it work. Besides this, there are
  AK no to few rules.

  AK We don't have a please beginners policy.

Totally. The only strong points we have as team are listed here

http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Packagingguidelines

and they are pretty packaging-tool-agnostic (re CDBS/DH7/whatever). We
have a lot of packages to care of and limited resources (it's almost all
volunteer work), so I think it makes sense to let whoever gets the job
done decide about how to do it, as long as it is compliant with the
Debian Policy and the few guidelines above.

Btw, thanks a lot Jonas and Adrian for pushing jack2-unstable forward.

Ciao!

Free

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


Re: jackd2 ready to roll

2010-04-06 Thread Jonas Smedegaard

On Tue, Apr 06, 2010 at 08:50:06PM +0200, Free Ekanayaka wrote:

Hi,

|--== On Sun, 4 Apr 2010 15:56:24 +0200, Adrian Knoth 
|--== a...@drcomp.erfurt.thur.de said:


 [...]

 AK What I've seen in the team so far: make it work. Besides this, 
 AK there are no to few rules.


 AK We don't have a please beginners policy.

Totally. The only strong points we have as team are listed here

http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Packagingguidelines

and they are pretty packaging-tool-agnostic (re CDBS/DH7/whatever). We 
have a lot of packages to care of and limited resources (it's almost 
all volunteer work), so I think it makes sense to let whoever gets the 
job done decide about how to do it, as long as it is compliant with the 
Debian Policy and the few guidelines above.


Btw, thanks a lot Jonas and Adrian for pushing jack2-unstable forward.


Thanks for the confirmation and encouragement, Free. I certainly 
appreciate there being room for my CDBS packaging style here at the 
Multimedia team.


I appreciate Reinhard being concerned about newcomers, too.  I have had 
a bad experience with setting the bar too high: I initiated the Debian 
packaging of Sugar packages and encouraged others to join me but 
insisted on doing it my own way.  Today - after several interested 
attempts to help out - I am still the only maintainer of those packages, 
and I partly blame the complexity of my packaging style for that.


So I seriously mean it when I wrote earlier that I appreciate you 
challenging me, Reinhard.  I could use some more challenges on the 
usability front.


Please continue to raise questions about my packaging.  Both to maybe 
learn something (you *and* me). But also to challenge the relevance of 
complexity.  Most probably I will be _very_ stubborn, but even if it 
seems you are getting nowhere with me it might be that your raising 
concerns in the long run help me shape up both my own personal packaging 
style and the features of CDBS.  Just wishing here :-)



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: jackd2 ready to roll

2010-04-06 Thread Reinhard Tartler
On Tue, Apr 06, 2010 at 22:26:06 (CEST), Jonas Smedegaard wrote:

 So I seriously mean it when I wrote earlier that I appreciate you
 challenging me, Reinhard.  I could use some more challenges on the
 usability front.

You're welcome, and I'll do so ;-)

 Please continue to raise questions about my packaging.  Both to maybe
 learn something (you *and* me). But also to challenge the relevance of
 complexity.

Oh, I find reading the cdbs source enlighting from time to time. In
fact, I do like some of its ideas. OTOH, I do have some disagreements,
my latest two have resulted in 2 bugs against the devscripts package,
which I consider as sucess from our dispute ;-) - And yes, I intend to
continue asking questions :-)

-- 
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: jackd2 ready to roll

2010-04-05 Thread Adrian Knoth
On Mon, Apr 05, 2010 at 01:03:45AM +0200, Jonas Smedegaard wrote:

 It seems to me that upstream use SVN, not Git.  Is that correct?
 And how could the packaging version be 1.9.5+svn3977 when apparently the  
 newest SVN commit in upstream trunk is r3968?!?

3977 was the revision shown by svn info by that time. So there might not
be a recent commit to trunk, but to other branches incrementing the
revision number.


Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-05 Thread Jonas Smedegaard

On Mon, Apr 05, 2010 at 12:54:16PM +0200, Adrian Knoth wrote:

On Mon, Apr 05, 2010 at 01:03:45AM +0200, Jonas Smedegaard wrote:


It seems to me that upstream use SVN, not Git.  Is that correct?
And how could the packaging version be 1.9.5+svn3977 when apparently 
the newest SVN commit in upstream trunk is r3968?!?


3977 was the revision shown by svn info by that time. So there might 
not be a recent commit to trunk, but to other branches incrementing the 
revision number.


Please then elaborate: Which branch do you track? And from which (public 
accessible!) SVN source?


debian/copyright lacked reference to the SVN source used (as does my 
rewritten one, until I know what will be used), so that have been of no 
help to me.



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: jackd2 ready to roll

2010-04-05 Thread Adrian Knoth
On Mon, Apr 05, 2010 at 01:33:48PM +0200, Jonas Smedegaard wrote:

 It seems to me that upstream use SVN, not Git.  Is that correct?
 And how could the packaging version be 1.9.5+svn3977 when apparently  
 the newest SVN commit in upstream trunk is r3968?!?

 3977 was the revision shown by svn info by that time. So there might  
 not be a recent commit to trunk, but to other branches incrementing the 
 revision number.

 Please then elaborate: Which branch do you track? And from which (public  
 accessible!) SVN source?

From svn info:

URL: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp
Repository Root: http://subversion.jackaudio.org/jack
Repository UUID: 0c269be4-1314-0410-8aa9-9f06e86f4224
Revision: 3978
Last Changed Rev: 3968
Last Changed Date: 2010-03-26 11:12:37 +0100 (Fri, 26 Mar 2010)


And there it is: the global revision is 3977+1, last change to the
branch in question is your 3968.


HTH

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-05 Thread Jonas Smedegaard

On Mon, Apr 05, 2010 at 01:49:33PM +0200, Adrian Knoth wrote:

On Mon, Apr 05, 2010 at 01:33:48PM +0200, Jonas Smedegaard wrote:


It seems to me that upstream use SVN, not Git.  Is that correct?
And how could the packaging version be 1.9.5+svn3977 when 
apparently the newest SVN commit in upstream trunk is r3968?!?


3977 was the revision shown by svn info by that time. So there might 
not be a recent commit to trunk, but to other branches incrementing 
the revision number.


Please then elaborate: Which branch do you track? And from which 
(public accessible!) SVN source?


From svn info:

URL: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp
Repository Root: http://subversion.jackaudio.org/jack
Repository UUID: 0c269be4-1314-0410-8aa9-9f06e86f4224
Revision: 3978
Last Changed Rev: 3968
Last Changed Date: 2010-03-26 11:12:37 +0100 (Fri, 26 Mar 2010)


And there it is: the global revision is 3977+1, last change to the
branch in question is your 3968.


I am not very good with SVN, so please verify if I understand correctly:

Above means that you did in fact track the standard public accessible 
trunk branch, and the most recent commit to that branch was not 3978 but 
3968 - that other number is simply the global counter of the SVN 
repository.


In other words: r3968 and r3978 of the trunk branch are identical.

Right?


If so, I would recommend in the future to use the revision number of the 
actual latest commit instead of the number of HEAD of the global 
repository. That makes more sense to me :-)



 - 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: jackd2 ready to roll

2010-04-05 Thread Adrian Knoth
On Mon, Apr 05, 2010 at 01:57:44PM +0200, Jonas Smedegaard wrote:

 Above means that you did in fact track the standard public accessible  
 trunk branch, and the most recent commit to that branch was not 3978 but  
 3968 - that other number is simply the global counter of the SVN  
 repository.

Right.

 In other words: r3968 and r3978 of the trunk branch are identical.
 Right?

Absolutely.


Ciao

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-05 Thread Jonas Smedegaard

On Mon, Apr 05, 2010 at 02:37:28PM +0200, Adrian Knoth wrote:

On Mon, Apr 05, 2010 at 01:57:44PM +0200, Jonas Smedegaard wrote:

Above means that you did in fact track the standard public accessible 
trunk branch, and the most recent commit to that branch was not 3978 
but 3968 - that other number is simply the global counter of the SVN 
repository.


Right.

In other words: r3968 and r3978 of the trunk branch are identical. 
Right?


Absolutely.



Thanks for confirming.  Moving on with the repackaging... :-)


 - 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: jackd2 ready to roll

2010-04-04 Thread Adrian Knoth
On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote:

Hi!

 Is it ok with you that I repackage from the current vcs-tarball to  
 pristine-(or-repackaged)-tarball + vcs-patch?

I'm not sure if I'm qualified to give an answer that respects all
implications of this question. I also don't understand half of the
quilt-gbp discussion, so I have to rely on the assumption that you know
what you're doing. ;)

In other words: if you say that tarball+vcs-patch is the right way to
address all the copyright issues in the jackd2 package, then go ahead.

jackd2-1.9.6 will probably contain most of the things we need, that is,
ffado port naming and manpages. ;)


Could give a little hint how to repackage/strip new upstream versions,
so more than one person in the team knows how to do it? ;)


Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-04 Thread Jonas Smedegaard

On Sun, Apr 04, 2010 at 12:25:02PM +0200, Adrian Knoth wrote:

On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote:


Is it ok with you that I repackage from the current vcs-tarball to 
pristine-(or-repackaged)-tarball + vcs-patch?


I'm not sure if I'm qualified to give an answer that respects all 
implications of this question. I also don't understand half of the 
quilt-gbp discussion, so I have to rely on the assumption that you know 
what you're doing. ;)


Thanks for pointing out some things that you cannot follow of the 
routines that I do:  That helps me know what need clarified :-D


So let me try elaborate on the implications of my question, to help you 
make a qualified decision if you agree on it or not:


The question is separate from that other discussion about Git packaging 
style and its clashing with the use of dpkg source format 3.0 (quilt).


The issue here, as I see it, has 2 implications:

 a) Basing our packaging on upstream tarballs or only on upstream VCS
 b) Having me do any of the packaging work

Regarding a) this has been discussed in detail recently on the list. 
Here I will summarise as a proposed new policy for this team:


 1. Use upstream tarball when possible.
 2. When impossible due to no upstream tarball at all, discuss first 
in the team if this should be packaged at all, as that often 
indicates a frequently moving target, which either might be unfit 
for redistribution or perhaps needs special care (e.g. overriding 
shared/static library handling).

 3. When impossible due to major changes since last tarball release
and current VCS, discuss first in the team, as there is a high
risk of accidentally releasing too experimental code.

Since problems have been discovered in the currently prepared packaging 
by you, requiring a repackaging, it makes sense to bring up the question 
now for this specific package.


Since TTBOMK there is no current team policy conflicting with above 
proposed one, I see no need to discuss that proposal before applying it 
to this specific package.


So regarding a) I believe it boils down to a guestion of whether or not 
you will find it annoying that I isolate the changes between latest 
upstream tarball and the VCS snapshot that you prepared, and include 
that difference as a patch?



Regarding b) that other ongoing discussion touched the general concern 
of complicating maintainance in this team by having multiple packaging 
styles.  I have a strong opinion about CDBS vs. short-form debhelper 7 
and insist on aggressively use CDBS while _avoiding_ short-form 
debhelper 7.  This has already affected simplicity of packaging in this 
team, and it is a relevant question if the team is better off without 
me.


There is a common misunderstanding about CDBS that it is targeted 
beginners, and helps hide complicated parts of packaging.  That is IMO 
wrong, and even dangerous: CDBS is better seen as a tool for advanced 
packaging.  When I claim that CDBS is easy to use (and I do claim that) 
then I do *not* mean that it is possible to avoid understanding what is 
going on during the packaging process, only that you need not explicitly 
declare all the tedious parts of it but can use a CDBS templating 
snippet for most if not all of it.  YOU ARE STILL RESPONSIBLE for what 
you let CDBS do for you.


So if a goal of the Multimedia team is to keep a low entry bar for new 
developers, and to keep all packages equally easy for new developers to 
engage in maintaining, then perhaps you should avoid CDBS and only use 
debhelper.


I say perhaps because I really do not know the parts of debhelper 
trying do reinvent the wheel of make - those enabled in short-form mode.  
And I have no interest in learning, because I fundamentally find it a 
wrong approach.  Maybe some day when everyone else in Debian have 
abandoned CDBS and Debian Policy changed to not have debian/rules be a 
make file but a debhlper config file, I might change my mind, but 
currently I cannot imagine that happen.


So I guess b) boils down to a question if you will allow me to infest 
the JACK packaging with even more CDBS now, potentially making it 
cumbersome to change later when maybe the team decides to avoid CDBS?




In other words: if you say that tarball+vcs-patch is the right way to 
address all the copyright issues in the jackd2 package, then go ahead.


Define right way.  It certainly is my way :-)


jackd2-1.9.6 will probably contain most of the things we need, that is, 
ffado port naming and manpages. ;)


...meaning either a) I am silly to waste my time on this since it is 
soon irrelevant (but hey - why bother, it is my time, pride and 
stubbornness, not yours), or b) you can simply delay answering my 
question until upstream at some point release that new version as a 
tarball.




Could give a little hint how to repackage/strip new upstream versions, 
so more than one person in the team knows how to do it? ;)


Most certainly:

  

Re: jackd2 ready to roll

2010-04-04 Thread Jonas Smedegaard

On Sun, Apr 04, 2010 at 03:56:24PM +0200, Adrian Knoth wrote:

On Sun, Apr 04, 2010 at 02:26:48PM +0200, Jonas Smedegaard wrote:

So regarding a) I believe it boils down to a guestion of whether or 
not you will find it annoying that I isolate the changes between 
latest upstream tarball and the VCS snapshot that you prepared, and 
include that difference as a patch?


I don't find this annoying, I could perfectly live with it.


Good.



My personal opinion is quite the opposite, I hate tarballs, I believe
they're obsolete in times of version control systems, they complicate
work due to always being outdated and so on and so on.

But since this is a developer's point of view and not a packager's
perspective, I'm fine with pristine tarballs and, if need be, one
additional vcs diff. (where's the difference to directly basing
everything on a vcs checkout and strip this one?)


That's exactly the point: development vs. (re)distribution!

Tarballs are that boring old tedious format for exchange: the lowest 
common denominator.


Debian packaging is based on tarballs, so from a global Debian POV any 
derivation off of those tarballs complicates matters - even of from 
other POVs it is more convenient.


The only time I ever do tarballs of my own work is when it is needed for 
redistribution.  So I guess I completely agree with you from a 
development POV :-D



Did that answer your question above, or should I elaborate more?


Regarding b) that other ongoing discussion touched the general 
concern of complicating maintainance in this team by having multiple 
packaging styles.


What I've seen in the team so far: make it work. Besides this, there 
are no to few rules.


We don't have a please beginners policy.


ok.


So I guess b) boils down to a question if you will allow me to infest 
the JACK packaging with even more CDBS now, potentially making it 
cumbersome to change later when maybe the team decides to avoid CDBS?


I guess we won't vote against CDBS, so, yes please, go ahead. ;)


Fine.

I would also be surprised if you did so - I am just trying hard not to 
be too biased in summarizing, so deliberately try to skew _away_ from my 
own preferred standpoint.



In other words: if you say that tarball+vcs-patch is the right way 
to address all the copyright issues in the jackd2 package, then go 
ahead.

Define right way.  It certainly is my way :-)


You are the DD, I'm only the DM. I'm more involved upstream, you 
downstream. In other words, you know what's right for Debian, I know 
what's right for jackd (again: developer vs. packager).


I am _a_ DD.  There are many many ways. :-)

But ok - I get the message: I will repackage my way.

...and regarding waf, I think I came up with a sane design: Store a 
checksum of the waf file, and if the actual waf does not match then 
refuse to invoke it and instead warn that it should be checked for 
validity and for licensing, and the checksum updated when ok.



Could give a little hint how to repackage/strip new upstream 
versions, so more than one person in the team knows how to do it? ;)


Most certainly:

  dch -bv 1.9.5-1
  debian/rules get-orig-source


Is there a list of CDBS targets? This looks interesting.


There is the source: CDBS is just a bunch of (carefully composed) make 
snippets below /usr/share/cdbs - go check them out yourself! :-)


You are not the first to ask for a definitive list of targets and 
variables.  It is in the TODO (or actually not, but in my mind and 
possibly in some bugreport too).  CDBS is seriously underdocumented.




To me, the package looks good. If you like, base it on 1.9.5 and upload 
it. I think I'll be able to cope with CDBS, it surely has some good 
features, especially the copyright checks. In case of problems, I'd 
simply ask you. ;)


Thanks for mentioning.  I have spend VERY long time refining that 
particular routine!  ...and it is far from complete.



PS: You might want to join #debian-multimedia on irc.oftc.net. It's 
sometimes easier to answer questions in realtime.


This email has taken me, hmmm, about 1/2 hour to write.  You would 
completely have lost track of the context if I'd done it in same pace on 
IRC.


Or rephrased: IRC is realtime, which is beneficial for getting a 
response, but the responses are seldom deeply reflected.


I do not mean to say that I only want to do deep reflection, just that 
technical discussion IMO are better done through email, while IRC and 
Jabber is better for hanging out.


...and I try to avoid hanging out too much, as it is s fun that I 
loose track of time and never get any productive work done when engaging 
in it.  Which I know is a silly standpoint, because what's to life if I 
only work work work and never have fun.  I know, I know...


...I might stop by that IRC room at some point. Just not now :-)


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing 

Re: jackd2 ready to roll

2010-04-04 Thread Jonas Smedegaard

On Thu, Apr 01, 2010 at 11:00:18PM +0200, Adrian Knoth wrote:

Different approach: make us the jackd2 repository. ;) So we simply use 
git, wildly patch whatever we want, no need to wait for upstream to 
apply my patches and pull from their svn repo from time to time. ;)


This way, we can ship the extracted (and checked) waf code, strip *.dll 
from the package and all the other tweaks that will be required.


Might sound completely crazy, probably because it isi, but it surely 
has its advantages... ;)


I do want to setup a tighter integration between Debian packaging VCS 
and upstream VCS.  Just very important to me to emphasize that is is in 
_addition_ to the use of tarballs, not _instead_ of it.


It seems to me that upstream use SVN, not Git.  Is that correct?

Would upstream perhaps be interested in maintaining a bridge - i.e. a 
Git instance mirroring the SVN, either pushed by an SVN hook or through 
cron?


I believe that will provide the most reliable way of keeping those VCSes 
in sync.


I am willing to help guide in the setup of an SVN→Git bridge.

(might be that a deroute through Bazaar or other more convoluted setups 
are more potent, I just don't know how so cannot help there at all)



 - 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: jackd2 ready to roll

2010-04-04 Thread Reinhard Tartler
On Thu, Apr 01, 2010 at 23:00:18 (CEST), Adrian Knoth wrote:

 Different approach: make us the jackd2 repository. ;) So we simply use
 git, wildly patch whatever we want, no need to wait for upstream to
 apply my patches and pull from their svn repo from time to time. ;)

 This way, we can ship the extracted (and checked) waf code, strip *.dll
 from the package and all the other tweaks that will be required.

 Might sound completely crazy, probably because it isi, but it surely has
 its advantages... ;)

TBH, this sounds not that unreasonable. However, you should be aware
this means essentially, that we are forking upstream. Moreover, this
also implies a totally different workflow compared to our other
pkg-multimedia packages.

For consistency reasons, I'd prefer to not go that way with a team
package. But I don't really work much on jack myself, so don't put too
much weight in this opinion.

-- 
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: jackd2 ready to roll

2010-04-04 Thread Jonas Smedegaard

On Sun, Apr 04, 2010 at 09:16:26PM +0200, Reinhard Tartler wrote:

On Thu, Apr 01, 2010 at 23:00:18 (CEST), Adrian Knoth wrote:

Different approach: make us the jackd2 repository. ;) So we simply 
use git, wildly patch whatever we want, no need to wait for upstream 
to apply my patches and pull from their svn repo from time to time. 
;)


This way, we can ship the extracted (and checked) waf code, strip 
*.dll from the package and all the other tweaks that will be 
required.


Might sound completely crazy, probably because it isi, but it surely 
has its advantages... ;)


TBH, this sounds not that unreasonable. However, you should be aware 
this means essentially, that we are forking upstream. Moreover, this 
also implies a totally different workflow compared to our other 
pkg-multimedia packages.


For consistency reasons, I'd prefer to not go that way with a team 
package. But I don't really work much on jack myself, so don't put too 
much weight in this opinion.


In my experience the workflow need not be very alien to normal 
git-buildpackage:


  * Reserve branches master*, upstream* and pristine-tar for Debian
  * Merge upstream release tag into upstream before tarball import

That's it!  Really!


 - 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: jackd2 ready to roll

2010-04-03 Thread Jonas Smedegaard

On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote:

On Thu, Apr 01, 2010 at 11:00:18PM +0200, Adrian Knoth wrote:

On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:


In short: I would very much like to volunteer to repackage the 
current vcs-tarball as pristine-tarball + vcs-patch.  Is that 
acceptable?


Different approach: make us the jackd2 repository. ;) So we simply use 
git, wildly patch whatever we want, no need to wait for upstream to 
apply my patches and pull from their svn repo from time to time. ;)


This way, we can ship the extracted (and checked) waf code, strip 
*.dll from the package and all the other tweaks that will be required.


Might sound completely crazy, probably because it isi, but it surely 
has its advantages... ;)


It certainly has its advantages if upstream also use Git to then 
maintain upstream and our branches in a single Git.  For packaging 
development.


But it still makes best sense to base our final releases on pristine 
tarballs (or not pristine, if upstream tarballs are not DFSG-free).



Is it ok with you that I repackage from the current vcs-tarball to 
pristine-(or-repackaged)-tarball + vcs-patch?



We can then _also_ extend to track upstream Git as well, but let's do 
one thing at a time.  You can have a look at e.g. debcheckout sugar 
and read its debian/README.source for a suggestion on how to do it.  
Or ask if that file is not easy to comprehend, and I'd be happy to 
elaborate :-)



Ping!


 - 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: jackd2 ready to roll

2010-04-01 Thread Adrian Knoth
On Thu, Apr 01, 2010 at 02:56:46PM +0200, Jonas Smedegaard wrote:

 One thing I noticed in your recent commits: You explicitly enable ALSA  
 in the configure options - but isn't that unavnailable on some archs (or  
 am I confusing this with some other feature?!?)?

kFreeBSD has no ALSA, but we conditionally include the resulting object
files in debian/rules, so I hope the configure process will detect the
missing build dependency and continue without ALSA on kFreeBSD and hurd.

If not, we'll get an FTBFS and set the configure options depending on
the architecture.

In other words: I don't know if it'll break. Let's see... ;)


-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-01 Thread Jonas Smedegaard

On Thu, Apr 01, 2010 at 02:44:21PM +0200, Adrian Knoth wrote:
Ok guys, I've fixed the ffado portnaming issue and I also provided the 
manpages, in other words, the jackd2 package is now ready to be 
uploaded to *unstable*.


New release uses waf as build system.

That's fine in itself, but there's a problem: It ships with a 
self-expanding waf 1.5.0 which works but is unacceptable to use in 
Debian: we should not execute a binary blob as part of the build 
process!


Using the separately packaged waf version 1.5.10 fails to locate expat 
and libsamplerate (and possibly other system libraries).


I have tried to wrap my head around the waf code for some hours but 
give up for now.


 1) someone needs to help patch ./wscript to work with system waf
 2) we need to repackage source to not include that binary waf, as we 
cannot easily verify if it contains wrongly licensed code.


That second point brings up that pet annoyance of mine: I can easily 
automate repackaging an official upstream tarball - so that it will get 
stripped automagically also when upstream releases their next tarball. 
But it is more clumsy to write a routine to pull from upstream VCS, 
strip from there, and store as a tarball.  And even if done, it is less 
obvious for others to track what is then upstream and how did we hack on 
the upstream code.


In short: I would very much like to volunteer to repackage the current 
vcs-tarball as pristine-tarball + vcs-patch.  Is that acceptable?



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: jackd2 ready to roll

2010-04-01 Thread Adrian Knoth
On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:

 Using the separately packaged waf version 1.5.10 fails to locate expat  
 and libsamplerate (and possibly other system libraries).

Though I don't know waf, I just figured it out, and like always, it's
completely non-obvious:

-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', -O3)
+conf.env.append_unique('CCFLAGS', -O3)

This makes it work, at least until the next error. I'll dig further.

 In short: I would very much like to volunteer to repackage the current  
 vcs-tarball as pristine-tarball + vcs-patch.  Is that acceptable?

Different approach: make us the jackd2 repository. ;) So we simply use
git, wildly patch whatever we want, no need to wait for upstream to
apply my patches and pull from their svn repo from time to time. ;)

This way, we can ship the extracted (and checked) waf code, strip *.dll
from the package and all the other tweaks that will be required.

Might sound completely crazy, probably because it isi, but it surely has
its advantages... ;)


Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

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


Re: jackd2 ready to roll

2010-04-01 Thread Adrian Knoth
On Thu, Apr 01, 2010 at 11:00:18PM +0200, Adrian Knoth wrote:

 -conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
 -conf.env.append_unique('CCFLAGS', '-O3 -Wall')
 +conf.env.append_unique('CXXFLAGS', -O3)
 +conf.env.append_unique('CCFLAGS', -O3)
 
 This makes it work, at least until the next error. I'll dig further.

I guess we could propose the following patch to upstream:

-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', [-O3, -Wall])
+conf.env.append_unique('CCFLAGS', [-O3, -Wall])



-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

The trouble with being punctual is that nobody's there to appreciate it.
-- Franklin P. Jones

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


Re: jackd2 ready to roll

2010-04-01 Thread Adrian Knoth
On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:

 New release uses waf as build system.

So, after perhaps 3hrs of hacking, I now have a patch that enables the
use of system-wide waf. Find attached.

However, the system-wide waf is going to be removed from Debian:

   http://www.mail-archive.com/debian-de...@lists.debian.org/msg281401.html

Upstream also discourages system-wide waf:

   http://freehackers.org/~tnagy/wafbook/single.html#_installing_waf_on_a_system

01:17  ita adi_: do not trust the distributions - use your version of
waf and redistribute your code with that version - it will save you a
lot of time

01:20  ita adi_: waf is like a configure script, it should not be
packaged - never



Though I understand your concern, I could perfectly live with the
shipped waf. But what do I know? ;)


Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver
diff --git a/common/wscript b/common/wscript
index da3ab93..ba2440b 100644
--- a/common/wscript
+++ b/common/wscript
@@ -64,7 +64,7 @@ def build(bld):
 'JackEngineProfiling.cpp',
 ]
 
-includes = ['.', './jack', '..']
+includes = ['.', './jack', '..', '../build/default']
 uselib = [PTHREAD]
 
 if bld.env['IS_LINUX']:
diff --git a/example-clients/wscript b/example-clients/wscript
index 4cf08d1..2643b5a 100644
--- a/example-clients/wscript
+++ b/example-clients/wscript
@@ -61,7 +61,7 @@ def configure(conf):
 
 def build(bld):
 if bld.env['IS_LINUX']:
-os_incdir = ['../linux', '../posix']
+os_incdir = ['../linux', '../posix', '../build/default']
 if bld.env['IS_MACOSX']:
 os_incdir = ['../macosx', '../posix']
 if bld.env['IS_SUN']:
diff --git a/linux/wscript b/linux/wscript
index 869985d..93957e3 100644
--- a/linux/wscript
+++ b/linux/wscript
@@ -19,7 +19,7 @@ def create_jack_driver_obj(bld, target, sources, uselib = None):
 driver.features.append('cc')
 driver.env['shlib_PATTERN'] = 'jack_%s.so'
 driver.defines = ['HAVE_CONFIG_H','SERVER_SIDE', 'HAVE_PPOLL']
-driver.includes = ['.', '../linux', '../posix', '../common', '../common/jack', '../dbus']
+driver.includes = ['.', '../linux', '../posix', '../common', '../common/jack', '../dbus', '../build/default']
 driver.target = target
 driver.source = sources
 driver.install_path = '${ADDON_DIR}/'
@@ -31,7 +31,8 @@ def create_jack_driver_obj(bld, target, sources, uselib = None):
 def build(bld):
 if bld.env['BUILD_JACKD'] == True:
 jackd = bld.new_task_gen('cxx', 'program')
-jackd.includes = ['../linux', '../posix', '../common/jack', '../common', '../dbus']
+jackd.features='cc cxx cprogram'
+jackd.includes = ['../linux', '../posix', '../common/jack', '../common', '../dbus', '../build/default']
 jackd.defines = 'HAVE_CONFIG_H'
 jackd.source = ['../common/Jackdmp.cpp']
 	if bld.env['IS_LINUX'] and bld.env['BUILD_JACKDBUS']: 
diff --git a/waf b/waf
index f0f7f63..cd561b6 100755
Binary files a/waf and b/waf differ
diff --git a/wscript b/wscript
index bc88c49..da75181 100644
--- a/wscript
+++ b/wscript
@@ -107,8 +107,8 @@ def configure(conf):
 #   conf.check_tool('compiler_cxx')
 #   conf.check_tool('compiler_cc')
  
-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', [-O3, -Wall])
+conf.env.append_unique('CCFLAGS', [-O3, -Wall])
 
 conf.sub_config('common')
 if conf.env['IS_LINUX']:
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: jackd2 ready to roll

2010-04-01 Thread Jonas Smedegaard

On Thu, Apr 01, 2010 at 11:00:18PM +0200, Adrian Knoth wrote:

On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:


In short: I would very much like to volunteer to repackage the 
current vcs-tarball as pristine-tarball + vcs-patch.  Is that 
acceptable?


Different approach: make us the jackd2 repository. ;) So we simply use 
git, wildly patch whatever we want, no need to wait for upstream to 
apply my patches and pull from their svn repo from time to time. ;)


This way, we can ship the extracted (and checked) waf code, strip *.dll 
from the package and all the other tweaks that will be required.


Might sound completely crazy, probably because it isi, but it surely 
has its advantages... ;)


It certainly has its advantages if upstream also use Git to then 
maintain upstream and our branches in a single Git.  For packaging 
development.


But it still makes best sense to base our final releases on pristine 
tarballs (or not pristine, if upstream tarballs are not DFSG-free).



Is it ok with you that I repackage from the current vcs-tarball to 
pristine-(or-repackaged)-tarball + vcs-patch?



We can then _also_ extend to track upstream Git as well, but let's do 
one thing at a time.  You can have a look at e.g. debcheckout sugar 
and read its debian/README.source for a suggestion on how to do it.  Or 
ask if that file is not easy to comprehend, and I'd be happy to 
elaborate :-)




 - 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: jackd2 ready to roll

2010-04-01 Thread Jonas Smedegaard

On Fri, Apr 02, 2010 at 01:27:33AM +0200, Adrian Knoth wrote:

On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:


New release uses waf as build system.


So, after perhaps 3hrs of hacking, I now have a patch that enables the 
use of system-wide waf. Find attached.


Great work!



However, the system-wide waf is going to be removed from Debian:

  http://www.mail-archive.com/debian-de...@lists.debian.org/msg281401.html


Oh shit!


Hmm.  I really do not want to blindly trust upstream binary code, but 
now that I know it is a bzip2, perhaps I can invent some routine to 
unpack as source locally, check those unpacked sources for changes 
(similar to my copyright-check routine now in CDBS utils.mk), and if ok 
then go ahead and invoke it...


Ugly, but doable, I think.


 - 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