Started at --> 19:07:09 jpr: welcome to the GNOME openSUSE meeting! jpr: today includes one of our continuing series of theme meetings jpr: with the topic being multimedia ** munkii is dancing, rather awkwardly jpr: and all that patent encumbered goodness that comes along with it jpr: so with out further ado..

Started at --> 19:08:39 jpr: abock, author of banshee is hear to day jpr: to discuss multimedia in 10.3, 11.0 and answer your questions munkii: hello abock ** abock waves suseROCKs: Welcome Abock! abock: morning all jpr: abock: if you could give a little background on yourself and then dive into an overview of the current 10.3/11.0 state and plans srag: hey abock jpr: that would be great abock: sure abock: So about 3 years and some odd months ago I started this little project called Remix, in C, which turned into Sonance, a 2 day rewrite of Remix in C# abock: and then about 3 years ago, I started hacking on it full time ala Novell under a great new name abock: Banshee abock: and the goal of course is world domination of some sort munkii: sweet! abock: GNOME was missing a really solid, well polished, integrated media player at the time abock: this being around GNOME 2.12 abock: Rhythmbox was pretty much the only thing out there abock: and frankly, it was pretty bad at the time abock: they have improved, but we still rock more, and I love debating that, so if you have questions or hecklings, please object abock: now, along the way with Banshee, we found that a number of things in our platform needed working on to bring the media player we wanted into reality munkii: lyrics support? :( abock: there is a great lyrics plugin, I'll post a link in a bit abock: ...we needed libraries for supporting the iPod munkii: yep, more plugins abock: ...we needed good hardware support, HAL was really starting to take off abock: but there was a good deal of work that needed doing there, and in gnome-volume-manager, etc. abock: just small projects that needed working on in GNOME to make the media player and other applications feel more integrated and automatic (i.e. plug in a camera or an iPod, it works, no manual mounting, configuration, etc.) abock: so we ended up with a handful of new libraries that are like subprojects of the "umbrella" banshee project abock: libipoddevice, ipod-sharp, entagged-sharp, taglib-sharp, etc. abock: anyway, that's all probably boring abock: so my point is that we couldn't just start writing the app, we needed a lot of the underlying infrastructure first, which hadn't existed before abock: and snorp would like me to point out that he technically started ipod-sharp before banshee, but we really forced him to work on it and bend to our needs snorp: :) abock: so, I think talking about tomorrow is more interesting abock: any questions so far? munkii: does suggestions count? abock: suggestions? suseROCKs: Is it true that the more current ipods have been locked out from Apple and don't work on non-iTunes software? abock: very true suseROCKs: So I shouldn't upgrade my iPod then. abock: supporting the ipod is a horrendous task abock: and apple regularly changes file formats which have to be reverse engineered regularly munkii: *cou-assholes-gh" abock: september 07 was a particularly bad release snorp: suseROCKs: currently everything except iPhone and Touch work, but I suggest not messing with yours if it already works :) FunkyPenguin: what about supporting devices like the creative zen family? abock: because they introduced a hashing mechanism that was meant to officially lock out third party clients btimothy: how much PR work has been done with Apple to have them be more cooperative? abock: since it involved a shared key that only the iPod and iTunes knew abock: it was reversed in 2 days snorp: not by us, btw :) snorp: (although we still had to implement it) abock: am looking for the beautiful file mw: how legal is that reverse engineering in us jurisdictions? snorp: heh suseROCKs: Don't ask, don't tell! :-) abock: yes, it was an interesting collaborative effort mainly between some great guys in the gpod project and someone from winamp I believe munkii: mw: the question should be "who cares?" mw: munkii: it should be, but it isn't snorp: mw: given that it only gives you access to your own data snorp: mw: I believe it is legal abock: I think it's legally okay, but there are some shades of gray, and I'm not a lawyer snorp: mw: it's not like DeCSS or anything suseROCKs: Are other products better supported than modern iPods? Like (gasp) Zune, etc.? abock: it's not DRM, it doesn't give you access to actual content snorp: right mw: nod abock: we're just interoping with an index file FunkyPenguin: abock: is device support solely the app's concern or is it something different? abock: device support comes into play in a number of levels snorp: abock: get back to the future abock: kernel, udev, HAL, mount daemon if necessary, libraries, application abock: so yes, the future abock: about 6 months ago, we started _rewriting_ banshee abock: now, it's not a complete rewrite - we have tons of great code that we're not throwing away abock: but one of the big problems with banshee historically has been performance and memory usage munkii: abock, is it released yet? abock: the release, no abock: er, rewrite abock: the main culprit for our bad reputation abock: was the fact that at the time I started writing Banshee, there weren't many options for efficiently using the GtkTreeView in Mono abock: the Gtk# binding did not support GInterface, so it was not possible, at least in any sort of maintainable and reasonable way, to write a custom data model for the tree view abock: which meant we had to load your entire database into a GtkListStore ahead of time, on startup abock: this leads to slow performance, degrading linearly with the number of songs in your library abock: er, slow startup munkii: does that mean we will have an integrated file browser like in amarok? abock: it means switching sources is equally slow abock: and everything has to be held in memory munkii: if not, sorry for not knowing what "TreeView" is abock: the TreeView is the widget in GTK that shows your track list rodrigo_: munkii: TreeView is a GTK widget munkii: ah abock: so I started writing a new list widget, one which would accept proper data models abock: which would allow us to load only the tracks into memory that were actually visible in the view or referenced elsewhere in the app (i.e. the playing track) abock: so we have most of the new model/view stuff done today in trunk abock: I posted numbers about 6 months ago munkii: so, performance advantage? abock: for the performance/memory gain abock: *huge* performance gain munkii: COOL! abock: and a substantial memory gain abock: the new model/view scales to hundreds of thousands of songs abock: searching is instantaneous abock: sorting is as well abock: though of course sorting is naturally a more complex operation, so it's inherently a bit slower abock: but it's still faster than the old one, by an order of magnitude FunkyPenguin: will it stop creating a 'Music' folder when you specify location for media? munkii: so, will this available in 11.0, could we checkout from cvs? munkii: FunkyPenguin: second that abock: ok, that's fixed, it was a bug abock: so these numbers are a bit old abock: but it may give you an idea of the performance gain abock: on a 25k song database abock: old banshee would take 32 seconds to start and consume 81MB RSS abock: and those numbers grow when your track count grows munkii: abock: bestest news ever ;) abock: and the new banshee abock: takes 0.8 seconds to start, and consumes 8.5 MB RSS abock: and those numbers are constant, regardless of the size of your collection srinidhi: woah!! abock: now again, those are a bit dated abock: and were more a measure of the model/view itself and not the entire application abock: the reality is that with other extensions and features enabled, those numbers are going to be higher abock: but they will still be constant abock: and startup speed doesn't suffer much either abock: today, banshee in trunk is faster and consumes less memory than rhythmbox or amarok abock: oh, and banshee runs on mono ;) suseROCKs: Is this in Factory for Alpha testing now? abock: no abock: svn only sontek: so is that gtkwidget you wrote a fully managed solution? suseROCKs: ok abock: I'll get to opensuse/planning in a bit munkii: abock, can you provide a link so we can grab it? abock: yes, the new model and view is completely managed code abock: I'll provide some links towards the end munkii: thanks ^_^ abock: so some other things you'll see in the new banshee.... abock: incredible searching support abock: our new search infrastructure supports advanced (or simple!) queries abock: maps directly to our sqlite database, so search is extremely efficient abock: and also is Xesam compliant abock: we are working with the Xesam guys on actually driving that spec and implementing a managed reference library for Xesam abock: this is a spec describing the user-query language that banshee in trunk supports today abock: http://banshee-project.org/OnePointEx/Search abock: and here's more info on Xesam itself abock: http://xesam.org/main abock: one of the interesting things we will get out of this is that smart playlists and user search queries are essentially the same thing abock: smart playlists will become Xesam XML stored queries abock: so our smart playlist and search features are unified in trunk abock: now, some user-visible, really fun things you'll see in trunk abock: the new album/artist browser munkii: abock, will banshee finally write metadata to files? abock: which can be positioned to the left or on top of the track list, or hidden completely abock: banshee has been able to write metadata to files for years abock: (about 2) abock: and also a playback queue/track mixer abock: that will allow you to add tracks to the queue from various sources and playback will only happen from the queue abock: this allows you to switch sources while playing and not have playback interrupted munkii: abock: hmm.. usually metadata are different on other mediaplayers abock: the playback queue didn't exist earlier because it was very difficult to do due to our dependency on the GtkTreeView/old model abock: ok, let's discuss that later munkii: ok :) abock: so those are the big features/improvements for banshee trunk abock: there will be more, but those are the big ones we have almost done now and will be in the first release abock: and speaking of release.... abock: we are trying to get a first release of trunk out by the end of february rodrigo_: are there any plans for supporting videos and other ipod goodies? if not, people end up using 2 apps for accessing the ipod's abock: which will find itself almost immediately pushed into factory abock: we are investigating video, but we are not ready to make a commitment on it yet abock: and "other ipod goodies?" suseROCKs: metadata (such as lyrics) will be seen on the device if sent through Banshee as well? rodrigo_: abock: ipod's support conctacts, calendar, notes, etc rodrigo_: not sure if that fits banshee though abock: rodrigo_: we're not too keen on supporting those features rodrigo_: but I wonder what to do when a user wants to add all that stuff to his ipod ** suseROCKs votes for tomboy synchronization with Banshee to iPod snorp: suseROCKs: yeah, that would be very easy to do too rodrigo_: he would need to use banshee for videos/music, f-spot for photos, etc jpr: abock: would you see Conduit as an avenue to do that? abock: possibly snorp: ugh ** snorp is not a fan abock: for a lot of those features (notes, contacts), there's really nothing ipod specific about them abock: you just have to drop files in the right place jpr: snorp: Conduit rocks! abock: so using conduit for those might be an answer suseROCKs: snorp... your response, in response to my lyrics question or tomboy question? snorp: jpr: I am not convinced snorp: suseROCKs: tomboy abock: or an 'export to iPod' extension in tomboy snorp: jpr: but it was a long time ago when I tried it jpr: snorp: try it out in factory snorp: jpr: ok suseROCKs: That would be an awesome integration! abock: snorp: yeah, stop whining snorp: haha snorp: jpr: can I install it on 10.3 at all? srinidhi: abock: in trunk, would it be possible to play songs without importing them? ** snorp is not bleeding edge jpr: snorp: yes munkii: snorp: it's really great, although have lost full support to tomboy since version 9.x snorp: cool btimothy: conduit +1! abock: oh, one thing I forgot... and this is available in banshee stable (what's in factory now) and from the build service for openSUSE 10.2 and 10.3... abock: Banshee now has a last.fm streaming plugin written by Gabriel Burt abock: who is apparently still sleeping and should be here with me munkii: abock, i use it ^_^ jpr: need to wrap up in < 10 inutes abock: ok jpr: abock: can you cover codec issues and opensuse 11.0 plans? abock: so munkii: abock: can you give us the trunk url now? abock: yeah, my next/last section is on packages/libraries/codecs abock: so in opensuse 10.3, I hastily wrote the opensuse-codecs-installer abock: which is a library conforming to the gstreamer codecs installation spec snorp: jpr: There are no installable providers of (any)python-gdataAny for conduit-0.3.4-9[factory] abock: that allows gstreamer applications to request installation of codecs in a distro agnostic way snorp: jpr: booo! abock: the problem is that in opensuse, we have no means of providing codecs to users munkii: abock, also we need a banshee plugin for xulrunner abock: or at least we didn't in 10.3 abock: we had no packages in the build service or otherwise mw: snorp: crap, i thought that had been fixe mw: d snorp: mw: fail! abock: so I had the codecs installer go off to a web site and at least provide some more information on how to get the codecs for 10.3 jpr: snorp: maw's home project abock: what I would like to see snorp: ah hub: I use packman, but it is tedious abock: yeah, packman is a horrible alternative for codecs ** snorp installs from home:maw ** munkii doesn't use packman anymore abock: mainly because it uproots your system gstreamer entirely if you try to install -bad or -ugly, where the problematic codecs live snorp: hub: yeah, it is abock: what I would like to see in the BS abock: is some policy allowing us to package patent encumbered codecs snorp: hub: and once you add packman you get a bunch of other stuff that you may not want abock: that would allow us to package -ugly and -bad abock: I'm not sure exactly how it would work hub: snorp: agree with you. I just deal with it abock: but then at least we could leverage package management to actually *install* codecs snorp: hub: yeah hub: abock: who would provide the packages? abock: so we have most of the infrastructure to make this happen abock: it's really a policy problem abock: and I'm not quite sure how to solve it abock: hub: no idea abock: and maybe it doesn't have to be the BS abock: maybe it can be something like pacman that supports *our* packages hub: abock: I was thinking of that alternative abock: the problem with packman is that it wants to install its packages abock: and by "its" I mean abock: if you install gstreamer010-plugins-uglu.packman (or whatever it is) hub: ubuntu use multiverse. why not doing a multiverse repository that novell has nothing to do with abock: it will try to install its own gstreamer010-plugins-base.packman, etc. abock: which breaks your entire system abock: hub: well that's what I mean hub: abock: it works. but again it is tricky (packman) hub: therefor not for end users hub: it did suck on 10.2 though hub: because of the prefix they used abock: anyway hub: (or WE used) abock: well we're not using 10.2 hub: yeah I know abock: so I guess that's all I have hub: SLED still an issue though hub: SLED 10 abock: no abock: links... abock: svn co svn://svn.gnome.org/svn/banshee/trunk/banshee munkii: yes please abock: that'll checkout banshee trunk, you will need some other dependencies, probably from svn at this time abock: I will write up a page on our wiki with detailed instructions on running trunk against 10.3 abock: that's probably the better thing to do for now srinidhi: abock: yeah.. was waiting for you to come to this section.. need build steps for trunk.. :) srinidhi: oh okay munkii: abock: can we get the plugins from trunk too? snorp: jpr: ok, so I have conduit snorp: jpr: the UI seems nice jpr: snorp: after the meeting :-) abock: mind you, trunk is still in the process of being rewritten and it's nowhere near as functional as stable banshee snorp: oh, indeed, apologies abock: don't expect to run trunk and have it replace your regular banshee right now jpr: ok jpr: we need to wrap up unfortunately abock: but you will get a good idea of what we're doing, you can see the browser, search, performance, etc. jpr: we have a whole meeting to do :-) abock: yeah, I'm done jpr: abock: any last thoughts? abock: heh srinidhi: abock: I understand and have failed to run it a couple of months back too.. :) abock: sorry! suseROCKs: Thanks abock and snorp. I'm certainly looking forward to testing it out when it comes out in Factory. jpr: that was really, really good jpr: thanks abock miguel: I missed it1 abock: any time, any time snorp: wooo abock miguel: do you guys have logs?

