[00:00] they do that kind of stuff elsewhere [00:00] so seems thats ok [00:00] maybe forward that and add to package for now ;) [00:00] i did just put it to patches/ directory [00:00] err patches/ugly [00:00] guess you dont like it ;) [00:00] indeed [00:00] :) [00:06] fta: ok so the CFLAGS in rules should be added everywhere [00:06] according to kees its bad to have libs without fPIC [00:08] fta: and the patch i gave you upstreamed ;) [00:08] "quickly upstream" [00:08] hehe [00:09] pinged the guy, but he's not there atm [00:09] great [00:09] ok let me build on lucid without armv7 [00:09] lets hope that just works [00:12] ok kicked off chromium without armv7 [00:13] you said the SSE issue we had in karmic is probably fixed too now? guess that means this might work then [00:21] * asac resets router .... port forward issues [00:34] fta: for neon background see slides 7 and following https://wiki.ubuntu.com/Mobile/ARMv7AndThumb [00:34] arm folks suggest that neon optimization should at best be don in post-processing rather than at compile time [00:34] but no tool exists yet [00:37] peephole neon? [00:37] that sounds unlikely [00:37] theres a bug about ffmpeg/neon/stack protector problems if it helps any -- https://bugs.launchpad.net/ubuntu/karmic/+source/ffmpeg/+bug/383240 (comment 41 and newer) [00:37] Launchpad bug 383240 in ffmpeg "Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmpeg trunk for armel" [Medium,Fix released] === asac_ is now known as asac [00:47] thanks. guess i should check with lool or dmart on what to best to to optimize the ffmpeg for chromium === powderluv_ is now known as powderluv === ApOgEE__ is now known as ApOgEE === ___bjf is now known as bjf-afk [02:47] Anyone ever used a SmartQ 7? [02:48] had one dropped in my lap today. A customer wants to use it in some kind of retail/bar scenario as an entertainment/targeted marketing doodad [02:49] I've been playing with it for about an hour and it looks fun, just looking for any tips, pointers, gotchas ect [03:29] joshm: The SmartQ5 is an fun little bit of hardware. It is restricted to Ubuntu 9.04, due to hardware limitations (doesn't support the newer instruction sets used in newer releases). [03:29] persia: cool thanks, is the 7 restricted like that as well? [03:30] I believe so, but I've only hearsay (I don't have one). [03:30] My understanding is that the only substantive difference between the 5 and the 7 is the screen size. [03:30] thanks for the heads up though. I'll be doing more research before I do anything drastic to the little guy [03:31] One concern though is that you need a special kernel for those: they don't work with the standard 9.04 kernel. [03:31] I've only been toying with it for a couple hours, but it seems like a nifty device [03:31] (But I think that's true for nearly everything except a couple developer boards today) [03:31] persia: From my instructions I've decided I don't need to replace the OS at all [03:32] I wouldn't think so. I'd recommend doing an update against the latest jaunty-updates repo though. [03:32] no DRM or anything so I was able to install openssh and get access from my desktop ( much easier to type ) [03:32] And then just install whatever apps you need to meet your use case. [03:32] I do need to work on paring down the install though [03:33] Oh, almost forgot. Mono support is weak, so f-spot and tomboy might not be best choices for a 9.04-based solution (although I'm not sure how much you need that for retail/bar use cases) [03:33] from what I gather ( I have very limited info atm ) my customer wants to use it as a kind of table trick/entertainment/ordering platform/targeted marketing thing [03:33] With a 5" screen! [03:33] so I don't think an SD card will be wise [03:34] I'd recommend the 7 for such a scenario. I carry a 3" and a 4.5" all day every day, but I do bring those closer to my face. [03:34] unless we epoxy the bastard in [03:35] Most of the at-table electronic ordering systems I use seem to be in the 7-9" range, at not very high DPI (100 or less). This seems more than sufficient for most entertainment/menu display, and avoids narrow touch points for drunken fingers. [03:35] basicly this got dumped on me ( I don't mind! it's fun! ) because I just started at this company and I have linux experience [03:36] The Q5 is probably a good dev platform, and just tell the customer to order the Q7s when it comes to installation. Last I checked (about 9 months back), they were about the same price, and had nearly the same specs (including screen resolution) [03:36] it's a small windows shop. The owner thought this would be fun for me ( he was right ) [03:37] I have no idea what the customer has bought yet, I have a 7 sitting next to me that was dropped off this afternoon [03:38] one of the requirements byt he customer was firefox. after a little research I've seen alot of posts about firefox being dog slow on arm [03:38] You oughtn't need that much storage. My Netwalker has 4G onboard, and I mostly use the microSD for convenience, rather than from need. The Q7 is a little tighter, but if you're running it in kiosk mode, you shouldn't need that many apps. [03:39] is that correct? should I be looking at another browswer? The customer specificly requested firefox. I've emailed him asking why firefox is a must. But haven't heard back yet [03:39] Well, it's slow, but it's usable. I find firefox on the Netwalker to have significantly faster performance than the default Zaurus browser (just because the HW is faster). [03:40] I saw a post from the ubuntu devs saying they would look at chromium for next release [03:40] so firefox is useable? [03:40] from the way the post read, firefox was a bear [03:40] At the recent UDS, we had a session to talk about it, and while I didn't attend, my memory of the results was that webkit-based browsers were considered preferable. That said, I don't think any of the webkit-based browsers in 9.04 are in good enough shape to use out of the box. [03:41] Firefox is definitely usable, but the performance is much slower than on a desktop. It depends on your expectations. [03:41] --->> link https://wiki.ubuntu.com/Specs/ArmLightweightBrowser [03:41] Right. Thats the spec for the session I mentioned. [03:42] great thanks [03:43] I'm about done futzing with it tonight, Thanks for the info, you have been awesome. [03:43] I'm wondering where my customer is getting them now [03:44] I think he is getting them pretty cheap, and my wife has been wanting an e-book reader [03:44] No problem. Good luck with your project. One other note: 9.04 is only supported until around October 2010, so once you have a PoC, it might be worth investigating alternate hardware solutions for the final instalaltion (that could take advantage of a newer release) [03:44] I know it isn't the liquid paper type stuff like kindle, but from what I gather it has a good uptime on battery [03:45] I've seen them advertised for export including shipping to Europe for ~ 140 euros from a few sources. [03:45] she hasn't gotten off work yet tonight [03:45] I didn't end up ordering one, so I can't recommend any specific vendor (as none of the places I saw it advertised were familiar to me) [03:46] I'm gonna toss a book on it and have her play with it [03:46] If it's not installed, you might want to try installing fbreader first. [03:46] yeah I've already "rooted" it [03:46] It's a reasonably nice interface for reading (unless your books are PDF or HTML) [03:47] installed openssh so I didn't have to deal with it's interface [03:47] Dont the SmartQ series come "rooted"? [03:47] yeah it was superficial [03:47] hence the "" [03:47] It's nice to see more consumer hardware coming out that way, so we can mess with it properly :) [03:48] there was no obstical, though trying to add a user and give it sudo rights while the onscreen keyboard covered the shell was fun [03:48] There's no USB port? [03:48] yeah there is, but I don't have a usb keyboard at my house [03:49] Ah, it all makes sense now :) [03:49] all mine are PS2 [03:49] actually I did find one after I was done, but it's almost as bad [03:50] Worse in some ways, because one has all the pain of not having one and then gets the fun of slapping one's forehead [03:50] my keyboard my sister gave me, it's dish washer washable [03:50] it's all plastic [03:51] hard to type on [03:51] the onscreen one was almost as good [03:51] except with the usb one I could see what I was typing [03:52] Oh my. That's an interesting choice. [03:54] I typed enough to add openssh-server, and add a user onscreen [03:55] then I logged in with ssh and created a script to add me to sudoers, script named /tmp/a [03:55] then ran that [03:55] And once you have an ssh connection, you can use the interface of your choice to hack it. [03:55] wasn't so much bypassing security as bypassing inconveinence [03:55] exactly [03:56] Just be careful with that: one issue I've seen a lot with using ssh to hack the little machines is that one forgets to make sure the interface works without it in the final solution. [03:56] well right now I'm just playing [03:56] per my boss this is low priority [03:57] think it might be by bosses friend or something [03:57] I don't know [03:57] don't care really. free hardware to play with is payment enough for me :P [03:58] Yeah. Toys always win :) === ogra_ is now known as ogra [12:10] lool: i saw you did some efforts on supporting neon for ffmpeg ... whats the idea? [12:11] like: how is that supposed to work only on hardare that supports neon etc. [12:16] fta: chromium seems not to open pdf files etc. is that known? [12:16] e.g. lack of mime integration with desktop et al [12:29] hmm, db4.2 seems to need a swp fix [12:32] * ogra gives back a bunch of packages that might be fixed with -mimplicit-it=thumb [12:38] asac is now an arm expert! [12:39] armin76, we dont leave him a choice ;) [12:39] haha [12:39] i know armin76 ... my personal super-expert [12:39] ;) [12:40] ogra: is implicit-it in toolchain now? [12:40] since dec. 4th [12:40] odd. thoughti talked to doko after that [12:40] he said it was blocked on eglibc fixes [12:40] i gave back everything that was failing before that date with assembler messages that didnt contain swp errors [12:40] good [12:41] well, gcc at least sets the option [12:41] ogra: do you have buildd powers or did you use launchpad web ui? [12:41] * Pass -mimplicit-it=thumb to as by default on ARM. LP: #488302. [12:41] LP ui [12:41] the pages are linked directly from the ftbfs list [12:41] we need a buildd admin in the team [12:41] we have lamont :) [12:41] so we can prioritize armel builds [12:41] well [12:41] asac: It's done using hwcaps [12:41] NCommander can priorize [12:42] asac: glibc is patched to look at /lib/neon, /lib/vfp, /lib/vfp/neon and the like [12:42] asac, archive admins can do that iirc, no need for a buildd admin [12:42] asac: So we have two ffmpeg builds, one with neon enabled and one without; the neon enabled one goes into the neon-vfp dir [12:42] ogra: afaik buildd admin (like doko) ... i dont think there is more power attached to "buildd" admin [12:43] lool: ok. so the package just does two runs? [12:43] I think ffmpeg should be revised for thumb2 / armv7 though, the flags are hardcoded to the lowest supported ABI [12:43] lool: where are the dirs located it looks at? [12:43] asac, there surely is, but i know that StevenK as well as NCommander can bump priorities for us [12:43] asac: glibc? [12:43] lool: i mean: where are they coded. ok [12:43] thx [12:43] ogra: ncommander is archive admin? [12:43] no [12:43] good ;) [12:44] but he is in the porters team [12:44] He is porter [12:44] so he can bump packages [12:44] ok [12:44] both are not really there though ;) [12:44] right, in that case ping in #ubuntu-devel [12:45] usually takes not more than ten mins until someone helps [12:45] hrm [12:45] The following packages have unmet dependencies: [12:45] libmetacity-private0: Conflicts: libmetacity0 but 1:2.28.0-0ubuntu1 is to be installed [12:45] E: Broken packages [12:45] still :/ [12:46] root@babbage2:/# apt-cache rdepends compiz [12:46] compiz [12:46] Reverse Depends: [12:46] ubuntu-netbook-remix [12:46] oh, intresting [12:46] ogra: https://edge.launchpad.net/~launchpad-buildd-admins [12:46] why is that seeded ? [12:46] thats the team ncommander is in [12:46] ubuntu-porters i think [12:46] no [12:46] https://edge.launchpad.net/~mcasadevall/+participation [12:47] Build Daemon Maintainers [12:47] ah [12:47] so yes. thats what i ment with buildd admins [12:47] for sparc and ia64 i think [12:47] ok [12:47] hmm, there is no rdep for libmetacity0 anymore [12:48] ogra: There is a workaround in the seed to avoid pulling compiz [12:48] It's due to the x-window-manager provides [12:48] * ogra doesnt get why his build working [12:48] lool, ah [12:49] *is not working (indeed) [12:50] we dropped it at tsome point because maximus got fixed [12:50] but apparently it's broken again [12:50] right [12:51] well, i dont really care atm [12:51] my armel builds fail ... thats more fatal [12:52] nothing in ubuntu-desktop should pull in libmetacity0 anymore ... but the image still moans [12:53] ogra: just interrupt for a while. we still don't have the patch drop from fsl? [12:53] StevenK borke maximus [12:53] cooloney_, i'll ping the world as soon as they release something [12:54] ogra: thanks, i just ordered a sata cable and try to test my patch on the platform tomorrow [12:54] cooloney_, they said there should be an untested unstable drop by end of this week [12:54] The following packages have unmet dependencies: [12:54] compiz-gnome: Depends: libmetacity0 (>= 1:2.25.8) but it is not installable [12:54] E: Broken packages [12:54] ARGH ! [12:56] Was maximus imported to Bzr yet? [12:56] I thikn StevenK has a spec on this [12:57] no idea, i thought he dropped all UNR work [12:59] he is still doing this for the time being [12:59] ah [12:59] not sure which spec he really puts work in though [12:59] * ogra cries [12:59] i have no idea why compiz-gnome is still tried to install [13:01] I uploaded a fixed maximus [13:02] sigh [13:02] ogra: Is still tried to install? [13:02] EPARSE [13:02] lool, i dropped compipz from ubuntu-desktop [13:02] For armel only I guess? [13:03] but yes, something still pulls it in [13:03] yep, armel only [13:03] Did you seed metacity on armel? [13:03] no, its in the default seed [13:03] The default seed? [13:03] What's that? [13:03] ubuntu-desktop [13:03] Oh it's always seeded already ok [13:03] both WMs are in there [13:03] i just dropped compipz [13:04] -p [13:04] root@babbage2:/# apt-cache rdepends compiz-gnome [13:04] compiz-gnome [13:04] Reverse Depends: [13:04] |gnome-session [13:04] |compiz [13:04] Did you wait long enough that the tasks get updated? [13:04] but gnome session has a "metacity | compiz-gnome | sawfish" [13:04] so it shouldnt be pulled [13:05] no idea, isnt the task updated with the seed commit ? [13:05] which happens long before the -meta is promoted [13:06] Apparently compiz-gnome is still in the seed [13:06] ogra: no, the tasks are updated two publisher runs after the seed is pushed [13:07] *If* at least one package changes [13:07] compiz-gnome was never in the seed [13:07] only compiz [13:07] chdist -a armel apt-cache lucid-armel show compiz-gnome | grep Task [13:07] Task: ubuntu-desktop, edubuntu-desktop, ubuntu-netbook-remix [13:07] It's definitely seeded on armel; it might be because of some dep [13:08] compiz depends on compiz-gnome [13:08] compiz is still seeded on armel ATM [13:08] well, rdepends shows gnome-session but as i said above ... we have metacity to fulfill that [13:08] Again, that might be due to some dep [13:09] Note that gnome-session is listed *first* in the seed [13:09] That said, metacity is listed first in gnome-session's deps [13:10] asac: ping [13:11] asac: im the person who emailed you a few hours back about chromium [13:12] ogra: it might be xinit pulling that [13:12] lool, thats fine ... i was apparently missing the second publisher run [13:12] colin said its gone now in germinate and will be gone after the next publisher [13:14] asac: if you try the link again the PDF should download correctly. it's just slides from a talk I gave a few weeks ago, i'd like to write up my results before i publish it broadly === shenki_ is now known as shenki [13:17] shenki: ok thanks. [13:19] and welcome ;) [13:20] thanks [13:56] everyone cross your fingers ! [13:56] * ogra just fired off an armel live build [13:57] * JamieBennett crosses everything [14:00] heh, ppc and ia64 are not happy ... [14:00] armel still runs though [14:47] me crosses fingers too [14:48] another 30-45min to go until it should spit out the first image [14:49] * asac waits for that [14:49] though i cannot test while this chromium build is going ;) [14:49] maybe i could try "hibernate" ;) [14:51] * ogra glares at the clutter FTBFS log [14:51] -g -O2 -g -Wall -O2 -march=armv5t [14:51] err [14:52] WTF [14:53] CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) [14:53] ifeq ($(CPU),arm) [14:53] CFLAGS += -march=armv5t [14:53] endif [14:53] GAR ! [14:53] how silly is that ! [14:58] ogra: in rules? [14:58] yeah [14:58] rules is about ten lines [14:58] thats one half [14:59] isnt ifeq (armel,$(DEB_BUILD_ARCH)) better? [14:59] i mean for the test (not for the flag ;)) [15:00] yes, that too [15:00] the whole chunk of code needs to go anyway though [15:01] * ogra will take care for it tomorrow after the freeze [15:01] who packaged that? [15:01] clutter upstream? [15:01] or debian? [15:01] debian i think [15:01] * ogra checks [15:02] well, upstream are DDs [15:02] Ross Burton worked for openhand last i checked [15:02] tell him that march is toolchain business ;) [15:03] and CPU is bad ;) [15:03] funnily i cant find anything that mentions why the arch was hardcoded [15:03] * Use LDFLAGS/CFLAGS vars directly to avoid overriding them completely; bdep [15:03] on cdbs >= 0.4.41 [15:03] armin76 said that debian made hacks to support armv4 or something [15:04] thats all i find even mentioning CFLAGS [15:04] maybe it didnt work for clutter so they forced armv5 [15:04] and thats a patch from lool [15:04] who i cant imagine doing something like above [15:04] no git/bzr for packaging? [15:04] dont we have debian bzr imports already? [15:04] or still "just" ubuntu? [15:05] we should have debian as well as upstream imports [15:05] right. so checking there when that line was modified might give a clue [15:05] when this was added at least [15:06] unless we didnt import at that point yet [15:06] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478152 [15:06] Debian bug 478152 in clutter "clutter: needs armv5 on arm/armel" [Normal,Fixed] [15:07] ugh [15:08] sorry :p [15:08] heh [15:09] we could probably make that conditional or some such ... so it doesnt executed when building on ubuntu [15:09] *doesnt get [15:09] the code that the bug references is no longer there. there are two places that are ifdef __arm__, and they contain instructions that are common to all variants [15:10] so you can drop the arch check, imo [15:10] though is debian building for anything smaller than v5 ? [15:10] i thought it defaults to v5 too now [15:10] ah, even better [15:19] asac: the CPU test covers any ARM distro, e.g. arm, armel, and perhaps future stuff like armelhardfloat [15:19] I don't think it's necessarily better to use the deb arch instead of the gnu cpu [15:19] build is wrong though, should be host [15:20] well, its apparently obsolete anyway [15:20] The current rules say CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) [15:21] So these are correct [15:21] yes, thats what i pasted above [15:21] asac wrote DEB_BUILD_ARCH though [15:21] yeah at least host [15:21] yes, why is host arch better here ? [15:21] For cross-compiling [15:21] x-compile [15:21] yes [15:21] host is where it will run [15:22] ah [15:22] the stuff i never do :P [16:16] ah ... at least didnt fail yet [16:17] well, it usually takes 1.5h per image === bjf-afk is now known as bjf [16:51] ogra: what CFLAGS you guys use? [16:53] ok, found it at https://wiki.edubuntu.org/ARM/Thumb2 [19:17] fta: fixed the skia build probs on arm wo armv7 [19:17] which pbs? [19:18] fta: it failed a) trying to build SSE and b) missing some opts files when SSE was excluded for arm [19:19] hm [19:19] one second [19:19] i cannot do a diff because i dont have the original source unpacked anymore [19:19] let me give you the full file ;) [19:19] http://pastebin.com/f482b739d [19:20] so what i added as an "arm" only section [19:20] well all-"arm" section [19:20] that exluces the SSE2.cpp and adds the other files that are also added for armv7 [19:20] actually we can remove the files from the armv7 block too [19:20] one second [19:21] fta: http://paste.ubuntu.com/338224/ [19:22] and remove those two blocks from the armv7 section [19:22] so http://paste.ubuntu.com/338225/ [19:24] asac broke launchpad [19:25] how? [19:25] still works for me ;) === bjf is now known as bjf-afk [19:27] ok restarted build with WANT_TESTS=0 ;) [19:49] fta: ok so WANT_TEST=0 fails to biuld as there are differences (or maybe just because i aborted a half built test build before) [19:49] chromium-codecs-ffmpeg depends on chromium-browser (>= 4.0.203.0~); however: [19:49] thats bad [19:50] two sided depends ;) [19:50] one of those should be dropped [19:50] i guess this one [19:51] it was for a transition [19:53] hmm. yeah. but pleaes drop it ;) [21:30] is it now possible to compile my code for arm on lp? [21:36] or should i squeeze everything out of my n800? === bjf-afk is now known as bjf [21:52] playya_: squeeze [21:52] :/ [21:53] i should use the 2 GB card for /var/cache [21:54] but i can upload it to my ppa? [21:59] playya_: ppas dont build for arm [21:59] and you can only upload sources there [21:59] ok [21:59] bye bye n800 [21:59] hehe [21:59] see you in the next decade [22:00] afair there's a bug report for it [22:00] and the arm machines are quite idle most of the time [22:00] i just want to build the fso stuff :( [22:01] playya_: they are usually busy [22:02] and break regularly atm [22:02] now is freeze time [22:02] thats why they are (luckily) idle [22:02] just saw the load on a info page [22:02] https://edge.launchpad.net/builders [22:02] maybe that was on the end of a release cycle [22:03] s/on/at/ [22:52] asac, still there? [23:00] fta: yes [23:00] bb in 5 min [23:01] asac, want me to bring the chromium/codec dev here? so it's faster and i don't act as a relay [23:03] fta: why not ;) depends when he can make it though [23:04] http://pastebin.com/f65476f12 [23:04] that was the patch ... the other was about arm + fPIC afair [23:05] hold on, asking [23:11] fta: when basetest is running are all the debs already produced? [23:11] nope, debs are created at the end [23:11] oh no :( [23:11] this thing from yesterday is still running [23:12] lol [23:12] thats not acceptable ;) [23:12] maybe we should skip the test on arm then [23:12] maybe i should really try qemu ;) [23:12] testS [23:12] i think so ... for now [23:13] ipc_tests now [23:14] awong, welcome! [23:14] hello! [23:15] hi [23:15] asac, could you please summarize the situation? [23:15] situation is that the -codecs package failed because of relocation issue on armel ... adding -fPIC fixed that [23:16] then that revealed that there seems to be some code built that isnt built on other archs in libavdecoder/aac.c [23:16] this: http://pastebin.com/f65476f12 makes it build [23:16] but i am not sure if its right ... though i saw other tests for that constant [23:16] cool. [23:16] so now it actually built here [23:17] awong: so wonder if you know why -fPIC is not added for armel (though it is for amd64) [23:17] or any reason not to add that on i386 too? [23:17] e.g. everywhere? [23:17] I actually do know the reason. :D [23:17] cool. can you fix that ;)? [23:18] i think -fPIC everywhere should be ok [23:18] For arm, it's an oversight. We've only recently trying to fix the arm build. The -fPIC and -DPIC will probably get added soon (fbarchard has some changes in flight so I don't want to get into the mix quite yet). [23:18] also please ccheck the patch above and commit that too if thats ok ;) ... so we get building packages [23:18] hmm [23:18] As for i386, -fPIC can't work. [23:18] cant? [23:18] nope. [23:19] can you elaborate? [23:19] Not unless you disable a whole bunch of the ffmpeg assembly. [23:19] If you look at the current debian packages, -fPIC is actually disabled on ia32 builds of ffmpeg because of this. [23:19] Basically, they need the extra register (ebx specifically) free to do some of their more optimized routines. [23:19] i saw it wasnt used [23:19] and thats why i thoght that adding everywhere is wrong as it felt intentional [23:20] awong: so when is his arm work going to land? [23:20] (fbarchard) [23:20] i'll walk over and ask him in a sec... [23:21] For your patch, if you could submit a crbug.com with the patch, that'd be the easiest way to get it committed. [23:21] i hoped someone else can do that ;) [23:21] http://dev.chromium.org/developers/contributing-code [23:21] felt complicated when i last looked [23:22] at least for drive-by contributors [23:26] aac should be built for all arches with the non-free flags [23:27] asac: the issue is that since it's your patch, we want to make sure the attribution is right. [23:29] As for the arm stuff, fbarchard says he'll probably have something in a day or two. [23:29] ok thanks. [23:30] i dont even know where the ffmpeg code i patched is in svn ;) [23:30] hah [23:31] its not in third_party/ffmpeg for sure [23:32] fta: where do you produce that ffmpeg-mt thing from? [23:32] the tarballs inside the tarball? [23:32] yes [23:32] ffmpeg-mt [23:32] i just get them from chromium [23:32] where? [23:32] untouched [23:32] i dont see them in svn [23:32] http://src.chromium.org/viewvc/chrome/trunk/src/third_party/ffmpeg/ [23:33] http://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/ [23:33] yep, same [23:33] nothingthere is nothing in it [23:33] no libavdecoder/aac.c ;) [23:34] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ [23:34] its different [23:34] crazy ;) [23:35] so this whole patch is not possible ;) [23:35] http://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/aac.c [23:35] hmm [23:35] yeah [23:35] ok [23:35] i can do that i hope [23:35] ;) [23:35] so, I can do the uploading of the patch and landing [23:36] but I think you still need to follow a few of the steops in http://dev.chromium.org/developers/contributing-code about the Individual COntributor License Agreement, and getting your name into the Authors file. [23:37] just for this minimal patch. cant you shuffle it a bit and then submit ;) [23:37] hah. [23:42] unforutnately, I don't htink that's quite cool. Frank's got a few changes for ARM in the air currently and will likely have fixed this same issue since it doesn't compile w/o it. Let's let his stuff land first and then we can hopefully just side-step this. [23:43] it's silly, I know...but not being a lawyer, I don't know the consequences, blah blah. [23:46] i now did all the gcl stuff ;) [23:46] so you want me to abort that? [23:46] heh [23:47] up to you man. If you're most of the way there, I'm happy to review and land for you. [23:48] awong: right. wonder if its a problem that i only checked out the libav*/ directory ... i assume gcl gets it right from svn info? [23:48] btw, on your guys's build, are you doing the full gyp/make thing? If so...how are you building our ffmpeg for arm at all? I don't think we have a config.h checked in for arm. [23:50] asac: I think gcl can handle it. However, bigger issue is that you're going to want to submit a patch to the source tree. [23:50] and add it to http://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/patches/to_upstream/ as patch 51. [23:50] The "patched-ffmpeg-mt-source" directory is autogenerated from the tarball and these patches. [23:50] right [23:50] thats what i planned to do [23:50] ah, ok [23:51] you say on the patch in patches/? [23:51] or both? [23:51] oh [23:51] only the patch in patches/? [23:51] that was the question ;) [23:51] sorry [23:51] ah. yes, that's all you need. [23:52] I'll regenerated the patches tree for you afterwards since Ihave everything already setup. [23:52] ok ... good [23:54] out for a few minutes getting some stuff [23:55] np. I'm here for another hour or so. Othewrise, feel free to e-mail me (ajwong@chromium.org)