[00:00] <apachelogger> last kdelibs upload also was feb 15
[00:00] <persia> So, we'd expect kdelibs to work
[00:00] <apachelogger> yes, reinstalling kdelibs5 - unity still works
[00:00] <persia> But kdebase is broken (uses old binaries)
[00:01] <apachelogger> looks like it
[00:01] <persia> http://launchpadlibrarian.net/62899430/buildlog_ubuntu-natty-armel.kdeartwork_4:4.6.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[00:02] <apachelogger> that is an intersting fail
[00:02] <persia> NCommander, Did you say that the bottom of the KDE stack is kdebindings?
[00:03]  * apachelogger loves how bindings always breaks arm building
[00:05] <ogra> lool, well, i think running_subarch is the wrong approach for consistency, all other arches use a fixed value apart from the ubuntu subarch detection stuff, i was more after finding out if imx51 is the right arch to use here (i'm not sure which flavour name is used on the efikas)
[00:05] <apachelogger> uhhhh
[00:05] <apachelogger> Program received signal SIGSEGV, Segmentation fault.
[00:05] <apachelogger> 0x414fbee0 in ?? () from /usr/lib/libphonon.so.4
[00:06] <persia> ogra, imx51 is the kernel flavour (linux-linaro-imx51)
[00:06] <ogra> ok
[00:06] <apachelogger> phonon needs a rebuild against ubuntu9
[00:08] <lool> persia, ogra: I checked the build log, and the vmlinuz file is called
[00:09] <lool> boot/vmlinuz-2.6.37-1003-linaro-mx51
[00:09] <lool> so maybe it should be linaro-mx51?
[00:09] <ogra> aha !
[00:09] <NCommander> persia: yeah
[00:09] <ogra> thanks !!
[00:09] <lool> just a guess
[00:09] <lool> it might be sed-ed down to mx51
[00:09] <persia> lool, Oh, maybe.  Is "linaro" part of $FLAVOUR?
[00:09] <ogra> i'll test that tomorrow before i upload
[00:09] <ogra> persia, doesnt matter :)
[00:10] <ogra> it depends what the sed command drops out
[00:10] <ogra> and i'll use that
[00:10] <lool> uname -r says 2.6.37-1003-linaro-mx51
[00:10] <persia> ogra, Yes it does: we ought be semantically correct.  if we're not, then we have a kernel bug.  If we are, then we may have a sed bug.
[00:10] <lool> persia: What's $FLAVOUR?
[00:10] <persia> Otherwise it all becomes guesswork.
[00:10] <ogra> in the context atm it doesnt matter, i wont change the function
[00:11] <lool> CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.37-1003.6-linaro-mx51 2.6.37"
[00:11] <ogra> i will just add the right value to the one line change i do so it matches the kernel naming
[00:11] <persia> lool, It's the type of kernel built.  I believe it's defined by the existence of./debian.${ENV}/config/vars.${FLAVOUR}
[00:12] <persia> ogra, OK.  Don't blame me if I change the kernel and you have to do it again.
[00:12] <lool> So I checked flash-kernel and check_subarch compares with subarch which is set as subarch=$(echo "$kfile" | sed -e 's/.*-//')
[00:13] <ogra> persia, why would you change linaro kernels ?
[00:13] <lool> so the correct subarch would be mx51
[00:13] <ogra> k
[00:13] <ogra> i would have checked that anyway
[00:13] <persia> ogra, Because when *any* package in Ubuntu is semantically wrong, I get annoyed at it.
[00:13] <apachelogger> ^^
[00:13] <ogra> i'm to tired to upload tonight
[00:13] <lool> persia: Oh ok; I thought you meant some runtime thing
[00:14] <persia> lool, No.  If you don't know offhand, I'll check the linux-linaro source.  I suspect that "linaro" is not part of the flavour, but just want to make sure.
[00:15] <persia> apachelogger, Indeed: phonon built nicely against ubuntu8, sadly.
[00:15] <persia> NCommander, Do you know which was the first revision of qt4-x11 to have issues?
[00:15] <lool> looking at 2.6.37-1003.6, I see the config is named config.flavour.linaro-mx51
[00:15] <lool> persia: ^
[00:15]  * persia thinks it might be best to ask for a mass-rebuild from an LP-generated lsit
[00:16] <apachelogger> persia: if that is the issue at all ;)
[00:16] <apachelogger> phonon ubuntu4 uploaded, should be finished in some 20 minutes
[00:17] <persia> lool, Indeed.  I'm not sure that's how it ought be done: I think it would make more sense to have linux-linaro as SRCPACKAGE, with flavours "mx51", etc.  So we'd end up with linux-linaro-image-foo-mx51 rather than linux-image-foo-linaro-mx51
[00:17] <persia> apachelogger, Let's see.  NCommander said it was at :09
[00:19] <lool> persia: Ah I can speak in favor of linux-image-*: apparently this pattern is used in places like d-i, and it's a bad idea to diverge from it
[00:20] <NCommander> persia: it was an issue with GCC, not qt
[00:20] <lool> persia: it was a design choice to have the packages be named linux-image-linaro-foo rather than linux-linaro-image-foo
[00:20] <persia> NCommander, I understand the root, but would the miscompiled qt4-x11 cause the segfaulting apachelogger is seeing in phonon?
[00:20] <lool> it's quite a dance to get this right across all binary packages and meta packages
[00:21] <persia> lool, I understand.  I don't like it.  I hope you understand why I don't like it.  I'll leave it alone for now.
[00:21] <persia> (and thanks for reminding me: I have to do a -meta)
[00:23] <persia> Oh, and to be clear, I don't care about linux-image-linaro-foo-mx51, it's the linux-image-foo-linaro-mx51 I don't like (but the former is hard to arrange with the kernel packaging scripts as they exist)
[00:24] <lool> ah with foo you meant ABI and version
[00:25] <lool> yeah linux-image-linaro-foo-mx51 is hard
[00:25] <persia> Yeah.
[00:25] <lool> more of a limitation
[00:25] <persia> I'm not sure it's a limitation, just would need definition and insertion of $VENDOR
[00:26] <lool> I mean, it's just not provisioned in the current implementation
[00:26] <persia> I'd like to fix it at some point, so that $FLAVOUR as defined in the kernel packaging and $FLAVOUR as detected by the many sed scripts again have the same value.  Doesn't have to be soon.
[00:30] <GrueMaster> persia: I think the fix in qt4-x11 is only temporary to disable precompiled headers.  The real fix is in gcc, and I am not sure if that has been released to update the toolchain.  If that is the case, we may need to rebuild kde with precompiled headers off as well.  Not sure.
[00:30] <persia> Probably just an entry in debian.linaro/control.d/vars.* and corresponding bit in flavour-control.stub, really.
[00:30] <GrueMaster> apachelogger: ^^^
[00:31] <persia> GrueMaster, apachelogger just tried a test recompile with phonon to see if that's sufficient.  We'll know more RSN
[00:31] <GrueMaster> Sorry, I was at the UPS store earlier.
[00:31] <GrueMaster> I don't think a simple recompile will fix it, but I could be wrong.
[00:32] <GrueMaster> NCommander: want to weigh in?
[00:32] <persia> More testing is welcome :)
[00:33] <persia> GrueMaster, What's the name of the maverick dove kernel meta package?
[00:34] <ogra> linux-mvl-dove
[00:35] <GrueMaster> Yep.  Was just verifying.
[00:35]  * ogra had to fight with the headers on the weekend ...
[00:35] <persia> ogra, That's real kernel, not the meta.
[00:35] <ogra> else i would have had to look it up too :)
[00:36] <apachelogger> still segfaulting \o/
[00:36] <ogra> persia, nope. thats the meta
[00:36] <persia> Not according to the source I'm looking at.
[00:36] <ogra> linux-image-mvl-dove is the kernel
[00:36] <persia> Ah, maybe I should ask: what's the name of the source package that provides that?
[00:36] <ogra> well, the kernels meta
[00:37] <apachelogger> GrueMaster, persia: rebuild apparently does not help :S
[00:37] <persia> NCommander, Any suggestions for workarounds that could help apachelogger?
[00:37] <ogra> persia, linux-meta-mvl-dove
[00:38] <persia> Thanks!  That's the one permutation I didn't try before giving up.
[00:38] <ogra> and the binaries of meta and kernel are actually just linux-dove and linux-image-dove
[00:39] <ogra> dunno where the mvl vanished to
[00:39]  * apachelogger installs dbg symbols
[00:39] <persia> ogra, The kernel packaging hackery fails to define VENDOR consistently (see above), with results like that.
[00:40] <ogra> yep
[00:40] <ogra> well, its gone from the archive since last week
[00:40] <ogra> so nothing to worry about anymore
[00:40] <ogra> (for now)
[00:40] <persia> Fixing it probably means me generating some PoC kernel hackery, and taking it to UDS, and getting it applied to all vendor kernels.
[00:41] <persia> Still have TI and Linaro kernels in the archive though.
[00:41] <ogra> well, linaro wants to have the branding in the package name as i understand
[00:41] <apachelogger> yay
[00:41] <apachelogger> http://paste.ubuntu.com/568547/
[00:41] <apachelogger> looks familiar
[00:41] <ogra> and TI can hopefully be built from upstream next round
[00:42] <persia> Yes, but there's always going to be reasons why vendor kernels are interesting, and it makes sense to do them right, rather than half-way and hackishly
[00:42] <ogra> agreed
[00:42] <apachelogger> persia: supposedly gcc 4.5 should be fixed, otherwise we'd need a pile of force-gcc-4.4 changes
[00:42] <ogra> i just meant its not for natty
[00:43] <ogra> anyway, nearly 2am ...
[00:43] <persia> Oh, indeed.  See earlier comment about UDS.
[00:43] <persia> Good night :)
[00:43]  * ogra vanishes
[00:43] <persia> apachelogger, The Linaro GCC team was looking at it.  I don't know current status.
[00:53] <XorA|gone> morning
[00:54] <persia> Good morning.
[00:54] <NCommander> apachelogger: persia I'm honestly not sure why sip is choking
[00:55] <persia> NCommander, I'm not fussed about sip: I'm concerned about phonon segfaulting, when it wasn't before.  Does *everything* have to be rebuilt, or is there a workaround of some sort?
[00:56] <persia> And if everything is rebuilt, will it need to be rebuilt again once gcc is fixed?
[00:57] <NCommander> persia: I wasn't aware of phonon segfaulting
[00:58] <NCommander> persia: that beign said, since we were dealing with a miscomplication, everything might need a bump-build :-/
[00:58] <persia> That's not enough.
[00:58] <persia> So, phonon was built against qt4-x11 ...ubuntu8, which was broken.  It segfaulted.  apachelogger rebuilt it against ...ubuntu9, which is the latest.  Same segfault.
[00:59] <persia> konsole is even segfaulting.
[00:59] <apachelogger> NCommander: http://paste.ubuntu.com/568547/
[01:00] <NCommander> apachelogger: what hardware are you one?
[01:02] <apachelogger> NCommander: n900
[01:02] <GrueMaster> apachelogger: Try building with gcc-4.4 & adding -no-pch to the extra_configure_opts.  This is what was needed to get a working qt.
[01:03]  * apachelogger i going to bed in a bit
[01:03] <GrueMaster> Just building with gcc 4.4 isn't enough as 4.4 has a bug with precompiled headers.
[01:03] <apachelogger> GrueMaster: I do not think that was built against 4.4 at all
[01:03] <apachelogger> just a rebuild against new Qt
[01:03] <persia> NCommander, Are we going to need to rebuild a significant chunk of the archive like that?
[01:04] <apachelogger> which does not help as the function in question seems to be inline
[01:04] <GrueMaster> I'm referring to gcc 4.4 not qt 4.4
[01:04] <apachelogger> GrueMaster: that is what I meant too ;)
[01:18] <NCommander> persia: I honestly don't know at this point
[01:20] <persia> See, if qt4-x11 is broken, I'm sorely tempted to upload a replacement that causes everything to fail to built against it, to reduce the number of times we have to reupload stuff later.
[01:25] <NCommander> persia: but its not broken, unity-2d now works fine against it
[01:25] <NCommander> as do other Qt apps, the problem seems tobe kdelibs
[01:27] <persia> Ah, so Qt works, but KDE is broken?
[02:36] <ScottK> It can't be too broken as I can build against it.
[02:36] <ScottK> persia: ^^^
[02:38] <persia> ScottK, Sure, but if you're building with an inline macro that generates a segfault at runtime, you may not find the results very useful.
[02:38] <ScottK> True, but I'm bulding kdebindings.  I think kdelibs has to actually do stuff for that to work.  Not sure though.
[02:40] <persia> I don't know.  From what I can tell from IRC traffic and bugs, it seems that there are two issues: firstly that gcc-4.5 has a reference count issue meaning that inlines in nested functions can break stack accounting, and gcc-4.4 has an issue with precompiled headers not being compiled in a way that safely allows reuse.
[02:40] <persia> This only affects some code, with certain sorts of inline macros.  Where that would be hit isn't clear.
[02:42] <ScottK> We'll re-upload all of KDE before release, so it should be ~fine as long as it's sorted soon.
[02:42] <persia> I don't think it would be advantageous to apply workarounds to everything that seems dodgy, but a simple rebuild (as tested with phonon) doesn't seem to help.
[02:42] <persia> There's a candidate patch under review by the Linaro gcc team for gcc-4.5, which looks like it might do the right thing.
[02:42] <persia> (at least in terms of generated RTL)
[02:43] <persia> I'm mostly concerned about the timing: with feature freeze and Alpha 3 coming up relatively soon.
[12:35] <ndec> ogra: hi! any news regarding the alsa upgrade in the archive?
[12:35] <ndec> persia: ^^^ you might be interested too
[12:58] <ogra> ndec, i havent heard from TheMuso yet buut pinged him
[13:21]  * XorA|gone dances
[13:23]  * ogra shades his eyes
[13:26] <apachelogger> GrueMaster, NCommander, persia: building phonon with gcc 4.4 and -no-pch seems to fix the segfault there ... so I guess we need a fixed gcc 4.5 or the better part of Qt based libs will have to get that workaround :/
[13:27] <apachelogger> actually I have semi-random segfaults now, so clearly nothing in phonon ^^
[13:27] <ogra> apachelogger, talk to the toolchain guys in #linaro
[13:27] <ogra> they will be intrested in debugging data to track down and fix the compiler issue
[13:29] <ogra> they solved our last issue within two days
[13:29] <ogra> (though it took two weeks to get them the right data and actually prove its gcc)
[13:29] <apachelogger> oh
[13:29] <apachelogger> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/705689/comments/30
[13:29] <ubot2> Ubuntu bug 705689 in gcc-4.5 "Qt applications crash with segfault error on armel when Qt is built with gcc 4.5 on natty" [High,Confirmed]
[13:30] <apachelogger> seems they have a patch already
[13:30] <ogra> yes
[13:30] <ogra> i dont think gcc was uploaded since
[13:30] <ogra> ask linaro if they ahve a testbuild in a ppa or so
[13:50] <kenws> Hi there, Does anyone know where to find the ddebs for natty?
[13:50] <kenws> The following apt.sources line doesn't seem to work:
[13:50] <kenws> deb http://ddebs.ubuntu.com natty main restricted universe multiverse
[14:01] <ogra> kenws, well, it should looking at http://ddebs.ubuntu.com/pool/main/ there are armel versions
[14:02] <kenws> ogra: thanks, do you know how the corresponding apt.sources line would look like?
[14:02] <kenws> brb
[14:03] <ogra> the above should technically work
[14:13] <ogra> kenws, did you run apt-get update after adding the line ?
[14:13] <ogra> https://wiki.ubuntu.com/DebuggingProgramCrash ha smore details
[14:15] <ogra> you might need to add the key etc
[15:33] <Neko> http://blog.efikamx.info/2011/02/one-kernel-to-rule-them-all.html Efika MX Smartbook devs might want to build a shiny new kernel from here :)
[15:54] <kenws> ogra: hm, this exactly what I'm using in my sources list
[15:55] <ogra> kenws, and you did apt-get update
[15:55] <ogra> kenws, and also impotred the gpg key
[15:55] <kenws> ogra: yes
[15:55] <kenws> also yes
[15:55] <kenws> http://pastie.org/1579164
[15:55] <kenws> http://pastie.org/1579161
[15:55] <ogra> https://wiki.ubuntu.com/DebuggingProgramCrash
[15:56] <kenws> ogra: yeah, and it matches what I have or am I blind? : )
[15:57] <ogra> how do you try to get a ddeb ?
[15:57] <ogra> you need a special invocation of apt for that
[15:57] <ogra> its documented on the page too
[16:00] <ogra> (point 6)
[16:01] <kenws> ogra: but the apt-get update fails to fetch the Packages.gz that is before the user installs any ddebs
[16:01] <ogra> weird
[16:01] <ogra> http://ddebs.ubuntu.com/dists/natty/main/binary-armel/
[16:02] <ogra> Packages.gz is there
[16:02] <kenws> yep, but what about natty-updates, natty-security and natty-proposed?
[16:03] <ogra> no security updates in the dev release ;)
[16:03] <ogra> nore -updates or -proposed test archives
[16:03] <kenws> point 2 of that wiki page seems to indicate that they shoul be there
[16:04] <ogra> for a release they are
[16:04] <ogra> but natty isnt released yet
[16:04] <kenws> ok, i see
[16:04] <kenws> ogra: thanks for your patience : )
[16:04] <ogra> np :)
[16:11] <NCommander> apachelogger: *groan* :-(
[16:14] <ogra> Bug 721121
[16:14] <ubot2> Launchpad bug 721121 in humanity-icon-theme "Icon in Launcher should be home folder icon" [Medium,Triaged] https://launchpad.net/bugs/721121
[16:14] <ogra> heh
[16:17] <GrueMaster> You should see the comments.
[16:18] <apachelogger> NCommander: only that bug is keeping us from having an almost rocking kubuntu mobile :(
[16:19] <apachelogger> kernel is close to inclusion too
[16:22] <apachelogger> ScottK, mpoirier: http://people.ubuntu.com/~apachelogger/tmp/sshot1.png
[19:57] <Neko> https://bugs.launchpad.net/update-manager/%20bug/610820
[19:57] <Neko> is anyone ever going to fix this?
[19:58] <prpplague> Neko: that the full url?
[19:58] <Neko> https://bugs.launchpad.net/update-manager/+bug/610820
[19:58] <ubot2> Ubuntu bug 610820 in update-manager "Download size discrepancies" [Undecided,Confirmed]
[19:59] <Neko> on ARM it says 704MB, 740MB, 74.0MB or some variation, it's so weird that it always has a 7 and a 4..
[21:56] <Homefix> anyone here i can annoy?
[21:57] <Homefix> Hello? anyone
[21:57] <Homefix> ogra:
[21:57] <Homefix> rbelem:
[22:08] <rcn-ee_at_work> Homefix, maybe you should state your question, and if it interest's someone they might answer.. ..;)
[22:20] <Homefix> sorry babysitting had a mess......
[22:21] <Homefix> I am missing var/run/dbus in my chroot using arm lucid build
[22:21] <Homefix> im soory..........
[22:21] <Homefix> im missing.....
[22:22] <Homefix> pid system_bus_socket normal?
[22:26] <Homefix> i must be loosing my mind i am running a ubuntu arm img lucid on my htc evo my article:http://forum.xda-developers.com/showthread.php?t=932754
[22:27] <Homefix> i am able to windows share thru hamachi I thought upstart does not function in that kind ov enviroment?
[22:28] <Homefix> Nautilus does not share, it did with karmic,
[22:30] <Homefix> sksudo nautilus brings up : (nautilus 1010) : WARNING**: Failed to connect to socket /var/run/dbus/system_bus_socket: no such file?
[22:30] <Homefix> Help
[22:32] <rcn-ee_at_work> Homefix, i'd bug the guy who wrote the article.. the people on this list are usually running boards where we have access to everything.. bootloader -> kernel -> rootfs..
[22:32] <Homefix> i wrote it
[22:33] <rcn-ee_at_work> ah fun.. so which kernel do you have on there?  lucid really needs 2.6.32+ ?
[22:33] <Homefix> of corse the kernel is mising bits and peices
[22:34] <Homefix> maybe it might be another issue u could help me with
[22:34] <Homefix> other than the kernel
[22:35] <rcn-ee_at_work> not likely, my chroot's work just fine, using debian squeeze as a base, chroots for (karmic/lucid/maverick/natty)
[22:38] <Homefix> im just looking for a kind help im not as intellegent as most of u people. thats all maybe ill get lucky and find a solution, what have i got to loose besides time. and maybe gain a friend:)
[22:39] <rcn-ee_at_work> google shows with that error, try restarting dbus in your chroot..
[22:40] <Homefix> i would be satisfied with karmic ( no uppstart to mess things up in the chroot) but the programs stop opening after some time.
[22:42] <rcn-ee_at_work> Homefix, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/441100 workaround seems promising
[22:42] <ubot2> Ubuntu bug 441100 in dbus "within chroot, can fail to reload daemon configuration if not running (detects dbus daemon outside of chroot)" [Medium,Triaged]
[22:43] <Homefix> I am unable to connect to upstart
[22:43] <Homefix> I now but i dont quite understand somthing.................
[22:44] <Homefix> I beg you would this workaround apply to this please look:http://forum.xda-developers.com/showthread.php?p=10584098#post10584098
[22:45] <Homefix> i dont have a dbus outside the chroot right?
[22:46] <Homefix> so im stuck with karmic?
[22:47] <Homefix> Im using an android kernel
[22:47] <Homefix> arm7
[22:48] <rcn-ee_at_work> it would seem so..  if you can get the kernel source, i've heard htc has that.. enable CONFIG_DEVTMPFS with atleast 2.6.32 should get you closer..
[22:48] <Homefix> yaaaaaaaaaa
[22:48] <Homefix> thanks for somewere to go ILOVEYOU
[22:49] <Homefix> like i said u amaze me with your knowledge
[22:49] <Homefix> and thank u
[22:54] <Homefix> rcn: one more thing please explain what is the "atleast 2.6.32" it cant mean ver.
[22:57] <rcn-ee_at_work> in lucid, that config was manadority and it was enable with 2.6.32
[22:59] <rcn-ee_at_work> i'm not sure if it matters for the os underneath the chroot.....
[22:59] <Homefix> rcn: how woul i enable in the kernel "CONFIG_DEVTMPFS 2.6.32" on a line, then compile ?
[23:00] <Homefix> add that is
[23:00] <rcn-ee_at_work> it's a .config option.. have you built kernel's before?
[23:01] <Homefix> well i enabeled loop_devices im the kernel i am using i have a lot to learn
[23:02] <Homefix> I will post over at xda to get help with this
 manadority?
[23:23] <xerebz> i'm trying to compile opencv 2.2 on a beagleboard xm but i get this: http://pastebin.com/X3H4SsDc
[23:44] <rcn-ee> pmathews, try booting lucid with out it.. i belive it's udev dependicy..
 define  manadority
[23:58] <rcn-ee> oh it's been awhile.. but during lucid's development cycle, you couldn't successfully mount lucid on a 2.6.32 kernel with out..
[23:59] <pmathews> man  manadority
[23:59] <pmathews> No manual entry for manadority
[23:59] <rcn-ee> this was on the beagle at the time..