Re: Multimedia Teams in Debian
Felipe Sateler <[EMAIL PROTECTED]> writes: > There's also git-cvsimport, which I used for a while. However, the import > stage is very slow, since it is done over the net. Subsequent updates are > very slow too (unless one keeps the cvsimport updated very frequently). The > problem is that one has to checkout every point in history, making it very > slow for relatively large projects. in order to speed up the whole thing, I'd recommend rsync'ing the cvs repository to localhost first and then run the conversion. That's how we tracked the OpenBSD CVS in git in a project I've worked previously on. >> > In the case of ffmpeg, where there are no released tarballs, it would >> > make sense to directly track the git repository (ie, the upstream >> > branch is a clone of upstream's master branch). >> >> The particular problem with ffmpeg is that upstream uses svn externals >> to track the 'libswscale' subdirectory. The upstream git repository even >> leaves that directory out completely. I haven't found a better way to >> track upstream than what we currently have as the current >> get-orig-tar.sh, but I'm open for improvements on that. > > Hmm, this is strange. I assume libswscale can't easily be built independently > of ffmpeg, or that would be done, am I right? What motivation has upstream > for doing this? libswscale is historically developed in the mplayer svn, ffmpeg has more or less integrated that in their own tree (well, it is optional but has more features than the internal scaler). It has no standalone buildsystem, but integrates cleanly in both the ffmpeg and mplayer build system. The sanest way would be to move the libswscale repository back to ffmpeg. That however would break bisecting, so they insist on rewriting the ffmpeg svn repository so seamlessly integrate the development history. This is a tedious job Diego is working for over a year on. >> > In either case, "upstream" releases should be tagged (eg, >> > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff >> > is not a diff against upstream's tip, but against these tags. >> >> If we track "upstream releases" (which I think we should do by default >> unless there are compelling reasons not to do so, see the ffmpeg >> example), indeed! > > Note that upstream releases need not be official. You can tag in your local > copy some point in history as upstream/x.y.z+somedate, and use that as the > upstream release. Ugh. And why and when should we do that? Would that make it rather difficult for upstream to know what changes we have done in the package? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multimedia Teams in Debian
El 29/11/08 17:41 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > >> For point 1: How often do you "snapshot" upstream? Every upstream commit > >> of their VCS or only upstream releases? What to do with upstreams that > >> don't do commits in years? (think ffmpeg, toolame). > > > > In our case, we track upstream releases only, but only because it doesn't > > make much sense to do otherwise[1]: csound uses CVS (ugh), thus making it > > painful to track it directly. > > for cvs, there is cvs2svn, which can export in a format compatible to > git-fast-import. Therefore AFAIUI it should be pretty easy to track the > upstrem cvs with git. > > I'm not suggesting (yet) to do that. I think it only makes sense if we > had a large set of patches that we want to get upstream. There's also git-cvsimport, which I used for a while. However, the import stage is very slow, since it is done over the net. Subsequent updates are very slow too (unless one keeps the cvsimport updated very frequently). The problem is that one has to checkout every point in history, making it very slow for relatively large projects. > > > In the case of ffmpeg, where there are no released tarballs, it would > > make sense to directly track the git repository (ie, the upstream > > branch is a clone of upstream's master branch). > > The particular problem with ffmpeg is that upstream uses svn externals > to track the 'libswscale' subdirectory. The upstream git repository even > leaves that directory out completely. I haven't found a better way to > track upstream than what we currently have as the current > get-orig-tar.sh, but I'm open for improvements on that. Hmm, this is strange. I assume libswscale can't easily be built independently of ffmpeg, or that would be done, am I right? What motivation has upstream for doing this? > > > In either case, "upstream" releases should be tagged (eg, > > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff > > is not a diff against upstream's tip, but against these tags. > > If we track "upstream releases" (which I think we should do by default > unless there are compelling reasons not to do so, see the ffmpeg > example), indeed! Note that upstream releases need not be official. You can tag in your local copy some point in history as upstream/x.y.z+somedate, and use that as the upstream release. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
Felipe Sateler <[EMAIL PROTECTED]> writes: >> For point 1: How often do you "snapshot" upstream? Every upstream commit >> of their VCS or only upstream releases? What to do with upstreams that >> don't do commits in years? (think ffmpeg, toolame). > > In our case, we track upstream releases only, but only because it doesn't > make > much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful > to track it directly. for cvs, there is cvs2svn, which can export in a format compatible to git-fast-import. Therefore AFAIUI it should be pretty easy to track the upstrem cvs with git. I'm not suggesting (yet) to do that. I think it only makes sense if we had a large set of patches that we want to get upstream. > In the case of ffmpeg, where there are no released tarballs, it would > make sense to directly track the git repository (ie, the upstream > branch is a clone of upstream's master branch). The particular problem with ffmpeg is that upstream uses svn externals to track the 'libswscale' subdirectory. The upstream git repository even leaves that directory out completely. I haven't found a better way to track upstream than what we currently have as the current get-orig-tar.sh, but I'm open for improvements on that. > In either case, "upstream" releases should be tagged (eg, > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff > is not a diff against upstream's tip, but against these tags. If we track "upstream releases" (which I think we should do by default unless there are compelling reasons not to do so, see the ffmpeg example), indeed! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505705: amsynth's freeverb don't work
This is due to the somehow broken CMT plugin library (package: cmt). Amsynth uses the Freeverb plugin from that package and that one doesn't work in lenny (I think it works in etch), for whatever reason. I've contacted the developer... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507248: jackd: realtime setting needs modifications to /etc/security/limits.conf
Package: jackd Version: 0.109.2-4 Severity: important if realtime is activated, jackd won't restart, because it fails to access "something". The fix is to add @audio - rtprio 99 @audio - nice -15 @audio - memlock 25 to /etc/security/limits.conf Also, it allows a regular user to launch jackd with "nice -n -15 /usr/bin/jackd" instead of the default "/usr/bin/jackd" -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jackd depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libjack0 0.109.2-4 JACK Audio Connection Kit (librari ii libreadline5 5.2-3 GNU readline and history libraries ii libsndfile1 1.0.17-4 Library for reading/writing audio Versions of packages jackd recommends: ii libpam-modules1.0.1-4+b1 Pluggable Authentication Modules f ii qjackctl 0.3.2-1User interface for controlling the Versions of packages jackd suggests: ii jack-tools0.0.2-5various JACK tools: plumbing, play ii libjackasyn0 0.11-2 The Asynchrounous JACK Library ii meterbridge 0.9.2-6A collection of Audio meters for t -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
attention please.
I have a new email address!You can now email me at: [EMAIL PROTECTED] I am David Thompson. I want to transfer the sum of $10.5MILLION to your account. David Thompson - David Thompson
