| DanaG | Bummer. Are there any Marvell ARM thingies that WILL run lucid? | 01:30 |
|---|---|---|
| DanaG | I'm still wanting an ARM with PCIe slot. =þ | 01:31 |
| Martyn | DanaG : Dove | 01:36 |
| Martyn | and an ARM with a PCIe slot -- is a tegra2 | 01:36 |
| Martyn | two PCIe 1x slots in fact | 01:36 |
| Martyn | (Mini PCIe) | 01:36 |
| DanaG | Hmm, but that already has a video card... a non-open one. | 01:36 |
| DanaG | Interesting adapter: http://www.hwtools.net/Adapter/PE4L.html | 01:37 |
| persia | Doesn't mean you have to use it. | 01:37 |
| Martyn | well, pcie doesn't have a lot of bandwidth, when you're using just one lane | 01:37 |
| Martyn | DanaG : But even if it's not open, that doesn't mean there aren't open source DRIVERS for it | 01:38 |
| Martyn | 2D is well supported | 01:38 |
| persia | WIth nouveau? | 01:38 |
| Martyn | why would nouveau even work? | 01:38 |
| Martyn | the technology in use on the tegra2 has nothing in common with the nvidia GPU's | 01:38 |
| Martyn | it's made by nVidia.. | 01:39 |
| Martyn | that's about it | 01:39 |
| persia | Ah :) | 01:39 |
| Martyn | 2D is supported by it being a bog-standard framebuffer | 01:39 |
| persia | Which drivers then? | 01:39 |
| Martyn | fbcon | 01:39 |
| persia | Oh. That make sense. | 01:39 |
| Martyn | persia : And I even disabled /that/ | 01:39 |
| Martyn | since it steals memory that I want for appliations | 01:39 |
| persia | heh. | 01:39 |
| Martyn | servers don't need memory, so instead of having nearly a gig, I had barely more than 600meg | 01:40 |
| Martyn | servers don't need VIDEO rather | 01:40 |
| persia | Right. | 01:40 |
| persia | I'm down 512MB on one of my servers for similar reasons, and thinking about fixing it (although with 4G, it's a little less painful) | 01:40 |
| DanaG | hmm, I can't find much about Marvell Dove. No boards easily findable. | 01:42 |
| Martyn | They aren't easy to get, no. | 01:42 |
| Martyn | DanaG : Frankly, if you're patient, there is a new OMAP44xx board coming out soon | 01:42 |
| Martyn | and that is a DUAL CORE cortex a9 | 01:42 |
| Martyn | more than powerful enough | 01:42 |
| Martyn | or you can spend $300 and get into the tegra2 program | 01:42 |
| DanaG | I'm not in any rush to buy anything... I'm just eyeing stuff and thinking "ooh, that looks interesting." =þ | 01:42 |
| Martyn | well, closer to $400 | 01:43 |
| Martyn | it's a great board though, and we have ubuntu working now | 01:43 |
| DanaG | Hmm, is there info about that board, publicly available? | 01:43 |
| DanaG | heh, I can't find even a _picture_ of the Marvell Dove boards. | 01:45 |
| DanaG | http://swik.net/Gentoo/Planet+Gentoo/Ra%C3%BAl+Porcel:+ARMv7+SoCs:+Freescale+i.MX51+Babbage,+TI+OMAP3,+Marvell+Dove%2FArmada,+Qualcomm+Snapdragon%E2%80%A6/do9pt | 01:46 |
| DanaG | ah | 01:46 |
| DanaG | I see... it's all very new stuff. | 01:48 |
| Martyn | DanaG : There's even a public FORUM for development of tegra2 | 01:50 |
| Martyn | http://developer.nvidia.com/tegra/forum | 01:50 |
| Martyn | I am prevented from photographing it due to NDA, but it's neat | 01:51 |
| DanaG | Can you say if it's a mobile form, or a desktop-ish form? | 01:52 |
| DanaG | Desktop-is as in, openrd-base counts as that. | 01:52 |
| Martyn | mobile, about 15cm on a side, square | 01:53 |
| Martyn | embedded memory, two PCIe slots, three USB, one USB OTG (used to load firmware), etc.. | 01:53 |
| DanaG | Spiffy. | 01:53 |
| DanaG | Hmm, is there an expiration date on that NDA? Or is the date itself... under NDA? | 01:53 |
| persia | Martyn: Are you allowed to describe the embedded memory? raw NOR, raw NAND, uses FTL, etc.? | 02:28 |
| persia | (and how much?) | 02:29 |
| Martyn | persia : There is 1GB of 667MHz DDR2 ram | 02:33 |
| Martyn | I honestly don't know how much flash there is, but there is quite a bit | 02:33 |
| Martyn | there is no NOR that I'm aware of, but I have a SPI nor chip attached (8mbit) for my own use | 02:33 |
| Martyn | I know they also have some kind of SPI EEPROM | 02:34 |
| persia | Thanks. I'm mostly interested in flash, as I like the idea of / on NAND, but that can wait for retail :) | 02:35 |
| * persia is mostly happy to wait for retail, but kinda wishes things would move a little faster sometimes | 02:36 | |
| Martyn | http://developer.nvidia.com/tegra/tegra-devkit-features | 02:36 |
| Martyn | They released a devkit picture and overview! | 02:36 |
| Martyn | No more NDA for me then | 02:36 |
| Martyn | 512MB SLC nand | 02:36 |
| persia | Nifty! | 02:37 |
| Martyn | it's a droolable board, and they are just now out of stock too | 02:37 |
| Martyn | more stock coming around May 1 | 02:37 |
| persia | Oh :( 512MB isn't quite enough. | 02:37 |
| Martyn | It's PLENTY for a boot/root filesystem | 02:37 |
| Martyn | you can put /usr on something else | 02:37 |
| persia | Yeah. | 02:37 |
| Martyn | persia : Consider for a moment, that ALL of android fits in 64MB | 02:37 |
| Martyn | 128MB on th eoutside | 02:38 |
| persia | My preference is / on NAND, and /var, /home on rotary (as I churn that), but that's just me. | 02:38 |
| persia | I only consider Ubuntu, which wants ~2GB for the base install. | 02:38 |
| Martyn | doens't need to be | 02:38 |
| Martyn | I've gotten the base down to 384M | 02:38 |
| persia | Depends on the install. servers can be a lot less. | 02:38 |
| Martyn | base is -very small- | 02:39 |
| Martyn | everything else on top of it is big | 02:39 |
| persia | Right. | 02:39 |
| Martyn | but my tarball of base is 276mb right now | 02:39 |
| Martyn | uncompressed | 02:39 |
| persia | My armel buildd chroot is 304MB uncompressed. | 02:40 |
| Martyn | that's about right | 02:40 |
| Martyn | and if you do tasksel server, it increases to ~380 | 02:40 |
| persia | (base+build-essential+vim-tiny+less) | 02:40 |
| Martyn | yeah, you need GCC in there | 02:40 |
| persia | For my buildd? Yeah :) | 02:40 |
| persia | But it gets *lots* bigger when you install all the Desktop/Netbook stuff. | 02:41 |
| Martyn | depends what you install | 02:41 |
| Martyn | I have basic browser, and support files, coming in at ~780m | 02:42 |
| persia | Oh, did you ever get a chance to dig into eucalyptus-nc and make it work for headless managed servers, rather than just KVM? | 02:42 |
| Martyn | no | 02:42 |
| Martyn | that's our new blueprint for UDS-M | 02:42 |
| Martyn | one of three that we've decided on | 02:42 |
| persia | Oh, cool. | 02:42 |
| persia | What are the other two? | 02:42 |
| Martyn | eucalyptus + LXC is one | 02:42 |
| Martyn | arm-server image without kernel/initrd | 02:42 |
| Martyn | so that more people can just download the .img and get working | 02:43 |
| Martyn | (because other than kernel/initrd .. all armv7 images are the same) | 02:43 |
| persia | I'm philosophically opposed to that, because I think separating the kernel from the rest of it is poor design, but yeah, that's probably best until we can *fix* the issues with ARM kernels. | 02:43 |
| Martyn | yep. | 02:43 |
| persia | Actually, do you have a working qemu target for your board? | 02:44 |
| Martyn | but the kernel --is-- separate .. there's no reason you shouldn't be able to get a .img of an ext4 filesystem | 02:44 |
| Martyn | no. We are not going to do QEMU of our board | 02:44 |
| Martyn | we're not in the business of building simulators | 02:44 |
| Martyn | by not doing so, we'll get to hardware that much faster | 02:44 |
| persia | Fair. | 02:44 |
| persia | Means no chance of changing the qemu kernel target though :) | 02:45 |
| Martyn | plus the performance of qemu of multicore architectures -sucks- | 02:45 |
| Martyn | much less of quad core | 02:45 |
| persia | Yeah :) | 02:45 |
| Martyn | much less one with 4GB of ram | 02:45 |
| persia | But I argume the kernel isn't separate: it inherently depends on the toolchain, and is interrelated. | 02:45 |
| persia | The initrd is even more not separate, since it's constructed based on the filesystem. | 02:46 |
| persia | And the filesystem contains all the kernel modules, etc. | 02:46 |
| Martyn | but the initrd is mostly -not used- by ARM targets | 02:46 |
| persia | But that's all well-known, and it doesn't make the situation better for folks stuck in the embedded model. | 02:46 |
| Martyn | in fact, Dustin and I use monolithic kernels | 02:46 |
| Martyn | right | 02:47 |
| Martyn | so, if you ignore it (and you can .. ) things get easier | 02:47 |
| Martyn | plus you can build the initrd after completing the install with a monolithic kernel if needed | 02:47 |
| persia | Well, I won't ignore it, but I'm willing to take a longer term view, and let folks work around it for now :) | 02:47 |
| persia | For some classes of install: the d-i installer is based inside the initrd, for example :) | 02:48 |
| persia | Which installer is the one used by the server installs. | 02:48 |
| persia | But I'll attend the session: some of this can be worked around. | 02:48 |
| persia | And what can't can probably be scripted in some way. | 02:48 |
| persia | So, what's the third spec? | 02:49 |
| Martyn | that's private for now | 02:54 |
| Martyn | but just for a week or so while the guy working on it gets it completed | 02:54 |
| Martyn | it's something around cluster control | 02:55 |
| Martyn | (aka cloud control) | 02:55 |
| persia | OK. From your first comment I worried that you'd forgotten that UDS is incredibly public (sessions are icecasted, specs are on the internet, etc.) | 02:55 |
| Martyn | No, I just don't want to say what I don't know :) | 02:56 |
| persia | That's as much detail as I sought. Makes sense, given the vision from your webpages. | 02:56 |
| * DanaG sticks with ubuntu. Angstrom is a pain. Ubuntu on my beagle matches my host system's development environment perfectly. =þ | 04:03 | |
| DanaG | hmm, is the GPU on that a PCI device, or a "platform" device (a.k.a. not PCI)? | 04:05 |
| DanaG | And can it run compiz? =þ | 04:06 |
| DanaG | hmm, which of the two slots is "external" MMC/SD? | 04:07 |
| persia | It's times like this that one wishes vendor spec sheets came with dmesg output and lspci -vvn and lsusb -v :) | 04:09 |
| DanaG | yeah. I'd hardly call that too much to ask. | 04:10 |
| persia | I think we need generic booting kernels first. | 04:23 |
| persia | Most of the other architectures have them, so now we just look silly. | 04:23 |
| persia | Mind you, powerpc seems to be moving in the multi-kernel direction, but I hope that's just a short-term thing. | 04:24 |
| DanaG | error: expected type-specifier before ‘boost’ | 04:47 |
| DanaG | ARGH | 04:47 |
| DanaG | er, wrong tab... off-topic for this channel. | 04:48 |
| ericm | who can point me a cross compiling friendly debian package as an example? | 09:33 |
| lool | ericm: You mean to cross debuild it? | 09:34 |
| lool | ericm: You could try the x-loader or u-boot packages in lucid, I fixed them to be cross-buildable | 09:34 |
| ericm | lool, thanks - I'll take a look | 09:35 |
| ericm | lool, are they tracked with bzr? | 09:37 |
| lool | ericm: All packages are nowadays :) | 09:37 |
| lool | well almost all | 09:37 |
| lool | ericm: try bzr branch lp:ubuntu/x-loader | 09:38 |
| ericm | https://launchpad.net/ubuntu/lucid/+source/x-loader, I'm seeing it might be managed with git? | 09:38 |
| lool | ericm: the git you see there is in the version because it's coming from git upstream | 09:38 |
| lool | So the version mentions this is a git snapshot | 09:38 |
| ericm | lool, ok - so it's actually managed by git and synced on lp with bzr? | 09:39 |
| lool | ericm: The way to retrieve exactly what's in the archive locally is "apt-get source", when you actually want to commit to the *packaging* vcs of some package, you can check whether the package has Vcs-* headers, or simply use "debcheckout" which will checkout the relevant Vcs (or just apt-get source if no Vcs was found) | 09:40 |
| lool | ericm: *Upstream* uses git | 09:40 |
| ericm | lool, ah I see | 09:40 |
| lool | ericm: For instance, I uploaded a snapshot of valgrind 3.6.0 from SVN and used: Version: 1:3.6.0~svn20100212-0ubuntu4 | 09:40 |
| lool | Just to reflect that I took the snapshot on 20100212 | 09:41 |
| ericm | lool, so the bzr only tracks the snapshots, not exactly sync'ed with upstream in full history? | 09:41 |
| lool | ericm: We have automated imports of what reaches the archive into bzr | 09:42 |
| lool | ericm: So the history is only that of the Ubuntu uploads | 09:42 |
| ericm | lool, btw - it looks to me x-loader/debian/rules is strange, no binary target? | 09:42 |
| lool | ericm: we have another import for the debian upload, and these are done in a compatible way so that you can merge between them | 09:42 |
| ericm | and dh_auto_build seems to do the magic of cross compiling? | 09:42 |
| lool | ericm: However if we were to track upstream history (which we do relatively rarely), we'd have to setup a git import in Launchpad first | 09:43 |
| lool | ericm: That's the new style "dh" rules, it basically say "do the standard thing unless I write an override" | 09:43 |
| lool | ericm: You could try cross-building zlib | 09:44 |
| lool | it's more standard-style | 09:45 |
| ericm | lool, ok let me take a look | 09:45 |
| === hrw|gone is now known as hrw | ||
| hrw | hi | 09:49 |
| lool | hi | 09:49 |
| ericm | lool, well it looks like zlib doesn't specify --host in its configure, just with a CC assignment before ./configure, which will work in most cases? | 09:49 |
| lool | ericm: zlib is not using autoconf IIRC | 09:49 |
| lool | ericm: So its configure doesn't support --host and --build | 09:50 |
| lool | ericm: Yes, the package should cross-build, I cross-built it recently | 09:50 |
| ericm | and CC="$(DEB_HOST_GNU_TYPE)-gcc" doesn't work with codesourcery toolchain and others | 09:50 |
| lool | ericm: To cross-build it, try something like DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -B -us -uc -aarmel -d | 09:50 |
| ericm | might need some way to specify the toolchain if it's not using the standard gcc naming convention | 09:51 |
| lool | ericm: Yes, that's the first problem you'll encounter | 09:51 |
| lool | ericm: then your package will also fail to build near dh_shlibdeps because codesourcery doesn't include debian specific shlibs information | 09:51 |
| ericm | lool, :-( | 09:51 |
| lool | ericm: I'm afraid it's not possible to switch triplet, many many upstreams expect $triplet-gcc | 09:51 |
| hrw | lool: OE has patch to make zlib more autotools | 09:52 |
| lool | ericm: What you need is debian/ubuntu cross-building training :-) | 09:52 |
| lool | hrw: Wont help dh_shlibdeps I'm afraid | 09:52 |
| ericm | lool, yes - any references? | 09:52 |
| ericm | lool, I'm a slack | 09:52 |
| lool | ericm: Let me email you the slides | 09:52 |
| ericm | lool, that will be nice | 09:52 |
| hrw | we remove configure, makefile.in and place configure.ac + makefile.am + zlib.pc.in | 09:52 |
| hrw | lool: probably not | 09:52 |
| lool | ericm: You're not going into safe and nicely working territory, this is pushing the limits of our current systems a bit :-) | 09:52 |
| nosse1 | lool: Would it be possible to gain a copy of those slides? | 09:52 |
| nosse1 | lool: We are working with the same issues here. | 09:53 |
| lool | ericm: sent | 09:53 |
| ericm | lool, thanks | 09:53 |
| lool | nosse1: It would, but I'd have to strip them slightly and double-check internally | 09:54 |
| nosse1 | lool: Please do. I'd be grateful. | 09:54 |
| lool | nosse1: Sorry, what's your real name again? | 09:54 |
| lool | nosse1: will check | 09:55 |
| nosse1 | lool: My name is Svein Seldal | 09:55 |
| lool | nosse1: People who I need to check with are sleeping still; I'll check later today, if I forget, please remind me | 09:56 |
| ogra | lool, time for an #ubuntu-classroom session ;) | 09:56 |
| nosse1 | lool: FYI I've finally installed Lucid on AM3517 eval kit from TI. And I'm using the CS toolchain to cross the kernel, qt and our application while running "mainstream" ubuntu on the rest | 09:56 |
| lool | ericm: I'm afraid you'll miss the '[ DEMO ]' parts :) | 09:56 |
| lool | ericm: xbuild.txt has notes on what I'd actually be typing there | 09:56 |
| lool | nosse1: Nice | 09:57 |
| ericm | lool, I went roughly through the first several slides, and decided to native build in my chroot :-) | 09:57 |
| lool | ericm: lol | 09:57 |
| lool | ericm: I think you're doing the right thing | 09:57 |
| lool | ericm: For people with very slow hardware, or generally resource-constrained hardware or no hardware I'd advocate trying qemu-user | 09:58 |
| lool | I think I should fix our cross-build tool to not care about build-dep loops when converting pre-built packages from the archive | 09:58 |
| ericm | lool, indeed | 09:59 |
| nosse1 | Since it is possible to mix host and target binaries in a chroot environment I played with the idea to inject the CS cross compiler into the chroot env to use host native tools for building. | 09:59 |
| lool | If I were to fix it, we'd have a single tool one step way of cross-building any package which can be cross-built *if* you have a dpkg-cross compatible toolchain | 09:59 |
| nosse1 | I don't know if it's even possible or if it's just an crazy idea... :o | 09:59 |
| lool | nosse1: It's definitely possible, I cover this in my slides, well I mention the idea | 10:00 |
| lool | nosse1: it's possible in three ways | 10:00 |
| lool | nosse1: a) real hardware + icecc to move the actual compilation from your slow hardware to a remote intel host running a cross toolchain | 10:00 |
| lool | b) QEMU machine emulation (emulating hardware), just like a) | 10:01 |
| nosse1 | Point is target native compilation, qemu/chroot is all very slow. That is the one reason you would want to use the CS cross compiler | 10:01 |
| lool | c) qemu-user emulation or sb/sb2 like emulation and actual intel binaries in your chroot; "croco" which suihkulokki maintains upstream on gitorious does this | 10:01 |
| lool | nosse1: the compilation isn't the only slow point though | 10:02 |
| lool | that's typically the case for large C++ apps like Qt, but there are other issues | 10:02 |
| nosse1 | lool: You asked about my name. Here's my lauchpad profile: https://launchpad.net/~sveinse | 10:03 |
| ogra | wow, the netbook installer looks really nice | 10:04 |
| lool | nosse1: Yup found it googling your name | 10:05 |
| persia | lool: Are you planning to drop clean croco support into maverick? | 10:05 |
| lool | persia: drop? you mean provide/upload? | 10:05 |
| persia | Yes. | 10:06 |
| ogra | drop into :) | 10:06 |
| lool | persia: I'd love to | 10:06 |
| nosse1 | lool: I need to go to a meeting. I'll remind you later if doesnt hear anything ;) Thanks! | 10:06 |
| persia | Lovely. Will this be something that has to be installed on both the chroot and the host, or just the chroot? | 10:06 |
| lool | persia: Just the chroot | 10:07 |
| lool | persia: it's qemu-user style emulation | 10:07 |
| persia | So how does it get to the non-chroot binaries, or does one have to install both architectures in the chroot? | 10:09 |
| lool | persia: exactly | 10:09 |
| persia | Oh :) | 10:09 |
| lool | There are various approaches to this kind of hack; in croco, you have a croco.map file which is used when intercepting exec() calls | 10:10 |
| persia | I don't suppose there's some way we could adjust the binfmt-misc wrapper to catch some stuff and execute that natively without adding to the chroot, is there? | 10:10 |
| lool | not really | 10:10 |
| lool | I mean, the kernel/binfmt will do the right thing and run the proper binaries | 10:11 |
| lool | That is, it will see that's for intel and just run them without qemu-arm-static | 10:11 |
| lool | or see it's for arm and run them with it | 10:11 |
| persia | RIght. I was kinda hoping for a way to get croco acceleration out of a Souyz chroot, but I don't think that's feasible. | 10:11 |
| lool | What the kernel doesn't do is remap what you really want to run depending on the path | 10:11 |
| persia | Needs a special crocoised chroot. | 10:11 |
| lool | I personally think security tools might be a better fit for this, but I'm not technical enough to look into it yet | 10:12 |
| lool | persia: Well you typically want your apps to run chroot-ed as to limit their view on files to the ones you have in your build env | 10:12 |
| lool | If they run chrooted, then you need chrooted binaries and their libraries; you could run them from the outside and then chroot, but many of them fork() to run other apps | 10:13 |
| lool | such as gcc calling cc1 or so | 10:13 |
| persia | Oh, certainly. I just wanted to reuse the same chroots for native and non-native. | 10:13 |
| persia | But I don't think that this will work with croco. | 10:13 |
| lool | persia: That works | 10:13 |
| ogra | binfmt should catch that | 10:13 |
| ogra | but you will effectively end up with two full environments in one | 10:14 |
| lool | persia: When you enter the chroot with croco turned on, it intercepts calls to e.g. /usr/bin/gcc, but if you enter it normally, it doesn't | 10:14 |
| lool | ogra: Not related to binfmt really | 10:14 |
| persia | ogra: Indeed, and it works well, so I can just `pull-soyuz-chroot lucid armel; sbuild -d lucid-armel-soyuz foo.dsc`, but that's not as fast as it could be. | 10:15 |
| persia | lool: Right, but the chroot needs to be multi-arch for croco to work, which the soyuz chroots aren't (and shouldn't be). | 10:16 |
| lool | persia: What do you mean multi-arch? | 10:16 |
| persia | having e.g. i386 *AND* armel binaries. | 10:16 |
| lool | persia: What I mean is that once you've included croco in your chroot (currently in /croco) you can still use it as before | 10:16 |
| persia | Right. | 10:16 |
| persia | So we can have a script that adds croco to a chroot, but we can't expect to install something on the host that automatically does croco-acceleration for all chroots. | 10:17 |
| === hrw is now known as hrw|gone | ||
| lool | persia: Well unless you make it part of your build tool, e.g. mount --bind /host/croco /build-chroot/croco | 10:22 |
| persia | And all the native stuff would live under /croco ? | 10:23 |
| lool | Yes | 10:23 |
| persia | Oh, suddenly that looks a lot nicer. | 10:24 |
| persia | Right. I think I have an idea how to do that, at least for schroots. pbuilder will require more investigation. | 10:31 |
| persia | (or rather pbuilder-dist integration: pbuilder has hooks that make it easy for folks that know how to use pbuilder) | 10:31 |
| ogra | #define DEFAULT_DEVICE "/dev/fb" | 10:34 |
| ogra | /* FIXME: We don't really want to do it like this... */ | 10:34 |
| * ogra grumbles about the omapfb xserver | 10:34 | |
| ogra | they could at least have picked fb0 | 10:35 |
| persia | So, XorA suggested we could (temporarily) ship a udev rule in the xserver package that would add the symlink. | 10:36 |
| persia | XorA also suggested that he expected to be directed to fix it in the near future. | 10:36 |
| ogra | well, given that we're in hard freeze it wont happen for lucid anyway | 10:37 |
| ogra | and for maverick we should just fix it properly | 10:37 |
| lool | Can't we fix this omap specific package instead? | 10:50 |
| lool | How does Debian do it? | 10:51 |
| ogra | lool, thast what i was saying :) | 10:51 |
| ogra | fix it properly by adding a routine that detects the device instead of hardcoding it | 10:52 |
| lool | ogra: switching to fb0 would be good enough for lucid | 10:52 |
| ogra | sure | 10:52 |
| persia | It's not terribly difficult to fix, but if XorA plans to fix it, I'm not sure of the value of trying to fix it before him. | 10:53 |
| lool | persia: Having the package in lucid work? :) | 10:53 |
| persia | That's trivially done by shipping a udev rule to create the node the software wants. | 10:54 |
| * ogra checks the other omapfb package as well ... i bet it uses the same hack | 10:54 | |
| persia | Could add a s/fb/fb0/ patch, but I had the impression from the discussion this weekend there was some reason this was complex. | 10:54 |
| lool | .BI "Option \*qfbdev\*q \*q" string \*q | 10:55 |
| lool | The framebuffer device to use. Default: /dev/fb0. | 10:55 |
| lool | From man/fbdev.man | 10:55 |
| lool | apparently this is a xorg default for options named "fbdev" -- couldn't find any actual default in xorg-fbdev | 10:57 |
| ogra | persia, given that we only support one board atm and in the light that fb0 is usually the default i think its safe to just take fb0 | 10:57 |
| ogra | for maverick we should add some detection code though | 10:57 |
| persia | XorA|gone: When you get back, please explain why this is a good/not good idea in some detail. | 10:58 |
| lool | fbdevHWInit(pScrn,NULL,xf86FindOptionValue(fPtr->pEnt->device->options,"fbdev")) | 10:58 |
| persia | ogra: My fear is that the hardcoding is more complex and deeper than you think. | 10:58 |
| ogra | persia, not really | 10:58 |
| ogra | but i'll test it as soon as this netbook install is done | 10:59 |
| ogra | (if that finishes before the volcano stops spitting ash :P ) | 10:59 |
| persia | OK. All I can advise is to check the weekend backscroll. If it trivially works, go ahead. If it doesn't, let's work around it for lucid. | 10:59 |
| lool | persia, ogra: So apparently, xorg-server/hw/xfree86/fbdevhw/fbdevhw.c does the default on fb0 | 11:01 |
| lool | It can be overriden with FRAMEBUFFER in the env | 11:01 |
| lool | or in the config obviously | 11:02 |
| ogra | yeah | 11:02 |
| ogra | so omapfb should just do the same | 11:02 |
| persia | lool: Indeed. THis is an omapfb-specific bug. | 11:02 |
| persia | (and known to be a bug) | 11:02 |
| lool | fbdevHWInit() calls fbdev_open() which open()s the fbdev, and that's pretty much it; I think src/omapfb-driver.c could do the same | 11:03 |
| lool | Uh plus it checks for fd > 0 ohw ugly | 11:03 |
| persia | There's some trickiness in omapfb because it makes assumptions that certain fbX devices have certain special features/functions. | 11:05 |
| persia | And this needs massive cleanup (upstream), which is why I believe the lucid-timeframe answer is a udev rule. | 11:06 |
| ogra | these are in different source files | 11:06 |
| ogra | xv has its separate source and uses fb1 | 11:06 |
| ogra | root@babbage2:/xf86-video-omapfb-0.1.1# grep -r /dev/fb * | 11:07 |
| ogra | src/omapfb-driver.c:#define DEFAULT_DEVICE "/dev/fb" | 11:07 |
| ogra | src/omapfb-xv.c:#define OMAP_FBDEV1_NAME "/dev/fb1" | 11:07 |
| ogra | in that light src/omapfb-driver.c should just be hardcoded to fb0 | 11:07 |
| cooloney | plars and GrueMaster, could you please guys to help look at bug #567157 | 11:07 |
| ogra | unless lool wants to add the proper fbdev_open() calls :) | 11:07 |
| ubot4 | Launchpad bug 567157 in linux-fsl-imx51 (Ubuntu) "regulators enabled at boot and also print error messages at boot. (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/567157 | 11:07 |
| lool | ogra: I'll do it in my CFT | 11:08 |
| ogra | CFT ? | 11:08 |
| * ogra wonders what C means | 11:08 | |
| lool | copious free time | 11:08 |
| ogra | ah | 11:08 |
| eggonlea | hi, anybody knows about netbook-launcher-efl? Would the XV window get damage info again after it redraws application GUI (e.g. totem)? Now it seems destroys the colorkey background so video cannot be shown correctly. | 11:08 |
| ogra | bah, crap flash-kernel fails in ubiquity | 11:10 |
| lool | eggonlea: Sorry no idea | 11:17 |
| lool | Who's maintaining netbook-launcher-efl here? | 11:17 |
| lool | JamieBennett: is that you? | 11:17 |
| JamieBennett | lool: mterry | 11:18 |
| persia | Isn't mterry upstream? | 11:19 |
| JamieBennett | persia: he is now but not the original upstream | 11:19 |
| lool | eggonlea: Try pinging mterry on #ubuntu-devel or so, he's upstream and is easter time | 11:19 |
| lool | *eastern | 11:19 |
| JamieBennett | he is looking after n-l-efl | 11:19 |
| eggonlea | lool: great, thanks! | 11:20 |
| persia | Yeah, well, teams have member turnover, but an upstream contact is an upstream contact :) | 11:21 |
| JamieBennett | persia: :) | 11:21 |
| === ogra_ is now known as ogra | ||
| === hrw|gone is now known as hrw | ||
| nosse1 | lool: I hope I wasn't rude or anything about requesting the presentation earlier on. I was kind of in a hurry, so I threw myself into the discussion | 12:55 |
| lool | nosse1: Oh not at all | 13:01 |
| lool | nosse1: I wouldn't have mentionned it here if there was no chance of publishing it | 13:01 |
| === nosse1 is now known as sveinse | ||
| * sveinse got his beloved old nick back. *nosse1* is now known as *sveinse* | 13:08 | |
| sveinse | Is #ubuntu-arm logged anywhere? | 13:13 |
| rcn-ee | sveinse, http://irclogs.ubuntu.com/ but usually an hour behind.. ;) | 13:14 |
| ogra | irclogs.ubuntu.com | 13:14 |
| sveinse | rcn-ee: np, I'm looking for something weeks old | 13:14 |
| rcn-ee | ogra, so i was playing around with different methods... The NetInstall really doesn't like it when i force nand to read only.. ;) | 13:15 |
| ogra | indeed | 13:15 |
| ogra | file a bug on flash-kernel so we can cancel the installation properly with a clean error message | 13:16 |
| rcn-ee | i will, after some more testing.. its weird since early in the flash-kernel script it calls the one /etc/flash*.conf so it shoudl exit. (well it works on an already built image) but the NetInstall still runs it.. | 13:17 |
| ogra | while its sourced, the omap code doesnt use anything from it | 13:18 |
| ogra | actually we only introduced it for imx51 since that has an awful setup | 13:18 |
| rcn-ee | yeah i saw that, awful bootloader mess you had to work thru... | 13:18 |
| ogra | after using it for three releases i really like redboot more than uboot | 13:19 |
| ogra | :) | 13:19 |
| hrw | ogra: can you tell more about that 'awful setup'? | 13:19 |
| rcn-ee | the easy thing, would be a variable in that config to please leave the nand alone | 13:19 |
| ogra | hrw, abusing your install media as "bootfloppy" | 13:19 |
| hrw | ah | 13:20 |
| ogra | truncating it at the end of the install ... | 13:20 |
| ogra | the babbage board can only boot from SD | 13:20 |
| ogra | but you cant easily install to the installation media you run from | 13:20 |
| ogra | so babbage requires you to install to USB and to keep the SD you installed from as boot media, carrying a special non-data partition that holds redboot, kernel, initramfs and the redboot config (simulating a flash) | 13:21 |
| hrw | ough | 13:32 |
| persia | sveinse: Did you find what you needed in the logs? They are (up to) an hour out of date, but they should go back to within a couple weeks of when I opened the channel. | 13:34 |
| sveinse | persia: yes, thank you | 13:37 |
| sveinse | Anyone here with openocd and kernel debug experience? | 13:45 |
| hrw | I use openocd only to reboot sheevaplug | 13:46 |
| NCommander | ogra: when you use a non-hacked up u-boot, your opinion will likely change | 13:47 |
| ogra | NCommander, nope | 13:47 |
| ogra | i like fast boots ... | 13:47 |
| NCommander | ogra: ouch. | 13:47 |
| ogra | uboot cant achieve that | 13:47 |
| ogra | by design | 13:48 |
| NCommander | ogra: u-boot can do raw reads just like redboot. | 13:48 |
| NCommander | I just like having a filesystem for my files | 13:48 |
| NCommander | But thats just me. | 13:48 |
| hrw | ogra: what you use for that 'fast boot'? | 13:48 |
| hrw | nand read? | 13:49 |
| lool | NCommander: redboot supports filesystems as well | 13:49 |
| NCommander | lool: upstream does, but no vendor fork of Redboot I've seen has it :-/ | 13:50 |
| lool | It's not really a problem with redboot though, but with the vendors :-/ | 13:51 |
| NCommander | lool: indeed. If we had a modern redboot, I suspect my ability to complain about imx51 booting would be severaly reduced | 13:52 |
| ogra | indeed i like its flexibility | 13:52 |
| ogra | it still needs to convert from uImage to raw, no ? | 13:52 |
| ogra | and copy it around in ram | 13:52 |
| NCommander | ogra: u-boot can do XIP | 13:53 |
| sveinse | Do you know if there a host graphical debugger (ddd or insight) which can debug arm code for target? (Probably it's a generic host for the GUI part and gdb-arm for the target) | 13:54 |
| NCommander | sveinse: ddd should be able to use a cross-debugger, but its been awhile since I tried it | 13:54 |
| * NCommander just got used to using gdb directly; less painful | 13:54 | |
| * sveinse is about to embark on some kernel driver development, and need eyes into the running kernel... | 13:54 | |
| ogra | hrw, redboot ... fast boot paid with zero flexibility | 13:55 |
| sveinse | I'm going to use JTAG tool + OpenOCD, but I need a GUI frontend for gdb on host | 13:55 |
| ogra | ******* reminder ubuntu mobile meeting in 5 min in #ubuntu-meeting ******* | 13:55 |
| slapin | hi, all! | 13:57 |
| slapin | I try to rebuild gtk+2.0 on my SheevaPlug, and it uses -mfpu=vfp for it, is it ok? I could'nt find that Sheeva supports any floating point unit... | 13:59 |
| lool | slapin: We require vfp nowdays | 13:59 |
| lool | in Ubuntu that is | 13:59 |
| slapin | where could I change that globally in my build environment? | 14:00 |
| lool | slapin: You'd need to rebuild all of Ubuntu | 14:01 |
| lool | slapin: This is encoded in the toolchain defaults | 14:01 |
| slapin | lool: is there some automated way to build all ubuntu (at least base system plus some packages)? | 14:02 |
| slapin | lool: I mean cross-compile | 14:02 |
| lool | slapin: Cross-compile, not really | 14:03 |
| lool | there are various tools available to rebuild Ubuntu as a whole, but they are not too clever, so you might have to do that multiple times | 14:03 |
| slapin | lool: what device is used to build lots of packages reasonably fast for ARM architecture? | 14:04 |
| slapin | lool: I think it is ok with me, I just want to know which tool is mainstream one | 14:05 |
| slapin | lool: and what setup is needed. | 14:05 |
| lool | slapin: We currently build continously | 14:06 |
| lool | slapin: using real ARM hardware | 14:06 |
| ogra | using launchpad/soyuz as builder system on top | 14:07 |
| lool | We tried using both dove and imx51 boards, but I think our build system is mostly imx51 atm | 14:07 |
| slapin | is it possible to build locally? | 14:08 |
| lool | slapin: Yes | 14:09 |
| lool | slapin: In theory you can setup launchpad, albeit that's heavy, or you can use the Debian tools such as wanna-build and dak, but these are a bit hard to setup as well; finally there are some ad hoc rebiuld tools like rebuildd | 14:10 |
| slapin | lool: 'heavy' is fine with me, is there any docs on how to set up launchpad? | 14:11 |
| persia | slapin: There's some (limited) docs as a side effect of https://dev.launchpad.net/Getting | 14:13 |
| slapin | thanks a lot! | 14:19 |
| === hrw is now known as hrw|gone | ||
| === JaMa is now known as JaMa|Opera | ||
| plars | ogra: omap image didn't build last night, I assume because of RC (which it is not really included in at the moment). Any way to force just that one to rebuild? | 15:05 |
| ogra | plars, we need the livecd-rootfs fix anyway, so i prefer to wait | 15:06 |
| plars | ogra: ok | 15:07 |
| ogra | assuming you refer to netbook | 15:07 |
| plars | ogra: yes | 15:07 |
| sveinse | lool: Thanks! If you are interested, I can keep you posted on how we solve cross compilation into Ubuntu. Currently it seems that apps built in the cross compiler works directly on target, but I think that's a coincidence that both libc and libstc++ has the same version on the cross and on the native system. | 15:40 |
| lool | sveinse: Correct; I don't expect too many incompatibilities there, because we try hard to have working binaries, but it's bad for other reasons (you actually want to know aganst what piece everything is built, and wihch features it uses -- toolchain flags and such) | 15:44 |
| === TheWhiteGhost_ is now known as TheWhiteGhost | ||
| sveinse | lool: Where is the default compile flags (for the native compiler defined)? In the spec file? | 15:58 |
| lool | The toolchain default to what you compiled it with | 16:00 |
| sveinse | Ah right, so it adopts its CFLAGS automatically | 16:01 |
| dmart | NCommander: does OOo build at the moment? I've been trying to get a build tree for a few days, but I've hit problems | 16:28 |
| ogra | dmart, it should | 16:28 |
| lool | dmart: Yes I think so | 16:28 |
| lool | dmart: Well it's *building* I think | 16:29 |
| ogra | and it did as well before that minor change upload | 16:29 |
| NCommander | dmart: in theory. | 16:29 |
| ogra | after NCommander fixed it | 16:29 |
| ogra | there was one finished build afaik | 16:29 |
| NCommander | ogra: you mean blundened it | 16:29 |
| lool | It's definitely building ATM | 16:29 |
| ogra | yeah, there was a recent upload | 16:30 |
| NCommander | dmart: we forced it to -marm. Not a real fix, but works for now | 16:30 |
| dmart | http://pastebin.ubuntu.com/419326/ | 16:31 |
| dmart | I always get this, whether the -marm workaround is present or not. | 16:31 |
| dmart | My filesystem should be up to date | 16:31 |
| lool | ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup | 16:31 |
| lool | hmm | 16:31 |
| ogra | dmart, how far into the build was that ? | 16:31 |
| ogra | https://edge.launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 says its running since 19th | 16:32 |
| dmart | Pretty early - no more than 1h in | 16:32 |
| dmart | Incorrect build-deps (or my filesystem in a mess) | 16:32 |
| dmart | ? | 16:32 |
| dmart | This is a lucid chroot running on top of Jaunty in babbage1 | 16:32 |
| ogra | heh | 16:33 |
| ogra | thats a pretty unpredictable env | 16:33 |
| ogra | our buildfarm is completely bbg3 on lucid now | 16:34 |
| persia | I've encountered a number of odd failures running pbuilder in jaunty to build lucid: I've had significantly better success with using qemu-user mode (although that's not a good basis for this specific issue) | 16:34 |
| ogra | surely not for OO.o, no :) | 16:34 |
| dmart | OK, maybe I ought to be careful about this | 16:34 |
| persia | I've been presuming it's due to missing thumb2 support int he jaunty kernel, although I have no basis for this presumption. | 16:34 |
| dmart | I have loads of babbage1 doing not much :/ | 16:34 |
| persia | dmart: Can you get a 2.6.32 kernel running on them? | 16:35 |
| dmart | persia: the jaunty kernel should support Thumb-2, but there might be some unfixed issues | 16:35 |
| persia | if so, you have the basis of a lovely build farm :) | 16:35 |
| ogra | persia, bbg1 was pre-production HW | 16:35 |
| dmart | I can maybe run the build on babbage3 and use the babbage1s as distcc slaves | 16:35 |
| ogra | there can be plenty of silicon issues | 16:35 |
| dmart | a pretty dumb board can run distccd | 16:36 |
| ogra | yeah, for distcc that might work | 16:36 |
| ogra | or icecc | 16:36 |
| dmart | icecc? | 16:36 |
| ogra | next gen distcc :) | 16:36 |
| * dmart googles | 16:37 | |
| dmart | oh, right :) | 16:37 |
| ogra | NCommander had a setup for his OO.o tests | 16:37 |
| dmart | For massive C++ compiles distcc can provide quite a boost | 16:37 |
| NCommander | ogra: dmart: icecc doesn't help much, since then it tries to parallize the things that icecc doesn't do, and the then it goes bad | 16:38 |
| ogra | ?? | 16:38 |
| ogra | which of the icecc should be distcc now ? | 16:38 |
| NCommander | ogra: basically, theres no way to tell OOo you only want to parallize the building only the C/C++ builds | 16:38 |
| NCommander | so it works great for C/C++ modules | 16:38 |
| NCommander | it gets really bad when it gets to running javac | 16:38 |
| * ogra still doesnt get what things icecc does that icecc doesnt do | 16:39 | |
| ogra | that sentence made no sense | 16:39 |
| NCommander | ogra: oh, I fail | 16:40 |
| NCommander | ogra: basically, the OOo build system is stupid, and can't properly parallize the build so only the C bits are build in parallel | 16:40 |
| suihkulokki | ofcourse, distcc/icecc don't parallilze javac. just c/c++ | 16:40 |
| ogra | right | 16:40 |
| ogra | i got *that* part | 16:41 |
| ogra | the initial sentence was just very confusing | 16:42 |
| prpplague | ogra: ping | 18:07 |
| XorA|gone | hey guys is UDS still going ahead as planned considering the chances of airflight being allowed by then seem to be minimal? | 18:13 |
| lool | XorA|gone: minimal? according to whom? | 18:14 |
| XorA|gone | lool: the volcano doesnt seem to be emitting any less ash | 18:14 |
| lool | Actually it does | 18:15 |
| XorA|gone | lool: not according to news this afternoon when scotland closed again | 18:15 |
| lool | I heard at lunch that ashes emissions went significantly down | 18:15 |
| prpplague | XorA|gone: hey bud | 18:15 |
| persia | XorA|gone: So, isn't that why the chunnel was dug? | 18:15 |
| prpplague | XorA|gone: ugh, saw the new dr.who last saturday :( | 18:16 |
| prpplague | XorA|gone: very disappointed | 18:16 |
| XorA|gone | persia: yeah thats easy enough for me, I just dont want to be the only guy there :-) | 18:16 |
| persia | Those of us from far away can fly to somewhere within train distance one way or another | 18:16 |
| XorA|gone | persia: just checking people are still planning to attend and not move to somewhere more reliable like spain | 18:17 |
| XorA|gone | as Ill need to book tickets ASAP | 18:17 |
| lool | it's definitely still planned :-) | 18:17 |
| persia | We did spain too recently to repeat | 18:17 |
| XorA|gone | BBC news if quite defineate on increasing volcano ash again today | 18:17 |
| persia | (and actually, twice: once andalucia and once catalunya) | 18:18 |
| * XorA|gone thinks we need an Edinburgh to Holland tunnel | 18:19 | |
| sveinse | The airspace here in Norway has been reopened today. And according to the news, the volcano has gone over to a lava-production phase where the ash production is significantly reduced | 18:31 |
| Martyn | sveinse: Thank goodness | 18:34 |
| Martyn | sveinse: But unfortunately the second volcano is starting to swell .. so we're likely going to see a second blast | 18:34 |
| NCommander | eggonlea: you around? | 19:14 |
| hrw|gone | XorA|gone: going for UDS? | 19:27 |
| hrw|gone | XorA|gone: would be great to see at least one known face ;D | 19:28 |
| ogra_cmpc | hrw|gone, we're not *that* ugly, don't be scared :) | 19:31 |
| ogra_cmpc | prpplague, hey | 19:31 |
| ogra_cmpc | (just here for a few mins) | 19:31 |
| hrw|gone | ogra_cmpc: I did not said that. | 19:31 |
| ogra_cmpc | though all the hugging might scare you probably *g* | 19:32 |
| hrw|gone | ogra_cmpc: but when I will arrive at ~21:00 on sunday it would be easier to just call xora and go for a beer then catch someone on irc and then wonder which of guys in lobby was that one | 19:33 |
| * ogra_cmpc doesnt actually knoe when he arrives (driving by car) but i'm surely up for a beer then :) | 19:34 | |
| hrw|gone | ogra_cmpc: during uds I will meet some familiar faces but connecting faces to irc nicks etc takes time | 19:34 |
| ogra_cmpc | indeed | 19:34 |
| * ogra_cmpc knows what you mean | 19:34 | |
| ogra_cmpc | and XorA|gone is easy to memorize :) | 19:34 |
| hrw|gone | guadec 2007 was great for me - I finally met OpenedHand people after working with them for nearly half year | 19:35 |
| ogra_cmpc | you will meet some again at UDS | 19:35 |
| hrw|gone | ogra_cmpc: I first met him in 2006 iirc | 19:35 |
| * ogra_cmpc met him about a month ago in nice | 19:35 | |
| hrw|gone | ogra_cmpc: so far I do not see ex-OH people on list | 19:36 |
| hrw|gone | but there is still time - I am not on a list yet too | 19:36 |
| hrw|gone | waiting for some mails first | 19:36 |
| ogra_cmpc | not sure they did their paperwork yet ... | 19:37 |
| hrw|gone | bts got my papers yesterday | 19:37 |
| ogra_cmpc | but i'm sure neil is coming | 19:37 |
| prpplague | ogra_cmpc: hey bud | 19:40 |
| NCommander | asac: so libgphoto2 successed in public devirtualized PPA | 19:56 |
| NCommander | asac: care to sponsor? | 19:56 |
| crimsun | I can if you pass me the dsc url | 19:56 |
| NCommander | asac: crimsun: https://bugs.edge.launchpad.net/ubuntu/+source/libgphoto2/+bug/567422 | 19:59 |
| ubot4 | Launchpad bug 567422 in libgphoto2 (Ubuntu) "ARM FTBFS fix for libgphoto2 on lucid (affects: 1)" [Undecided,New] | 19:59 |
| asac | NCommander: could you check with -release ... i guess this wont be before RC? | 20:03 |
| NCommander | asac: already did check with release yesterday on fixing this problem this way | 20:04 |
| NCommander | asac: not sure on uploading it now though | 20:04 |
| NCommander | asac: we're in pre-release freeze now though, so you can upload now, and if its problematic, it will just sit in the queue until after RC | 20:09 |
| asac | NCommander: ok. let me test build at least ;) | 20:16 |
| Sayag_Samuel | hello | 21:30 |
| Sayag_Samuel | I'm trying to set an USB camera on the beagle board and I have some problems | 21:30 |
| === JaMa|Opera is now known as JaMa|Zzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!