[08:32] <bizulk> Hello World !
[08:58] <bizulk> 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] <ogra_> 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] <xnox> ogra_: hmm.... i am running quantal.
[09:01] <ogra_> yes, i was referring to quantal
[09:01] <xnox> ogra_: what was my question? I lost context....
[09:02] <ogra_> * xnox is playing with ac100 android install before reinstalling it with ubuntu
[09:02] <ogra_> * xnox ac100 no tarball found hm =/
[09:02] <ogra_> i was referring to the last one
[09:02] <xnox> ogra_: ah. I did manage to install with sdcard =)
[09:02] <ogra_> ah, great
[09:02] <ogra_> well, usb should work too now
[09:02] <xnox> 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] <ogra_> heh
[09:03] <xnox> ogra_: media keyboard buttons. Do they work?
[09:03] <ogra_> dont blame it ... the kernel was missing usb-storage
[09:03] <ogra_> no, they are F-keys
[09:03] <ogra_> you can re-assign some of them, i.e. i use the volume and mute keys remapped
[09:04] <xnox> =(
[09:04] <ogra_> the touchpad toggle key (F9) is sadly hardwired to touchpap power
[09:04] <xnox> ogra_:  what about bug 1061430 ?
[09:04] <ubot2> Launchpad bug 1061430 in libmtp "[ac100] libmtp-runtime is not pre-installed" [Medium,New] https://launchpad.net/bugs/1061430
[09:04] <ogra_> if your touchpad doesnt work once, first try with that key :)
[09:05] <ogra_> oh, yeah i noticed the noise on boot
[09:06] <ogra_> ac100 doesnt differ from other images (same seeds, no arch specific bits)
[09:06] <ogra_> so i really wonder why its not showing on other systems
[09:07] <ogra_> This package provides the udev rules file and the FreeDesktop.org Device
[09:07] <ogra_>  Information Files file (used by HAL).
[09:07] <ogra_> hal ... hmm
[09:08] <xnox> ogra_: I disagree with you.
[09:08] <xnox> ogra_: http://paste.ubuntu.com/1259609/
[09:09] <xnox> ogra_: notice how runtime is seeded everywhere where common is, but in the pre-installed case.
[09:09] <ogra_> heck, why is it seeded at such a high level ?
[09:09] <ogra_> thats like seeding alsa-libs in desktop
[09:09] <xnox> 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] <ogra_> yeah
[09:10]  * xnox made lubuntu look ~ unity-like
[09:10] <ogra_> that should at least be in desktop-common
[09:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$ grep -r mtp *
[09:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$
[09:12]  * ogra_ scratches head
[09:13] <ogra_> not in platform either
[09:15] <xnox> 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] <ogra_> ah
[09:15] <ogra_> i dont see any of them in the binary rdepends
[09:15] <xnox> ogra_: so check the diff between lubuntu daily-live and daily-preinstalled manifests?
[09:16] <xnox> 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] <ogra_> ah. recommends
[09:17] <xnox> ogra_: well. diff the manifests on cdimage.u.c =)))) and it should be in the ubuntu-seeds project as  a branch?!
[09:17] <ogra_> lubuntu ships gmplayer or gnome-mplayer
[09:17] <ogra_> yeah, something like that
[09:18] <xnox> ogra_: then why did it get libmtp-common?
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-common|grep lubuntu|wc -l
[09:19] <ogra_> 2
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-runtime|grep lubuntu|wc -l
[09:19] <ogra_> 0
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$
[09:20] <ogra_> seems something explicitly seeds it
[09:24] <ogra_>   * Move all recommends to depends, to be consistent with the
[09:24] <ogra_>     no-follow-recommends feature of the seed.
[09:24] <ogra_> hmm, intresting changelog entry in lubuntu-meta
[09:25] <ogra_> i suspect that might explain it
[09:37] <ogra_> ok, got it
[09:37] <ogra_> lubuntu seeds audacious ... that depends on libmtp9 .... which doesnt depend on its own runtime buut only libmtp-common
[09:37] <ogra_> so its a dependency error in libmtp9
[10:53] <ogra_> xnox, fixed lubuntu-desktop uploaded :)
[10:54] <xnox> ogra_: cool.
[10:55] <xnox> ogra_: seeded-in-ubuntu transmission looks odd. why depend on a metapackage instead of selecting gtk frontend like the rest of seeds.....?
[13:20] <janimo`> hrw, hi, is there any catch in using ccache with the cross gcc for building kernels
[13:25] <janimo`> hrw, nevermind, found it :)
[13:26] <janimo`> marvin24, CROSS_COMPILE="ccache arm-linux-gnueabihf-" passed in the make or debuild line
[13:26] <janimo`> maybe the kernel build system ignores the PATH somehow
[13:27] <janimo`> since for a simple Makefile in another project arm gcc works via ccache if the symlinks are set
[13:42] <marvin24> janimo`: ok, thanks - will try out
[15:20] <bizulk> just in case my story does interest somebody : I did pass the configure step with --disable-modular-tests option
[15:57] <marvin24> janimo`: yup, that worked - easy enough
[15:57] <marvin24> thanks!
[15:59] <janimo`> marvin24, yes, quite faster here as well :)
[15:59] <janimo`> thanks for reminding me that ccache does not work, I somehow kept ignoring it and sufferint longer build times than needed
[16:01] <marvin24> janimo`: I guess that won't balance the time I stole you already ;-)
[16:09] <janimo`> 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] <janimo`> unless you mean ALL THE TIME YOU STOLE by starting the ac100 kernel and all it lead to ;)
[16:13] <marvin24> ^^^ yes, that's what I meant
[17:22] <hrw> guys: when #ubuntu-arm64? :D
[17:29] <infinity> hrw: Won't be a new channel, but I'm sure more arm64 talk will happen here soonish.
[17:30] <ogra_> hrw, as soon as we have #ubuntu-amd64
[17:31] <hrw> so far I crosscompiled only 634 packages
[17:31] <hrw> but with OE
[17:32] <infinity> hrw: Which libc are you using?  Our 2.15+libc-alpha patches, or master+alpha?
[17:33] <hrw> infinity: 2.16+svn+aarch64-public
[17:33] <hrw> its 2.16+svn20393 iirc in last build
[17:33] <infinity> So, vaguely master+libc-alpha.
[17:33] <hrw> 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] <infinity> 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] <hrw> infinity: wookey works on it already too
[17:36] <infinity> wookey: We should talk. ;)
[17:37] <ogra_> why oh why that arch name
[17:37] <infinity> ogra_: Which one?  arm64 or aarch64?
[17:37] <ogra_> arm64 and amd64 are way to close for my taste
[17:38] <infinity> Heh.
[17:38] <infinity> Get less dyslexic. ;)
[17:38] <ogra_> aargh64 at least allows a funny typo :)
[17:38] <xnox> arrrr64 whould be awesome though
[17:38] <ogra_> pirates !
[17:38] <xnox> aka *our arch does not exist*
[17:58] <hrw> bye
[20:00] <wookey> ogra_: it's true that amd64 and arm64 are easy to confuse - I've been doing that quite a lot already
[20:00] <wookey> infinity: talk away
[20:01] <infinity> 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] <infinity> wookey: How's your tomorrow look?
[20:02] <wookey> tomorrow I foresee more fighting with eglibc2.16 and toolchain bootstrap :-)
[20:02] <wookey> so yes, anytime
[20:02] <wookey> tomorrow evg I'm out. But presumably you are thinking of my morning, your evg?
[20:03] <infinity> wookey: I was thinking my morning, your afternoon, but well before your evening.
[20:04] <wookey> 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] <wookey> So moving to 2.16 seems like likely path of least resistance (and matches aarch64 patches much better too)
[20:04] <infinity> wookey: Bring that up with me tomorrow too. ;)
[20:05] <infinity> wookey: Well, we're moving to 2.16 for Ubuntu-R and Debian/experimental, I just need to get to it.
[20:05] <infinity> 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] <wookey> OK. aurel told me the packaging was done, so I'm just assembling all the right parts to see if it builds
[20:06] <infinity> wookey: Yeah, aurel's done a lot of the heavy lifting already, I need to do a bit more though.
[20:06] <wookey> I'll have a patch for that within the hour I think
[20:06] <infinity> wookey: Oh, spiffy.  In that case, you can provide me with useful patches tomorrow. :)
[20:06] <wookey> no idea if it'll actually work...
[20:06] <infinity> wookey: And I'll get it all committed and we can work from there.
[20:07] <wookey> it's a bit wierd the way the debian packaging doesn;t match upstream layout
[20:07] <wookey> But I think I have groked what goes where
[20:07] <infinity> Hysterical raisins.
[20:07] <wookey> so I gathered
[20:08] <infinity> Going back to when it was three different upstream branches that had to be merged.
[20:08] <infinity> I'll mangle all of that when I move Debian to git.
[20:08] <infinity> But that won't happen until we're also ready to move Debian back to glibc.
[20:08] <wookey> I was confused for a while though...
[20:12] <infinity> Heh.
[20:12] <infinity> It's not ideal.
[20:12] <infinity> We'll fix it in the next 6-12mo, I hope.
[20:12] <infinity> As soon as we verify that glibc has all the eglibc patches we care about (or most of them), and switch back.
[20:13] <infinity> Some serious round tuits required for that audit.
[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] <GrueMaster> Try one from Precise, just in case.  The MLO shouldn't have changed, afaik.
[21:36] <infinity> It's been rebuilt, even if the code didn't change.  That said, it works in our pre-built images.
[21:36] <infinity> (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] <infinity> [7]: Which "those images"?  boot.img-serial.gz?
[21:40] <[7]> yes, that one
[21:41] <infinity> Same voltage select error?
[21:41] <infinity> 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] <infinity> As for the error when you swap around MLO, it may well be that MLO and u-boot need to match.
[21:42] <GrueMaster> [7]: Just download either boot.img-fb or boot.img-serial and then "gunzip <boot.img.*|sudo dd of=/dev/mmcblk0 bs=4M"
[21:42] <[7]> infinity: so you say a precise uboot is likely to work with quantal?
[21:42] <GrueMaster> You don't need the other files unless you are manually creating a boot image.
[21:43] <infinity> [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] <infinity> 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] <infinity> Booting a non-standard kernel?
[22:00] <GrueMaster> what exactly are you trying to do?
[22:01] <[7]> or rather why does the installer set up a root=uuid=<label> bootarg if I specify a partition label during installation
[22:02] <GrueMaster> What does your boot.scr contain?
[22:03] <[7]> "root=uuid=root"
[22:03] <[7]> the interesting question is how that ended up in there
[22:04] <GrueMaster> Back to my earlier question, what are you trying to do?  Netboot installation?
[22:23] <[7]> GrueMaster: yes
[22:23] <[7]> and it worked for the most part, only problems were that MLO/uboot thing, and that wrong root device
[22:24] <GrueMaster> If you are doing a netboot install, just download the boot.img-fb or boot.img-serial and flash it to your SD card.  Don't worry about anything else.
[22:25]  * GrueMaster wishes he could log into the home network from work to verify the images are indeed ok.
[22:27] <[7]> GrueMaster: well, that didn't work with this card at least, which worked on oneiric just fine, for more than a year
[22:28] <[7]> hm, now it froze :/
[22:28] <[7]> no heartbeat anymore
[22:28] <[7]> no console output either
[22:47] <GrueMaster> Har!  Found a way into my home network.  Now testing the quatnal netboot install on my panda farm.
[22:48] <GrueMaster> Seems to be working for me just fine.  Panda4 rebooted and is running my preseed install (which is a symlink to my Precise preseed - i.e. unchanged).
[22:50] <GrueMaster> [7]: Just fyi:  I automated  SRU Kernel testing when I was doing Ubuntu ARM QA.  I am no longer doing that work, but my systems are still operational as is my local mirror.  Everyhting still appears to be working fine.
[22:50] <[7]> so we apparently have an incompatibility between this sd card and newer uboots?
[22:51] <GrueMaster> The automation process downloads the boot.img-serial.gz to the local panda and reflashes the SD.  It then reboots, and the preseed installes the designated release on a USB Sata drive.
[22:51] <GrueMaster> As to your SD, I don't know.  Try seroing it out and reimaging it.  I've had to do that on occasion when I was doing daily testing.
[22:51] <GrueMaster> *zeroing
[22:52] <[7]> hm, maybe I'm gonna try another card with that boot image to see if that works
[22:52] <[7]> but this card seems to be working just fine
[22:52] <[7]> (after swapping out xloader and uboot)
[22:53] <GrueMaster> Try reflashing the boot.img to the sd card.  You shouldn't have to do anything else.
[22:53] <GrueMaster> Are you on a Panda or PandaES?
[22:54] <[7]> the old (4430) one
[22:54] <GrueMaster> Ok.  That is what I am testing on.  (not sure if my ES is still plugged in)
[22:54] <[7]> and it did try that image on this card earlier, and it didn't work
[22:54] <[7]> now that I've installed everything I'm not sure I'll wipe it again
[22:55] <GrueMaster> heh
[22:55] <infinity> Are you positive you tried the .gz images, and not the -fat?
[22:55] <infinity> The latter is a red herring.  And we really need to stop publishing it.
[22:56] <[7]> no, i tried the gz
[22:56] <infinity> Kay.
[22:56] <[7]> both dd'ed directly to the sd card (superfloppy) or as a properly sized partition
[22:56] <infinity> Then I'm all for either blaming the card entirely, or doing a low-level zeroing of it before rewriting it.
[22:56] <infinity> Err, what?
[22:57] <GrueMaster> [7]: Did you gunzip before flashing it?
[22:57] <[7]> sure
[22:57] <infinity> The .gz contains a partition table, no superfloppiness about it.
[22:57] <[7]> hm? lemme check again
[22:57] <infinity> If what you have there doesn't have a partition table, it's not the right image.
[22:57] <[7]> hm, indeed it does
[22:57]  * [7] tries to remember what he did
[22:58] <GrueMaster> The proper way to flash (well, what I use anyway) is "gunzip <boot.img-serial.gz|sudo dd bs=4M of=/dev/mmcblk0"
[22:58] <infinity> I tend to just zcat as root, since the image is small enough that bumping the block size doesn't buy much.
[22:58] <GrueMaster> You could also use /dev/sdb (or whatever your PC designates as the SD drive).
[22:58] <infinity> But yeah, GrueMaster's command is best practice.
[22:59] <[7]> anyway, I'm sure I dd'ed that onto the sd card
[23:00] <GrueMaster> infinity: It isn't about size.  I discovered early on (Karmic timefram iirc) that using BS actually changes the write order a bit.
[23:00] <[7]> and only tried partitioning when that didn't work
[23:00] <GrueMaster> On some devices.
[23:00] <GrueMaster> [7]: Yea, no need to partition.  The img is a disk image that contains a small fat partition preloaded with good stuff.
[23:02] <[7]> hm, odd... anyway, I always checked that it was mountable
[23:03]  * GrueMaster wishes he had ipv6 access to the home instead tunneling around through putty.
[23:19] <GrueMaster> Hmm.  Fail.  infinity:  Did openjdk-6-jre-headless get removed this cycle?
[23:20] <GrueMaster>  same with python-software-properties apparently.
[23:49] <[7]> has someone seen aptitude crash like this before? Uncaught exception: ../../src/generic/problemresolver/choice.h:328: const version& generic_choice<PackageUniverse>::get_ver() const [with PackageUniverse = aptitude_universe; generic_choice<PackageUniverse>::version = aptitude_resolver_version]: Assertion "tp == install_version" failed.
[23:49] <[7]> seems to happen when it tries to resolve dependencies of broken packages
[23:57] <[7]> hm, apparently aptitude's pkgstates got corrupted during that crash