Started at --> 19:54:33 rodrigo_: yeah, very good :-) jpr: mw, hpj, sreeves : updates on factory testing? munkii: miguel, yep sreeves: miguel: logs will be posted right after the meeting suseROCKs: FYI: hpj will not be present at today's meeting. mw: i've started updating all of gnome again. parts of it are still in a broken state, unfortunately mw: but we're finding and fixing those problems as we go miguel: thanks jpr: mw: do you think after we get a full 2.21.x update in we'll be better going forward? jpr: sreeves: any updates? jpr: hpj: progress on the work around page? mw: yes sreeves: so factory updating is kind of hit and miss right now - if you are updating via the online repos you will run into the banshee - mono conflict suseROCKs: I had that last night sreeves: you can work around it though and a fix should be coming shortly jpr: sreeves: whats the work around? btimothy: sreeves: and is it published on the wiki? rodrigo_: ujpdating via yast->software management seems to work better rodrigo_: at least you can disable packages as they fail updating sreeves: manually messing with the dependencies unfortuanately sreeves: btimothy: no no steps, this should hopefully be short term sreeves: if you are installing in a vm be aware that you will get X crashes jpr: i think we should post even the short term work arounds sreeves: see https://bugzilla.novell.com/show_bug.cgi?id=353489 bugbot: openSUSE bug 353489 in openSUSE 11.0 (X.Org) "vmware: gdm crashes Xserver on startup" [Critical,Resolved: fixed] sreeves: there is a fix and it should hit factory soon btimothy: jpr: +1. I think whoever's watching factory ought to be able to see the latest and hot issues claes: In virtualbox then? Does that work better? btimothy: ...so they ought to be recorded sreeves: one page that might be useful to check is http://en.opensuse.org/Factory/News jpr: anything else on factory testing right now? jpr: i think hpj was going to drive more of the factory testing for us sreeves: they list the major packages that are updated and links to roll back if needed jpr: AI: hpj and sreeves post factory work arounds suseROCKs: I tested the new GDM with hpj last night. looks pretty good so far. suseROCKs: also when I did zypper dup last night, I got conflicts for banshee, tomboy and splashy. (Not sure what splashy is) munkii: yum suseROCKs: what are you eating, munkii? sreeves: yeah thats the last thing, hpj is evaluating whether to put in the new gdm munkii: suseROCKs: "I tested the new GDM with hpj last night. looks pretty good so far." sreeves: so if you can test http://hpjansson.org/temp/ and let him know your results that would be good sreeves: thats it jpr: great, thanks

