16:00:34 <edrz> #startmeeting
16:00:34 <MeetBot> Meeting started Tue Jan 12 16:00:34 2010 UTC.  The chair is edrz. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:49 <edrz> #topic debimedia
16:00:59 <siretart`> ok, well, let me first explain the idea of debimedia.
16:01:02 <siretart`> this basic idea of debimedia originated from fabian and me actually.
16:01:05 <siretart`> we basically want to have some dsfg free packages in debian that are (currently) not accepted by debian ftpmaster
16:01:09 <siretart`> but we decided to package them anyway
16:01:13 <siretart`> in order to have them usable for our users, we need to put them in some archive
16:01:26 <siretart`> so I've setup a private vserver with a reprepro instance
16:01:40 <siretart`> it is currently in a state that we can accept sources and builds
16:01:58 <siretart`> but that is clearly not enough for a sustainable service
16:02:15 <siretart`> basically, we ship packages like lame, x264 and so on
16:02:30 <siretart`> most (if not all?) of them have been accepted in ubuntu, btw
16:02:43 <siretart`> are there any specific questions on debimedia from you?
16:03:03 <edrz> where is it?
16:03:33 <siretart`> edrz: currently, it has rather limited content and a single mirror: http://debian.informatik.uni-erlangen.de/debimedia/
16:04:18 <siretart`> IIRC, fsateler wanted to look into buildd&wanna-build, but I guess he didn't find the time to setup something
16:04:21 <adi> If need be, I could provide powerpc and sparc to debimedia, but I guess the amount of affected users is rather limited.
16:04:39 <siretart`> I'm currently considering deploying a private instance of the opensuse build service.
16:04:40 <fabian> we decided to wait making it public (e.g. on d-d-a) until we've got a significant number of packages to offer
16:05:04 <fabian> and until we are sure we can provide proper maintenance for all of them
16:05:09 <siretart`> but I'd need to experiment with OSB a bit first
16:05:12 <xxtjaxx> what about libdvdcss?
16:05:37 <siretart`> setting up soyuz (the launchpad builder) look rather scary to me, but would probably be an alternative
16:05:38 <lool> What's the concept?
16:05:42 <edrz> would this also serve as a better and more compatible alternative to debian-multimedia.org?
16:05:45 <fabian> xxtjaxx: that's problematic, it DFSG-free source-wise, but distributing it may be illegal in some countries
16:05:45 <lool> I mean, what's your vision of debimedia?
16:05:53 <lool> Is it for DDs?  For Debian users?
16:06:00 <siretart`> xxtjaxx: fabian and I agreed to not include it at this time and reconsider it later
16:06:01 <lool> What about other distros or other distributions?
16:06:05 <lool> err users
16:06:06 <fabian> edrz: Yes, that's the main motivation
16:06:17 <siretart`> lool: the vision of debimedia is to ship "the missing bits"
16:06:30 <lool> missing bits of... Debian?  Debian and Ubuntu?  anybody?
16:06:35 <siretart`> free software that is currently not accepted in debian for political reasons
16:06:44 <fabian> lool: It is focussed on Debian, ubuntu already has multiverse
16:06:44 <xxtjaxx> And Would it be possible to install crossplatform compiler and so have builds for those too?
16:07:04 <siretart`> top objective: stay 100% binary compatible with debian. debian-multimedia.org isn't, for example
16:07:05 <lool> Is this hosted in Germany?
16:07:08 <siretart`> lool: yes
16:07:25 <lool> siretart`: You own the server and you are bound to it?
16:07:28 <bdrung> siretart: isn't libdvdcss a political reasons, too?
16:07:38 <siretart`> xxtjaxx: if you volunteer, sure :-)
16:07:38 <xxtjaxx> bdrung: it is actually
16:08:03 <fabian> bdrung: We keep it out for now, it's on the list anyway
16:08:15 <fabian> see http://wiki.debian.org/DebianMultimedia/debimedia
16:08:16 <lool> Who do you envision will upload to debimedia?  A separate set of developers, or all DDs?
16:08:23 <siretart`> lool: for this context, yes, I own the server. technically, it is a lenny openvz instance.
16:08:30 <xxtjaxx> siretart`: I do have a small server that doesnt do much but then again it is having a hard time since its not even 1 GIG of ram nor Hz
16:08:36 <fabian> lool: members of pkg-multimedia
16:08:38 <quadrispro> debomatic would be a good solution for building the packages
16:08:39 <hrickards> What would be the policy for if a package already exists in Debian (I had a similar problem to this with debian multimedia_
16:08:42 <quadrispro> (hello folks!)
16:08:58 <siretart`> xxtjaxx: hardware isn't the problem, manpower to administer and maintain things is.
16:09:07 <lool> So it's basically multiverse for Debian run by pkg-multimedia IIUC
16:09:28 <fabian> hrickards: This is also (hopefully) answered on the wiki page that I sent the link to
16:09:31 <siretart`> lool: not really. multiverse does not require dfsg. debimedia does.
16:09:40 <xxtjaxx> siretart`: In this case the group as in the team of multimedia in Debian is the manpower right?
16:09:41 <fabian> lool: Yes, somewhat like this.
16:09:54 <edrz> so, what is needed is people to volunteer to commit some time to exploring and setting up build options?
16:09:55 <fabian> lool: The official unofficial Debian archive :)
16:10:21 <lool> siretart`: Good point
16:10:25 <hrickards> fabian: Ah yes, I missed that.
16:10:32 <lool> Well this is pretty nice folks
16:10:49 <fabian> edrz: You need access to the pkg-multimedia git repo, so you have to be member of pkg-multimedia, that's pretty much it
16:11:22 <edrz> fabian: no, sorry. i understand that ... i meant to try and summarize what is debimedia needs
16:11:35 <edrz> *what it is that
16:11:44 <siretart`> edrz: debimedia needs 2 things: people maintaining our git branches and infrastructure for autobuilding packages
16:12:07 <siretart`> I hardly manage to keep up our ffmpeg.extra branch, I guess the other branches lag behind as well
16:12:11 <xxtjaxx> So upload is allowed by team members of pkg multimedia. How do we keep the builds/Packages maintained in debimedia in a reasonable shape so they arent as uncompliant as debianmultimedia.org?
16:12:16 <edrz> #info debimedia needs 2 things: people maintaining our git branches and infrastructure for autobuilding packages
16:12:47 <siretart`> we could also need a bugtracking system if we want our users to be able to file bugs
16:12:52 <edrz> autobuilding presumably helps ... but, really it's mostly a matter of the diligence of the packagers, right?
16:13:04 <fabian> xxtjaxx: they are maintained in "extra" branches of the official packages
16:13:07 <xxtjaxx> siretart`: what is the problem with ffmpeg? The ammount of people contributing to it or the fast development/bugs?`
16:13:25 <Fuddl> siretart`: I'd suggest to wait with a BTS until "everything else" is solved
16:13:39 <siretart`> xxtjaxx: are you familiar with the difference between the 'ffmpeg' and 'ffmpeg-extra' source packages?
16:13:40 <hrickards> siretart`: Regarding bug tracking you could go with a project on Launchpad. It seems to work rather well for GetDeb
16:13:58 <xxtjaxx> siretart`: unfortunately not no
16:14:05 <siretart`> hrickards: TBH, I'd very much favor malone (launchpad) over alioth's bugtracker, e.g.
16:14:06 <fabian> hrickards: Should be possible on alioth as well
16:14:22 <siretart`> xxtjaxx: let's discuss this after the meeting please. that goes too far
16:14:29 <xxtjaxx> ok
16:14:58 <siretart`> "my" problem with ffmpeg is that I can only really test the packages on ubuntu
16:15:15 <siretart`> so feedback on my  "debian" builds would really help and encourage me
16:15:25 <xxtjaxx> Should we gather a list from what is reported as multimedia wishes in the BTS to know what people actually want?
16:15:28 <fabian> the biggest challenge for debimedia I see is: getting the archive known to people and convincing them that quality > quantity is a good choice
16:15:36 <siretart`> test as in "functional" tests. I of course do installation tests in chroots
16:15:45 <lool> I'm getting into a similar situation; I use Debian chroots, but it's less than ideal
16:15:59 <lool> However I think we could be more aggressive with testsuite to alleviate the problem
16:16:20 <xxtjaxx> siretart`: no problem I will do some experimenting with it :)
16:16:46 <siretart`> xxtjaxx: excellent. I'll explain the challenges with the ffmpeg package then after the meeting to you.
16:16:58 <edrz> #action xxtjaxx will experiment with ffmpeg
16:17:37 <fabian> another important point before I have to leave: we need to coordinate with debian-multimedia.org and debian-unofficial.org
16:17:55 <lool> aka "politics"
16:17:55 <fabian> else the chaos will be definite
16:18:02 <siretart`> let me try conclude: If someone feels encourage to join the debimedia efford, please do not hesitate to ask me or fabian directly. our goal is to maintain it as subproject of pkg-multimedia.
16:18:17 <edrz> debian-multimedia.org is just one person, though, right? and that has been much of the problem ...
16:18:19 <xxtjaxx> ok
16:18:36 <siretart`> fabian: well, we tried, but that failed. marillat made "fait accompli" without further discussions
16:18:48 <siretart`> I've come to the conclusion that we can do no better than ignoring him
16:19:00 <edrz> #info contact siretart` or fabian if you can contribute to debimedia
16:19:39 <xxtjaxx> siretart`: "fait accompli" means what exactly?
16:19:54 <edrz> #info debimedia aims to be maintained as a subproject of pkg-multimedia
16:19:57 <siretart`> xxtjaxx: "vollendete tatsachen" on german
16:20:04 <edrz> siretart`: fabian anything further on this point?
16:20:07 <hrickards> siretart`: +1 My previous contact with him hasn't exactly been great.
16:20:37 <siretart`> edrz: let's continue, I'd say
16:20:45 <xxtjaxx> +1
16:21:05 <edrz> #topic a/v migrations (eg. pulseaudio)
16:21:30 <edrz> felipe is not here?
16:21:47 <adi> Can't see him.
16:22:04 <siretart`> I'm really not an pulseaudio expert, and it seems that pulseaudio is not maintained by pkg-multimedia
16:22:15 <xxtjaxx> pulseadio in debian? Do we need it?
16:22:25 <adi> PA is maintained by somebody else, that's right.
16:22:32 <siretart`> does anyone volunteer (I obviously do not), to push pulseaudio in debian? as in having it installed by default?
16:22:38 <fabian> edrz: I have been asked, please allow me to answer:
16:22:41 <edrz> i personally don't use it. but, i guess many users might benefit.
16:23:03 <siretart`> I think it is actually already installed and configured by default in current squeeze if you install gnome.
16:23:08 <fabian> Conclusion (debimedia): (1) Please read http://wiki.debian.org/DebianMultimedia/debimedia , (2) please contact me or siretart for questions and if you want to join
16:23:09 <siretart`> but I'm not sure on this
16:23:09 <fabian> thanks
16:23:13 <Fuddl> siretart`: PA only makes sense on desktop installations. it's not that suitable for server installations
16:23:16 <xxtjaxx> Most people I heard about it were rather negative and I myself wasnt actually happy with it
16:23:34 <fabian> I am out, have a nice evening!
16:23:35 <edrz> #info Conclusion (debimedia): (1) Please read http://wiki.debian.org/DebianMultimedia/debimedia , (2) please contact me or siretart for questions and if you want to join
16:23:40 <siretart`> xxtjaxx: AFAIUI gnome upstream requires it nowadays
16:23:52 <adi> Fuddl: You're right, PA is for desktops.
16:24:05 <bdrung> so +1 for GNOME desktops.
16:24:10 <free> hi guys :)
16:24:16 <siretart`> hi free :-)
16:24:17 <xxtjaxx> hi
16:24:18 <bdrung> hi
16:24:21 <adi> I always hated it and switched to PA some months ago. It's a good thing to have.
16:24:30 <siretart`> so, is there anything to discuss at all re. PA in this meeting?
16:24:41 <Fuddl> PA is very useful for desktop systems - especially in cases when a user plugs/unplugs USB sound devices and wants applications to dynamically switch between sound cards
16:24:42 <adi> Make it the default output type for our packages?
16:24:55 <Fuddl> also PA makes use of multichannel playback MUCH easier than ALSA!
16:25:05 <xxtjaxx> Can we ensure that it wouild be stable and working in Debian?
16:25:06 <Fuddl> I'd suggest PA as a must-have for default desktop installations
16:25:13 <adi> Fuddl: ACK.
16:25:16 <siretart`> adi: I think our applications should try PA first, and if it is not available, fallback to alsa
16:25:23 <edrz> adi: can it be easily switched off for people like me who never use it?
16:25:26 <adi> siretart`: Something like this, yes.
16:25:31 <siretart`> at least that is the behavior of mplayer currently
16:25:42 <Fuddl> but AFAIK PA doesn't work well with KDE - I'm no KDE user, maybe someone else knows more about KDE and PA?
16:25:43 <lool> Usually, the default sink in multimedia apps should be something like "auto" or "guess" which should try to connect to pa/jack etc. and end up using alsa if nothing is running
16:25:48 <siretart`> this might need upstream work, though.
16:25:52 <edrz> who is the current maintainer? someone from gnome team?
16:25:56 <adi> edrz: killall -9 pulseaudio. ;)
16:26:06 <free> Fuddl: what else does KDE use? I think arts is dead
16:26:15 <xxtjaxx> yes pulseaudio not nice but I had gnome squeek and scream abit in gnome before
16:26:26 <lool> For instance for gstreamer, the default sink is autoaudiosink
16:26:28 <siretart`> adi: "pactl exit". that'll do as well
16:26:37 <adi> Right, that's the clean way.
16:26:42 <lool> free: KDE uses a wrapper around pulseaudio called phonon
16:26:45 <xxtjaxx> free: phonon and xine
16:26:48 <Fuddl> free: I don't know, I didn't come in touch with KDE for over 10 years ;)
16:27:06 <siretart`> free: AFAIUI, kde uses phonon where applicable, which itself uses either xine or gstreamer
16:27:07 <lool> edrz: Maintainer of pulseaudio?
16:27:10 <free> Fuddl: hehe
16:27:23 <adi> So the minimal consensus could be: "make our packages work on pulseaudio"
16:27:28 <xxtjaxx> lool: phonon is a frontend fro several backends such as xine pa and gstreamer where xine is the actual saint for upstreamers
16:27:29 <free> siretart`: gstreamer looks deprecated
16:27:32 <edrz> lool: yes.
16:27:33 <Fuddl> siretart`: is phonon something comparable to PA?
16:27:36 <edrz> lool: for debian
16:27:36 <lool> A separate team on alioth; I joined at some point but haven't been doing much lately
16:27:50 <siretart`> Fuddl: no, not really
16:28:00 <xxtjaxx> Fuddl: no
16:28:03 <lool> xxtjaxx: Ack
16:28:08 <edrz> well, i guess this boils down to "those who care, should coordinate with the PA maintainers" ?
16:28:58 <edrz> but, i would argue for there being a sane way for those who don't use it to not have to install it ... if that is at all possible.
16:28:59 <siretart`> any objections to the conclusion: "pkg-multimedia should use PA/JACK with fallback to alsa in packages where possible"?
16:29:43 <edrz> siretart`:  by that you mean PA or Jack .... or PA -> jack ?
16:29:47 <adi> siretart`: We could be a little bit more precise here.
16:29:53 <lool> Perhaps Phonon/Pulseaudio/Jack covers KDE better
16:30:00 <adi> siretart`: PA for consumer apps, JACK for pro-audio apps (i.e. making music)
16:30:01 <xxtjaxx> edrz: siretart` Im not quite sure about the stabiliity of PA so better if needed or recommends
16:30:14 <edrz> xxtjaxx: ++
16:30:41 <siretart`> edrz: setting up routing from PA -> jack is not the buisness of applications
16:30:49 <xxtjaxx> and for kde xine as a default please it just works currently very good and is also the blessed one from upstream
16:31:04 <siretart`> that would need coordination between PA and jack maintainers (we happen to be the latter)
16:31:23 <free> we should add at least something in the README indeed
16:31:34 <xxtjaxx> siretart`: who is the PA maintainer?
16:31:54 <edrz> so, "pkg-multimedia should use PA for "consumer" apps and JACK for "pro" apps with fallback to alsa in packages where possible"  ?
16:32:00 <siretart`> xxtjaxx: the pkg-pulseaudio team on alioth
16:32:20 <xxtjaxx> anybody asked them to join?
16:32:22 <adi> edrz: This sounds reasonable to me, but let's see what others think.
16:32:23 * bdrung has to leave now.
16:32:25 <edrz> pkg-pulseaudio-devel@lists.alioth.debian.org
16:32:37 <Fuddl> oh btw. I noticed flaws in Ubuntu and Debian considering pushing PA: a bunch of configuration files should be changed so that applications and especially libraries use PA by default
16:32:51 <edrz> #info PA maintainers are pkg-pulseaudio-devel@lists.alioth.debian.org
16:33:14 <siretart`> Fuddl: kubuntu does not start PA, so this is tricky if you look at specific packages
16:33:15 <xxtjaxx> gnome = PA , KDE=xine ?
16:33:16 <edrz> bdrung: bye
16:33:17 <adi> Fuddl: Yep. This is desktop integration, and we're part of it. Fedora is probably the only distro which got it right.
16:33:32 <Fuddl> siretart`: http://pulseaudio.org/wiki/PerfectSetup came to my mind
16:33:47 <siretart`> xxtjaxx: KDE=phonon, and phonon uses xine by default, but can alternatively use gstreamer as well
16:33:57 <xxtjaxx> right
16:34:13 <lool> xxtjaxx: KDE=Phonon rather?
16:34:22 <edrz> so ... we should probably wrap this point up.
16:34:25 <siretart`> edrz: your conclusion sounds about right to me
16:34:28 <xxtjaxx> siretart`: I ignoreed phonon as it is dep anyway :)
16:34:45 <edrz> #agreed pkg-multimedia should use PA for "consumer" apps and JACK for "pro" apps with fallback to alsa in packages where possible
16:35:17 <edrz> #info kde uses phonon which uses xine by default
16:35:27 <xxtjaxx> thanks
16:35:42 <edrz> #topic Running a beginner's how-to session to aid new members in learning the ropes (via IRC)
16:35:54 <siretart`> perhaps a small intermedia topic (just for your information): I'm currently pushing a discussion involving ftpmaster and the DPL regarding the patent situation
16:36:09 <edrz> #info coordinatin with PA maintainers would be a good thing.
16:36:10 <siretart`> that is btw the reason why mplayer is in NEW for half a year now
16:36:39 <siretart`> no details here, only that this discussion doesn't seem to make much progress lately.
16:37:02 <edrz> #info siretart` is discussing with DPL and ftpmaster wrt patent concerns holding up mplayer in NEW for ages.
16:37:11 <siretart`> if no further questions, I'd suggest to continue with the next topic
16:37:36 <edrz> so.
16:38:09 <edrz> a sort of tutorial session over irc.
16:38:16 <siretart`> ah
16:38:25 <Fuddl> what should this session include?
16:38:27 <siretart`> let's please discuss ffmpeg-snapshot first
16:38:36 <Fuddl> k
16:38:39 <xxtjaxx> Oh tell me
16:38:50 <edrz> #topic ffmpeg packages/ffmpeg-snapshot
16:39:00 <siretart`> okay, the situation with ffmpeg is this:
16:39:05 <siretart`> we are currently stuck with ffmpeg 0.5
16:39:19 <siretart`> this is a mostly upstream unmaintained branch in upstream's svn
16:39:33 <siretart`> mostly unmaintained because it doesn't really see development/backports
16:39:46 <siretart`> I'm going to talk to upstream at fosdem about this
16:39:47 <siretart`> anyway
16:40:05 <siretart`> look raised the question on our list if we could ship a newer upstream version
16:40:08 <siretart`> in experimental
16:40:13 <siretart`> for testing newer codecs, etc.
16:40:28 <siretart`> I prepared a test package and noticed the SONAME bump in libavutil
16:40:46 <siretart`> which caused breakage in our existing package wrt. transitive dependencies
16:41:05 <siretart`> for those who are curious, please readup the thread "upgrade trouble" on ffmpeg-devel@
16:41:10 <siretart`> or ask me afterwards
16:41:38 <xxtjaxx_> siretart`: what version is the freshest one? I only see he 0.5 on the site
16:41:41 <siretart`> in any case, this is a very serious problem which causes very weird segfaults in applications like vlc and mplayer
16:42:00 <siretart`> so I'm currently in the process of getting my symbol versioning patch merged upstream
16:42:12 <edrz> xxtjaxx: ffmpeg generally just don't care to do releases.
16:42:14 <siretart`> I've already prepared packages with that patch in debian/experimental
16:42:27 <siretart`> and just wait for the green light to start that transition in debian
16:42:40 <siretart`> green light from the release team that is
16:43:01 <siretart`> as soon as we have all packages compiled against a symbol versioning enabled ffmpeg, we can start packaging ffmpeg-snapshot in experimental
16:43:03 <siretart`> but not sooner
16:43:11 <edrz> siretart`: are you still discussing with upstream to do a 0.6 release?
16:43:22 <siretart`> lool: I think that should answer all your questions on this :-)
16:43:51 <edrz> or is symbol versioning "good enough"?
16:44:07 <xxtjaxx_> I think we should go per release as snapshot feels fishy to me if I had to install it :(
16:44:09 <siretart`> edrz: TBH, I'm considering proposing myself as release manager for a potential 0.6 release. but only after a) my patch gets accepted upstream, and b) squeeze is released
16:44:18 <siretart`> I don't think it makes much sense for us before that
16:44:23 <lool> siretart`: Yup
16:44:38 <xxtjaxx_> right
16:44:44 <lool> Getting symbol versioning upstream would be lovely
16:44:51 <edrz> xxtjaxx: this is just the way ffmpeg is, though. 0.5 was the first ever release.
16:44:55 <lool> Even better would be a regular release cycle  :-)
16:45:01 <edrz> and they didn't _really_ want to do it.
16:45:11 <edrz> (as i understand it)
16:45:12 <siretart`> edrz: symbol versioning is not only "good enough", IMO it is an absolute requisite to have to proceed any further
16:45:27 <xxtjaxx_> siretart`: right
16:45:42 <siretart`> edrz: no, they've also done releases earlier. 0.5 is not the first release
16:45:49 <edrz> ah. ok. sorry
16:46:12 <siretart`> but they don't maintain any "release". so we'll have to do that work ourselves anyway
16:46:26 <siretart`> I hoped that other distros would stick to ffmpeg 0.5 as well
16:46:38 <siretart`> but it seems that other distros switched to trunk as well
16:47:01 <xxtjaxx_> so everybody else except us does snapshots?
16:47:03 <siretart`> lool: one thing that we could discuss is if we want to track ffmpeg trunk, or astrange 'ffmpeg-mt' branch in experimental
16:47:11 <siretart`> xxtjaxx_: essentially, yes.
16:47:32 <siretart`> xxtjaxx_: gstreamer0.10-ffmpeg sticks with 0.5, though.
16:47:59 <lool> siretart`: mt?
16:48:06 <siretart`> lool: as in multithreaded
16:48:09 <edrz> before 0.5 debian also had snapshots, right?
16:48:18 <siretart`> edrz: yes. and it was hell.
16:48:45 <xxtjaxx_> if trunk is stable each time we snapshot it I think it is ok. But to my mind snapshots and trunks tend to be quite unstable and dangporouse to people usually going from major distro release to distro release
16:49:05 <siretart`> edrz: the problem was that many other packages included internal copies of ffmpeg, and used the headers from the internal copy but where dynamically linked against the system ffmpeg. -> pure pain
16:49:32 <edrz> siretart`: yes. i've experienced some of that pain from the user side.
16:49:32 <lool> siretart`: No strong opinion on trunk vs mt; ideally this would make it to a release first
16:49:51 <siretart`> xxtjaxx_: the problem is that we cannot update the package in a debian stable release either. so any snapshot will get outdated.
16:50:25 <siretart`> lool: ideally, astrange's patch will finally be merged. but that's a long discussion that not really belongs here...
16:50:38 <lool> Ack
16:50:49 <xxtjaxx_> siretart`: would it make sense to go with long terms of snapshots and as time passes test and stabilize them if patches for found bugs appear?
16:50:55 <edrz> so: 1) symbol versioning patch needs to be accepted upstream 2) we try to get a new snapshot in for squeeze (coordinating with release managers) 3) siretart` becomes ffmpeg upstream release manager ?
16:51:11 <siretart`> okay, then let's first shoot at ffmpeg trunk, I'd say, and see how well it works out
16:51:18 <siretart`> we can then still consider ffmpeg-mt
16:51:42 <edrz> what is that, again?
16:51:43 <siretart`> edrz: please don't mention 3) in the minutes :-)
16:51:51 <edrz> siretart`: ack :)
16:51:52 <xxtjaxx_> siretart`: would you recommend testing trunks of ffmpeg in a vbox or on an actual system?
16:52:12 <siretart`> xxtjaxx_: excellent question. I don't have a definitive answer on that
16:52:49 <edrz> #info  1) symbol versioning patch needs to be accepted upstream 2) we try to get a new snapshot in for squeeze (coordinating with release managers)
16:53:02 <xxtjaxx_> I am ready to test and help but if that means shooting myself in the foot...
16:53:07 <siretart`> xxtjaxx_: as for maintaining, I guess you did notice the considerable patchset in our package? ;-)
16:53:21 <xxtjaxx_> didnt have a look yet
16:53:47 <siretart`> I'll talk to the current ffmpeg 0.5 at fosdem about that as well, and how to proceed here
16:53:51 <edrz> xxtjaxx_: just shoot yourself in the foot first, then the added pain won't be so noticeable.
16:54:17 <edrz> so, anything further I should note for the minutes on this?
16:54:20 <xxtjaxx_> Btw I would love a link to the git repositories web view on the alioth page
16:54:32 <edrz> otherwise, we should wrap up soon.
16:54:33 <siretart`> xxtjaxx_: feel free :-)
16:54:46 <siretart`> edrz: I have nothing to add to the current topic
16:55:20 <edrz> #topic postponed to next meeting: Running a beginner's how-to session to aid new members in learning the ropes (via IRC)
16:55:26 <edrz> #topic next meeting
16:55:44 <free> edrz: I'd have a last minute topic
16:55:44 <xxtjaxx_> siretart`: edrz could we first try the ffmpeg part on debimedia first??
16:55:52 <siretart`> xxtjaxx_: I think we should work out some testing guidelines in form of a README.testing in the ffmpeg-snapshot package.
16:55:59 <free> how we could help Ubuntu to get jack into main
16:56:05 <free> lool: ^^^
16:56:16 <edrz> free: what's the problem?
16:56:17 <siretart`> free: what's the current blocker for jack? I see there is already a MIR filed
16:56:35 <lool> free: There's an open bug on that I think
16:56:44 <free> I'm not sure, but I'd like confirmation that everything is good
16:57:08 <adi> Last time, there was an open ffado bug (closed in 2.0.0-1) and freebob being unmaintained upstream.
16:57:16 <edrz> #idea new ffmpeg-trunk perhaps on debimedia
16:57:17 <free> yeah
16:57:20 <lool> https://bugs.launchpad.net/ubuntu/+source/libffado/+bug/416778
16:57:23 <lool> So that's ready
16:57:30 <lool> The next step is to MIR jack itself
16:57:34 <free> lool: do you think we can see this happen in lucid?
16:57:35 <edrz> #topic jack in ubuntu main
16:57:37 <xxtjaxx_> edrz: thanks
16:57:44 <lool> free: It depends on the rationale
16:57:51 <free> okay
16:57:52 <siretart`> xxtjaxx_: I'd rather not have ffmpeg-snapshot in debimedia
16:57:59 <edrz> (btw, anyone can add #idea's to the minutes)
16:58:02 <lool> free: What's the rationale for having it in main, who will maintain it, which builds will use it etc.
16:58:18 <lool> free: If the software is good enough and commitment strong enough, it can happen in lucid absolutely
16:58:26 <siretart`> #idea siretart is against having ffmpeg-snapshot on debimedia
16:58:31 <free> lool: fine, anyway that's all sorted on the Debian side
16:58:46 <lool> siretart`: Yeah, this seems orthogonal to the goals of debimedia to me
16:58:47 <xxtjaxx_> siretart`: why danger?
16:59:13 <siretart`> free: perhaps jack's MIR needs 'just' further pings on the MIR bug? who's driving this efford currently?
16:59:38 <free> siretart`: no idea, maybe there's nobody pushing hard for it
16:59:50 <xxtjaxx_> lool: siretart` it is a missing bit if we keep 0.5 in squeeze
16:59:51 <siretart`> xxtjaxx_: ffmpeg-snapshot would be highly experimental. I'd prefer debimedia to be a usable add-on repository
16:59:57 <adi> The pulseaudio-module-jack could pull jackd into main, if this is still an open question.
17:00:05 <xxtjaxx_> siretart`: ah right
17:00:13 <siretart`> xxtjaxx_: I plan to stick with 0.5 for squeeze
17:00:28 <siretart`> adi: so could xine, or alsa, I think
17:00:33 <siretart`> s/or/and/
17:00:42 <lool> I dont see any jack MIR bug though
17:00:47 <xxtjaxx_> siretart`: if there is no other choice given by the devs no problem
17:01:01 <siretart`> free: perhaps the main blocker is that there is no driver at all?
17:01:11 <free> siretart`: seems likely
17:01:28 <lool> There are pointers to disucssions in the bug I mentionned earlier
17:01:36 <siretart`> xxtjaxx_: there is of course another choice, but I don't want to take the responsibility for that :-). at least not alone.
17:01:53 <lool> The main rationale IIRC is that apps in main aren't jack enabled because it's not in main and this means jack support isn't too good in these apps
17:02:09 <edrz> so. we've just stepped over the 1 hour point.
17:02:25 <siretart`> last point: next meeting :-)
17:02:36 <lool> I dont think there is any blocker to the jack inclusion which needs to be discussed there; the next steps are just the usual ones
17:02:39 <edrz> #topic next meeting
17:02:41 <xxtjaxx_> lool: why is jack not in main?
17:02:57 <lool> xxtjaxx_: We just discussed this  :)  check the backlog and the libfaado bug
17:03:10 <xxtjaxx_> ah sorry
17:03:11 <free> okay, we've fall off-topic now I think, this is Ubuntu-specific
17:03:14 * siretart` suggests in about 4 weeks
17:03:25 <free> let's talk about the next meeting and possibly catch up later
17:03:26 <lool> edrz: Monthly might be a good idea; depends if we have a lot of topics
17:03:43 <xxtjaxx_> yep
17:03:52 <lool> free: The jack main inclusion was Ubuntu specific yes
17:03:55 <edrz> ok. i'll set up another doodle poll for 4 weeks from now. this time just monday-friday for one week.
17:04:04 <adi> ++
17:04:13 <siretart`> edrz: indeed. how about calendar week 7?
17:04:16 <xxtjaxx_> ++
17:04:25 <edrz> #action edrz will create next meeting poll
17:04:52 <edrz> siretart`: so 8-12 Feb?
17:05:01 <siretart`> yes
17:05:04 <xxtjaxx_> fine for me
17:05:07 <edrz> good enough.
17:05:14 <edrz> #endmeeting