[11:59] <lool> Heya; I've noticed hildon-fm doesn't build anymore with gtk 2.11.x; I've pushed a fix in 2.11.6-1 in Debian/experimental
[12:00] <Mithrandir> any chance we could convince you to merge that into the branch in LP too? :-)
[12:01] <lool> I don't think gtk is maintained in LP, is it?
[12:01] <Mithrandir> ah, the fix is in gtk?
[12:01] <lool> Yes
[12:01] <Mithrandir> ok, thanks.  I'll ask seb128 to pull it in, then
[12:01] <lool> But I would have merged a fix in an ubuntu-mobile bzred package :)
[12:01] <Mithrandir> seb128: ^^ ; pretty please?
[12:01] <lool> seb128: ^^^
[12:02] <seb128> Mithrandir: yeah, will do it
[12:02] <Mithrandir> thanks a lot.
[12:02] <seb128> you're welcome
[12:02] <lool> seb128: Basically 009_filechooserfoobar and the 070_relibtoolize of course
[12:03] <seb128> lool: I'll just take the Debian package as it is and apply Ubuntu changes
[12:03] <lool> Perfect
[01:00] <GyrosGeier> doko, ping?
[01:01] <doko> GyrosGeier: do you want to propose a m68k port?
[01:04] <GyrosGeier> yes and no
[01:04] <GyrosGeier> I need cross compilers for dapper
[01:04] <GyrosGeier> but I'm not entirely sure about some things
[01:05] <GyrosGeier> debian/rules2 sets -fno-stack-protector if $with_ssp_default is set, for both STAGE1_CFLAGS and BOOT_CFLAGS
[01:06] <GyrosGeier> with this flag, compilation fails, because Dapper's gcc doesn't know it
[01:07] <GyrosGeier> without it, I have undefined symbols in libcpp.a (but only there)
[01:07] <GyrosGeier> so it seems that STAGE1_CFLAGS is used outside of stage 1 when building a cross compiler
[01:08] <GyrosGeier> (the undefined symbols are the check value and abort function of the stack checker
[01:08] <GyrosGeier> also, I'm slightly confused, as I thought that cross compilers are built in a single pass
[01:09] <doko> GyrosGeier: afaik the cross stuff in gcc-4.0 is out of date.
[01:09] <GyrosGeier> but libcpp.a is obviously built with stack-protector
[01:09] <GyrosGeier> it's the most recent gcc package
[01:09] <GyrosGeier> the compiler is allowed to be recent
[01:09] <GyrosGeier> but the people who want it are running Dapper
[01:10] <GyrosGeier> and do not want to upgrade
[01:11] <doko> seems I still do not understand what you want. dapper's gcc doesn't turn on stack-protector by default
[01:11] <GyrosGeier> (so I thought I'd write a script that builds all combinations for all supportable distributions; http://www.emdebian.org/~sjr/toolchains/pool/main/b/binutils/ is my collection of binutils packages
[01:11] <GyrosGeier> doko, that's why I'm confused
[01:12] <GyrosGeier> it doesn't have stack-protector, I think; otherwise it wouldn't fail and complain with -fno-stack-protector
[01:12] <GyrosGeier> but libcpp.a is built with stack-protector
[01:12] <doko> so which package do you try to build?
[01:13] <GyrosGeier> ATM most recent gcc-4.2 as found in Debian sid (I understand that should be identical to the one in gutsy)
[01:14] <GyrosGeier> build environment is Dapper, with backported dpkg and binutils
[01:14] <doko> well, then start to backport gcc-4.2 to dapper; I didn't do that
[01:15] <GyrosGeier> you are the sole Uploader in the gcc-4.2 package
[01:16] <GyrosGeier> essentially, this is what I'm doing; gcc-4.2 only builds with a fairly recent gcc, it seems
[01:16] <GyrosGeier> (or at least the build-deps claim so)
[01:19] <doko> gcc-4.2 should build with dapper's gcc as a bootstrap compiler
[01:20] <GyrosGeier> nope; that's why I'm asking.
[01:21] <GyrosGeier> it fails because of -fno-stack-protector and (later) because of ld --hash-style=both
[01:21] <GyrosGeier> the latter is why I backported binutils first
[01:22] <doko> for a native build?
[01:23] <doko> not a cross?
[01:23] <GyrosGeier> native build also fails.
[01:24] <GyrosGeier> IIRC it was also -fno-stack-protector
[01:25] <doko> well, try to build a compiler first, without stack-protector as the default, then use that as the bootstrap compiler; or find out why it wants to use the -fno-stack-protector option for the stage1 compiler
[01:26] <GyrosGeier> doko, debian/rules2 sets that option unconditionally when it builds a compiler with stack protector
[01:27] <doko> well, then remove it?
[01:27] <GyrosGeier> then the linking fails, as described above, because libgcc gets compiled with stack-protector enabled
[01:28] <GyrosGeier> a cross build shouldn't build a bootstrap compiler, should it?
[01:29] <doko> then go back to use a bootstrap compiler which understands -fstack-protector
[01:30] <GyrosGeier> okay
[01:31] <GyrosGeier> also, debian_rules.defs lines 402 to 405 seem wrong
[01:31] <GyrosGeier> ssp_no_archs is first set conditionally for cross builds, and then unconditionally overwritten
[01:32] <GyrosGeier> fixing that doesn't change anything for me, interestingly
[01:43] <seb128> Mithrandir, lool: GTK synced and libhildonfm builds fine again
[01:43] <seb128> s/synced/merged
[01:44] <Mithrandir> thanks a lot
[01:54] <agoliveira> seb128: Yey! )
[01:54] <seb128> you're welcome
[01:54] <agoliveira> :)
[03:09] <Mithrandir> once moblin-image-creator hits, I _think_ we should be able to build images properly
[03:10] <GyrosGeier> w00t
[03:10] <GyrosGeier> where can I take a look at the image creator?
[03:11] <Mithrandir> apt-get source moblin-image-creator on a gutsy system, or git clone rsync://moblin.org/tools/moblin-image-creator.git
[03:11] <GyrosGeier> thanks
[03:12] <GyrosGeier> @ERROR: Unknown module 'tools'
[03:13] <GyrosGeier> repos/tools
[03:17] <Jonathan_Cardozo> GyronsGeier use the console syntax
[03:17] <Jonathan_Cardozo> in my feisty fawn ucurred this to
[03:47] <GyrosGeier> git clone rsync://moblin.org/repos/tools/moblin-image-creator.git
[03:48] <GyrosGeier> that is what I was trying to say
[03:54] <Jonathan_Cardozo> Gyros, this line copy a tree of source from moblin0image-creator, the last release of tha
[03:55] <Jonathan_Cardozo> copy and compile in you machine
[03:56] <GyrosGeier> yes
[03:56] <GyrosGeier> the path was wrong before
[04:19] <Hub441> hi!
[04:21] <lool> Hmm, I think there's something wrong with https://code.launchpad.net/~vcs-imports/hildon-fm-l10n/trunk the SVN has way more revisions than this mirror
[04:22] <lool> Who can I ask to update it to track stage.maemo.org/maemo/projects/haf/trunk/hildon-fm-l10n instead of whatever it tracks?
[04:23] <Mithrandir> Adilson is the registrar, so he should be able to see where it pulls from
[04:24] <Mithrandir> agoliveira: ^^ ; could you please tend to this?
[04:25] <agoliveira> Mithrandir, lool, No problem
[04:25] <Mithrandir> thanks
[04:25] <lool> agoliveira: thanks!
[04:25] <lool> Mithrandir: How can I see who's the registrar?  I saw "VCS imports" on launchpad
[04:26] <Mithrandir> click on the project, then on overview and then on the lifecycle portlet.
[04:27] <lool> Got it; thanks
[04:30] <agoliveira> Hmmm... looks like even being the registar, I don't have the rights to change where to import it from.
[04:41] <agoliveira> lool, the current hildon-fm-l10n is being imported from stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-fm-l10n-2.0. Are you sure we should move it to stage.maemo.org/maemo/projects/haf/trunk/hildon-fm-l10n?
[04:43] <agoliveira> lool, if you confirm that, I will have to ask someone from the VCS team to change it as, once the import starts, only them can do it.
[04:44] <agoliveira> Well, I'm going lunch now.
[04:45] <lool> agoliveira: The SVN log I have from the 2.0 branch seems to be included in the 3.0 branch which I think is "stage.maemo.org/maemo/projects/haf/trunk/hildon-fm-l10n"
[04:45] <lool> agoliveira_lunch: And they seem to be tracking this branch in repository.maemo.org/pool/sardine
[04:46] <lool> agoliveira_lunch: But these are all my guesses; I do think this is a newer version, but there's an inconsistency between the SVN and the archive (version in archive is slightly older than SVN)
[05:55] <agoliveira> lool: You're seen to be right about it. I'll ask for the change. Thanks for pointing that out.
[05:56] <lool> Cool, thanks
[05:59] <agoliveira> lool: Thank you :) I already requested the change.
[08:07] <CharliefJohnson> amitk_: Did you get adequate response to your comments on the mobile-power-thermal-optimizations blueprint ?? 
[08:12] <CharliefJohnson> Amit - Are you online?
[08:12] <amitk_> CharliefJohnson: not yet. We are supposed to have a conf call thurs/fri
[08:13] <amitk> CharliefJohnson: sujith requested a conf call to discuss the blueprint
[08:14] <CharliefJohnson> amitk: That's good.  That will allow for a much higher bandwidth discussion.  Thanks.
[08:17] <amitk> CharliefJohnson: Would it be possible to get them on IRC or discuss on the UME mailing lists on a regular basis? That might allow others in canonical to keep abreast of the discussions.