Started at --> 20:02:55 suseROCKs: guys don't forget to add to 11.0/testing page for tests jpr: rodrigo_, btimothy : little introduction or update? btimothy: okay, so rodrigo and i have started a "lived-in project" btimothy: if you look at: http://en.opensuse.org/GNOME/Projects/Lived_in_Project btimothy: you'll see that we're basically going to "live" in another linux desktop distro for a full month btimothy: and the main purpose of doing so is ... btimothy: to see the cool things that other distros are doing btimothy: so we might be able to brainstorm and pick up some ideas btimothy: and make openSUSE better btimothy: we're trying to focus on their positives and not have it turn into a bashing of other distros btimothy: we're each keeping notes/screenshots/ideas on the wiki btimothy: others are welcome to join us w/ other distros not listed btimothy: and we're open to suggestions ;) ** FunkyPenguin installs foresight suseROCKs: AlbertoP last night suggested that one of the live-ins should be openSUSE/KDE. btimothy: and btw, i really really miss openSUSE on my desktop! ;) rodrigo_: and with other OS'es, if I may suggest it :-) rodrigo_: suseROCKs: yeah, good idea, you volunteer? :) btimothy: suseROCKs: excellent point! (kde) suseROCKs: sheesh rodrigo_, don't shoot the messenger! :-) btimothy: we haven't been very vocal abt. this project jpr: it would be good for volunteers to try Mandrake, Foresight linux btimothy: we weren't sure if it would be too controversial, but we could send a mail out to the mailing list asking for other volunteers for the opensuse KDE stuff jpr: whatever btimothy: ...someone who's primary desktop has been GNOME forever jpr: one note about KDE jpr: we can't steal patches for GNOME :-) jpr: like we can with the other distros rodrigo_: but we can steal ideas btimothy: exactly rodrigo_: that's why I suggest looking also for other os's btimothy: so far, one of the hottest topics seems to be package management and updates ** jpr votes for not expanding the scope too drastically in the short term rodrigo_: yeah, it's mainly what differentiates the distros suseROCKs: I guess its also a good idea because it helps us to strengthen our abilities to evangelize openSUSE munkii: good artists copy, great artists steal mw: (sublime artists assassinate their competition) FunkyPenguin: from my experience of kde one thing i really liked was the seamless integration of its apps - it seemed to gel better than gnome apps btimothy: besides my terrible ATI graphics card (i still can't get it to work right in fedora), everything is mostly all GNOME, so there's not a lot of differences rodrigo_: FunkyPenguin: we need screenshots on the livedin wiki page :-) suseROCKs: one question though... suseROCKs: Do we really want to make this such a public project? People who see the page may misunderstand and assume we're in favor of other distros. suseROCKs: maybe it should just be a very quiet team project. btimothy: ...hence the hopefully clear statement about what/why/when FunkyPenguin: ok, i'm just installing it now on what should be my 11.0 machine (i cant seem to get 11.0 to install) rodrigo_: maybe jpr: btimothy, rodrigo_ : anything else to add? btimothy: suseROCKs: i don't feel like there's really much to hide rodrigo_: no

