=== awafaa is now known as FunkyPenguin [08:32] Hello World ! [08:58] Question about gstreamer : when gst-inspect return that some plugins are blacklisted, it means that they won't be loaded with playbin, right ? [08:59] xnox, there was a usb bug in the ac100 kernel, either try again once thats in, install from an SD card or go with the beta and upgrade [09:01] ogra_: hmm.... i am running quantal. [09:01] yes, i was referring to quantal [09:01] ogra_: what was my question? I lost context.... [09:02] * xnox is playing with ac100 android install before reinstalling it with ubuntu [09:02] * xnox ac100 no tarball found hm =/ [09:02] i was referring to the last one [09:02] ogra_: ah. I did manage to install with sdcard =) [09:02] ah, great [09:02] well, usb should work too now [09:02] ogra_: i was like, what the heck let's try the sdcard. Cause i was suspecting that my usb thumb drive was "tempremental" [09:03] heh [09:03] ogra_: media keyboard buttons. Do they work? [09:03] dont blame it ... the kernel was missing usb-storage [09:03] no, they are F-keys [09:03] you can re-assign some of them, i.e. i use the volume and mute keys remapped [09:04] =( [09:04] the touchpad toggle key (F9) is sadly hardwired to touchpap power [09:04] ogra_: what about bug 1061430 ? [09:04] Launchpad bug 1061430 in libmtp "[ac100] libmtp-runtime is not pre-installed" [Medium,New] https://launchpad.net/bugs/1061430 [09:04] if your touchpad doesnt work once, first try with that key :) [09:05] oh, yeah i noticed the noise on boot [09:06] ac100 doesnt differ from other images (same seeds, no arch specific bits) [09:06] so i really wonder why its not showing on other systems [09:07] This package provides the udev rules file and the FreeDesktop.org Device [09:07] Information Files file (used by HAL). [09:07] hal ... hmm [09:08] ogra_: I disagree with you. [09:08] ogra_: http://paste.ubuntu.com/1259609/ [09:09] ogra_: notice how runtime is seeded everywhere where common is, but in the pre-installed case. [09:09] heck, why is it seeded at such a high level ? [09:09] thats like seeding alsa-libs in desktop [09:09] ogra_: i suspect it's not hal specific anymore. it's the thing that should tell what is an iPod / iPad / photo camera / video camera / mp3 player / etc. [09:10] yeah [09:10] * xnox made lubuntu look ~ unity-like [09:10] that should at least be in desktop-common [09:12] ogra@anubis:~/Devel/seeds/ubuntu.quantal$ grep -r mtp * [09:12] ogra@anubis:~/Devel/seeds/ubuntu.quantal$ [09:12] * ogra_ scratches head [09:13] not in platform either [09:15] ogra_: due to reverse-recommends from libmtp9 runtime is installed because of: amarok, rhythbox-plugins, banshee or audacious-plugins (all default music players?!) [09:15] ah [09:15] i dont see any of them in the binary rdepends [09:15] ogra_: so check the diff between lubuntu daily-live and daily-preinstalled manifests? [09:16] ogra_: reverse-depends libmtp-runtime -> libmtp9 (reverse-recommends) -> music players (reverse depends) [09:16] * ogra_ doesnt even know where the lubuntu seeds live :) [09:17] ah. recommends [09:17] ogra_: well. diff the manifests on cdimage.u.c =)))) and it should be in the ubuntu-seeds project as a branch?! [09:17] lubuntu ships gmplayer or gnome-mplayer [09:17] yeah, something like that [09:18] ogra_: then why did it get libmtp-common? [09:19] ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-common|grep lubuntu|wc -l [09:19] 2 [09:19] ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-runtime|grep lubuntu|wc -l [09:19] 0 [09:19] ogra@anubis:~/Devel/seeds/platform.quantal$ [09:20] seems something explicitly seeds it [09:24] * Move all recommends to depends, to be consistent with the [09:24] no-follow-recommends feature of the seed. [09:24] hmm, intresting changelog entry in lubuntu-meta [09:25] i suspect that might explain it [09:37] ok, got it [09:37] lubuntu seeds audacious ... that depends on libmtp9 .... which doesnt depend on its own runtime buut only libmtp-common [09:37] so its a dependency error in libmtp9 [10:53] xnox, fixed lubuntu-desktop uploaded :) [10:54] ogra_: cool. [10:55] ogra_: seeded-in-ubuntu transmission looks odd. why depend on a metapackage instead of selecting gtk frontend like the rest of seeds.....? === doko__ is now known as doko [13:20] hrw, hi, is there any catch in using ccache with the cross gcc for building kernels [13:25] hrw, nevermind, found it :) [13:26] marvin24, CROSS_COMPILE="ccache arm-linux-gnueabihf-" passed in the make or debuild line [13:26] maybe the kernel build system ignores the PATH somehow [13:27] since for a simple Makefile in another project arm gcc works via ccache if the symlinks are set [13:42] janimo`: ok, thanks - will try out === ndec_ is now known as ndec [15:20] just in case my story does interest somebody : I did pass the configure step with --disable-modular-tests option [15:57] janimo`: yup, that worked - easy enough [15:57] thanks! [15:59] marvin24, yes, quite faster here as well :) [15:59] thanks for reminding me that ccache does not work, I somehow kept ignoring it and sufferint longer build times than needed [16:01] janimo`: I guess that won't balance the time I stole you already ;-) [16:09] marvin24, nah, the time it took was not longer than the delta between a regular and a ccached build so it is already gained back :) [16:10] unless you mean ALL THE TIME YOU STOLE by starting the ac100 kernel and all it lead to ;) [16:13] ^^^ yes, that's what I meant [17:22] guys: when #ubuntu-arm64? :D [17:29] hrw: Won't be a new channel, but I'm sure more arm64 talk will happen here soonish. === _Lucretia___ is now known as _Lucretia_ [17:30] hrw, as soon as we have #ubuntu-amd64 [17:31] so far I crosscompiled only 634 packages [17:31] but with OE [17:32] hrw: Which libc are you using? Our 2.15+libc-alpha patches, or master+alpha? [17:33] infinity: 2.16+svn+aarch64-public [17:33] its 2.16+svn20393 iirc in last build [17:33] So, vaguely master+libc-alpha. [17:33] yes [17:34] * infinity needs to spend some time in the next week or two to dump something vaguely workable into Debian/experimental and prep for R. [17:35] Not that R will be building arm64, due to lack of anything to use as a buildd, but I want R to be able to cross-build it without pain. [17:35] infinity: wookey works on it already too [17:36] wookey: We should talk. ;) [17:37] why oh why that arch name [17:37] ogra_: Which one? arm64 or aarch64? [17:37] arm64 and amd64 are way to close for my taste [17:38] Heh. [17:38] Get less dyslexic. ;) [17:38] aargh64 at least allows a funny typo :) [17:38] arrrr64 whould be awesome though [17:38] pirates ! [17:38] aka *our arch does not exist* === mcasadevall is now known as NCommander === NCommander is now known as Guest84314 [17:58] bye [20:00] ogra_: it's true that amd64 and arm64 are easy to confuse - I've been doing that quite a lot already [20:00] infinity: talk away [20:01] wookey: Oh just about glibc and how your cross-building adventures are going. Perhaps I should have suffixed "we should talk" with "soon", or maybe even a date. [20:01] wookey: How's your tomorrow look? [20:02] tomorrow I foresee more fighting with eglibc2.16 and toolchain bootstrap :-) [20:02] so yes, anytime [20:02] tomorrow evg I'm out. But presumably you are thinking of my morning, your evg? [20:03] wookey: I was thinking my morning, your afternoon, but well before your evening. [20:04] no probs. I was miffed today to find tha the bug you get from trying to build eglibc2.15 with gcc4.7 gives zero google hits [20:04] So moving to 2.16 seems like likely path of least resistance (and matches aarch64 patches much better too) [20:04] wookey: Bring that up with me tomorrow too. ;) [20:05] wookey: Well, we're moving to 2.16 for Ubuntu-R and Debian/experimental, I just need to get to it. [20:05] wookey: If the current libc-alpha aarch64 patches apply cleanly to 2.16, I may not need much input from you, but I just want to pick your brain about your experiences so far. [20:05] OK. aurel told me the packaging was done, so I'm just assembling all the right parts to see if it builds [20:06] wookey: Yeah, aurel's done a lot of the heavy lifting already, I need to do a bit more though. [20:06] I'll have a patch for that within the hour I think [20:06] wookey: Oh, spiffy. In that case, you can provide me with useful patches tomorrow. :) [20:06] no idea if it'll actually work... [20:06] wookey: And I'll get it all committed and we can work from there. [20:07] it's a bit wierd the way the debian packaging doesn;t match upstream layout [20:07] But I think I have groked what goes where [20:07] Hysterical raisins. [20:07] so I gathered [20:08] Going back to when it was three different upstream branches that had to be merged. [20:08] I'll mangle all of that when I move Debian to git. [20:08] But that won't happen until we're also ready to move Debian back to glibc. [20:08] I was confused for a while though... [20:12] Heh. [20:12] It's not ideal. [20:12] We'll fix it in the next 6-12mo, I hope. [20:12] As soon as we verify that glibc has all the eglibc patches we care about (or most of them), and switch back. [20:13] Some serious round tuits required for that audit. === Ursinha_ is now known as Ursinha [21:21] <[7]> hey [21:21] <[7]> I've just tried to install quantal on my pandaboard (omap 4430) [21:21] <[7]> sd card works well with oneiric/precise [21:21] <[7]> however with the xloader from http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap4/netboot/MLO it freaks out with this: [21:21] <[7]> OMAP SD/MMC: 0\nmmc_send_cmd : timeout: No status update\nCard did not respond to voltage select!\nspl: mmc init failed: err - -17\n### ERROR ### Please RESET the board ### [21:21] <[7]> so... is that a broken MLO, or a weird card that somehow happened to work right with an older one [21:21] <[7]> if the former, where do I get a working MLO that works with quantal (12.10)? [21:21] <[7]> if the latter, what kind of trouble is to be expected if I just use an older MLO, e.g. from oneiric or precise? [21:35] Try one from Precise, just in case. The MLO shouldn't have changed, afaik. [21:36] It's been rebuilt, even if the code didn't change. That said, it works in our pre-built images. [21:36] (I'll admit I haven't built an SD by-hand with the one we publish, but it's identical to what's in the boot images sitting next to it) [21:37] <[7]> GrueMaster: precise is 33K in size, quantal is 26K [21:37] <[7]> swapping it results in this: http://pastie.org/4910961 [21:38] <[7]> infinity: those boot images fail to boot on my board/card [21:38] <[7]> does this output mean that I might have to swap uboot as well? or did it actually fail to load uboot? [21:39] <[7]> (that output loops over and over again) [21:40] [7]: Which "those images"? boot.img-serial.gz? [21:40] <[7]> yes, that one [21:41] Same voltage select error? [21:41] It could be the card, unsure. [21:41] <[7]> haven't observed serial output of that, but it resulted in no LED activity as well [21:41] As for the error when you swap around MLO, it may well be that MLO and u-boot need to match. [21:42] [7]: Just download either boot.img-fb or boot.img-serial and then "gunzip infinity: so you say a precise uboot is likely to work with quantal? [21:42] You don't need the other files unless you are manually creating a boot image. [21:43] [7]: Should do. [21:45] <[7]> hm, now that card acts weird in my laptop as well: http://pastie.org/4910997 [21:47] <[7]> hm, replugged it, works again [21:48] This fits nicely with my "blame the card" mantra. [21:48] <[7]> ok, swapping uboot as well seemed to help [21:48] <[7]> booted a kernel at least [22:00] <[7]> "ALERT! /dev/disk/by-uuid/root does not exist. Dropping to a shell!" [22:00] <[7]> now why on earth does it look for a label in by-uuid? [22:00] Booting a non-standard kernel? [22:00] what exactly are you trying to do? [22:01] <[7]> or rather why does the installer set up a root=uuid=