[00:06] cjwatson, Thanks for the help! It works flawlessly! :) [00:09] slangasek: do I need a UserInterfaceFreeze exception for the pulseaudio task in bug 533877? The effect is an addition of the correct "Connector" in gnome-volume-control's Input tab. [00:09] Launchpad bug 533877 in alsa-utils "[SigmaTel STAC9228] Recording problem - integrated microphone no longer available on Dell XPS 1330" [Low,Fix released] https://launchpad.net/bugs/533877 [00:10] ^^ anyone else on the release team [00:10] (err, am I supposed to be asking in -release?) [00:10] tjaalton, bryceh: any X dudes about? [00:11] aliendude3500: good, happy to help [00:20] Riddell, mm? [00:21] bryceh: has the intel version string changed recently? [00:21] I mean the format [00:22] bryceh: kwin expects something like "20061017" but it seems to be "2009" "Q" "4" [00:34] Riddell, it quite possibly could have [00:34] Riddell, they have adopted a quarterly release process and it seems quite likely they'd change the nomenclature to suit [00:35] Riddell, probably worth making kwin's regex support either style [00:35] thanks to everyone involved in UDD, bzr and lp! I've just did bzr merge-package and it did the right thing without generating a single conflict! [00:36] nice, isn't it :) [00:36] cjwatson: It's awesome. Thank you ;-) [00:36] not I, really [00:38] cjwatson: btw - there are no bzr-nightly builds for lucid [00:39] I wouldn't know about that [00:39] I can update cookbook branch (or do a merge proposal) but do i need to poke james westby about that? [00:39] check whoever seems to be uploading the others, or runs the team, or whatever ... [00:39] Yeah it's james =) [00:40] * xnox is stuck in stone age without bzr nightly builds for lucid ;-) [00:46] crimsun: I don't think that needs a UI freeze exception === jono_ is now known as jono [01:14] cjwatson: what's the status of bug #513197? [01:14] Launchpad bug 513197 in ntfs-3g "Please merge ntfs-3g 1:2010.1.16-0.1 (main) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/513197 [01:14] I intend to apply for a feature freeze exception for it, but have not got round to it yet. no other statuss [01:14] *status [01:29] ArneGoetje: gbrainy.mo is in both base and gnome langpacks, breaking DVD builds. Where's a good place to report this sort of thing, that isn't specific to a single package? [01:36] cjwatson: those exceptions are handled individually in langpack-o-matic [01:39] cjwatson: so, I take it that it should be only present in the gnome langpacks? [01:42] ArneGoetje: I don't know; I just know it shouldn't be in both :-) [01:42] cjwatson: ok, I'll check [01:42] err, it's part of what used to be gnome-games isn't it? [01:42] and it's in ubuntu-desktop and not kubuntu-desktop [01:42] so yes, I think that would make it gnome langpacks [01:43] cjwatson: ok [01:44] cjwatson: I will add an override to langpack-o-matic. [01:45] great, thank you [01:45] will there be another langpack upload before beta-1? [01:46] I think it's important that we have buildable DVDs for beta-1 [01:46] agreed, I was wondering whether new langpacks were planned anyway, or would need to be added [01:47] cjwatson: current situation is that in the -base langpacks (full-export), gbrainy.po is in the base package. In one of the delta updates it seems to have switched over to the gnome langpacks. So, what I can do now is to manually delete it from the gnome langpack updates and re-upload them. [01:48] cjwatson: next full-export is scheduled for Saturday night (UTC), so new langpacks will be available on MOnday [01:50] cjwatson: and with the next langpacks gbrainy.po should be in the gnome langpacks only. [01:50] that sounds workable [01:50] as long as we get the delta fixes before Saturday, since we'll need to iterate some more on DVD builds and need as much lead time as we can get [01:50] cjwatson: yes, I will do it right away [01:50] they've been failing since January on and off, so we can't expect them to be particularly sound :( === yofel_ is now known as yofel [01:51] (not your fault, this is the first time I've seen this particular error) [01:51] great, thank you [01:51] cjwatson: :) [01:56] Any archive admins around? https://edge.launchpad.net/ubuntu/+source/spim/8.0-0ubuntu1 should be in universe, not multiverse [01:56] (license changed this release; it's now 3-clause BSD) [02:04] cjwatson: ok, so gbrainy will be without translation updates for this short period, but will get them back on Monday. [02:07] cjwatson: can i borrow you a moment? [02:11] maco2: is there a bug report open for this? There's no interface that lets us comment on component changes, so a bug report is our best bet for figuring out why it moved if there are questions later [02:12] slangasek: i can go file one [02:12] appreciated :) [02:14] slangasek: sure, now there's bug 537063 [02:14] Launchpad bug 537063 in spim "spim 8.0 should be moved from multiverse to universe" [Undecided,New] https://launchpad.net/bugs/537063 [02:15] cjwatson: gaa, doesn't work this way... need to run the complete delta update again, otherwise it will mess up the packages... should not take that long... [02:17] maco2: and promoted [02:18] slangasek: thanks === cjohnston_ is now known as cjohnston [02:32] ArneGoetje: I wanted to ask you about bug 534417 [02:32] Launchpad bug 534417 in thunderbird "Thunderbird: localization not installed automatically" [Undecided,Confirmed] https://launchpad.net/bugs/534417 [02:35] micahg: right, need to move that bug to software-center. That function is already implemented in language-selector and software-center just needs to call a function to get this. I will add a comment and move it over later, when I'm done with the language-packs [02:36] ArneGoetje: great...I also wanted to ask you about the template for the firefox langpacks [02:36] do you want to switch from firefox-3.6 to firefox after beta 1? [02:36] micahg: template has been fixed [02:36] ArneGoetje: it's firefox now? [02:37] micahg: oh, that... no, we can only switch when 3.0 and 3.5 are out of life and firefox has been upgraded to 3.6 for all releases. [02:38] ArneGoetje: oh, I thought it was going to be sooner...ok, I'll talk to asac about the translation menu link in ubufox then [02:38] micahg: ok, thanks [03:00] Hello, anyone interested in kernel BUG at /build/buildd/linux-2.6.31/fs/btrfs/inode.c:735 ? [03:12] leagris: I suspect a number of folk are. I'd recommend running `ubuntu-bug linux` to gather up a lot of the information about the bug and your system, and then report with as much additional detail as you can to the bug tracker. [03:14] persia, here is a extract from dmesg: http://pastebin.ca/1832949 [03:16] leagris: Thanks, but I'm not someone who can understand the problem from that. Please do file a bug. IRC is a poor place for bug reports, because lots of folk sleep. [03:16] (well, other reasons too, but that's a big one) [03:18] :) [03:18] thanks persia [04:04] for some reason i can no longer ssh to my systems foo.local address, anyone know what could cause that? [04:05] hmm it works after resetting the ethernet connection [04:35] aloha jono [04:37] hey emgent` [05:53] How can I use the *-dbg* packages with gdb? [05:54] nonix4: Install the -dbg package. Start gdb. If you have to do something special, file a bug. [05:59] * nonix4 ponders (a bit offtopicly) which alternate browser to use since the buggy app in this case is firefox in infinite loop and gdb says "no debugging symbols found" [06:05] nonix4: what's wrong with firefox? [06:06] It got to infinite loop switching mouse cursor between pointer and hand. Thoughts on how to analyze situation better? gdb backtrace doesn't tell much to untrained eyes with missing symbols [06:08] nonix4: what were you hovering over? [06:12] Not sure anymore... one of {a login input, submit button, help href, another tab}. But regarding the -dbg packages I was apparently just missing some of them (guess there're no dependancies between them) [06:16] oh great, X froze on attach to firefox... [06:17] * nonix4b makes a mental note of debugging X apps requiring remote connection for the control [06:18] nonix4b: well, if you get enough info feel free to file a bug and I'll try to get to it at some point [06:22] pitti: could you please check on the lucid retracer (bug 533357 has been waiting 4 days) -- thanks [06:22] Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/533357) [06:43] * nonix4b considers filing a bug on debug symbols of gdb itself missing [06:45] Good morning [06:45] pitti: Good morning. [06:56] 'k "kill -CONT $ff; kill -9 $gdb" got X back alive, so may actually be able to get some information out of it :) [07:17] ev: oh, nice! usb-creator has completed 140% :) [07:38] Riddell, ping. [07:38] morning pitti [07:38] apachelogger, ping too [07:47] good morning [07:49] morning dholbach [07:50] hey dholbach ! how goes? [07:50] long time to saw you [07:50] hey amitk, hi emgent [07:50] how are you guys doing? [07:51] really busy with my job :-\ [07:51] and anyway i have a not good news for us.. [07:51] ? [07:52] lifeless, ola, are you in involved in canonical webapps ? [07:52] somewhat [07:52] why? [07:53] i have some security hole to notify. [07:53] so do so [07:53] we use launchpad, it has support for that [07:54] are not ubuntu stuff bug.. are canonical webapps issue [07:54] but if you prefer.. i will notify in LP. [07:55] dholbach, when back query me [07:55] I'm all here [07:56] would opening a kernel bug with patch to support the Marvel 8431 (which is in newer netbooks) be appropriate? [07:58] spaetz: You could, but I think they kernel team likes git-formatted patches to their mailing list (although I may be mistaken). [07:59] spaetz: You ought get guidance in a bug if you file it though. [07:59] spaetz: https://wiki.ubuntu.com/KernelTeam/KernelPatches [08:00] spaetz: having the patch in a bug is good, but the kernel team prefers discussion on their mailing list [08:00] I'm trying to use pam_ck_connector to make local LTSP sessions CK-aware, but I don't understand how I'm supposed to export the CKCON_X11_DISPLAY_DEVICE environment variable (i.e. export doesn't work). It does work if I put it in /etc/environment, but I want it to have different values per session, so I don't want it in a global file. Would someone care to give me some hint? [08:00] https://wiki.ubuntu.com/MeetingLogs/devweek1001/KernelPatches has some good discussion about it too [08:01] persia, dholbach thanks. I can point to the corresponding git commit for the opensuse kernel, hope that is fine. I will send a mail to the mailing list. [08:02] awesome [08:09] emgent: we have products in lp for many/most of our webapps [08:09] emgent: which ones are affected? you can privmsg if you want [08:15] dholbach: filed bug 537168. Thanks for your pointers. [08:15] Launchpad bug 537168 in linux "[lucid] add support for Marvel 0x8431 (88E8059)" [Undecided,New] https://launchpad.net/bugs/537168 [08:15] no worries :) [08:35] Anyone got some tips on where to get started in bug fixing? I want to get into developing for ubuntu, but for obvious reasons don't want to dice into the deep end trying to start my own project. [08:37] dive* [08:37] bigon: gupnp-igd FTBFS in lucid because of a problem with the test suite, which I assume was enabled as an MIR requirement; there's a fix upstream for getting the test suite to *build*, but enabling 'make check' in debian/rules still causes the package to FTBFS even with version 0.1.6-1 - do you have any ideas on this? (bug #534311) [08:37] Launchpad bug 534311 in gupnp-igd "gupnp-igd ftbfs on all archs in lucid" [Critical,Triaged] https://launchpad.net/bugs/534311 [08:38] dugger5688: try https://wiki.ubuntu.com/MOTU/GettingStarted [08:38] bigon: it looks like it might need dbus running for the testsuite [08:39] Thanks, found my way there already :-) Will go through it in the morning. [08:46] slangasek: well there is the same bug in debian [08:47] bigon: in Debian the testsuite isn't enabled - do you mean this is why it's not enabled? [08:47] wait I check [08:48] Keybuk: purple consoles, +1 ftw [08:49] slangasek: it could be related to nm support (and the fact that dbus-glib is not working properly when initialised inside a thread, dixit gupnp-igd upstream [08:50] slangasek: I'm planning to make a gupnp-igd without nm support in debian to fix a related FTBFS [08:51] seb128, moonlight 2.2 uploaded. good luck to whomever needs to clear that through NEW. [08:51] directhex, thanks! [08:52] 1.0.1-3ubuntu0.xul191build2 to 2.2-0ubuntu1 (36.1 MiB) [08:52] bigon: ok - if you decide to fix it in Ubuntu as well, please note that I've merged up to 0.1.3-4 (testing) already on the lp:ubuntu/gupnp-igd branch, so if we continue with 0.1.3+fixes, would be good to preserve that [08:53] maco2: did slangasek cover what you wanted, or was there something different you wanted to ask me about? [08:55] slangasek: do you have logs of gupnp-igd 0.1.6 FBTFS? [08:56] bigon: posted to the bug [09:01] slangasek: oh it's not a crash (I thought so) well then It could be http://bugzilla.openedhand.com/show_bug.cgi?id=1979 then [09:01] bugzilla.openedhand.com bug 1979 in gupnp "g_warning make gupnp-igd test fails" [Normal,New] [09:02] bigon: ah, looks right, yes [09:03] hi [09:06] Does /etc/security/pam_env.conf have access to the normal environment variables, or it can only access pam-environment? E.g. I'm trying to put MYVAR DEFAULT=${LANG} there, but it doesn't work for me... [09:08] cjwatson: thanks for fixing ubiquity so fast. Glad I could help with my logs [09:09] apw: do you think there's a chance to fix bug 397734 for lucid? it still causes a lot of grief, and OEM team also has trouble [09:09] Launchpad bug 397734 in devicekit-disks "can't eject cdrom with hardware button" [Medium,Fix released] https://launchpad.net/bugs/397734 [09:09] apw: (it's basically flipping the default value of /proc/sys/dev/cdrom/lock to 0) [09:10] apw: we could set it in /etc/sysctl.d somewhere, but first that's racy (doesn't get active if the cdrom module isn't loaded yet), and also means extra parsing during boot, etc. [09:11] apw: hm, I guess it could be a modprobe.d file, but it'd still feel cleaner to set the default right at the source [09:12] pitti, i'll have a look [09:12] apw: thanks [09:15] siretart`, hello [09:15] hi seb128! how are you? [09:15] siretart`, good, you? [09:15] siretart`, I'm starting that gst-ffmpeg against ffmpeg discussion with pitti again [09:15] hey siretart`, wie gehts? [09:15] thanks, fine. [09:15] danke! :-) [09:15] since he was not around the other day [09:15] siretart`, can you summarize the issue between both? [09:16] does gst-ffmpeg need a newer or older ffmpeg to work correctly? [09:16] ah, another round in the gst-ffmpeg vs ffmpeg deathmatch :-) - okay, let the fun begin [09:16] is downgrading or upgrading ffmpeg to that version an option? [09:17] siretart`: background is, ffmpeg is pretty prone to security flaws (and bugs, too, I suppose), so if we can avoid a copy, we should [09:17] okay, short recap: ffmpeg 0.5 is now pretty exactly 12 months old, and has since then gained quite a lot of additional codecs [09:18] gst-ffmpeg upstream has decided that these additional codecs are important for them and switched from tracking the 0.5 release branch (which we use as system ffmpeg) to ffmpeg trunk [09:18] seb128: 0.5+svn was in karmic as well, so I guess that had the same problem? [09:18] naturally, some details have changed, and gst-ffmpeg has strongly advised me against compiling it against 0.5 [09:18] pitti, ok, seems I got my version wrong, better to read what siretart` is writting [09:18] slomo however has identified which parts don't work against 0.5, and patched them out [09:18] siretart`: ah, so the issue is that gst-ffmpeg has a _newer_ copy than our system ffmpeg? [09:19] pitti: exactly. gst-ffmpeg will track the 0.6 branch as soon as it opens (maybe we'll create that branch this weekend, maybe next weekend, we'll see) [09:20] pitti: regarding security issues, does the security team really care about the security patches in the ffmpeg package? I did write a mail to security, but they were rejected because "no testcase" [09:20] in the mean time the patches I did for the debian package got integrated in 0.5.1 [09:20] hm, I had assumed they did; kees, jdstrand, mdeslaur ^ ? [09:20] and are now in lucid. but for karmic the patches are still missing [09:20] siretart`, should we understand from that using the system 0.5 ffmpeg will mean cutting or features and codecs which would work using the copy then? [09:20] siretart`: ah, so is there actually a problem in lucid then? [09:21] or->on [09:21] I really care about security patches. :P [09:21] I'm not sure I understand the question, though. [09:21] pitti: 0.5.1-1ubuntu is in lucid and has these patches. all sec related patches I'm aware of are included there [09:21] kees, the question is "do you care if gst-ffmpeg uses a ffmpeg copy" ;-) [09:22] siretart`: I meant, you said that slomo patched out the bits of gst-ffmpeg which don't work with our 0.5.1 ffmpeg lib [09:22] seb128: yes, trunk always has (almost per definition) more codecs then a release branch [09:22] siretart`: so it seems that in lucid it's actually fine? [09:22] `I did write a mail to security, but they were rejected because "no testcase"` ? surely not security@ubuntu.com ? [09:22] pitti: lucid should be fine [09:22] seb128: yes, I care -- it absolutely should not use an embedded copy. [09:22] siretart`: *phew* great to hear [09:22] kees: I'll fetch the message id [09:22] siretart`, if lucid should be fine I'm getting confused about your ping from the other day [09:23] seb128: security wise. gst-ffmpeg in lucid is compiled against 0.5, which upstream strongly opposes [09:23] why, if it works fine? [09:23] I had the impression you told me it was open door for crasher issues [09:23] but now you say it's fine [09:24] pitti: kees: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550442#35 this is the last message I got from the ubuntu security team, I think [09:24] Debian bug 550442 in ffmpeg "ffmpeg: deluge of crashes due to missing input sanitization" [Serious,Fixed] [09:24] I understood the last sentence as "we need an proof-of-concept exploit" for each crash [09:25] which I really don't have the time for [09:25] that would be weird [09:25] most security issues we fix don't have one, AFAIK? [09:25] siretart`: he meant "someone needs to analyze these crashes to see if they're really security issues." [09:25] seb128: yes, and that is right. we are having two seperate discussions here [09:26] I'd hope that we weren't writing test cases for every security hole. That code would be dangerous. [09:26] persia: we do try -- how else to better validate a vulnerability has been fixed? [09:26] kees: I've discussed each single patch with other ffmpeg developers, and I think only one or two were classified as 'not security relevant' [09:26] Oh my! [09:27] persia: kees has bee doing this for years :) [09:27] s/ee/een/ [09:27] persia: have you not see lp:~ubuntu-bugcontrol/qa-regression-testing/master ? [09:27] kees: I've not looked in detail, no. [09:28] * persia wonders how the publication of that branch intersects with UEC images [09:28] seb128: I'm saying that *ffmpeg* itself should be fine security wise. I didn't say that about gst-ffmpeg! [09:28] siretart`, I've to admit I'm confused about the discussion now [09:29] siretart`, I though the discussion was about having something which is stable against something not tested and crashy [09:29] siretart`: if there are open security issues in ffmpeg in releases of ubuntu, we need to track them. mdeslaur seemed to be identifying where various things were fixed already? this list needs to be clarified, etc. [09:29] siretart`, and now it turns to be a discussion about ffmpeg security which I've no real clue about or interest in [09:29] kees: pitti: anyway, in the mean time a DSA has been released about these issues, so the patches could be taken straigt from there. however, looking at the latest commits svn://ffmpeg.org/branches/0.5 might be helpful as well [09:29] siretart`, so I will let you guys sort that one [09:30] seb128: okay, let's discuss open security issues first and then return to gst-ffmpeg [09:30] siretart`, thanks [09:31] kees: I haven't heared anything back from mdeslaur since then, no idea if he continued to track that issue [09:32] siretart`: okay, I'd like to get it clarified. specific what patches are missing for which ubuntu releases of ffmpeg. [09:34] kees: for intrepid, I think taking the patches from the debian DSA would probably be easiest, although I didn't check if I haven't missed to backport some patched back then. I think there might be even some newer patches to check [09:35] siretart`: can you perhaps open a new LP bug (tracking this in a debian bug probably isn't the clearest way to handle this)? [09:35] kees: for jaunty and karmic (they are effectivly both 0.5), replaying the patches from the 0.5 release branch should be easiest [09:35] okay, I can do that [09:36] shall we return to the issue of gst-ffmpeg then? [09:37] siretart`: cool thanks. when mdeslaur wakes up, he can poke at it more. I'm overdue for sleep. :) g'night! [09:37] pitti: :) [09:37] siretart`: so now I'm confused; I thought it would work well in lucid now, with slomo's patches? [09:37] kees: good night! :-) [09:37] kees: sleep well! [09:37] pitti: well, it is the 'well' that upstream objects. They highly doubt that it works 'well' [09:38] it builds, but nobody really tested that combination [09:38] and I have to admit that I'm not going to look to deeply into crashers that come via that way [09:38] siretart`: if you feel too unsure about it, perhaps we could downgrade to an earlier gst-ffmpeg from a time when 0.5.1 was current? [09:39] pitti: yes, sticking to the version of gst-ffmpeg from karmic seems to me a safe solution [09:39] siretart`: so we should go back from 0.10.10 to 0.10.9? [09:40] or use the gst-ffmpeg copy? [09:40] I don't fancy using year old code [09:40] especially for multimedia, it often means lack of support for codecs, etc [09:41] well, we should either upgrade ffmpeg to trunk or downgrade gst-ffmpeg [09:41] pitti: that would make us stick to a codebase that we know, but it also would make seb128 and many users sad because we're missing lots of codecs [09:41] having two copies of ffmpeg really doesn't make sense, either from security or maintenance POV [09:41] if we keep a newer ffmpeg in gst-ffmpeg, then we'd still have those codec/bugs problems in the system library [09:42] pitti, it would make sense in the sense it would provide a decent multimedia experience to our user [09:42] seb128: how wouldn't that be provided by updating the system library? [09:42] pitti: as for long term plans, I plan to work on the 0.6 release soon, and bilboed (gst-ffmpeg upstream) has indicated that they will start tracking that branch as soon as it opens [09:42] pitti, this CDROM lock thing ... i just played with mine and i am unsure as to what the real issue here is... as far as i can tell the button works when you are allowed to eject the CD and not when you are not (its in use) ... are we saying we want to allow eject even on mounted FSs? [09:42] pitti, you are trading distro work against user experience, ie arguing that we care about having less work and not about providing a good user experience there [09:42] seb128: but if it's not ready for release yet, then that's just bad luck and timing [09:43] pitti: I didn't push 0.6 for lucid because I cannot commit to transition all package in ubuntu from 0.5 to 0.6. I have really no idea how much breakage that will cause [09:43] so [09:43] for me, the plan was to go with 0.5 for both lucid and squeeze [09:43] pitti, by experience upgrading system ffmpeg is not trivial [09:43] we are saying that ffmpeg 0.5 is stable, and 0.6 is not there yet [09:43] pitti, also having just tried it, when you rip out the disk the fs remains mounted from there on ... and nautilus (i think) triggers 5 errors to syslog every few seconds until its reinserted or unmounted [09:43] pitti, right [09:43] bilboed was fully aware of that plan but decided to go for trunk anyways [09:43] apw: that's a separate bug indeed [09:44] and I can udnerstand him in some ways. there are really very interesting new features in 0.6 [09:44] seb128: so either 0.6 is ready for release, then we can update to it, or it's not, then I don't see a major reason why we shouldn't stay with 0.5? [09:44] pitti, i also can't see what would stop eject working in the middle of a disk burn ... [09:44] but since we are way past feature freeze, I did considered upgrading as an option [09:44] seb128: do you really think 0.5 was so bad? video codecs have worked great in linux for at least a decade, after all [09:45] upgrading gst-ffmpeg to use ffmpeg 0.6 would require a FFe anyway AFAIUI.. [09:45] seb128: do we have lots of bug reports which would be fixed with 0.6? [09:45] pitti: well, we could also see it that way: [09:45] pitti, I don't know enough about ffmpeg to say [09:46] pitti: for lucid+1, I will very soon upload a ffmpeg 0.6 package as system ffmpeg [09:46] pitti, I just know that a year is lot in multimedia things [09:46] seb128: but you just argued that we need 0.6 for good user experience? [09:46] pitti, and sirestart said slomo had to turn codecs and things off since they didn't work with ffmpeg 0.5 [09:46] pitti: so as soon as ffmpeg 0.6 is releasd, the security team would have to care for 0.6 as well anyways.. [09:46] pitti, I'm just saying that based on siretart`s comment [09:47] "users sad because we're missing lots of codecs" [09:47] siretart`: that's the natural flow of things, yes; but they'd have to care about it much longer if it's in lucid, too; [09:47] siretart`: and apart from the seucrity side, if 0.6 isn't stable yet, it sounds like we would introduce more problems than we solve [09:48] I mean seriously, how many video formats cause problems on recent linux? My feeling is "hardly any" [09:48] but we do have a lot of _bugs_ with playing back videos indeed [09:48] pitti: seb128: http://paste.ubuntu.com/393150/ is the change log in ffmpeg trunk so far since the 0.5 release [09:48] (thinks like searching in totem, etc.) [09:48] pitti: AVC HD is miserable currently. /me really goes to bed now [09:49] I even had been presented a backport of wmapro for 0.5... [09:49] kees: in totem? [09:49] pitti: right. and not even mplayer can play it right. the only thing that seems to get it right is mythtv's internal player. [09:49] pitti: AVC HD playback is pretty bad shape in all ubuntu packages right now [09:49] seb128: so, I guess we can argue either way (for 0.5 or 0.6), but I really object to having _both_ as a rational answer [09:50] there will always be new codecs. [09:50] * kees votes for 0.6 just because it'll be easier to get fixes for in 3 years. :) [09:50] * kees really really goes to bed === yofel_ is now known as yofel [09:50] well, that's fair enough [09:50] pitti, I've not spent enough time looking at bugs and I don't know enough about gst-ffmpeg and ffmpeg to have an argumented answer there [09:51] but that wouldn't help you at all if gst used 0.6 and everything else 0.5 [09:51] pitti: there are no 'stable' releases. ffmpeg development is way to fast to even think about that. It took years to convince upstream to do at least snapshot releases. ATM, its mainly me who tries to identify security related changes in trunk and backports them to release branches [09:51] siretart`: so, what's your recommendation right now? [09:51] pitti, I'm mainly trying to avoid us realizing in one month that we are flooded by totem gst-ffmpeg crash bugs because we use a non support ffmpeg and gst combinaison [09:51] asac: about bug 526480 -- you think you'll have time for it ? [09:51] Launchpad bug 526480 in liblog-log4perl-perl "[MIR] liblog-log4perl-perl" [High,New] https://launchpad.net/bugs/526480 [09:51] otherwise may be best to assign it to someone else in MIR team [09:51] pitti, and being stucked in a sucking position then for the lts because it's too late for changes [09:52] seb128: right, and I'm trying to avoid that flood by suddenly switching to a new upstream ffmpeg in gst which nobody tested yet.. [09:52] well it's an internal copy [09:52] it has been tested by upstream [09:52] and switch the configure flag back is easy [09:52] pitti: with following three options: A) compiling new gst-ffmpeg against 0.5 B) reverting to old gst-ffmpeg and C) new gst-ffmpeg with internal copy [09:53] pitti: I'd probably vote C>B>A [09:53] same here [09:53] siretart`: I'm interested why you favor C [09:53] since the first one is unsupported and crashing [09:53] it seems like the least sensible option to me [09:53] pitti: it is the only option blessed by upstream [09:53] it's the one providing the best user experience [09:53] siretart`: like, "get twice the amount of bugs for double the price"? [09:53] at a cost for us to fix issues in that copy [09:54] pitti, well, we have to choice is we care about having less work or about having a better user experience [09:54] let me ask in a different way [09:54] since the less work solution will bring trouble and crashes [09:54] who cares for gst-ffmpeg bugs these days? [09:54] so what about D) update system ffmpeg? [09:54] in terms of crashers? [09:54] care in which sense? [09:54] nobody work on those [09:55] but I would prefer not having crashers there [09:55] I do care about what we ship to our users [09:55] seb128: you are sure that updating ffmpeg won't bring new problems? [09:55] pitti, we would not update, we would use the gst-ffmpeg ffmpeg copy with is what upstream work on and test [09:55] and which is the version which probably match best what gst-ffmpeg handle [09:55] seb128: sure we would [09:56] pitti: D) would be an option as soon as we have an 0.6 release branch, or even better, the 0.6 release. I don't think that will happen in time for lucid [09:56] whether it's linked or internal, it's still a new version [09:56] seb128: But why not take the ffmpeg gst-ffmpeg recommends and use that for system ffmpeg? [09:56] D) would also mean a transition [09:56] how much other things would that break? [09:56] pitti: and I cannot commit for doing that transition in a couple of weeks. the last ffmpeg upgrade was pretty painful [09:56] persia, because we are not sure how it would impact on everything else using ffmpe [09:56] persia, ie xine, vlc, ... [09:57] persia, what sirestart says [09:57] And given schedule, urk. [09:57] siretart`: yes, I wasn't going to ask you to actually; (I favor neither C nor D, FWIW, but it seemed prudent to at least complete the option table) [09:57] I can say for sure that our mplayer won't remotely compile against 0.6 [09:57] but mplayer is special [09:57] anyway [09:57] pitti, well new version right, but with limited scope, it just needs to be tested on gst-ffmpeg, we don't risk stability issue for ie xine [09:58] or mplayer or vlc or etc [09:58] so, I don't think I have any new arguments at this point; seems we just need to agree to disagree then :) [09:59] I think the safest option would be to revert to lucid's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg [09:59] siretart`: s/lucid/karmic/ ? [09:59] err, of course [09:59] I think the safest option would be to revert to karmic's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg [10:00] and upload a newer gst-ffmpeg to lucid-backports that uses the internal copy of ffmpeg [10:00] how much drawback is that compared in format supports, bug fixed, etc? [10:00] (we should probably go to 0.10.9-3, not -1, but details..) [10:00] siretart`, do you know what slomo plans to do for debian? [10:01] seb128: no idea, I havn't seen him on irc for quite some time now [10:01] I think he is going with newer gst-ffmpeg compiled against 0.5 [10:01] read: option A [10:01] so it seems pitti and security team stand strongly against C [10:02] so we have choice between downgrade or stay with that unsupposed binaison [10:02] how can we get feedback on well or not gst-ffmpeg + ffmpeg 0.5 is working or crashing or...? [10:02] on *how* well [10:03] my personal gut feeling is A>B>D>C, but since it seems that D) is not practical, it reduces to A>B>C [10:03] I'm told that gst-ffmpeg comes with an extensive testsuite [10:03] seb128: hm, we could look at gstreamer/totem/gst-ffmpeg bugs since lucid? [10:03] I guess we could run totem over a test-suite of video files; I know they exist. [10:03] perhaps running that would give us more insight? [10:03] siretart`: sounds like a good idea [10:04] everyone watch pr0n for a week and report the results! [10:04] ok, so let's stay on A and try to do some testing with it? [10:04] maybe talk to the qa team about organizing some testing on that? [10:04] just to know where we stand [10:05] seb128: perhaps you could try talking to upstream about that issue? [10:05] I mean with your ubuntu gnome guy hat on? [10:05] looks like http://live.gnome.org/GStreamerMediaTest [10:05] what issue? how to test? [10:05] about option A) anyway despite their explicit disapproval [10:05] this choice is not going to please them [10:06] siretart`, who did you talk to upstream about that before? [10:06] I will get in touch with them [10:06] seb128: to bilboed [10:06] ok thanks [10:06] seb128: he approached me in #ffmpeg-devel [10:07] not sure if there is an gst-ffmpeg specific dev channel [10:07] siretart`, #gstreamer will do [10:07]