Started at --> 20:10:59 jpr: suseROCKs: go man go btimothy: i think it's pretty obvious that this stuff happens ... everyone looks at each other's distro suseROCKs: ok folks... hopefully you're updating your task status suseROCKs: if not please go to RTM and update your status jpr: suseROCKs: any particular tasks you want to raise here? ** rodrigo_ updates suseROCKs: Due today, btimothy, jpr, rodrigo_, and oops me. suseROCKs: for jpr, you have a task due today for 10.3 updates. How's that coming along? jpr: not so good :-/ jpr: i really need to prioritize or delegate it :-/ suseROCKs: just send some veal and we'll pretend not to notice :-) suseROCKs: btimothy have you found anything about mail notifications for the wiki? munkii: actually, i have a question about this task suseROCKs: and rodrigo_ any plans for the Patch Review Day? btimothy: suseROCKs: i'm embarrassed to admit that i haven't spent time doing that at all... btimothy: and i unassigned myself rodrigo_: yeah, was going to talk in the dev section about it ** btimothy runs and hides suseROCKs: btimothy feels different being on the other end of the whip, eh? :-) btimothy: suseROCKs: ouch! btimothy: :) suseROCKs: munkii what's your question? munkii: we are already getting wiki updates through mail, what is this task supposed to do about it? btimothy: munkii: you are? munkii: yes btimothy: munkii: i haven't been btimothy: munkii: maybe you and me need to talk offline (after the meeting) munkii: have you tried ot set it from your profile? btimothy: munkii: of course, yes. :) ** suseROCKs shifts the task to munkii and asks him to outline to the group perhaps in an email later. jpr: ok munkii: um, ok btimothy: munkii: perhaps you could mail the group about how to set it up to work properly? suseROCKs: are there any upcoming tasks that people are having difficulty with? munkii: sure, if it's not too obvious

