=== awafaa is now known as FunkyPenguin | ||
bizulk | Hello World ! | 08:32 |
---|---|---|
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:58 |
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 | 08:59 |
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:01 |
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:02 |
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:03 |
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:04 |
ogra_ | oh, yeah i noticed the noise on boot | 09:05 |
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:06 |
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:07 |
xnox | ogra_: I disagree with you. | 09:08 |
xnox | ogra_: http://paste.ubuntu.com/1259609/ | 09:08 |
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:09 |
ogra_ | yeah | 09:10 |
* xnox made lubuntu look ~ unity-like | 09:10 | |
ogra_ | that should at least be in desktop-common | 09:10 |
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:12 | |
ogra_ | not in platform either | 09:13 |
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:15 |
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:16 | |
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:17 |
xnox | ogra_: then why did it get libmtp-common? | 09:18 |
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:19 |
ogra_ | seems something explicitly seeds it | 09:20 |
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:24 |
ogra_ | i suspect that might explain it | 09:25 |
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 | 09:37 |
ogra_ | xnox, fixed lubuntu-desktop uploaded :) | 10:53 |
xnox | ogra_: cool. | 10:54 |
xnox | ogra_: seeded-in-ubuntu transmission looks odd. why depend on a metapackage instead of selecting gtk frontend like the rest of seeds.....? | 10:55 |
=== doko__ is now known as doko | ||
janimo` | hrw, hi, is there any catch in using ccache with the cross gcc for building kernels | 13:20 |
janimo` | hrw, nevermind, found it :) | 13:25 |
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:26 |
janimo` | since for a simple Makefile in another project arm gcc works via ccache if the symlinks are set | 13:27 |
marvin24 | janimo`: ok, thanks - will try out | 13:42 |
=== ndec_ is now known as ndec | ||
bizulk | just in case my story does interest somebody : I did pass the configure step with --disable-modular-tests option | 15:20 |
marvin24 | janimo`: yup, that worked - easy enough | 15:57 |
marvin24 | thanks! | 15:57 |
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 | 15:59 |
marvin24 | janimo`: I guess that won't balance the time I stole you already ;-) | 16:01 |
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:09 |
janimo` | unless you mean ALL THE TIME YOU STOLE by starting the ac100 kernel and all it lead to ;) | 16:10 |
marvin24 | ^^^ yes, that's what I meant | 16:13 |
hrw | guys: when #ubuntu-arm64? :D | 17:22 |
infinity | hrw: Won't be a new channel, but I'm sure more arm64 talk will happen here soonish. | 17:29 |
=== _Lucretia___ is now known as _Lucretia_ | ||
ogra_ | hrw, as soon as we have #ubuntu-amd64 | 17:30 |
hrw | so far I crosscompiled only 634 packages | 17:31 |
hrw | but with OE | 17:31 |
infinity | hrw: Which libc are you using? Our 2.15+libc-alpha patches, or master+alpha? | 17:32 |
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:33 |
* 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:34 | |
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:35 |
infinity | wookey: We should talk. ;) | 17:36 |
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:37 |
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:38 |
=== mcasadevall is now known as NCommander | ||
=== NCommander is now known as Guest84314 | ||
hrw | bye | 17:58 |
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:00 |
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:01 |
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:02 |
infinity | wookey: I was thinking my morning, your afternoon, but well before your evening. | 20:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:12 |
infinity | Some serious round tuits required for that audit. | 20:13 |
=== Ursinha_ is now known as Ursinha | ||
[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:21 |
GrueMaster | Try one from Precise, just in case. The MLO shouldn't have changed, afaik. | 21:35 |
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:36 |
[7] | GrueMaster: precise is 33K in size, quantal is 26K | 21:37 |
[7] | swapping it results in this: http://pastie.org/4910961 | 21:37 |
[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:38 |
[7] | (that output loops over and over again) | 21:39 |
infinity | [7]: Which "those images"? boot.img-serial.gz? | 21:40 |
[7] | yes, that one | 21:40 |
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:41 |
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:42 |
infinity | [7]: Should do. | 21:43 |
[7] | hm, now that card acts weird in my laptop as well: http://pastie.org/4910997 | 21:45 |
[7] | hm, replugged it, works again | 21:47 |
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 | 21:48 |
[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:00 |
[7] | or rather why does the installer set up a root=uuid=<label> bootarg if I specify a partition label during installation | 22:01 |
GrueMaster | What does your boot.scr contain? | 22:02 |
[7] | "root=uuid=root" | 22:03 |
[7] | the interesting question is how that ended up in there | 22:03 |
GrueMaster | Back to my earlier question, what are you trying to do? Netboot installation? | 22:04 |
[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:23 |
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:24 |
* GrueMaster wishes he could log into the home network from work to verify the images are indeed ok. | 22:25 | |
[7] | GrueMaster: well, that didn't work with this card at least, which worked on oneiric just fine, for more than a year | 22:27 |
[7] | hm, now it froze :/ | 22:28 |
[7] | no heartbeat anymore | 22:28 |
[7] | no console output either | 22:28 |
GrueMaster | Har! Found a way into my home network. Now testing the quatnal netboot install on my panda farm. | 22:47 |
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:48 |
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:50 |
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:51 |
[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:52 |
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:53 |
[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:54 |
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:55 |
[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:56 |
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:57 | |
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:58 |
[7] | anyway, I'm sure I dd'ed that onto the sd card | 22:59 |
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:00 |
[7] | hm, odd... anyway, I always checked that it was mountable | 23:02 |
* GrueMaster wishes he had ipv6 access to the home instead tunneling around through putty. | 23:03 | |
GrueMaster | Hmm. Fail. infinity: Did openjdk-6-jre-headless get removed this cycle? | 23:19 |
GrueMaster | same with python-software-properties apparently. | 23:20 |
[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:49 |
[7] | hm, apparently aptitude's pkgstates got corrupted during that crash | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!