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