Started at --> 20:16:57 jpr: oops, sorry suseROCKs jpr: finish up suseROCKs: jpr its okay :-) I think no one will add anything ... so take it away! jpr: questions? suseROCKs: I actually have none this morning.. hmm... Most likely I'll think of a question when you guys are feet deep in some project :-) munkii: yes, we need to have mozplugger by default srinidhi: banshee: in trunk, would it be possible to play songs without importing them? munkii: it integrates nicely with all gnome apps suseROCKs: what's mozplugger's function? munkii: suseROCKs: just a second let me get you a link jpr: abock: i think srinidhi 's question is for you munkii: http://mozplugger.mozdev.org/ abock: srinidhi: no, not right now, that functionality hasn't been ported over from stable ** srinidhi had already asked it.. :) abock: I am working on the wiki page explaining all about trunk, what to expect, etc. jpr: wolfiR: don't know what your thoughts are on mozplugger abock: give me an hour ;) srinidhi: abock: oh its available in stable? srinidhi: abock: cool.. jpr: other questions? munkii: it can make you view any kind of media in any web browser that works with xulrunner suseROCKs: abock, when updated, could you send an email to -gnome ML? munkii: including pdf's using evince srinidhi: abock: no hurries .. will check in the morning.. jpr: munkii: please discuss with mw and wolfiR

