Patch for Blends package
Hi, while working on an UDD importer I detected some issues in debian-multimedia Blends package. Please apply the attached patch (and possibly set ACLs to enable me pushing directly). Kind regards Andreas. -- http://fam-tille.de >From 2632edbbef1d06abb3094f1f7f57bb1e16bdd61e Mon Sep 17 00:00:00 2001 From: Andreas Tille <ti...@debian.org> Date: Fri, 1 Jan 2016 14:04:30 +0100 Subject: [PATCH] Fix typo and remove duplicates --- tasks/audio-plugins | 2 +- tasks/devel | 18 -- tasks/puredata | 2 -- 3 files changed, 1 insertion(+), 21 deletions(-) diff --git a/tasks/audio-plugins b/tasks/audio-plugins index 03b0cd7..60f566c 100644 --- a/tasks/audio-plugins +++ b/tasks/audio-plugins @@ -144,7 +144,7 @@ Depends: zam-plugins Depends: zynadd -Depend: vlevel +Depends: vlevel Depends: ingen Pkg-Description: modular audio processing system diff --git a/tasks/devel b/tasks/devel index 2ee6c60..5a65c37 100644 --- a/tasks/devel +++ b/tasks/devel @@ -29,8 +29,6 @@ Depends: libjack-dev Depends: liblircclient-dev -Depends: liblo-dev - Depends: liblrdf0-dev Suggests: libmxml-dev @@ -71,8 +69,6 @@ Depends: libaubio-dev Suggests: libboost-dev -Suggests: libfftw3-dev - Suggests: libgail-common Suggests: libgail-dev @@ -83,8 +79,6 @@ Suggests: libgnomecanvas2-dev Suggests: libgnomecanvasmm-2.6-dev -Depends: liblrdf0-dev - Depends: libsoundtouch-dev Suggests: libusb-dev @@ -99,8 +93,6 @@ Depends: librubberband-dev Depends: libvorbis-dev -Depends: libmad0-dev - Depends: ladspa-sdk Depends: liba52-0.7.4-dev @@ -213,8 +205,6 @@ Depends: liblivemedia-dev, livemedia-utils Depends: liblo-dev, liblo-tools -Depends: liblrdf0-dev - Depends: liblscp-dev Depends: libltc-dev @@ -227,8 +217,6 @@ Depends: libmms-dev Depends: libmpcdec-dev, musepack-tools -Depends: libpostproc-dev - Depends: libquicktime-dev, quicktime-utils, quicktime-x11utils Depends: libreplaygain-dev @@ -311,8 +299,6 @@ Depends: libsndobj-dev Depends: libsord-dev, sordi -Depends: libsoundtouch-dev - Depends: libsratom-dev Depends: libstk0-dev @@ -355,10 +341,6 @@ Depends: libx265-dev Depends: libbdplus-dev -Depends: liba52-0.7.4-dev - -Depends: libdvdnav-dev - Depends: libsfark-dev Depends: gstreamer-sharp-1.0 diff --git a/tasks/puredata b/tasks/puredata index 30a01d7..9d65be2 100644 --- a/tasks/puredata +++ b/tasks/puredata @@ -256,8 +256,6 @@ Depends: pd-readanysf Depends: pd-rtclib -Depends: pd-scaf - Depends: pd-sigpack Depends: pd-smlib -- 2.6.4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Proposal 213 - Debian Multimedia BoF (Andreas Tille)
Sorry, wrong subject was previously injected here - it previously said Med instead of Multimedia. I'm about to cancel this BoF due to a lack of any response from Debian Multimedia. Please raise your hand soon if this slot should be reserved for a team meeting of multimedia maintainers. Kind regards Andreas. On Sat, Jul 04, 2015 at 08:10:14PM +0200, Andreas Tille wrote: Hi, On Fri, Jun 19, 2015 at 11:32:54PM +0200, Maximiliano Curia wrote: Hi! In previous DebConfs there have been many events called BoFs that were actually presentations of one speaker in the front, sometimes with slides, usually held in the same big rooms as the other talks. In DebConf15, the largest BoF room will have space for a maximum of 45 people (and will have video coverage) and there will be a number of other smaller rooms with space for 15 to 20 people, without video coverage. We have quite a number of BoF proposals, and only a few of them will get video coverage, which is of course a hard decision to take, as not all of the currently submitted BoFs will get video coverage. For all these reasons we ask you to consider the following options: - Will your BoF consist mostly of one or two speakers in the front, doing a presentation? If so, please change it to be a talk. - Will your BoF be mostly for the people present in the room, and thus does not require video coverage? If so, please make sure that the video recording box is not ticked. - Would it make sense to split it into two sections, one that can be streamed and one that can be just in-person? If so, you could submit a second event, or add a comment in the already existing one to let us know. Whatever you decide to do, please also tell us by replying to this email. I had no single response from Debian Multimedia to my initial information[1] which was the only mail in May to this mailing list. I've now put the packaging list in CC but I'm considering to withdraw my proposal above. In any case it seems no video coverage will be needed. Kind regards Andreas. [1] https://lists.debian.org/debian-multimedia/2015/05/msg0.html -- http://fam-tille.de -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Proposal 212 - Debian Med BoF (Andreas Tille)
Hi, On Fri, Jun 19, 2015 at 11:32:54PM +0200, Maximiliano Curia wrote: Hi! In previous DebConfs there have been many events called BoFs that were actually presentations of one speaker in the front, sometimes with slides, usually held in the same big rooms as the other talks. In DebConf15, the largest BoF room will have space for a maximum of 45 people (and will have video coverage) and there will be a number of other smaller rooms with space for 15 to 20 people, without video coverage. We have quite a number of BoF proposals, and only a few of them will get video coverage, which is of course a hard decision to take, as not all of the currently submitted BoFs will get video coverage. For all these reasons we ask you to consider the following options: - Will your BoF consist mostly of one or two speakers in the front, doing a presentation? If so, please change it to be a talk. - Will your BoF be mostly for the people present in the room, and thus does not require video coverage? If so, please make sure that the video recording box is not ticked. - Would it make sense to split it into two sections, one that can be streamed and one that can be just in-person? If so, you could submit a second event, or add a comment in the already existing one to let us know. Whatever you decide to do, please also tell us by replying to this email. I had no single response from Debian Multimedia to my initial information[1] which was the only mail in May to this mailing list. I've now put the packaging list in CC but I'm considering to withdraw my proposal above. In any case it seems no video coverage will be needed. Kind regards Andreas. [1] https://lists.debian.org/debian-multimedia/2015/05/msg0.html -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Please be verbose whether you would like to get your Blend promoted by tasksel
Hi, yesterday I joined the videostream of the installer BoF at DebConf[1]. I also became a bit involved via IRC. Joey Hess raised the question about the criteria to add a Blend or not. I answered all in the list of the bug report #758116 which IMHO fits the criterion of actively maintained and some valuable content for users. I think it should be also a criterion that the team behind the Blend confirms that they are interested and so I'm hereby pinging all lists in question to ask you for confirmation. I have set Reply-To to the bug report and the general Blends list in case you are interested in further discussion with other Blends. Any input is welcome to make sure users will realise the fruits of your great work at the earliest point in time. Kind regards Andreas. [1] https://summit.debconf.org/debconf14/meeting/44/debian-installer-and-cd-bof/ -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#732159: Bug#732622: snp-sites: ITP First time debian snp-sites package
Hi Jorge, I was wondering why I was not seeing the ITP you was talking about. I guess you should try to read some relevant documentation since we explicitly point to the way how you are doing ITPs in our policy: http://debian-med.alioth.debian.org/docs/policy.html#itp It is very advisable to read this first to avoid mistakes like this ITP. To fix it I see two options: 1) You create a proper ITP via reportbug wnpp fill in the template but do not finally send the result but only save the document and afterwards answer to this existing bug report. 2) You close this existing (broken) ITP and create a new one from scratch by `reportbug wnpp` Thanks for your work anyway - it is no shame to do some beginner mistakes and we as the Debian Med team is trying to minimise this by explaining how to do things properly. Kind regards Andreas. On Sat, Dec 21, 2013 at 01:54:50PM +0200, Andrei POPESCU wrote: Control: reassign -1 wnpp On Jo, 19 dec 13, 12:47:52, Jorge Soares wrote: Package: snp-sites Version: 1 Severity: normal Dear Maintainer, I would like to regiater my intent to package the software snp-sites -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: PET users: please report {bugs,wishlist} | contributors are welcome
Hi intrigeri, we would be happily stay PET users which we were in the past. Unfortunately David Paleino who cared for this for the Debian Med team is not very active in our team any more and at some point in time it stopped working for us. So a quick introduction what we need to do to make use of the PET web interface would be great. Kind regards and many thanks for providing PET and even pinging your users Andreas. On Thu, Aug 08, 2013 at 11:31:01AM +0200, intrigeri wrote: Hi all, PET is a collection of scripts that gather information about your (or your group's) packages. It allows you to see in a bird's eye view the health of hundreds of packages, instantly realizing where work is needed. Last time I checked, your team was using PET. Is this still the case? If it is, what version are you running? We at the Debian Perl Group would like to point you to a few useful resources about PET: * bug and task tracker: http://bugs.debian.org/pet.debian.net - Feel free to report bugs and needed features there. Also feel free to provide patches! Did I mention that help is warmly welcome? * code: http://anonscm.debian.org/gitweb/?p=pet/pet3.git;a=summary * database dumps: http://pet.43-1.org/~pet/db/. * mailing-list: http://lists.alioth.debian.org/mailman/listinfo/pet-devel * IRC channel: #pet-devel at OFTC * homepage: http://pet.alioth.debian.org/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8561vgpm0a@boum.org -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Presentation + A debian-based for audio creation and production, stage technics and video blend (or the future of TangoStudio)
On Mon, Nov 12, 2012 at 12:26:14PM +0100, Reinhard Tartler wrote: We discussed the option of having conflicts in metapackages several times. If I remember correctly the main drawback is that users who really really want to have pulseaudio need to deinstall the metapackage which is not always what you want. TBH, I do not think that a conflicts in the meta package is the right technical solution. As I said we did not had any request for this and thus it is not implemented. Perhaps it's just because this is not the right technical solution. In any case each previous discussion starting with an initial request of the feature ended up with the conclusion that it is not needed. What you want here is to provide the users the best technical environment to get his work done. I think a much better solution would be a something like a wizard that examines your system installation, educates the user about the findings, and then does specific recommendations (ideally with fix this buttons to just do so). Things that I imagine that this wizard could do would include: * The pulseaudio seems to be running. This can cause the following problems ... do you want to a) disable pulseaudio in your user profile, b) remove it from your system c) do nothing * Your Gnome System Menu is missing the following entries. Do you want to add them? * We recommend installing the following applications: app purpose * You are not running a -rt kernel: do you want to install and reboot? * Your system needs special configuration to reduce the system latency, do you want me to do the following changes to /etc/...? I think you get the idea. That would leave the choice to the user and still be very functional and easy to use. BTW, the idea is not really novel. See for example the powertop application, which makes such suggestions (albeit in text mode) about power management to save battery time. I guess that would be an interesting application for a Debian multimedia blend. +1 Now we only need somebody who writes this tool. :-) Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Remaining packages with debian-multime...@l.d.o as maintainer:
On Tue, Nov 09, 2010 at 09:08:43AM +0100, G??rkan Seng??n wrote: If debian-multimedia is not interested in those. I will definitely keep maintaing them, since I also use those. So I'll just remove debian-multimedia from the Uploaders with the next upload... I think this is a misunderstanding: Debian Multimedia as a team is definitely interested (as well in the package as in team maintenance). However, the list address should be Debian Multimedia Packages Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org as the packaging oriented list where bug reports etc should go and the currently used list should rather be used for user oriented discussion. Kind regards Andreas. PS: We most probably need a policy document which clarifies issues like this. Examples are the policies of Debian Med and Debian Science. Not everything applies here - but might give a reasonable draft. If I'm not completely wrong the documents I mentioned were originally drafted from the doc the Debian Perl team is using. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Debian Multimedia team
Hi, I would be really happy if discussion which is not directly packaging related would be done on debian-multime...@lists.debian.org. Thanks Andreas. On Sun, Nov 07, 2010 at 05:19:37PM -0300, Felipe Sateler wrote: On Sun, Nov 7, 2010 at 07:56, Jonas Smedegaard d...@jones.dk wrote: On Sat, Nov 06, 2010 at 01:44:46PM -0300, Felipe Sateler wrote: I propose we wait one more week in case somebody else wants to add something (Jonas, Fabian, Alessio, Adrian, Andrés, Cristophe, Benjamin; want to add anything?). Then I will send the bits to debian-devel-announce. I most likely won't find time to add to the text. I am in the middle of moving to a now[1] house, and the day after tomorrow I go on a 2 week trip to Vietnam to give a talk on Debian Pure Blends and generally get involved with local hackers there. A suggestion (if someone else is volunteer to put it in nice words): Mention some of the exciting news happening after the freeze: growth of active members in the team, a bunch of exciting new packages, and finally deciding to generally use dpkg source format 3.0 (quilt). I've added a paragraph on the growth of the team, additions are welcome. -- 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 -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: metapackages
Hi Rosea, [I hope you do not mind if I quote you on a public list but to my understanding nothing in the mail is really private.] For pkg-multimedia list users: Rosea asked on Debian Blends mailing list about problems using blends-dev and seeing that it is multimedia related I think it is reasonable to discuss the issues here (and by doing so) stress the Blends topic a bit more as I did in[1]. On Sat, Oct 30, 2010 at 08:49:52AM +0200, rosea.grammostola wrote: BTW, Could you please be a bit more verbose what you are actually doing (commit your blends source code for further inspection or applying patches)? I'm specifically asking because we could actually need some help in the multimedia issue. I'm currently try to push the Blends technique at the Debian Multimedia team (you find the code at svn://svn.debian.org/svn/blends/projects/multimedia/trunk/debian-multimedia and we are probably able to cooperate. I will try to be a bit more verbose. The metapackages I make are for some kind of personal (commercial) support service I have for people who wants to start with producing music on Linux, mostly Ubuntu. For my understanding there is no real need to keep things like this personal / privately for the purpose of a commercial or Ubuntu use. As Debian is Upstream for Ubuntu and Ubuntu might serve as upstream for your commercial distribution pushing things into upstream might not harm at all. I actually see the Blends effort as a good chance to base commercial applications on these subsets of Debian because it makes things easier even for your business. It is finally your decision but the concept is quite open to this application. But I'm open for collaboration. You are good in making the blends structure and I might be able to help you with the packageslists. I'll look into your code. Just feel free to subscribe a reasonable Debian Multimedia list and I hereby repaetedly urge for a non strict packaging related list (like this) but rather than (miss-)using the pure packaging list. Kind regards Andreas. [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-October/013219.html -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
On Thu, Oct 28, 2010 at 08:34:38PM -0300, Felipe Sateler wrote: Since we need to advertise this list, I think we should do a Bits From our team. I have started a draft in http://wiki.debian.org/DebianMultimedia/BitsFrom, so please add anything you think we should be saying. That's a really good idea. I have enhanced the Blends paragraph a bit. Once this bits are published I probably will unsubscribe the packaging list (so please at least CC me in Blends related subjects) and subscribe rather the general list. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
On Wed, Oct 20, 2010 at 10:12:47PM -0300, Felipe Sateler wrote: Bugreports have been mentioned as an example of inappropriate mails for such list, right? So what is then on-topic? Is it for visions and metadesign - like a multimedia-specific d-project@ ? Or is it more of a d-user-multimedia@ list? I would think of it more of a d-user-multimedia type of list than d-project. In Debian Med we have such a list which is open for user problems. It is a good idea to involve users into discussion about tasks layout. Also the list is a good entry point for future developers who are just seeking a first contact. The main issue is to form a community around the multimedia topic inside Debian. Sometimes you can not predict what mails such a list might see. When we (apparently) lack the time already to do the technical work we would like to, then where should the ressources come from to manage and care for such a list? Or do we simply provide the space and leave the Multimedia users to discuss with themselves? I would try to chip in when possible (it is much easier to answer a quick email than actually do work :p). But I would expect that, if there are multimedia users out there, soon they will start helping each other there. +1 Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
[Quick answere from Hotel in Sevillia] On Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote: I apologise again for having forgotten about this discussion. No problem - thanks for taking action now. potential Multimedia Blend - just agree upon a fieldname (UpstreamDoc comes to mind) and feed it into a debian/upstream-metadata.yaml in each package which provides such information (remember: there is NO need for uploading a package with this information - the file just needs to be in packaging VCS). I find the blends approach much better than the wiki approach. Me too. ;-) Using upstream-metadata.yaml would make sense in any case. In short: The mailing list is de facto free and really using it might be a way to actively be notified about packages which are not yet moved under pkg-multimedia-maintainers maintenance. So far Jonas is (I believe) the only one who opposes this split. I'm in favor, and if we do this we should announce it to devel-announce and -announce so that we can get some users there. What do others think? Whatever we decide: We should announce in any case the result. 2. The name I'm in strong favour of DeMuDi because it is catchy and might be known. This is the name for the blend? If so, I agree cannibalizing the DeMuDi name might be good. Yes. IMHO it was suggested by Free as name for the Blend in a past thread. I wholeheartedly agree with this. I will try to start modifying the tasks (they are a good base). I've added a new task, hopefully others can help too (I think we have too many, maybe we should merge some of them). I'm perfectly fine with any change you might do on the tasks layout. The changes become effect on the tasks pages after the cron run (one per day). I don't really care much about debtags. They are inconsistent, little used and even less policed. While this probably describes the current state I think DebTags are a good idea anyway. If a Blends would be able to help for better DebTags design this would be a good side effect. There is at least one commit that is not by you now :p Great! Thanks for working on this Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
Hi, I'm trying to come back to a thread about a Multimedia Blend which was started in August this year[1]. There was some discussion but no obvios action. Yesterday I was able to do at least a bit of action *I* feel able to do (and I do not feel able for the other parts). I try to remember you hereby to some kind of todo list / somehow agreed upon actions to bring the idea of a Debian Multimedia Blend foreward. On Mon, Aug 23, 2010 at 12:01:30PM +0200, Reinhard Tartler wrote: well spent. In the Blends approach we had done much efforts to maintain lists of packages manually and all of them (explicitely those who were Wiki based) just failed. It takes you much time to create such lists and finally you will fail to keep them up to date. Thus we invented the tasks pages including the long version (see example for Debian Multimedia[1]) which was inspired by Ubuntu Wiki style. If you are missing some information on the tasks pages please make some suggestions what should be added (and how it should display). Well, the most obvious pieces of information missing are a) what version of the package is included in lenny and squeeze, and b) link to the package documentation. The first missing piece of information ( a) versions in Lenny and Squeeze) is solved now (see [2]). I agree that the layout is not nice - it is just a prove that it was quite easy to do (about 15 lines of code). The reason why I did not spend more effort in the layout is: 1) The long list of packages is rarely used by other Blends and Multimedia has not shown enough interest to make me highly motivated to spend more time. 2) It's quite simple to do for anybody, just change the template which is available here[3]. I think a tabular design like Package ShortdescriptionVersion Lenny Version Squeeze Link pkg Homepage translated short desc version-link version-link woul be reasonable. the ubuntu help wiki implements b) by linking to the upstream online user manual or similar if available. As I explained we just need to store this information somehow and as I wrote in my previous response to this mail[4] (which remained unanswered in mail as well as action) the solution I can see for this problem is upstream-metadata.yaml[5]. If the information is *really* important for you and you *really* want it to see it on the packages list of a potential Multimedia Blend - just agree upon a fieldname (UpstreamDoc comes to mind) and feed it into a debian/upstream-metadata.yaml in each package which provides such information (remember: there is NO need for uploading a package with this information - the file just needs to be in packaging VCS). Further problems discussed but unsolved (in no specific order): 1. Mailing list I suggested to use debian-multime...@lists.debian.org as general discussion list (for instance for discussion like this) for a Debian Multimedia Blend and for an entry point of users to talk to the package developers. This list has turned out to be a good success in other Blends. The reason to not to do so was that this list is used as packaging list of DeMudi packages. List Archive of August: 8 mails List Archive of September: 1 SPAM mail List Archive of October: 1 mail In short: The mailing list is de facto free and really using it might be a way to actively be notified about packages which are not yet moved under pkg-multimedia-maintainers maintenance. 2. The name I'm in strong favour of DeMuDi because it is catchy and might be known. 3. The tasks We had also a discussion about reasonable tasks[6]. I hereby want to stress that my proposed task definitions[7] which are rendered here[8] for a better overview are simply a suggestion of an uneducated multimedia outsider. They are probably not very practical - but it is a task for a multimedia expert and it should be *done* (not only discussed). If you ask me, it should be done *before* Squeeze release. Even if we will probably not able to release metapackages (we did not even decided whether we want them at all - see below) - we can mention DeMuDi in the release notes of Squeeze anyway. If not - we are simlpy missing a chance to get attention of a wide public. 4. Metapackages I'm in favour of creating metapackages because they have certain advantages and they at least do not harm. Those who do not like this stuff will not install it - that's fine. 5. Debtags The DebTags technique should be used more heavily in Blends (see for instance [9]). I do not mind what comes first: Designing Debtags for multimedia packages and proper debtagging for *all* relevant packages or defining tasks, putting the packages in and use the tasks pages for enabling proper DebTagging. IMHO the latter approach is more simple and can be easier
Re: Defining interesting multimedia tasks
On Thu, Aug 19, 2010 at 01:18:47AM +0200, Alessio Treglia wrote: On Wed, Aug 18, 2010 at 10:02 PM, Reinhard Tartler siret...@tauware.de wrote: I particularily like https://help.ubuntu.com/community/UbuntuStudio/Applications, which is linked from the PackageList page! We should write a similar page for summarize all available applications. I'm not sure that the time which is needed to write such Wiki pages is well spent. In the Blends approach we had done much efforts to maintain lists of packages manually and all of them (explicitely those who were Wiki based) just failed. It takes you much time to create such lists and finally you will fail to keep them up to date. Thus we invented the tasks pages including the long version (see example for Debian Multimedia[1]) which was inspired by Ubuntu Wiki style. If you are missing some information on the tasks pages please make some suggestions what should be added (and how it should display). Kind regards Andreas. [1] http://blends.alioth.debian.org/multimedia/tasks/packagelist -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Mon, Aug 23, 2010 at 12:01:30PM +0200, Reinhard Tartler wrote: Well, the most obvious pieces of information missing are a) what version of the package is included in lenny and squeeze, and b) link to the package documentation. Do you mean the information is missing on the long list[1] (version information it is there on the detailed list)? What exact Link you have with package documentation in mind? the ubuntu help wiki implements b) by linking to the upstream online user manual or similar if available. The only source of information about upstream in a Debian package is currently the Homepage field. However I see a chance to establish something like you are suggesting if we would add a field to upstream-metadata.yaml[2] of each releavnt package. Charles Plessy and me are currently working on moving this information into Ultimate Debian Database (UDD - the web sentinel page is created from the information in UDD). So if it becomes consensus in Debian Multimedia to use this file we can fix this (no package upload should be needed because Charles has implemented a way to read the file from packaging Vcs). Kind regards Andreas. [1] http://blends.alioth.debian.org/multimedia/tasks/packagelist [2] http://wiki.debian.org/UpstreamMetadata -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: separate discussion and development lists
On Tue, Aug 17, 2010 at 12:08:20PM -0400, Felipe Sateler wrote: debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. I thought this was the idea the whole time? Yes. Every time I think about it, I like it more. I think we should do that. And announce it to the world via d-d-a. In fact announcing this (together with the tasks pages for Debian Multimedia) is a really good idea and I was just intending to make the project more popular this way all the time. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: separate discussion and development lists
On Tue, Aug 17, 2010 at 06:30:11PM +0200, Adrian Knoth wrote: Anyway, make this the place for users and keep pkg-multimedia-maintainers for internal discussion. Also note that we should change the maintainer address in the following packages: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org If we want to make debian-multimedia a place for users anytime soon, we'd probably need to change all those packages upfront, IOW, before we release squeeze. This is actually the wrong move IMHO, because users should NOT be spammed by package maintenance mails. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: several user groups. If there are applications which are useful for more groups just list the application in question for all of them. Interesting. Is there some easy way to query in what tasks a given package is used? I'm just using grep on the tasks files in SVN. IMHO for developers this is OK. Do you have any other purpose in mind? is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? I tried to enable selection of Blends tasks immediately after installation (see bug #186085) but failed. So for the moment you just install the metapackages as any other package with your favourite package management tool. Let's imagine the following depends in the 'multimedia-consumer' metapackage: Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc I guess that if we the user first selects to install an KDE system in tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Yes (but untested). Assuming that an 'LXDE' task does not install any media player and is selected first in the installer, does the 'multimedia-consumer' metapackage only install mplayer and nothing else? Yes (also untested). If I get that correctly, this sounds pretty useful to me! If apt works as I expect it to work than this is exactly the case. Interesting. Just curious, did you have a look at the 'ubuntustudio-meta' source package? http://packages.ubuntu.com/source/lucid/ubuntustudio-meta. I should do this later. It's implementation might be different (it uses germinate), but it seems to me that blends-dev and germinate/ubuntustudio-meta share very similar goals, right? I imagine that we could use that at least as source of inspiration what multimedia tasks would be useful for a DeMuDi Blend. BTW, do Blends provide their own, customized installation media? What about live CDs? We should probably make a FAQ about this. The answer is: There *should* be a script to simplify this but probably it does not exist yet. Somebody has prepared something for Debian Med at svn://svn.debian.org/svn/debian-med/trunk/community/infrastructure/livecd In principle metapackages make the lice CD preparation quite simple by using live-helper but I would be really happy if somebody would write a generalised script + configured hooks which just needs a blend-build-livecd blendname and similar with to build d-i images. It's just a matter of finding the nneded time to do this, but in principle it should not be that hard. For comparison, ubuntustudio-meta in lucid creates these metapackages: $ grep -E ^Package debian/control Package: ubuntustudio-desktop Package: ubuntustudio-audio Package: ubuntustudio-graphics Package: ubuntustudio-audio-plugins Package: ubuntustudio-video Package: ubuntustudio-font-meta So this matches your suggestion pretty closely. Perhaps somebody could browse the list and adapt our tasks. I see. Well, I think we'd first need to get an idea what kinds of configuration options would be interesting for a DeMuDi Blend, but it's great to know that we have a place for this. :-) About what content are you thinking of at this point? Multimedia related packages which are in Ubuntu or debian-multimedia.org but not (yet) in Debian. I guess there are some of them, but I'm not that deeply involved in this field. Thinking further in this direction we could think about adding Debian-Multimedia.org package information to UDD and add this to the tasks page. Well, with the experiences we've made so far from bug reports, I don't think that we can endorse using that archive with good conscience. Well, we are not really *using* this but we are providing information about packages which can be used in principle by our users (they do it anyway). Moreover it saves us some work to maintain the metainformation about potentially interesting packages for our users in the tasks files explicitely. (This probably needs some detailed demonstration and is hard to explain in a short mail.) Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: separate discussion and development lists
On Tue, Aug 17, 2010 at 06:49:58PM +0200, Adrian Knoth wrote: Not sure if we're talking the same: currently, 17 (16 if you count the fixed gigedit package in experimental) contain debian-multime...@lists.debian.org as the maintainer field. If I correctly understand the proposal, then this very address should be used for discussions with users. Hence, to avoid users being spammed by bug reports from the BTS, we need to change the maintainer fields in all those packages to pkg-mmm. Ahh, yes. I perfectly agree here: debian-multime...@lists.debian.org should NOT be used as maintainer field but rather pkg-mmm should. However, I'm not perfectly sure whether we should really push for a move into testing if this is the only problem of the package. Sorry for the confusion I might have caused Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 08:33:45PM +0200, Jonas Smedegaard wrote: At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Not completely right. Blends-dev creates a blend-tasks package which contains a tasksel control file which works with tasksel. I personally did not used this tasksel option because the only use *I* see would be in replacing the default tasks in d-i (or adding them to default tasks). Because this was not accepted by tasksel maintainer I *personally* go with the single metapackages because they allow more fine grained selection (as it was explicitely requested here with alternatives). what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Beware that if *both* KDE *and* multimedia-consumer is selected during same installation routine (e.g. at initial install) then there is no guarantee which media-player, or how many of them, gets installed. That's correct - but we do not have a reasonable way to control this (except with the debconf method I suggested previosely in the thread). Beware that if first installing KDE + multimedia-consumer, and then at a later installation batch installs LXDE, then there is no ensurance (from multimedia-consumer) that any multimedia tools optimal for LXDE gets installed. Even uninstalling and later reinstalling multimedia-consumer does not ensure this. It is (during installation, at least) simply a metapackage! That's correct. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Maintaining tasks files (Was: projectm 2.0.1+dfsg-3 MIGRATED to testing)
Hi, after subscribing this list I now get several e-mails about packages I just don't know which are obviosely relevent for multimedia issues but I just do not feel competent to put into the right task. Apt-cache told me that projectm has for instance a binary package libprojectm-dev which could be added to a (not yet existing) task multimedia-dev which might collect all those packages which are relevant to package multimedia applications (for sure there could be also more fine grained tasks for development issues created). In general I would strongly suggest: Please check out the tasks pages whether they are featuring your package and if not at least drop me a note to what tasks it should be added. Kind regards Andreas. On Thu, Aug 12, 2010 at 04:39:13PM +, Debian testing watch wrote: FYI: The status of the projectm source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 2.0.1+dfsg-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend
On Fri, Aug 13, 2010 at 12:59:57PM +0200, Free Ekanayaka wrote: nice to see you keep pushing Debian Blends :) Free, nice to hear from you again! \o/ Yes, the DeMuDi idea is quite old and eventually evolved in the 64 Studio project, which is more a Debian remix/customization than an official Debian Blend. At some point there was an AGNULA/DeMuDi implementation too, but not 100% Debian either. I still like the name DeMuDi, so if it could be incarnated in some new Blend-based project it would be great :) If you ask me: DeMuDi sounds way cooler than Debian Multimedia (and by the way has the extra advantage that it can not mixed up with debian-multimedia.org which Google tricked me in twice). So I'd be in big favour of DeMuDi (and hope the other way around that this name is not covered by some restrictions which might be remain by the EU-project). However I have not enough time to push for that, so if nothing new comes in, feel free to remove it from the docs. Just tell me if I should update the docs and I will do so. BTW, I have another issue: This mailing list recieves a lot of packaging related information which I#m not really interested in. However, de just have this mailinglist debian-multime...@l.d.o. Do you see a chance that we move discussion like this about general project management, Blends stuff, user oriented questions to this mailing list. I was asked to raise the Blends issue here on this list and so did I, but I would prefer if I would not be spammed by bug reports of multimedia packages which I'm simply not interested in. In other projects such split between user oriented list @l.d.o and a maintainer list @a.l.d.o has turned out as quite reasonable. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend
On Sun, Aug 08, 2010 at 11:50:16AM -0400, Felipe Sateler wrote: As seen on the documentation, there is already a DeMuDi blend. Maybe we can start from there? DeMuDi people were part one of the 2 teams that merged into this one (d-multime...@lists.debian.org). Thanks for reminding me that the doc is a bit outdated. The DeMuDi Blend idea is quite old and Free was involved into this topic but as far as I know there is no existing technicla implementation. I should fix this in the doc (but perhaps I weit with fixing until the discussion here proceeds to some point). This is the part that I find interesting. While maybe metapackages are not what we need now, the basic idea of defining tasks and listing software that might help you with that could be very useful for users. This is what Debian Accessibility and Debian Enterprise are also thinking and it is perfectly fine. Once reasonable tasks are defined and people think metapackages could be builded anyway everything is prepared - but there is no real need to do it. The current infrastructure requires tasks to live in the blends svn repository (to get the nice webpage shown on debconf, for example)? That would imply that interested people need to join the blends project. Am I correct? There is no explicit requirement and for instance Debian Edu uses their own SVN. The location of the tasks file can be defined in svn://svn.debian.org/svn/blends/blends/trunk/webtools/webconf for each project. However I would recommend to keep all the tasks files in one place just to enable easier general modifications in case they are needed. DDs do not really join the blends project to get access permissions because the ACLs of the Blends project grant any Debian developer commit permissions. For guests it is not that easy and I would recommend to subscribe the project. I really like those pages. We just need to polish the tasks files a bit :). Yes, definitely. As I said this was just my uneducated shot on this topic for my on purpose. Feel free to change whatever you think makes sense - I'm keen on learning more about Multimedia by watching your changes. ;-) As mentioned by Reinhardt in the talk, the scope of the team is not clearly established. However, as of now digital imaging seems to be outside of it, and we are more oriented towards audio and video. That's perfectly fine. So I will move any imaging related stuff to some Debian Imaging area which I will keep on maintaining for my own purposes - perhaps some other people will consider this useful and we can start a Blend about this. For the moment it would just blur the Multimeida issue and thus should not be there. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend
[quoting myself in parts] On Mon, Aug 09, 2010 at 12:01:10PM +0200, Andreas Tille wrote: That's perfectly fine. So I will move any imaging related stuff to some Debian Imaging area which I will keep on maintaining for my own purposes This is just done and the imaging stuff is not any more in multimedia. Moreover I added the activity graph of all multimedia related lists to http://blends.alioth.debian.org/multimedia/ If you do not like this - the source for the index file (which you should probably enhance anyway) is at svn://svn.debian.org/svn/blends/blends/trunk/websites/multimedia Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Debian Multimedia Blend
On Mon, Aug 09, 2010 at 09:26:38AM -0400, Felipe Sateler wrote: Probably. So, if there was no actual technical work involved, we'll just start from your definitions. OK. for each project. However I would recommend to keep all the tasks files in one place just to enable easier general modifications in case they are needed. DDs do not really join the blends project to get access permissions because the ACLs of the Blends project grant any Debian developer commit permissions. For guests it is not that easy and I would recommend to subscribe the project. Hmm, OK. I'm good then, what about the rest of the team? Anyone else interested? I see in those files that all that is required is the file to live on the same host, so there not even a need to use SVN (we use git on this team). Am I correct? Ahh, sorry no. The script which creates the Blend web sentinel pages is only parsing SVN (there was no reason to support other VCSs because the only tasks files outside the Blend SVN are as well in SVN). So I would suggest to stick to Blends SVN (or provide a patch which obtains the tasks files from git if you regard it as really important). The Blends stuff turned out to be simple enough to not change the used VCS just for the sake of following the crowd to Git. ;-) That's perfectly fine. So I will move any imaging related stuff to some Debian Imaging area which I will keep on maintaining for my own purposes - perhaps some other people will consider this useful and we can start a Blend about this. For the moment it would just blur the Multimeida issue and thus should not be there. OK I see you already did that. So, all that's left now is to actually do some work! Right, only some work, that's all. ;-)) Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Debian Multimedia Blend
Hi, I'm inspired by the following IRC log to rephrase my mail I recently sended to debian-enterprise list[1]: fsateler :) I'm liking this more and more. I would really appreciate it if you could mail us a short introduction to the mailing list an3as Is this the proper list: pkg-multimedia-maintainers@lists.alioth.debian.org ?? fsateler yes, it is I would like to give an introduction into Debian Pure Blends[2] in the hope that this might be helpful for the Multimedia team. Before I start I would like to mention that I'm a quite uneducated multimedia user - rather somebody who is constantly seeking for the package that might help me in a task I might want to do once per month or so. I started the Debian Med project in 2002 and found a lot of similarities between several user oriented projects (Debian Junior, Debian Edu, Debian Science, Debian Accessibility) to get the idea to technically join those projects via common tools. This effort which is called Debian Pure Blends since 2008 was quite fruitful because each project has developed some technical stuff which somehow turned out to be useful for others as well. My main idea which I outlined at DebConf 7[3] is that we need to introduce a new abstraction level when looking at our package pool: Looking at a single package level you are just lost in the large pool and thus we should rather have a view on package groups which are useful to do certain tasks. This is implemented in so called tasks files which are used as basic source of information in Blends. All currently existing tasks files are in Alioth SVN[4]. The format is described in the Blend doc[2] and also in my talk at MiniDebConf in Berlin[5]. By using the blends-dev package you can easily build metapackages from these tasks files. The so called web sentinel contains user oriented tasks pages which are rendering all interesting information in several languages (as far as there are DDTP translations) including screenshots, popcon, debtags etc. Moreover the tasks pages are featuring calls for action for users who might provide DDTP translations easily (hint: a user visiting a page with packages he is interested in is a potentially better translator than a random volunteer who might not necessarily understand the description text) or screenshots for screenshots.debian.net. Moreover there is a developer oriented bugs overview which lists all bugs of packages which are part of the task in question. Same idea as above: A developer who is interested in a certain task might have a good motivation to keep packages of this task clean. If you are interested in the web sentinel I would recommend to have a look at the entry page at Alioth[6]. Just follow some links to tasks and bugs pages. IMHO the application of these tools for Debian Multimedia makes perfectly sense to make users better aware of all the nice packages inside Debian or rather give them a leading hand to guide them trough the jungle of multimedia software in Debian. At least I feel totally lost there and the issue is not important enough for my work to fight through. Because I felt that lost I just tried the usual thing which worked for me in the past with other topics: Build tasks files and use the web sentinel of Blends to get an overview. The result can be seen here[7]. I personally do not know the scope of Debian Multimedia team - my feeling in the BOF was that it is not really about digital imaging but rather audio and video. If this is the case some of the tasks do not really make sense for you and we should probably split these to some (potential) Debian Imaging Blend to not spoil your main target. As I realised in the talk you are prefering group maintenance and to my great pleasure you even managed to join two existing teams. That's really great, because group maintenance of packages is not mandatory in a Blend but it has turned out to be very convenient and I'm convinced that the web sentinel is suporting this. Currently I'm testing some code which sends weekly reminders to Blends mailing lists about packages of the Blend with newer upstream versions available and which have RC bugs. I intend to implement more of these QA tools always based on the set of packages defined in the tasks files. I have a lot more ideas and hope some are useful for enterprise issues as well that I hope that some people of Debian Multimedia might bring in other ideas (ironed out in code ;-)). Thanks for reading up to this point of the long mail - hope this was the longest one I wrote to this list. Kind regards Andreas. [1] http://lists.debian.org/debian-enterprise/2010/08/msg6.html [2] http://blends.alioth.debian.org/blends [3] http://people.debian.org/~tille/talks/200706_debconf7_cdd/ (unfortunately the video recording is not available from video archive - I pinged video team) [4] svn://svn.debian.org/svn/blends/projects [5] http://people.debian.org/~tille/talks/201006_minidebconf/ [6]
