[08:26] <keesj> Hi, I want to get started on ubutunu-arm. I currently want to target qemu-arm versatile (possibly using the arm11 cpu) and would like to use 9.10 and rootstock. Would this be recommented (elinux.org has a "ok" turorial when using beagle + rootstock the topic links on this irc channel point to what looks to the old way of doing things)
[10:04] <lool> keesj: this is incompatible
[10:05] <lool> keesj: It can work with a patched versatile kernel though
[10:06] <lool> keesj: I think there is such a kernel in the development release now, or you can get some binary ones in some places
[10:07] <lool> keesj: Just FYI, the real hardware named "versatile" which qemu emulates only supports up to v5 ATM
[11:03] <armin76> lool: question: now that karmic is the latest released version, does that mean that jaunty doesn't get any update anymore?
[13:26] <lool> armin76: In terms of where developers spend their time, I don't think many stable updates will happen in jaunty, it's not impossible but unlikely; but of course security support continues and if critical bug fixes need to be addressed in jaunty they can be
[13:26] <lool> armin76: Even at this point, karmic is much less of a focus than lucid
[13:49] <armin76> lool: ack, thanks
[14:04] <asac> ogra: yes ... my install feels good too ... thats t2 maybe?;)
[14:28] <asac> fta: chromium codecs fails on i386?
[14:28] <asac> wanted to copy it
[14:28] <fta> asac, please don't.
[14:29] <fta> asac, http://code.google.com/p/gyp/issues/detail?id=123
[14:29] <asac> sure
[14:29] <asac> i wont copy if the build fails ;)
[14:29] <asac> fta: would that impact arm?
[14:29] <fta> asac, last comment
[14:29] <fta> probably yes
[14:30] <asac> why did you switch to make just now :(
[14:30] <fta> i thought it was ready
[14:30] <asac> can i disable that manually again?
[14:30] <asac> e.g. just a single rules line?
[14:31] <fta> I don't have common.gypi in this package so most variables have no default during the build (like target_arch, chromeos, branding, library, and guess what.. cflags and ldflags), so i set those in GYP_DEFINES, but it doesn't work for cflags/ldflags.  The build fails with an asm error (the fix is to add the missing -O2) but if i set CFLAGS=-O2, it breaks all the defines and the -I.
[14:33] <fta> nope, it will be the same with scons (unlike for chromium)
[14:41] <fta> asac, ^^, testing my proposed fix right now
[14:43] <asac> what changed that even scons suddenly doesnt work anymore?
[14:45] <fta> scons would work if i also ship the whole src/build/ dir from chromium in the codecs package (and probably other dirs), while i just took the ffmpeg.gyp file, which is enough, in theory
[14:46] <fta> i just loose the defaults, so i have to specify them as i said above
[14:47] <fta> what happens if is say gcc -O2 -Os ? which one is used?
[14:47] <fta> -is+I
[14:48] <asac> feels not right to "loose defaults" ... they might do arch dependent tweaks etc.
[14:48] <asac> i dont think we want to duplicate all defaults in rules
[14:48] <asac> feels like not running configure
[14:48] <fta> that's the whole point of this gyp, not run configure
[14:49] <fta> gyp is a configure rival
[14:49] <fta> in python :S
[14:50] <fta> and upstream is dropping support for scons anyway, so the sooner i move, the better
[14:50] <asac> right. but i expect that the defaults contain detection stuff etc.
[14:50] <asac> yes. but you dropped the defaults ... which feels like a bug
[15:00] <keesj> lool I will be able to create a kernel if needed. still rootstock + qemu-system-arm should be easy right?
[15:08] <fta> asac, i'm pretty conservative here. missing defaults make gyp fail, so it FTBFS for us and we notice. And i set only those: GYP_DEFINES="target_arch=ia32 chromeos=0 branding=Chromium library=static_library use_system_yasm=1". The only problem is cflags/lflags that dpkg-buildpackage wants to overwrite
[15:12] <fta> asac, if i really want to pull src/build too, that would mean 3 svn to pull to create the tarball.
[15:13] <fta> asac, i already name my stuff 0.5+svn20091210r34297+34315, i can add a 3rd rev-id :P that would mean rebuilding more often (for any commit in src/build, even totally unrelated)
[15:15] <fta> i should start a contest of the longest version ever used for a package
[15:35] <lool> keesj: Yes
[15:48] <keesj> thanks
[15:49] <asac> fta: isnt it like "extra_cflags=..:" ?
[15:51] <fta> asac, no, not without src/build :(
[16:21] <fta> asac, chromium-codecs-ffmpeg_0.5+svn20091210r34297+34315+34433.orig.tar.gz uhuh
[16:22] <asac>       self.WriteLn("$(OBJS): CFLAGS := $(CFLAGS_$(BUILDTYPE)) "
[16:22] <asac> shouldnt that be
[16:22] <asac>       self.WriteLn("$(OBJS): CFLAGS += $(CFLAGS_$(BUILDTYPE)) "
[16:22] <asac> ?
[16:22] <asac> in make.py
[16:22] <asac> (gyp)
[16:23] <fta> won't work, as make CFLAGS="-g -O2" would overwrite it anyway
[16:23] <asac> += ?
[16:23] <fta> yes
[16:24] <fta> asac, http://paste.ubuntu.com/340609/
[16:24] <asac> yes thats ok too
[17:47] <fta> asac, i'm done fixing the codecs
[19:10] <fta> asac, you can copy the codecs now, they are all green in lucid. you need to copy gyp too (a new build-dep)