Started at --> 20:23:01 jpr: rodrigo_: take it away rodrigo_: ok, so we're ready to start the patchupstreaming process rodrigo_: so if noone disagrees, we'll have next Mondat and Tuesday and patch review days rodrigo_: this means we'll be reviewing the patches in our packages rodrigo_: and tagging them and upstreaming/removing as needed rodrigo_: anything against it? jpr: yes, overlap with the 2.21.5 updates jpr: and where do we do the review? j rodrigo_: http://en.opensuse.org/GNOME/Projects/PatchUpstreaming has the "rules" to do the patch reviewing rodrigo_: well, as we update to 2.21.5 I'm sure we can do the review rodrig if we can sync after to STABLE, mw? mw: yes, G:U rodrigo_: ok, then we'll start on Monday from G:Uwith the packages with most patches mw: since G:U nearly always current with or ahead of Factory jpr: ok

Started at --> 20:27:59 sreeves: I have not seen any negative comments on the set of updates jpr: i added metacity jpr: sreeves: should we pull the trigger then? sreeves: I think so ** munkii notices the absence of captain_magnus sreeves: has anyone specifically tested the metacity addition ? suseROCKs: he's not absent, captain_magnus is just being studiously attentive and quiet to hang on to every detail here. jpr: AI: sreeves, jpr push 10.3 update btimothy: jpr: btw, it makes it easier in rmilk if we specify or at least estimate due dates associated with AIs ^^^ jpr: ok btimothy: not necessarily this one, but you know what i mean. btimothy: :) jpr: i think we'll skip 11.0 feature updates this week jpr: hpj is away jpr: and time is an issue

