=== Quintasan_ is now known as Quintasan [01:23] janimo: Ooo, shiny, a 3.5.0 armadaxp kernel? [01:25] janimo: Any reason that went to the PPA instead of the archive? === heathkid|2 is now known as heathkid [04:38] janimo: And a followup question to the above, did you want that copied to the archive? [06:35] ogra_: aptitude merge was done long time ago. during weekend it was review/sponsored/uploaded [07:25] Hey guys, I'm trying to get video playback with my pandaboard ES, I heard this was a better platform then the old pandaboards but every OS I install on it has serious performance issues. [07:25] Is there a way to squeak better performance out of this? I've tried Linaro Ubuntu and Android, I'm switching to a usb 2.0 boot harddrive [07:25] but it looks like the software not the hardware is rendering 3d, I know people got smooth playback with the old pandaboard and linaro, is there a way to get the graphics drivers from TI or anything like that? === ericb2 is now known as Guest23308 === zyga is now known as zyga-afk [10:43] rsalveti: first great screenshots of 3d working nice on the pandaboard.. [10:43] encouragins to see [10:44] well i tested to boot up my own pandaboard and installed the latest drivers offered by "jokey" .. something installed but it did not get connected all the way to silicon http://paste.ubuntu.com/1156993/ [10:45] running quantal [10:45] forget quantal until the new drivers are uploaded [10:47] ogra_: ok well cant help it.. i have to try it before its stable.. will try the 3.5 kernel and use the precise drivers in hope to see http://lockerz.com/s/236484513 [10:47] :) [10:48] xranby: where? [10:49] RoyK: (17:17:33) robclark: this omap ppa for precise plus this kernel works fine w/ unity3d: http://people.freedesktop.org/~robclark/try9 [10:49] if only nvidia would provide us with a nice working driver :( [10:49] xranby, i'd rather use rsalveti's packageds than the precise ones ;) [10:49] i guess there is a PPA somewhere [10:49] xranby: thanks - gotta try that when I get back home :) [10:50] ogra_: i hope so. i was hoping rsalveti would say.. hey use my secret ppa at location X) [10:51] xranby, well, patience will help too, it has to be uploaded this week (feature freeze coming) [10:52] RoyK: good luck [10:53] thanks [10:54] xranby: should this work with precise, or should I upgrade to quantal? [10:54] RoyK: honesly i do not know [10:54] i have not tested it yet [10:54] the shots are from the quantal development drivers ... they arent uploaded yet [10:55] but will ... during the week [10:56] RoyK: to get the nice result shown in rsalveti screen shots ogra_'s advice is the best.. be patient and wait for the upload [10:56] to get something working today with a high chance of breaking things use the link i posted [10:57] :) === Quintasan_ is now known as Quintasan [11:05] ogra_: the "unaccelerated" experience on the omap4 is amazinly snappy in quantal.. running the lubuntu desktop and it flies [11:05] great progress [11:05] yeah, same on the ac100 :) [11:06] the accelerated expirience with unity running isnt so great i heard though [11:06] if i only can get away from my opengl es addiction ;) [11:06] i.e. massively limits your video playback framerate to have compositing on [11:07] ogra_: how is it imagined to get solved? [11:07] can unity get re-engineered to fix this limitation? [11:08] for example is someone working on temporally disable composition if openmax is running [11:08] ? [11:08] no idea, i was even surprised by the llvmpipe as default switch ... [11:08] i guess you have to ask the unity guys [11:09] lovely, have you send them a pandaboard? [11:09] to test their work on? [11:09] i think they have one ... but that wont help ... upstream llvmpipe isnt ready on arm afaik [11:10] i fear panda will have to use swrast (and fail with that) [11:12] i will install the package and check, by running some 3d fluff to see if it is working on the panda [11:12] its only a libGL replacement after all [11:12] the grand plan is to ship pvr by default though [11:13] this is plan B [11:13] if all else fail [11:13] of course getting the accelerated bits in would be great [11:13] well, plan B wuold be more intresting on all the other arm images we have [11:13] hello there [11:13] plan A has to happen in any case for the panda [11:13] anyone own beagleboard ? [11:13] the nice thing about llvm-pipe is ofcourse that it supports all desktop GL applications [11:14] but only runs on SSE currently [11:14] i imagine that the accelerated bits only supports opengl es === doko__ is now known as doko [11:40] ogra_: you are correct as allways. its only using the traditional old and slow mesa sw rasterizer [11:41] well, i was just guessing :) [11:42] nice guessed then! [12:18] infinity, I wanted to make 100% sure it builds in the archives not only on my machine. And then I'd want it copied sure, but no meta yet so others can test too [12:18] infinity, this is a code-drop from Marvell, my attempt at forward porting the 3.2 patches did resulted in a kernel that hangs while calling init [12:18] did result === zyga-afk is now known as zyga === furan is now known as Guest43356 [13:05] xranby: hopefully we should have the packages at a ppa today [13:05] there's a fix at the kernel package that needs to land as well, bug 1038846 [13:05] Launchpad bug 1038846 in linux-ti-omap4 "linux-headers pkg for omap4 doesn't include omap_drv/drm headers" [High,In progress] https://launchpad.net/bugs/1038846 [13:05] ppisati: ^ [13:15] rsalveti: i fwded to the ukml, but it's in master next [13:15] rsalveti: i'll cut a new relase with what we have now + that fix [13:18] great, already got applied at master-next [13:18] ppisati: awesome, thanks! [13:18] just because without it we can't install the pvr-omap4 package [13:19] rsalveti: ok, thumbs up, thank you for processing all the bits and packages through the grinder [13:20] rsalveti: have the drivers been tested on both old and new pandaboards? [13:20] i got a rev A here (assuming its the old panda) [13:20] A1 [13:21] xranby: yup [13:25] rsalveti: does pvr-omap4 need anything else to work properly with 3.5? [13:25] ppisati: not at this point, it worked just fine with 3.5 [13:25] unfortunately I got 2 freezes while testing, similar to what I was having with 3.4 [13:26] not sgx specific [13:26] didn't get any logs at the serial, just stopped completely, without blinking leds [13:26] that's with a panda es [13:43] plymouth is rather married into the bootup process, right? I tried to remove it but mountall depends on it. Does it do anything except provide splash? What should I do if I don't want any of that at all? [13:44] sveinse: it prints *all* of the login text as well.... [13:45] s/login/boot/ [13:46] xnox: ok.. I added console= to my serial port and I think I got all of the boot output (fsck and such). It's plymouth that does that? [13:47] sveinse: i am not sure. but my experience was that, that is the case [13:47] Point is: I have plymouth installed, but no themes. Now initramfs does not contain plymouth binaries, just some init-top and init-bottom scripts which complain upon boot. [13:52] I'm tempted to not use plymouth at all since I have all the output I want, yet for some reason mountall depends on plymouth, so some connection/requirement must there be [13:55] ah, it's a requirement to mountall because mountall pass progress to the plymouth daemon [13:56] sveinse, imagine libplymouth as a poor mans dbus :) [13:57] yep. [13:57] it lives between the UI and the backend, so mountall is heavily tied into it for any kind of user communication [13:57] ogra_: i'd rather imagine btrfs giving me a pony [13:57] haha [13:57] lol [13:58] It seems its not in ubuntu's use cases to not have any plymouth themes installed, since its complains without one [13:59] Having no plymouth theme installed, will result in having no plymouth[d] installed in initramfs, yet they are referred to by the init-top and init-bottom plymouth scripts :P [14:00] the init-top and init-bottom scripts are parts of the plymouth package, they are gone if the package is gone [14:00] and plymouth should force a rebuild of the initrd from its postinst [14:01] no, you can't rid yourself of plymouth. Its a dep of mountall. So you have it either way. However if you don't have any themes installed, no ply bin end up in the initramfs, but their init-* script does [14:02] in all cases, plymouth does not bother me. point is. Is there a theme I should use if I want text/serial output only. No hazzle dazzle. [14:03] (I'm optimizing a product for faster bootups...) [14:04] I wish I could get it to display the splash :p [14:05] I have to press the down or up arrow for it to appear :/ [14:07] Well, we did write a simple plymouth theme showing a simple splash (no progress & stuff). and it works. However, plymouth assumes that the text console and the splash device are the same, so for embedded products where you want everything on the serial port, while keeping the screen with a splash, it not easy with plymouth AFAIK. === basiaf_ is now known as basiaf [14:48] Are there any tools for recording the timestamps during boot. I want to see what the system is spending time on while booting. [14:49] sveinse, dmesg shows time since boot [14:50] or well time since kernel start [14:50] and there is indeed bootchart ... [14:50] sveinse: you may want to look at bootchart [14:50] lilstevie: Well, dmesg only shows kernel events. Theres a 20 second delay between the last kernel message during boot and our application start [14:50] oh well, ogra_ was faster ;) [14:50] heh [14:51] bootchart, thanks both of you. I'll look at it [15:11] I'm asking to make sure: Is there any way to get plymouth to log to a serial console, while displaying a splash on the fb? [15:19] no [15:19] plymouth will not allow a splash as soon as console= is set [15:19] (silly upstream decision) [15:19] * xnox wants dual screen support for plymouth: splash on the left, console messages on the right. [15:20] * ogra_ wants two splashes ... [15:20] i got a triple screen setup ;) [15:20] janimo: Is this Marvell code drop audited and all the non-free stuff removed? I spent a lot of time license checking and removing junk from the old source. [15:20] infinity, they say so, and that the code can be published [15:20] heh [15:20] I pushed it onto zinc anyway [15:20] I want a splash screen on one screen, logs in the middle, and a youtube video of cats on the 3rd one [15:21] janimo: Their last code drop could be published, that didn't make it Free (and it wasn't). [15:21] what's worst that can happen? [15:22] janimo: The worst that happens is that we lie to people and give them things they can't modify or redistribute legally. :P [15:22] well, if someone notices we can fix whatever is wrong :) [15:23] Aug 20 17:12:35 ubuntu acpid: 1 rule loaded [15:23] Aug 20 17:12:35 ubuntu acpid: waiting for events: event logging is off [15:23] * ogra_ glares at his beagleboard [15:23] it's not like we reveal secrets or offer non-free but irreplacable code [15:23] small mistakes at worst imo :) [15:23] * sveinse wants splash on screen with console on serial port [15:23] ogra_, wait... console= means no splash? so then on tegra we are screwed [15:23] lilstevie, my saying :) [15:23] with that stupid bug where it dies unless we set it [15:23] since months [15:23] :/ [15:23] not much we can do though [15:24] lilstevie, nvidia is supposed to be working on that bug already [15:24] janimo, yeah yeah, we'll see :p [15:24] lilstevie: Yes it's like that. You get console though since getty runs. But you lose console output between kernel handing off to initramfs and until getty is run if you enable splash [15:25] janimo: Hrm? No, no secrets, but there's plenty of "all rights reversed" code in their code drops with no license. Even if they hand-wave and tell us we can distribute it (which their engineering department really can't tell us anyway), third parties definitely can't. [15:26] janimo: This isn't the sort of thing we should do the "well, we'll just ship it and wait for them to whine" thing with. We put serious effort into cleansing that tree for 3.2, for good reason. [15:26] afaik the talks were among sales/whatever departments too or at least not just engineers [15:27] infinity, I had no idea 3.2 was assumed clean by them but cleansing was needed [15:27] With Marvel, never assume anything. [15:32] wait [15:32] holy [15:32] apparently that bug is fixed for tegra3 already :p [15:37] Tegra 2 does not have NEON, right. So no armhf? What about newer tegras? [15:37] ?? [15:37] why would there be no armhf ? [15:38] no float ops implemented in HW... I might well be misinformed. I though NEON and FPU was part of the same deal [15:39] no [15:40] it is a pain to not have NEON but NEON and FPU are not mutually exclusive [15:41] right. And FPU is generally implemented across the >=ARMv7 devices today? [15:43] is a requirement of armv7 AFAIK [15:44] aha (while reading http://wiki.debian.org/ArmHardFloatPort/). ARM implements a VFP which is the FPU. And it poses an extra set of registers -- which is the same reason the EABI is different [15:45] But from what I understand, the kernel is agnostic to armel/armhf, right? The VFP is never used for passing arguments to/from kernel? [15:45] sveinse: Right. [15:46] excellent. That might help a lot... You see. If mgmt decides they want armhf in the next release, I need to figure out how to dist-upgrade armel -> armhf... [15:46] LOL ! [15:46] now you made my day [15:48] (It's always interesting to be the center point for laughing. Especially when you don't know why....) [15:48] dist-upgrade does not sound fun at all [15:48] like potentially broken.... everywhere [15:48] well, currently the distro doesnt support that path withoutu tinkering a lot on the low level [15:49] I think I'll have to construct some chroot jail with armel and let it stage the upgrade the main system [15:49] It's not something we support, period. It's something you can make work in a very controlled environment, but you're not going to upgrading customer machines blind. [15:49] No, I dont expect you to either [15:50] speaking of crossing armel/armhf, still haven't found a reason worth setting up multiarch [15:50] :p [15:50] Let me put it differently. It's not something YOU will be able to support any more than we can. Unless your machines are all a specific image with no extra packages. And if they are, you can just re-image them armhf. :P [15:50] ok hud is starting to annoy me :/ [15:50] ogra_, I need some assistance, it would be nice to get linaro-boot-utils pushed to quantal before ff [15:50] lilstevie, shout at it ... that surely helps *g* [15:51] ooh, it has voice recognition already? [15:51] jcrigby, where is it ? [15:51] it is only in a ppa now, [15:51] jocarter, only shout recognition yet :) [15:51] https://code.launchpad.net/~jcrigby/+recipe/linaro-boot-utils-daily [15:51] is it possible to multiarch armel/armhf? I though the nature of the incompatabilities between the EABIs made them unable to multiarch [15:51] ogra_, I have had several cases where I am working away nicely in my terminal, accidentally trigger hud, and all of a sudden my sudo password has ended up in xchat :( [15:51] ogra_: heh [15:51] sveinse: We can multiarch them, yes. [15:52] sveinse: We put a lot of effort into that. [15:52] lilstevie, do you use focus-follows-mouse ? [15:52] sveinse: (And ABI incompatibility is the use-case for multiarch... i386 and amd64 are incompatible ABIs too...) [15:52] infinity: right [15:52] ogra_, that shouldn't make a difference right? I run my terminal windows at full screen [15:53] lilstevie, it makes a massive difference, unity isnt ready for FFM [15:53] lilstevie: Just re-bind the HUD hotkey to something you never press (mine is "pause"), and your life will be much better. [15:53] infinity: Am I understanding that armel->armhf is not possible at all? (If not, I can save me the attempt) [15:54] sveinse: Multiarch cross-grading isn't something that's "possible" on more than a macihne-by-machine with insane amounts of effort and breakage basis. [15:54] sveinse: So, for someone who's wanting to attempt it to more than "their personal laptop that they're happy breaking", I'd call it impossible, yes. [15:55] ogra_, in any case I haven't changed the setting from default, I was considering it though, but if it will make it worse :p [15:55] jcrigby, so are the source packages on https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+packages in a state you want to have them released in ? [15:55] infinity, sounds like a good idea, while I like the idea of hud, I still haven't really used it [15:56] jcrigby, signing and uploading them only takes me a few :) [15:57] lilstevie: If I still did a lot of graphic arts things, I could see it maybe being useful. Or if I did office productivity type things. But if you don't use complex applications with thousands of menu entries, the novelty wears off pretty quickly. And the bugs become the only part that you notice. :P [15:58] infinity, I live in the command line [15:58] so yeah [15:58] not really much use [15:59] * ogra_ really doesnt get that acpid thing in his beagle boot [15:59] i mean, i dont mind that we have it installed, by why the heck does it start ?! [16:00] ogra_, I believe so except for the funky version string [16:01] jcrigby, yeah, looks a bit like a math exercise :) [16:01] anyway, I'm turning in for the night [16:01] later [16:01] so pick a nicer version, put the source package somewhere and i'll upload [16:02] ogra_, ok thanks [16:10] infinity: Thanks. You'll have to excuse me for challenging armel->armhf upgrade feasability. I'm trying to measure the degree of "impossibleness". Not trivial is not the same as impossible. (A couple of years ago we were told cross building of armel deb package was impossible, but that turned out to be just non-trivial, but implementable.) [16:11] sveinse: Oh, yeah, no. This is way beyond "not trivial" for anything other than a single system. And the single system is something that would need excessive babysitting. [16:12] you could write a babysitter ;) [16:13] Well, in our case, if you babysit one, then you've handled all. All installed systems are *exactly* the same in respect of package composition [16:14] ogra_: You really couldn't. [16:14] ogra_: That's why it's not feasible. [16:14] sveinse: If they're identical, re-image. Seriously. You'll hate yourself less. [16:14] sveinse: Heck, that's a truism for dist-upgrading when not cross-grading too. :P [16:15] infinity: This is an embedded device with no alternative boot. The only bootsource available is the sd-card (which we don't want customers to fiddle with). That's why I trying to hot-upgrade a running system [16:17] For the fun of it: Here's how I hoped it would work: 1) deboostrap armel into a dir 2) chroot into jail. Bind mount system drive. Run debootstrap armhf over armel installation (which "resets" the list of installed packages). 3) reboot 4) finish install and install the set of packages needed on the system [16:22] I have to leave. _ogra, infinity. Have a nice evening (or whatever TZ you're in) [16:23] samei guess :) === Guest43356 is now known as furan [16:51] One way to handle the switch from armel to armhf is through a two-step reboot. I'd have to diagram it out, then script it, but it is possible. For an embedded system, it is a bit tricky, but that is what test environments are for. [16:51] And it also depends on how the embedded system is layed out to begin with. [16:53] Actually, I wonder if it could be done with netboot d-i & preseed? [16:53] * GrueMaster wishes he had free time to experiment with this idea. [17:25] ogra_, http://people.canonical.com/~jcrigby/linaro-boot-utils/ [17:41] bah, sigh [17:41] since when does dpkg-buildpackage fail hard on a missing ubuntu maintainer address [17:41] how silly [17:49] ogra_: Since forever. [17:49] ogra_: But it depends on if you have DEB_EMAIL set. [17:49] ogra_: Which is a weird heuristic. [17:49] infinity, no, im sure it never killed the build [17:49] ogra_: It's done this for ages. [17:49] it was a warning [17:49] (And I actually quite appreciate it) [17:49] * ogra_ doesnt [17:50] ogra_: No, really, it's hard failed like this for quite a long time. Unless you've been building all your source packages on an ancient release for the last few years. [17:50] i like to maintain the packages i'm upstream for in ubuntu ... [17:50] now, i'm in the lucky position to have an ubuntu.com address ... others arent [17:50] I maintain my Debian packages in Ubuntu too. That's not a problem, unless you try to upload something with an ubuntu revision but no ubuntu maintainer. [17:51] well, it breaks for sponsored linaro uploads [17:51] It doesn't "break" at all, it's working as intended. [17:52] Just run update-maintainer(1) and be done with it. [17:52] jcrigby, adding a watch file would be nice, the standards version is one behind and apparently you need to run update-maintainer as infinity suggests above [17:53] ogra_, just catching up, my xchat lost connection just after I sent link [17:55] yeap, saw that [18:33] ogra_, I fixed the standards version and maintainer. I did not add a watch file because after searching I'm still unsure how to do that part. I pushed the result to http://people.canonical.com/~jcrigby/linaro-boot-utils/