jack-audio-connection-kit override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): libjack0.100.0-dev_0.115.6-1_all.deb: package says section is libs, override says libdevel. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your mail due to missing information. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
jack-audio-connection-kit_0.115.6-1_amd64.changes ACCEPTED
Accepted: jack-audio-connection-kit_0.115.6-1.diff.gz to pool/main/j/jack-audio-connection-kit/jack-audio-connection-kit_0.115.6-1.diff.gz jack-audio-connection-kit_0.115.6-1.dsc to pool/main/j/jack-audio-connection-kit/jack-audio-connection-kit_0.115.6-1.dsc jack-audio-connection-kit_0.115.6.orig.tar.gz to pool/main/j/jack-audio-connection-kit/jack-audio-connection-kit_0.115.6.orig.tar.gz jackd_0.115.6-1_amd64.deb to pool/main/j/jack-audio-connection-kit/jackd_0.115.6-1_amd64.deb libjack-dev_0.115.6-1_amd64.deb to pool/main/j/jack-audio-connection-kit/libjack-dev_0.115.6-1_amd64.deb libjack0.100.0-0_0.115.6-1_all.deb to pool/main/j/jack-audio-connection-kit/libjack0.100.0-0_0.115.6-1_all.deb libjack0.100.0-dev_0.115.6-1_all.deb to pool/main/j/jack-audio-connection-kit/libjack0.100.0-dev_0.115.6-1_all.deb libjack0_0.115.6-1_amd64.deb to pool/main/j/jack-audio-connection-kit/libjack0_0.115.6-1_amd64.deb Override entries for your package: jack-audio-connection-kit_0.115.6-1.dsc - source sound jackd_0.115.6-1_amd64.deb - optional sound libjack-dev_0.115.6-1_amd64.deb - optional libdevel libjack0.100.0-0_0.115.6-1_all.deb - optional libs libjack0.100.0-dev_0.115.6-1_all.deb - optional libdevel libjack0_0.115.6-1_amd64.deb - optional libs Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of jack-audio-connection-kit_0.115.6-1_amd64.changes
jack-audio-connection-kit_0.115.6-1_amd64.changes uploaded successfully to localhost along with the files: jack-audio-connection-kit_0.115.6-1.dsc jack-audio-connection-kit_0.115.6.orig.tar.gz jack-audio-connection-kit_0.115.6-1.diff.gz libjack0.100.0-0_0.115.6-1_all.deb libjack0.100.0-dev_0.115.6-1_all.deb jackd_0.115.6-1_amd64.deb libjack0_0.115.6-1_amd64.deb libjack-dev_0.115.6-1_amd64.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do for new packages
Hi Felipe, |--==> On Fri, 28 Nov 2008 13:04:12 -0300, Felipe Sateler <[EMAIL PROTECTED]> said: FS> El 27/11/08 18:01 Reinhard Tartler escribió: >>Felipe Sateler <[EMAIL PROTECTED]> writes: >>> OK, so I'm about to co-maintain liblo, which is an OSC library, and can >>> be considered a multimedia package (csound, rosegarden and ardour are >>> some "big" packages using it). >> >>ok. cool! >> >>> So... I want to bring it under the scope of the teams-to-become-one. I >>> have imported the sources into a git repository. >> >>IIRC we agreed on tracking upstream releases in an upstream branch, >>maintain debian packaging in a branch derived from the upstream branch >>but keep patches to the upstream source in quilt. Is that correct? >> >>We should really document that somewhere. Probably on wiki.debian.org >>would be a good place. FS> OK, I've started a page: http://wiki.debian.org/DebianMultimedia/Merge. Please FS> add, edit, remove whatever you think necessary. I just filled a stub based on FS> what I think we have agreed. Excellent. Apparently pkg-multimedia does not have a wiki page yet, we might want to use the DebianMultimedia one as base to move forward. >> >>> demudi already has a git area >>> enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? >>> What list should I put in the Maintainer field? >>> Given that pkg-multimedia is more active maybe we should it? >> >>I really don't mind using pkg-multimedia-maintainers, since it is more >>active. I've setup a doodle poll, please vote here: >> >>http://doodle.com/v6df6bx2akdft73f FS> Great! I placed my vote. I agree with Fabian that debian-multimedia may be FS> associated with Marillat's repository, and we should avoid that. That is true, even though I would point out that as far as I remember Marillat's repository used to be called simply "marillat", and only later the name has been changed to "debian-multimedia" (about 1.5/2 years ago I think). The debian-multimedia mailing Debian list and associated team is there since more than 5 years now. Marillat and the other maintainers at debian-multimedia.org could have asked our opinion before using that name. Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multimedia Teams in Debian
Felipe Sateler <[EMAIL PROTECTED]> writes: >> 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. > > Ehm, I'm not sure I understand this. Moving the libswscale repository back to > ffmpeg would break bisecting of libswscale, you mean? it would break bisecting ffmpeg with having libswscale enabled. > And Diego is trying to retrofit libswscale's history into ffmpeg's? yes. >> >> >> > 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? > > For the same reasons you take a particular snapshot any time. It just saves > you the hassle of manufacturing a tarball and importing it into a "fake" > upstream branch. I cannot imagine any case when I would have wanted to do that. could you perhaps name examples? Maybe I just don't understand this point, but it doesn't seem too important to me either. >> Would that make it rather difficult for upstream to know what changes >> we have done in the package? > > I worded it badly. The tag would be present in the debian git repository, and > as such it would be public. Also, upstream doesn't need to care about this, > since we would still be using quilt patches that can be mailed to them. Also, > if upstream is tracking the debian branch, merge points are stored, so > upstream knows precisely which point in time you snapshotted. upstream would still have the hassle to understand git and the way we use git. I'd prefer to save them this efford unless we have good reasons to do so. -- 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 30/11/08 04:32 Reinhard Tartler escribió: > 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. Yes, but that requires me to remember to do that :). The point was that doing this requires more effort than it's worth, if upstream does releases frequently. > > >> > 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. Ehm, I'm not sure I understand this. Moving the libswscale repository back to ffmpeg would break bisecting of libswscale, you mean? And Diego is trying to retrofit libswscale's history into ffmpeg's? > > >> > 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? For the same reasons you take a particular snapshot any time. It just saves you the hassle of manufacturing a tarball and importing it into a "fake" upstream branch. > Would that make it rather > difficult for upstream to know what changes we have done in the package? I worded it badly. The tag would be present in the debian git repository, and as such it would be public. Also, upstream doesn't need to care about this, since we would still be using quilt patches that can be mailed to them. Also, if upstream is tracking the debian branch, merge points are stored, so upstream knows precisely which point in time you snapshotted. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
Hi, |--==> On Fri, 28 Nov 2008 18:47:54 +0100, Loïc Minier <[EMAIL PROTECTED]> said: LM> On Fri, Nov 28, 2008, Free Ekanayaka wrote: >>demudi has already a repo on git.debian.org, and I prefer it over >>collab-maint because the latter is writable only by DDs (for non-DDs >>you have to ask for write permission on case-by-case basis), while the >>former is writable by all the members of the relevant Alioth project, >>DDs or not. LM> That doesn't make any sense to me: LM> - demudi: non-DD have to ask, DD have to ask LM> - collab-maint: non-DD have to ask, DD don't LM> Besides, you ask only once for collab-maint membership, but it's not LM> only about multimedia packages. But in case of demudi (or whatever alioth project we choose) we have direct control on the project members, this avoids having to ask every time, we can do it ourselves. Furthermore we avoid giving write permission to the whole collab-maint tree to any contributor of our project. >>I would like to have a git branch for these patches as well, but we >>might want to make this optional. For very small patches it is >>probably overkill. LM> Please, no; you can create the patches from local git branches when you LM> prepare them, but it doesn't make sense if we export branches to LM> patches because what we might receive are ... updated patches. >>As said, I would stick to the git-buildpackage standards, that means a >>git branch for upstream sources, which can get imported with >>git-import-orig LM> Sounds right! We would still be compliant with the git-buildpackage standards, but we would simply have more branches than only master and upstream. In any case if exporting patch branches does not sound good, I can keep them in my private repository only, that's the beauty of git :) Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