Started at --> 20:31:44 jpr: any last questions on development? sreeves: abock: generic multimedia question abock: yep sreeves: what support will there be for other files types like 3g2 files sreeves: ie - how do I get them to play on my box abock: I have no idea robberbaron: would be a gstreamer issue right? abock: yeah abock: I'm not sure what codecs specifically are used abock: I just backported GSM wave support to SLED 10 SP2 abock: but that already works in openSUSE 10.3 abock: if the codecs in question are not patent encumbered, then support will probably land in gstreamer upstream abock: if they are patent encumbered, we have no plans to support them :) jpr: abock: can you unbreak banshee in factory? I think its still borked :-) jpr: other questions? abock: jpr: I've been shooting in the dark abock: libbeagle has been giving me problems for days now jpr: abock: its the debuginfo thing, lets talk after abock: my last submission was just checked in, so wait a minute abock: ah, ok abock: sreeves: also, a lot of obscure codecs are actually supported, we just don't install them by default - try installing gstreamer010-plugins-bad sreeves: abock: cool munkii: also we need to minimize beagles footprint, it's a real memory hog at this moment abock: (-bad because they're obscure, no one really has given them the love to bring them to a quality to move to -good) munkii: are their plans to rewrite? jpr: there are no plans to rewrite beagle jpr: but i did check in 0.3.2 jpr: for factory munkii: can we feature beagle's team in the next meeting? jpr: rewrites are generally a very bad idea jpr: (complete rewrites) munkii: jpr, but it's good last resort option jpr: munkii: we'd have to invite upstream people, the beagle devs don't work any more jpr: not really munkii: for novell you mean? jpr: because you bring back bugs you already fixed jpr: yes munkii: jpr, not necessarily suseROCKs: ok ok discuss afterwards :-) abock: in no way does beagle need rewriting, it's core infrastructure is perfectly fine, as are many of its plugins jpr: ok Meeting ended at --> 20:38:51

AI: hpj and sreeves post factory work arounds AI: sreeves, jpr push 10.3 update