| DanaG1 | No command 'strace' found, did you mean: | 02:23 |
|---|---|---|
| DanaG1 | Command 'dtrace' from package 'systemtap-sdt-dev' (universe) | 02:23 |
| === DanaG1 is now known as DanaG | ||
| persia | DanaG: On which architecture did you get that? | 02:33 |
| DanaG | ARM, ssh login. | 02:33 |
| persia | Really! Hrm. | 02:33 |
| DanaG | I also had dbus deny me sending stuff to bluez... had to add myself to 'lp' group. | 02:33 |
| persia | So maybe bug #533031 isn't correct. | 02:33 |
| ubot4 | Launchpad bug 533031 in command-not-found (Ubuntu) "command-not-found fails to work on ports architectures (affects: 1)" [Undecided,New] https://launchpad.net/bugs/533031 | 02:33 |
| DanaG | maybe it was just fixed. | 02:33 |
| persia | Still fails for me for some commands on powerpc. | 02:34 |
| persia | Seems to work for others. | 02:34 |
| * persia needs to dig more. | 02:34 | |
| DanaG | weird. | 02:35 |
| persia | Anyway, about strace: do you have the 'strace' package installed? | 02:35 |
| DanaG | *** glibc detected *** aptitude: double free or corruption (!prev): 0x0029d928 *** | 02:36 |
| DanaG | nope, didn't have it installed. | 02:36 |
| persia | There's clearly something wrong with command-not-found, but install it, and it ought work. | 02:37 |
| persia | I wonder if it works for some commands because they happen to be in arch:all packages (so that they are on archive.ubuntu.com) | 02:37 |
| DanaG | Unhandled fault: external abort on non-linefetch (0x1018) at 0x402b5000 | 02:49 |
| DanaG | I also have other weird issues. for example, gnome-disk-utility (palimpsest) can't connect to dbus. | 02:49 |
| persia | Can you run `ubuntu-bug`? If so, please file bugs, | 02:52 |
| DanaG | hmm, I'm not sure how much of that is just me not having the right stuff installed -- for example, is dbus supposed to deny stuff over ssh? | 02:53 |
| DanaG | interesting... it did tell me to install apport. | 02:55 |
| === Guest61212 is now known as NCommander | ||
| persia | DanaG: How did you set up your environment? | 03:01 |
| DanaG | I used a minimal rootfs image and kernel from rcn-ee. | 03:20 |
| persia | How did you construct the minimal rootfs image, or did you get it also from rcn-ee? | 03:31 |
| DanaG | The latter, yes. | 03:34 |
| persia | Have to wait until he's about then. The package relationships *should* enforce it being correct, but I'm not sure the minimal installs get enough testing. | 03:35 |
| DanaG | It's also odd that I get "class driver suspend failed for CPU 0" | 03:36 |
| DanaG | hmm, I wonder if there | 03:37 |
| DanaG | if there's any point to putting kernel in nand with rootfs still on sd card. | 03:38 |
| DanaG | eh, probably not. | 03:38 |
| persia | On my primary armel device, I put both kernel and rootfs on nand. How much space do you have in nand? | 03:38 |
| DanaG | Just 256 megs for rootfs. | 03:39 |
| DanaG | interesting... screen as serial console, with another 'screen' underneath, doesn't resize properly. | 03:42 |
| persia | 256MB isn't really enough to fit Ubuntu. | 03:43 |
| DanaG | For sure. | 03:43 |
| DanaG | hmm, is there anything that WOULD be worth putting there? | 03:43 |
| persia | Depends on what you're doing. | 03:43 |
| persia | You could put / there with /usr and /var elsewhere, but that may not help that much. | 03:44 |
| DanaG | yeah, not worth the pain of /var being separate. =þ | 03:44 |
| persia | If you don't install that much, you could probably put /usr/bin there. | 03:45 |
| persia | (requires some hackery on setup) | 03:45 |
| DanaG | "Class driver suspend failed for cpu0" | 03:51 |
| DanaG | weird. | 03:51 |
| persia | Very. | 03:52 |
| DanaG | actual dmesg doesn't give any additional info. | 03:55 |
| DanaG | heh, sensors-detect assumes PCI must exist. | 04:22 |
| persia | If you can, please fix that :) | 04:29 |
| persia | It should work for i2c with no pci just fine. | 04:29 |
| DanaG | hmm, looks like it's too deeply coded to depend on PCI for its looking-around. | 04:37 |
| persia | Probably :/ | 04:38 |
| DanaG | Better logic would be this: check for pci i2c; if not loaded, load them. | 04:42 |
| DanaG | Now, even if that fails, go on and check all i2c buses. | 04:42 |
| persia | Why? Shouldn't it check for each bus type and only probe if the bus exists? | 04:45 |
| persia | Something like a combination of modprobe and sysfs inspection (to cover in-tree AND external modules) | 04:45 |
| DanaG | yeah, or if it's really lazy, just look at already existing i2c devices in i2c-1 through i2c-whatever. | 04:47 |
| persia | I think it makes sense to write slightly more robust code :) | 04:52 |
| DanaG | well, if I were given a choice between what we have now, and that "just use i2c devices already there" way, I'd choose the latter for this ARM thingy. | 04:54 |
| Baybal | do you have mtd support here? | 04:54 |
| persia | Baybal: How do you mean "mtd support". The answer is probably yes, but there are a few bits not yet working perfectly.. | 04:54 |
| Baybal | mtd booting | 04:55 |
| Baybal | and mtd as root | 04:55 |
| persia | Those certainly work: the gap is really mtd install. | 04:55 |
| persia | So, to get MTD set up like that, you need to boot in some other way, and then format the MTD, set it up for filesystems, and then manually install stuff. | 04:56 |
| persia | Right now I like ubifs for / and jffs2 for /boot, but my opinion is changing as I investigate what is required to make install work smoothly. | 04:57 |
| persia | DanaG: The trick is that the same code has to work for all architectures: it's a huge pain to try to have the script be different for different arches. | 04:58 |
| Baybal | i think jtag install is the only option on the most of devices now | 04:58 |
| persia | Baybal: I don't. Most devices have some way to boot off SD or HD (although you may need to tweak the bootloader) | 04:58 |
| DanaG | ah, as it is right now, it DOESN't work without PCI. bleh. | 04:59 |
| persia | DanaG: please fix :) | 04:59 |
| Baybal | no, even those last generation advanced socs lacks it | 04:59 |
| persia | Baybal: Hrm? What device do you have that cannot boot off SD or HD? | 04:59 |
| Baybal | like my cell phone | 05:00 |
| Baybal | lots of others | 05:00 |
| Baybal | the only advanced soc which had SD boot I know is TI omap | 05:00 |
| persia | i.MX51x does as well. | 05:01 |
| persia | But I only have i.MX51x and Orion9x devices, so I don't really know about others. I think I have some StrongARMs too, but I haven't played with those in a while. | 05:01 |
| Baybal | like nvidia tegra, qualcoms... | 05:03 |
| Baybal | and most of them are thought as advanced | 05:03 |
| Baybal | also samsungs... | 05:04 |
| persia | OK. So, how do the development boards for those platforms boot? | 05:04 |
| Baybal | on harmony boards there are standalone nor with bootloader | 05:05 |
| Baybal | which then tries to do booting | 05:05 |
| Baybal | some manufacturers simply don't have any kind of dev boards | 05:05 |
| DanaG | hmm, how about the marvell stuff? | 05:06 |
| Baybal | don't know | 05:06 |
| DanaG | nvidia tegra... wonder what the driver situation is like for those... | 05:06 |
| DanaG | would it be same as nouveau? | 05:06 |
| Baybal | much better than most of other arm socs | 05:06 |
| Baybal | like qualcomm has tons of code with no documentation | 05:08 |
| persia | I doubt that anyone doesn't produce dev boards (although they may be very difficult to get). | 05:09 |
| Baybal | and different versions of kernel per device running on the same chips | 05:09 |
| persia | From others I hear that marvell can boot off SD. | 05:09 |
| persia | (and my onions can definitely boot off HD) | 05:10 |
| DanaG | something I wish: I wish somebody would port 2.6.28 kernel to the realtek RTL8186 (Lexra MIPS) thingy. | 05:10 |
| persia | DanaG: Have you checked with the Debian MIPS folk? | 05:10 |
| DanaG | I've looked at the kernel itself, and it doesn't seem to support Lexra. | 05:11 |
| persia | Is there out-of-tree support somewhere? | 05:12 |
| DanaG | http://www.sondigo.com/sirocco/overview | 05:12 |
| DanaG | Only in 2.4 kernel. bleh. | 05:12 |
| Baybal | like qualcomm have 2 kernel with totally different stuff for 2 phones running exactly the same chip | 05:16 |
| DanaG | Oh yeah, and that kernel is not 2.4.32 OR linux-mips 2.4.32 -- it's god-only-knows what. | 05:17 |
| DanaG | It's so bad, you might as well buy a beagleboard and a USB sound card. =þ | 05:17 |
| DanaG | http://www.sondigo.com/node/229 | 05:18 |
| Baybal | I think at least a fs image + kernel with embedded initrd would be nice | 05:26 |
| Baybal | so it would be possible to flash and boot over jtag | 05:26 |
| persia | Baybal: So, what's required to boot over jtag? We can definitely construct rootsfs and initrds. | 05:29 |
| Baybal | Just bootloader and image understandable to it | 05:30 |
| Baybal | the mechanism works this way | 05:30 |
| Baybal | first you flashes memory over jtag to non boot partition | 05:31 |
| Baybal | then flashes bootloader to boot partition | 05:31 |
| Baybal | then starts all this things and hope they work | 05:32 |
| Baybal | so we need just a well compact set of images in popular flash filesystems | 05:32 |
| DanaG | I know for the old Zaurus devices, there was this "kexecboot" loader that was made for tiny in-flash execution. | 05:33 |
| DanaG | So, the kexecboot loader then goes off and loads the real kernel. | 05:33 |
| Baybal | usually something like das u boot sits as a bootloader | 05:34 |
| Baybal | and it would be nice if we would be able to utilise device's stock one | 05:34 |
| persia | There's been some work to make kexec() booting work (I think in the mukluk project). | 05:36 |
| persia | I don't know that it's widely tested yet. | 05:36 |
| Baybal | I think it's far from what is desired | 05:37 |
| persia | But for devices that need JTAG to populate the boot space, that approach is probably best. Otherwise it's hard for end-users to update their kernels. | 05:37 |
| persia | Baybal: By which audience? | 05:37 |
| Baybal | I think the best would be to utilise bootloaders supplied with device | 05:38 |
| Baybal | and moreover, most socs don't have nand boot logic and they use very tiny boot partitions on nors | 05:38 |
| Baybal | sometimes so small that things like dasuboot can't fit | 05:39 |
| persia | Baybal: I'm a fan of using bootloaders supplied with devices. Some just don't happen to support loading arbtrary kernels, and these need to be worked around. | 05:40 |
| Baybal | yes | 05:40 |
| Baybal | probably there are no way other than to have a set of custom bootloaders for every device | 05:42 |
| persia | Why? | 05:43 |
| persia | In the x86 world, there are about 8 common first-stage bootloaders, and *one* common second-stage bootloader. | 05:43 |
| persia | In the ARM world, there are about 4 common monolithic bootloaders. | 05:44 |
| persia | There exists no reason beyond lack of communication and cooperation that the same code can't work everywhere (that's kinda the point of portable code). | 05:44 |
| Baybal | just because of nand and nor differences for example | 05:45 |
| persia | That's just bootloader config. For example, the i.MX51 can boot from NOR, NAND, or SD, depending on the config with redboot. | 05:47 |
| persia | No reason we can't have per-board configs (or even per-install configs), but that doesn't mean we can't have only a few bootloaders. | 05:47 |
| Baybal | it's not a problem on devices with a few megabytes of boot flash, but in example on cell phones boot flash can be small as a few kilobytes | 05:47 |
| jmc93739653 | persia & Baybal: are there relatively simple ways to have Ubuntu's ARMv7-A images start booting from NOR and shift to NAND? I'm hoping it is something which does not require custom USB images to alter. (A bit of a cop out, I know. :) ) | 05:49 |
| persia | jmc93739653: How do you mean "shift"? | 05:49 |
| persia | jmc93739653: Typically the monolithic kernel has to exist on some single device. No reason you can't do something like bootloader-on-NOR, kernel-on-NAND, rootfs-somewhere-else (I do) | 05:50 |
| Baybal | yes, we would probably end up doing this | 05:51 |
| Baybal | I think there would be no need in custom images, but would be need in custom kernels and bootloaders | 05:52 |
| persia | Baybal: No need for images? How does an install happen? | 05:52 |
| jmc93739653 | persia: I had finished downloading an earlier Lucid i.MX515 image very late at night, about a month ago. I 'dd' the .img to an SDHC card. Didn't work (aah, ignorance!), but wanted to ask if the bootloader was a hard-dependency (RedBoot versus u-Boot, for example), or if it could be altered. | 05:53 |
| persia | jmc93739653: You can certainly alter it. I doubt you can use those SD images except on the dev boards they were designed to run on. | 05:53 |
| Baybal | just we need to get fs image to be on device flash, then we are free to boot our kernel as we wish | 05:54 |
| persia | I know they don't work on my NetWalker. | 05:54 |
| persia | Baybal: That's what the images are designed to do :) But sure, you don't need to use them. | 05:54 |
| Baybal | US visa declaration site is such a pain | 05:55 |
| jmc93739653 | Baybal: I can alter the provided uBoot source & use the BSP supplied Linux kernel in the stead of the image's default. (I have no qualms about creating custom images.) | 05:55 |
| Baybal | yeah you can | 05:56 |
| Baybal | Paper forms was much more nicer... | 05:56 |
| persia | jmc93739653: The main tricky bit is that you might have to fiddle with flash-installer to properly install new kernels if you're using .deb format for kernel distribution. | 05:56 |
| jmc93739653 | Baybal: I've been rather impressed at the large UX/workflow disparities between different governmental bodies' online softwares. | 05:57 |
| persia | jmc93739653: If you *do* have to fiddle, and you do so in a generic way that keeps other boards working, patches would be appreciated. | 05:57 |
| Baybal | The main target now is to get linux arm tree unified and not to have few thousands of forks for every chip | 06:00 |
| jmc93739653 | persia: Awesome. It's nice having _real_ ARM kit. The ARMv7-A ISA revision, specifically. The performance improvements stemming from lithographic evolution is quite pleasing. | 06:00 |
| jmc93739653 | Baybal: It's the only sane path forward, IMO. | 06:00 |
| persia | I think we need to take a couple steps with the kernels. | 06:01 |
| jmc93739653 | Is linux-omap still a radically different branch than Linus' "vanilla" upstream? | 06:01 |
| persia | To me, the first step is to move from one-kernel-per-board to one-kernel-per-SoC | 06:01 |
| persia | Once there, moving to one-kernel-per-architecture gets easier. | 06:01 |
| Baybal | and for now I think we would be forced to have multiple kernels on image, like kernel-{broadcom,tegra,omap,msm,etc} | 06:01 |
| persia | jmc93739653: The code is getting closer, but there's still lots of limitations in terms of compiled artifacts. | 06:02 |
| jmc93739653 | persia: Is #ubuntu-arm's topic information still up-to-date? I'd love to be of use. (I'm no expert [far, far from it], but it is always fun to dive head-first into a new area of expertise.) | 06:03 |
| jmc93739653 | persia: I'm beginning to despair at the state of what appears to be _every_ ARM SoC's GPU's drivers. | 06:03 |
| jmc93739653 | nVidia's binary blobs seem the least offensive, if only because their Linux x86-32 & x86-64 driver support is always in-tune and on-time. (Setting aside my ideological/legal misgivings.) | 06:05 |
| Baybal | the stock kernel can now work only on a handful of devices which were initially planed as completely open | 06:05 |
| persia | jmc93739653: I don't see anything specifically out of date in the topic, except that some of the wiki pages would benefit from a refresh (been on my TODO list for a very long time) | 06:07 |
| persia | jmc93739653: And more hands would certainly be welcome. The three areas that need the most help are more porting (see the FTBFS list), more porting (see the Thumb2 stuff), and testing. | 06:07 |
| jmc93739653 | I need to get a FPGA device in the next year or two and start fiddling with fundamental GPU hardware implementation details. I'm hoping ARM's future ISA revisions will aid the use of pure CPU-driven graphics engines. (Multi-core & SIMD advances similar to Intel's Larrabee New Instructions [LRBni] and Advanced Vector Extensions [AVX], et cetera would help immensely. | 06:09 |
| DanaG | My gripe with nvidia is with the legacy stuff: | 06:10 |
| persia | Or get an ARM box with PCIe, and use any of the cards for which we have drivers :) | 06:10 |
| Baybal | and it would be nice to stick at least with armv7a with thumb, cache, new eabi and have neon as option | 06:10 |
| DanaG | All it ever does is segfault the X server. | 06:10 |
| DanaG | And then they keep updating it to *segfault* NEW X servers. =þ | 06:10 |
| persia | Baybal: The rumours I hear are that we'll be seeing that kind of stabilisation in future releases, but it largely depends on enough factors that I can't be sure. | 06:10 |
| Baybal | just I think there are no point to have support of anything older than cortex cores | 06:11 |
| Baybal | just because everything older simply is too slow | 06:12 |
| jmc93739653 | Off topic: I noticed about ten weeks ago ARM announced certified Jazelle support for Android's Dalvik VM. So much for field of use restrictions! :) | 06:13 |
| Baybal | as i know dalvik doesn't use jazelle | 06:14 |
| Baybal | and simply have different bytecode format | 06:14 |
| jmc93739653 | Baybal: I've been procrastinating too much reading the reference docs for ARMv6 (i.e. ARM11) and ARMv7 (Cortex-??) | 06:14 |
| Baybal | armv7a=cortex-a{5,8,9} | 06:15 |
| DanaG | Hmm, there's some confusing naming. | 06:16 |
| DanaG | so ARM11 is weaker than ARM7? | 06:16 |
| Baybal | about 2 times | 06:16 |
| Baybal | for cortex a8 | 06:16 |
| Baybal | 1.5 for a5 | 06:16 |
| persia | Baybal: lucid doesn't support anything less than ARMv7+vfp+thumb2 | 06:16 |
| jmc93739653 | Baybal: Really? I could have sworn ARM and the OHA got all lovey during their Solution Center for Android (ARM SCA). | 06:17 |
| persia | And I doubt it works reliably on ARMv7 != ARMv7a | 06:17 |
| jmc93739653 | DanaG: ARMv7 refers to the microarchitectural guarantees for ARMv7 instruction set architecture compliant chips. | 06:18 |
| jmc93739653 | DanaG: The tell is the "v" between ARM and the numbers following it. | 06:18 |
| Baybal | just armv7 cores other armv7a are targeted not for consumer electronics | 06:19 |
| DanaG | ah, so is Cortex just a marketing name? | 06:19 |
| Baybal | like m and r for something like dishwashers | 06:19 |
| Baybal | no | 06:19 |
| Baybal | cortex just means armv7* | 06:19 |
| persia | Baybal: Are you *sure* you don't want to run Ubuntu on your dishwasher :) | 06:19 |
| persia | (but more seriously, yeah, ARMv7a is the only target) | 06:20 |
| Baybal | I just want it to play nice on my v7a phone | 06:20 |
| Baybal | we can run netbsd on toasters and dishwashers =D | 06:20 |
| jmc93739653 | DanaG: An ARM1136JF-S, however is a specific ARMv6 compliant CPU design. | 06:21 |
| Baybal | so I think some of developers here should propose shift from v7 to v7a | 06:21 |
| persia | Baybal: There is already an assumption of v7a, I believe. | 06:21 |
| persia | Or rather, I don't think there's any available optimisation to be gained by making changes to more aggressively not support 7m or 7r devices. | 06:22 |
| Baybal | just gcc have different -march values | 06:22 |
| persia | And I know that there's almost no testing done for anything other than 7a | 06:22 |
| persia | Baybal: Precisely which changes to gcc defaults would you recommend? | 06:23 |
| Baybal | and I suspect that setting -march to other than armv7a greatly limits gcc in selection of instructions | 06:23 |
| jmc93739653 | I thought ARMv7-A was a partial superset of ARMv7 µArch; including ARMv7-M and ARMv7-A (dropping the real-time guarantees found in ARMv7-R cores). | 06:23 |
| Baybal | there are some instruction set differences | 06:24 |
| jmc93739653 | Lucid is still using GCC 4.4.x, yes? | 06:24 |
| jmc93739653 | (GCC-4.5 still being held up by libgcc licensing issues?) | 06:24 |
| jmc93739653 | Thanks all for the lively channel, by the way, this is great fun. :) | 06:25 |
| persia | I think it's also that lucid is in a test-phase preparing for release. | 06:25 |
| Baybal | so I hope somebody would ensure that gcc is set for armv7a+thumb only | 06:25 |
| jmc93739653 | persia: the toolchain has to be locked down by now in the release schedule. Debian Testing couldm | 06:26 |
| jmc93739653 | couldn't have moved that fast. (I know I'm presuming here, so there's definitely a margin of error..) | 06:28 |
| persia | jmc93739653: We usually make best efforts to lock down at least the major version of the toolchain packages in the first month of each release cycle. Otherwise it's toohard to keep up with 20,000 packages. | 06:28 |
| jmc93739653 | persia: Agreed, if there isn't a hard deadline at some point, releases couldn't adhere to any rational schedule. | 06:30 |
| persia | Precisely :) | 06:31 |
| jmc93739653 | persia: Debugging a toolchain _and_ any given kernel, library, application? That's asking for pain. | 06:31 |
| persia | Right, so we tend to freeze toolchain (except for bugfixes for known issues) early, freeze kernel version early (although lots of patches and bugfixes continue), and focus on applications. | 06:33 |
| persia | We freeze the application and library versions (mostly) around the middle of the release cycle, and then just try to hammer out all the bugs. | 06:33 |
| persia | We've yet to be completely successful, but it works as a model for our release schedules. | 06:34 |
| Baybal | and also gcc doesn't set other necessary flags by default, so ensure things like -mthumb-interwork -mthumb -mtpcs-frame -mcallee-super-interworking | 06:36 |
| persia | Baybal: Are you sure these aren't being set by Ubuntu gcc by default? This sounds a lot like a conversation we had at UDS where it was decided to set these by default. | 06:37 |
| Baybal | don't know | 06:37 |
| persia | Baybal: Please try (qemu if you don't have hardware). I think most of your concerns have been addressed. | 06:40 |
| persia | And I think the rest are intersting, but need to be separated and reviewed individually, after comparison with the current defaults. | 06:41 |
| Baybal | can you give a link to image? | 06:41 |
| persia | Which kind? We have Ubuntu Netbook, Kubuntu Netbook, and Ubutu Server. Ubuntu Netbook gets the most testing. | 06:42 |
| persia | Lots of folk use rootstock to generate rootfss to meet their needs. | 06:42 |
| Baybal | I mean arm image | 06:43 |
| persia | Baybal: So do I :) Which flavour? | 06:44 |
| Baybal | netbook | 06:44 |
| persia | http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ always points at the most recent image. | 06:44 |
| persia | It might not work perfectly (depending on the state of the packages when it was constructed). | 06:45 |
| Baybal | ok I would check after I finish downloading movie | 06:45 |
| persia | Also note that they are currently images for specific SoCs : you may have to extract the rootfs if you don't have one of those SoCs. | 06:45 |
| persia | Baybal: Thanks! | 06:45 |
| Baybal | have you any experience with a9 boards? | 06:46 |
| persia | Not I. | 06:46 |
| * jmc93739653 so wishes he had ahold of an A9 MPcore. | 06:47 | |
| Baybal | also it would be interesting if we are going to run it on a5 machines if there would be any other than cellphones | 06:47 |
| persia | a5? | 06:48 |
| Baybal | yes | 06:48 |
| Baybal | smartphone market are probably going to separate on a8 for high end devices and a5 retaining current arm11 position | 06:49 |
| persia | What is a5? | 06:49 |
| * persia has not previously encountered the term | 06:49 | |
| Baybal | arm cortex-a5 | 06:49 |
| persia | What instruction set does that support? | 06:50 |
| Baybal | v7a | 06:50 |
| persia | Oh, cool. No worries then: it ought just work. | 06:50 |
| Baybal | it's going as a change for arm11 | 06:50 |
| persia | If it's a low-end design, I'd expect to see it also in NAS boxes, home routers, etc. | 06:50 |
| Baybal | probably it's mostly for cellphones | 06:51 |
| Baybal | as it's our of order, neon, but not superscalar | 06:51 |
| persia | Is it also cheaper than a8 or a9? | 06:51 |
| Baybal | much more | 06:51 |
| jmc93739653 | I'm rather bewildered as to why ARM didn't just roll a completely in-house, no third-party IP graphics chip for their Mali line. They'd have pragmatists ditching ImgTec's PowerVR & Qualcomm Adreno graphics cores ASAP. | 06:52 |
| persia | Then yeah, I definitely expect to see it in NAS, home routers, watches, etc. | 06:52 |
| Baybal | but I haven't yet seen any soc based on it with my own eyes yet | 06:52 |
| persia | jmc93739653: Ask the same question for any CPU design firm for any architecture :) | 06:52 |
| jmc93739653 | Baybal: I _knew_ the A9 had superscalar OoOE. I tried finding primary sources a few months back and no joy. | 06:53 |
| Baybal | they license mali core just as they do with cpu cores | 06:54 |
| jmc93739653 | I do find it rather interesting ARM had the benefit of implementing decades old microarchitecture CPU improvements, as process nodes and thermal budgets permit, where as Intel has to strip out the power-intensive features and invest deeply into more and more advanced fabrication nodes. I'm sure IBM chuckled at Intel during x86's evolution. | 06:56 |
| Baybal | a5 don't have superscalar execution because it's thought that for crunching big amounts of data the chip would use various dsps and accelerators | 06:56 |
| Baybal | the reason is you don't have to have ooo, superscalarity, mmu and fpu to drive dishwashers | 06:58 |
| persia | Well, depends on the dishwasher :) | 06:59 |
| Baybal | but anyway a5 is going to be faster than arm11 | 07:00 |
| jmc93739653 | Baybal: Do you think there are any serious chances ARM would work with the FSF (akin to the Linux Driver Project) to improve [L]GPL toolchain support for their designs? (Firms deviating from standard IP core offerings would probably not elect to do this) | 07:01 |
| persia | jmc93739653: toolchain isn't the issue at this point. It's all kernel + drivers. | 07:01 |
| jmc93739653 | Baybal: Nice. I had read the A5 was going to be a dog. | 07:02 |
| persia | comparatively, surely, but for most applications that oughtn't matter. | 07:02 |
| persia | We're arguing about different things. | 07:03 |
| * jmc93739653 facepalms. persia: you are correct re: kernel & drivers. I conflated toolchain & driver issues. I'm going to need to sleep soon. | 07:03 | |
| persia | I completely agree that you can't make a public bug private. | 07:03 |
| persia | ECHANNEL :) | 07:03 |
| persia | Apologies for those who may have misunderstood. My comment "ECHANNEL" was about *my* traffic being in the wrong place. | 07:25 |
| persia | Everyone else should feel free to continue. | 07:25 |
| persia | I just happened to set the wrong focus when having a separate conversation. | 07:25 |
| jmc93739653 | I'm happy I haven't entered my IRC passcode in a channel; plain-text, naturally. | 07:29 |
| persia | I've made that mistake :) I've also pasted by SSH passkey, my user password, my GPG passkey, etc. | 07:30 |
| persia | Most of these can be resolved by quick action and judicious choices of passwords, but ... :) | 07:31 |
| jmc93739653 | There's always the eight year old password that I use when I'm dog-tired that I know I'll blurt out some day _juuust_ as the search engine crawlers scan wherever I leaked it. | 07:48 |
| persia | heh. | 07:49 |
| === 20QAAD298 is now known as Meizirkki | ||
| rlaager | This might be blasphemy here, but I'm wondering how hard it would be to recompile the Ubuntu Lucid for armv5t. | 10:02 |
| ogra_cmpc | might take you some months (depending onh the amount of pacages you want) and a buildd setup ... and indeed you would need to fix breakage you find along the go | 10:04 |
| rlaager | Hmm, it's probably not worth it then. I was hoping there wasn't a huge delta from Debian (which still works on armv5). | 10:06 |
| ogra_cmpc | if you want v5 better go with debian | 10:08 |
| ogra_cmpc | or stick with jaunty :) | 10:10 |
| persia | Debian is ARMv4, not ARMv5. | 10:12 |
| suihkulokki | which is 95% irrelevant | 10:13 |
| persia | But it's not that much *code* delta, it's just toolchain and compile delta. There's no reason one can't construct an ARMv5 repo, except nobody has (recently) invested the time into doing so. | 10:13 |
| persia | suihkulokki: Hrm? Aren't there a bunch of devices that aren't ARMv5 that Debian supports? | 10:13 |
| suihkulokki | persia: I mean ARMv4 vs ARMv5 | 10:14 |
| persia | I thought that there was some stuff that needed ARMv4. | 10:15 |
| ogra_cmpc | openmoko, no ? | 10:15 |
| persia | I thought openmoko was almost-but-not-quite ARMv4 and needed special hacks. | 10:15 |
| * persia may well be misinformed, but would appreciate correctyion | 10:16 | |
| suihkulokki | .... | 10:16 |
| * ogra_cmpc sighs about qemu ... | 10:17 | |
| * amitk is surprised there is not editor in our initramfs! | 10:17 | |
| amitk | *no | 10:17 |
| ogra_cmpc | so i went back with the qemu-system-arm binary to 0.11.1 and still see the hangs | 10:17 |
| persia | amitk: Why does one need one? | 10:17 |
| ogra_cmpc | amitk, there is ed :) | 10:17 |
| persia | and busybox-sed | 10:17 |
| amitk | persia: to edit files if you've messed your sysstem? | 10:18 |
| amitk | ogra_cmpc: no ed either | 10:18 |
| ogra_cmpc | and you should be able to chroot into /root and copy back and forth files | 10:18 |
| amitk | ogra_cmpc: what if /root is the problem ;) | 10:18 |
| persia | amitk: There's nothing that you can't do with busybox sed. Users who want a good interface are encouraged to boot something else and chroot :) | 10:19 |
| ogra_cmpc | i.e. copy the file you want to change into /root ... chroot ... edit, exit, copy back | 10:19 |
| ogra_cmpc | amitk, hmm, you could create a vim hook for initramfs-tools that just copy_execs vim | 10:20 |
| ogra_cmpc | indeed if your system is already unbootable you are screwed | 10:20 |
| persia | amitk: From your preboot environment can you mount anything? That's often a good way to get to executables. | 10:21 |
| aaron_liu | http://pastehtml.com/view/5tp3b34.txt | 10:23 |
| aaron_liu | rootstock failed | 10:24 |
| amitk | persia: yeah, I can get to break=init. So chroot should probably work | 10:24 |
| aaron_liu | http://pastehtml.com/view/5tp3b34.txt | 10:24 |
| ogra_cmpc | aaron_liu, what release are you trying to build and whats your host release ? | 10:26 |
| aaron_liu | the latest release | 10:29 |
| ogra_cmpc | lucid on lucid ? | 10:29 |
| aaron_liu | sudo apt-get install rootstock | 10:29 |
| ogra_cmpc | on a lucid system ? | 10:30 |
| ogra_cmpc | (10.04 dev) | 10:30 |
| ogra_cmpc | (use lsb_release -a to find out if you dont know) | 10:30 |
| aaron_liu | Distributor ID: Ubuntu | 10:31 |
| aaron_liu | Description: Ubuntu 9.10 | 10:31 |
| ogra_cmpc | ah | 10:31 |
| ogra_cmpc | 9.10 | 10:31 |
| ogra_cmpc | and what are you trying to build ? (did you ude the -d option for rootstock ?) | 10:31 |
| aaron_liu | i have update to 9.10 from 9.04 | 10:32 |
| aaron_liu | no | 10:32 |
| ogra_cmpc | hmm, that should work ... it does for others .... | 10:32 |
| ogra_cmpc | you can easily modify the rootstock script in /usr/bin/rootstock though | 10:33 |
| ogra_cmpc | http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/53 | 10:33 |
| ogra_cmpc | thats the change you need | 10:33 |
| aaron_liu | http://code.google.com/p/chromium/wiki/LinuxChromiumArm | 10:35 |
| aaron_liu | i just follow the steps to compile chrome for arm | 10:35 |
| ogra_cmpc | yes, that should wor | 10:37 |
| ogra_cmpc | k | 10:37 |
| aaron_liu | but i don't know where i should to modify | 10:41 |
| aaron_liu | but i don't know where i should to modify /usr/bin/rootstock | 10:42 |
| ogra_cmpc | open it in an editor (with sudo) then look for the line that mounts /dev/pts | 10:42 |
| ogra_cmpc | relatively far at the bottom of the script | 10:42 |
| ogra_cmpc | before the mount command you add: | 10:43 |
| ogra_cmpc | mkdir -p /dev/pts | 10:43 |
| ogra_cmpc | then save the file | 10:43 |
| aaron_liu | E486: Pattern not found: mounts \/dev\/pts | 10:48 |
| ogra_cmpc | mount | 10:49 |
| ogra_cmpc | not mounts | 10:49 |
| aaron_liu | E486: Pattern not found: mount \/dev\/pts | 10:49 |
| ogra_cmpc | just look for \/dev\/pts | 10:49 |
| aaron_liu | yeah found it | 10:51 |
| aaron_liu | follow echo "I: Starting basic services in VM" | 10:51 |
| aaron_liu | but how to do that next | 10:51 |
| aaron_liu | do i need mkdir -p /proc / | 10:52 |
| * lool just discovers about slind.org; apparently a wider set of tools than just emdebian, with some corporate backing | 10:52 | |
| lool | Not that active in the last year though | 10:53 |
| aaron_liu | ogra_cmpc | 10:53 |
| aaron_liu | and then i what should i do | 10:54 |
| aaron_liu | and then what should i do | 10:54 |
| ogra_cmpc | add the line i gave you above | 10:54 |
| ogra_cmpc | mkdir -p /dev/pts | 10:54 |
| aaron_liu | yeah ,i have down | 10:54 |
| ogra_cmpc | directly above the line where /dev/pts gets mounted | 10:54 |
| aaron_liu | how to do next ? | 10:55 |
| ogra_cmpc | save the file | 10:55 |
| ogra_cmpc | then run it again | 10:55 |
| aaron_liu | yeah | 10:55 |
| ogra_cmpc | should work now | 10:55 |
| aaron_liu | run again , how to run | 10:56 |
| aaron_liu | ? | 10:56 |
| aaron_liu | i follow the steps http://code.google.com/p/chromium/wiki/LinuxChromiumArm | 10:57 |
| ogra_cmpc | right | 10:57 |
| aaron_liu | Building a rootfs section command | 10:57 |
| ogra_cmpc | yes, do that | 10:58 |
| aaron_liu | sudo rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --seed xfce4,gdm,pkg-config,python,perl,g++,bison,flex,gperf,libnss3-dev,libgtk2.0-dev,libnspr4-0d,libasound2-dev,libnspr4-dev,libgconf2-dev,libcairo2-dev,libdbus-1-dev,libstdc++6-4.4-dev,libexpat1-dev,libxslt1-dev,libxml2-dev,libbz2-dev --dist karmic | 10:58 |
| aaron_liu | but it need long time to download packages and unzip its | 10:59 |
| ogra_cmpc | yes, thats normal | 10:59 |
| aaron_liu | i think there should be a good method to avoid it | 11:00 |
| ogra_cmpc | avoid what ? | 11:00 |
| aaron_liu | download pkgs | 11:00 |
| ogra_cmpc | use an apt proxy | 11:00 |
| * ogra_cmpc uses approx | 11:00 | |
| ogra_cmpc | or a local package mirror | 11:01 |
| aaron_liu | i mean if each time runs the system .i need so long time to download pkgs | 11:02 |
| ogra_cmpc | yes, a package proxy or local mirrir help with that | 11:02 |
| aaron_liu | where i can got the rootfs | 11:04 |
| aaron_liu | where i can got the rootfs in he end | 11:04 |
| aaron_liu | where i can got the rootfs in the end | 11:04 |
| ogra_cmpc | the script tells you where it stored the tarball | 11:04 |
| aaron_liu | BUILDDIR=$(mktemp -d) | 11:05 |
| ogra_cmpc | (similar to how it told you about the logfile when your build failed before) | 11:06 |
| ogra_cmpc | lool, so i went backwards through the binary packages replacing qemu-system-arm ... i can even reproduce the hang with the two karmic versions ... | 11:09 |
| ogra_cmpc | (which i cant on a krmic system) | 11:09 |
| aaron_liu | root@aaron-ubuntu:/tmp/tmp.bypTc6Upgl/tmpmount# ls | 11:10 |
| ogra_cmpc | i'm starting to wonder if its an issue with the hostkernel?host system | 11:11 |
| aaron_liu | root@aaron-ubuntu:/tmp/tmp.bypTc6Upgl/tmpmount# ls | 11:11 |
| aaron_liu | debootstrap lost+found var | 11:11 |
| aaron_liu | it's the fsroot ? | 11:11 |
| ogra_cmpc | its the tmeporary dir | 11:12 |
| aaron_liu | is it /tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img ? | 11:13 |
| ogra_cmpc | no, it is what comes out in the end | 11:14 |
| ogra_cmpc | you just point to random pieces that are used to assemble the final thing | 11:15 |
| ogra_cmpc | just wait until its done, i tells you where it copies the final tarball | 11:15 |
| lool | Err build-essential rebuild as part of mass-thumb2 rebuilds? :) | 11:17 |
| ogra_cmpc | seems it was on the list :) | 11:17 |
| ogra_cmpc | likely a false positive | 11:17 |
| aaron_liu | LANG=C tar czvf ../armel-rootfs-$STAMP.tgz . >>$LOG 2>&1 | 11:18 |
| ogra_cmpc | i think the list criteria was only: not uploaded and not imported from debian during lucid | 11:18 |
| lool | ogra_cmpc: And some arch: any package I hope | 11:22 |
| aaron_liu | I: Retrieving ..... | 11:22 |
| aaron_liu | I: Validating..... | 11:22 |
| ogra_cmpc | lool, i dont know, i didnt assemble that list, i think it comes from some script from doko | 11:23 |
| ogra_cmpc | intrestig, build-essential is any ??? | 11:24 |
| lool | yes | 11:24 |
| lool | because the deps differ on architectures | 11:24 |
| ogra_cmpc | i thought thats only a metapackage | 11:24 |
| ogra_cmpc | ah | 11:24 |
| aaron_liu | so long time to waste each time i runs rootstock for download pkgs ,why it cannot connot runs as begin as prevoius time | 11:25 |
| aaron_liu | so long time to waste each time i runs rootstock for download pkgs ,why it cannot runs begin as prevoius time | 11:26 |
| ogra_cmpc | because the packages are individually selectable ... it doesnt know in the beginning which dependencies are needed | 11:26 |
| ogra_cmpc | it would be possible to generate the dependency chain in advance with germinate... but its unlikely that this would be any faster | 11:27 |
| aaron_liu | ok,i known | 11:27 |
| ogra_cmpc | the lucid (10.04) version of rootstock has a cache function but you need at least one successfull run and you can only do the same run again subsequently | 11:28 |
| aaron_liu | who have done for chrome in the arm ubuntu-arm platfom | 11:29 |
| ogra_cmpc | https://launchpad.net/ubuntu/+source/chromium-browser | 11:29 |
| ogra_cmpc | there is a team https://launchpad.net/~chromium-team | 11:30 |
| aaron_liu | it's not for arm | 11:30 |
| ogra_cmpc | sure it is | 11:31 |
| ogra_cmpc | see the "builds" links on the first page i posted | 11:32 |
| aaron_liu | it desn't show it for arm | 11:37 |
| ogra_cmpc | it does for me | 11:38 |
| aaron_liu | http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/dists/karmic/main/binary-armel/Packages.bz2 | 11:42 |
| aaron_liu | it for arm ? | 11:42 |
| ogra_cmpc | binary-armel is for arm, yes | 11:49 |
| ogra_cmpc | note that there are no chromium packages for karmic ... chromium is in the archive for lucid though | 11:49 |
| aaron_liu | bin/installer: line 15: udevd: command not found | 11:52 |
| ogra_cmpc | udevd is installed in the first stage, did zou change any other stuff or fiddle in the directories you posted above during the build ? | 11:55 |
| ogra_cmpc | s/zou/you/ | 11:55 |
| aaron_liu | http://pastebin.com/vZhM9ddA | 11:57 |
| ogra_cmpc | line 433 is your problem | 11:58 |
| ogra_cmpc | is the qemu-arm-static package installed on your system ? seems like your machine cant execute armel binaries | 12:01 |
| ogra_cmpc | (i guess that also caused the /dev/pts issue before) | 12:02 |
| aaron_liu | mkdir -p /dev/pts | 12:03 |
| aaron_liu | mount -t proc proc /proc | 12:03 |
| ogra_cmpc | no | 12:03 |
| aaron_liu | mount -t sysfs sys /sys | 12:03 |
| aaron_liu | mount -t devpts devpts /dev/pts | 12:03 |
| aaron_liu | udevd --daemon & | 12:03 |
| ogra_cmpc | see your first paste, it has exactly the same error as line 433 in your second paste | 12:03 |
| aaron_liu | but how should i do | 12:04 |
| ogra_cmpc | chroot: cannot run command `debootstrap/debootstrap': Exec format error | 12:04 |
| ogra_cmpc | your system isnt properly set up, the qemu-arm-static package cant execute armel binaires | 12:05 |
| ogra_cmpc | the /dev/pts issue was only a subsequent error | 12:05 |
| aaron_liu | http://pastebin.com/gfYdkiiY | 12:09 |
| ogra_cmpc | cack your installation of qemu-arm-static ... pasting random lines from the rootstockj script doesnt help | 12:10 |
| ogra_cmpc | your system apparently cant execute armel binaries | 12:10 |
| aaron_liu | i think line num 611 udevd --daemon & cause error | 12:11 |
| ogra_cmpc | no | 12:11 |
| ogra_cmpc | again ... your qemu-arm-static package is not properly installed | 12:11 |
| ogra_cmpc | fix that and it will work | 12:12 |
| ogra_cmpc | it has nothing to do with udev or /dev/pts | 12:12 |
| aaron_liu | but where i can find qemu-arm-static | 12:12 |
| ogra_cmpc | it is a dependency fo rootstock and should be installed already | 12:13 |
| ogra_cmpc | but something is wrong with it | 12:13 |
| ogra_cmpc | are you using an ubuntu kernel on your machine ? | 12:13 |
| aaron_liu | yeah | 12:13 |
| ogra_cmpc | qemu-arm-static uses the binfmt support of the ubuntu kernel | 12:13 |
| aaron_liu | from rootstock-201003071903.log | 12:14 |
| aaron_liu | first line Formatting '/tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img', fmt=raw size=2147483648 | 12:15 |
| aaron_liu | bu i couldn't find the file '/tmp/tmp.bypTc6Upgl/qemu-armel-201003071903.img' | 12:15 |
| ogra_cmpc | yes ? | 12:15 |
| ogra_cmpc | no, it gets removed during build | 12:15 |
| ogra_cmpc | or rather at the end of the build | 12:15 |
| ogra_cmpc | its a temporary file | 12:16 |
| aaron_liu | but how to do that for me | 12:16 |
| ogra_cmpc | what ? | 12:17 |
| aaron_liu | how i should to do | 12:17 |
| aaron_liu | what can i do | 12:18 |
| ogra_cmpc | fix your qemu-arm-static install | 12:18 |
| aaron_liu | apt-get install qemu-arm-static | 12:19 |
| aaron_liu | ? | 12:19 |
| ogra_cmpc | try: sudo apt-get install --reinstall qemu-arm-static | 12:19 |
| ogra_cmpc | that will force a reinstall | 12:19 |
| ogra_cmpc | also try sudo /etc/init.d/binfmt-support restart | 12:20 |
| aaron_liu | have down | 12:20 |
| ogra_cmpc | also have a look at /proc/sys/fs/binfmt_misc/ | 12:21 |
| ogra_cmpc | there should be a file called arm in there | 12:21 |
| aaron_liu | binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) | 12:23 |
| aaron_liu | when i mount | 12:23 |
| aaron_liu | binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) | 12:23 |
| aaron_liu | right ? | 12:23 |
| ogra_cmpc | no | 12:23 |
| ogra_cmpc | <ogra_cmpc> also have a look at /proc/sys/fs/binfmt_misc/ | 12:23 |
| ogra_cmpc | <ogra_cmpc> there should be a file called arm in there | 12:23 |
| ogra_cmpc | look in the directory | 12:24 |
| aaron_liu | root@aaron-ubuntu:~# ls /proc/sys/fs/binfmt_misc/ | 12:25 |
| aaron_liu | arm cli python2.4 python2.5 python2.6 register status | 12:25 |
| ogra_cmpc | lool, oh, looking at that in lucid i seem to have founda bug :) the binfmt handler for armel points to qemu-arm-static instead of qemu-armeb-static :) | 12:26 |
| ogra_cmpc | err | 12:26 |
| ogra_cmpc | the binfmt handler for armeb i mean | 12:26 |
| ogra_cmpc | aaron_liu, that looks good | 12:26 |
| persia | ogra_cmpc: Um, everything looks right to me. Are you sure? | 12:26 |
| ogra_cmpc | ogra@osiris:~$ cat /proc/sys/fs/binfmt_misc/qemu-armeb|grep interpreter | 12:27 |
| ogra_cmpc | interpreter /usr/bin/qemu-arm-static | 12:27 |
| persia | Oh, indeed. | 12:28 |
| ogra_cmpc | persia, given that lool enabled a specific qemu-armeb-static binary build i'd expect the binfmt handler to use it :) | 12:28 |
| persia | That package has had *lots* of uploads recently. Just do it again :) | 12:28 |
| * persia needs to update mk-sbuild and pbuilder-dist now | 12:29 | |
| ogra_cmpc | i doubt most of the handlers work though | 12:29 |
| ogra_cmpc | ppc might with luck ... | 12:29 |
| persia | So what? | 12:29 |
| ogra_cmpc | i wouldnt rely on them | 12:29 |
| persia | The important bit isn't whether they work, but whether the interfaces are sane. | 12:29 |
| ogra_cmpc | armel is the only tested one atm | 12:29 |
| persia | I don't intend to do so. | 12:30 |
| persia | But I'd rather unpack the special-case stuff. | 12:30 |
| ogra_cmpc | ah, i thought you wanted to make the builder tools point to them | 12:30 |
| persia | I did. | 12:30 |
| persia | Still do, actually. | 12:30 |
| persia | Or rather, I want to not special-case arm in the tools. | 12:30 |
| ogra_cmpc | ah | 12:31 |
| * ogra_cmpc still tries to track down the qemu hang | 12:31 | |
| persia | lool: When you have a chance, could you share your strategy? I'd be happy to help with various bits, but don't want to duplicate work. | 12:31 |
| ogra_cmpc | i dont get why it doesnt happen in karmic | 12:31 |
| ogra_cmpc | i use the karmic qemu-system-arm binary and my old qemu kernel now ... | 12:32 |
| ogra_cmpc | but it still hangs | 12:32 |
| * ogra_cmpc replaces qemu-img with dd now | 12:32 | |
| aaron_liu | root@aaron-ubuntu:~# cat /proc/sys/fs/binfmt_misc/qemu-armeb|grep interpreter | 12:40 |
| aaron_liu | cat: /proc/sys/fs/binfmt_misc/qemu-armeb: No such file or directory | 12:40 |
| aaron_liu | arm cli python2.4 python2.5 python2.6 register status in the /proc/sys/fs/binfmt_misc dir | 12:41 |
| aaron_liu | ls /proc/sys/fs/binfmt_misc | 12:42 |
| aaron_liu | arm cli python2.4 python2.5 python2.6 register status | 12:42 |
| ogra_cmpc | aaron_liu, yes i was not talking to lool about lucid, you rin karmic there only the arm binfmt hook exists | 12:43 |
| persia | aaron_liu: qemu-armeb is brand new: you only care about /proc/sys/fs/binfmt_misc/arm | 12:43 |
| ogra_cmpc | hrm, dd didnt help either, i dont get what else could be wrong | 13:28 |
| lool | ogra_cmpc, persia: I copied the other binfmts from Debian; it might be a bug I copied over (armeb versus arm) | 13:37 |
| lool | persia: Strategy on which part? I also would like to remove arm-specific handling | 13:37 |
| lool | persia: I had in mind to rename build-arm-chroot to build-qemu-chroot or something along these lines; perhaps qemu-debootstrap | 13:37 |
| lool | I started some wiki pages, but these are too rough at the moment, I was too busy to finish them last week | 13:38 |
| lool | Laibsch: heya | 13:39 |
| lool | Laibsch: Thanks for your emails; will check it out | 13:40 |
| Laibsch | hey! | 13:40 |
| Laibsch | great | 13:40 |
| Laibsch | I have a few stupid questions | 13:40 |
| Laibsch | Is armv4, armv5, etc. akin to i386, i486, i586, etc? | 13:40 |
| lool | Kind of | 13:41 |
| lool | It's usually more complex than that because there are sub-ISAs associated with armvN families | 13:41 |
| Laibsch | yes | 13:41 |
| Laibsch | It's a big mess | 13:41 |
| lool | For instance armv5 only comes in Thumb flavors | 13:41 |
| lool | And then Thumb itself was extended multiple times | 13:41 |
| Laibsch | and I so far successfully avoided to understand it | 13:41 |
| lool | and on an orthogonal scale, you have the FPU ISA; 387 or SSE for Intel, and either a lot of old stuff on ARM or VFP with associated versions | 13:42 |
| lool | and optional NEON or other VFP extensions | 13:42 |
| Laibsch | OK, so it's not linear like in the Intel case, but lots of different things that may or may not be supported (with the later CPUs generally supporting more, of course) | 13:43 |
| Laibsch | ? | 13:43 |
| lool | There are some "implications" in the case of intel code as well, but it's more backwards compatible than arm is | 13:43 |
| Laibsch | OK | 13:43 |
| Laibsch | thanks | 13:43 |
| Laibsch | I guess that is sufficient for me for now as far as the CPU variations are concerned | 13:44 |
| Laibsch | what determines the minimum level of CPU support a binary needs? Is that a flag given to gcc, determined by the host on which it runs or something else entirely? | 13:44 |
| ogra_cmpc | lool, ++ on qemu-debootstrap ... | 13:44 |
| lool | Laibsch: You mean at build time? | 13:45 |
| Laibsch | well, both | 13:45 |
| Laibsch | for example, can a very recent arm cpu output armv4 code? | 13:45 |
| lool | Laibsch: It's mostly the flags you pass to gcc, but it can also be what binaries you combine together | 13:45 |
| Laibsch | can I force it to output armv4? | 13:45 |
| Laibsch | OK | 13:46 |
| lool | Laibsch: hardware has nothing to do with build output | 13:46 |
| Laibsch | so, it's got nothing to do with the compile host | 13:46 |
| lool | Since you can cross-compile arm from i386 | 13:46 |
| Laibsch | OK, good | 13:46 |
| Laibsch | Well, I want to avoid cross-compilation | 13:46 |
| persia | lool: I like the qemu-debootstrap name. | 13:46 |
| Laibsch | I want to use all the debian-goodies out there | 13:46 |
| Laibsch | that are generally not cross-compile-aware | 13:47 |
| lool | Laibsch: If you're running a Debian or Ubuntu armel userspace, it might be able to output binaries using a different target architecture than what Debian or Ubuntu targets, but you have to keep in mind that your binary might get linked to stuff such as libgcc or of course runtime libs such as libc | 13:48 |
| persia | lool: Do you need help with qemu-debootstrap, or are you already making progress there? The pbuilder-dist and mk-sbuild changes I'm confident about doing myself. qemu-debootstrap needs a complete rewrite of build-arm-chroot (proper options handling for one). | 13:48 |
| lool | In which case you need to rebuild these | 13:48 |
| lool | persia: I can do it I guess | 13:48 |
| Laibsch | lool: that's kind of the idea | 13:49 |
| Laibsch | I understand Ubuntu does not support older arm CPU | 13:49 |
| Laibsch | The devices I currently own are all armv5te max | 13:49 |
| persia | lool: Up to you. I don't mind doing it if you've got other stuff (as you've already done most of the heavy lifting) | 13:49 |
| persia | ogra_cmpc: Do you care about the contents of qemu-debootstrap as long as it's call-compatible for rootstock? | 13:50 |
| * ogra_cmpc wonders what else to look for to track down the hang ... i ruled out qemu-system-arm, the kernel, qemu-img | 13:50 | |
| Laibsch | lool: I intend to compile the binaries elsewhere and then work out the kinks you mentioned (although I will likely hit more than enough bumps where I have no idea how to smooth them out) | 13:51 |
| ogra_cmpc | persia, rootstock doesnt even use the script :) | 13:51 |
| persia | ogra_cmpc: Oh. Didn't it used to do that? | 13:51 |
| ogra_cmpc | it still does a debootstrap --foreign ... all it uses is qemu-arm-ststic to chroot into the rootfs for the second stage run | 13:51 |
| persia | Aha. Then you don't care at all. | 13:52 |
| ogra_cmpc | persia, no, because there is no qemu-arm-static in jaunty | 13:52 |
| persia | Right. | 13:52 |
| ogra_cmpc | in jaunhty it does the second stage in a VM | 13:52 |
| ogra_cmpc | which is horribly slow | 13:52 |
| persia | lool: I should have time to work on this on Tuesday, so I'll take a swing if you haven't first. I want to get the updates to u-d-t in before betafreeze. | 13:52 |
| ogra_cmpc | heh | 13:59 |
| * ogra_cmpc just had a weird idea | 13:59 | |
| ogra_cmpc | i wonder if it would work to run a VM, export proc through nbd and mount that inside a chroot | 14:00 |
| ogra_cmpc | hmm, i suspect /proc/self etc wouldnt work | 14:10 |
| Laibsch | http://ograblog.wordpress.com/2009/07/18/juggling-your-arms-in-karmic-and-no-more-excuses/ I hope this does what I've been looking for | 14:10 |
| Laibsch | eFfeM1: that may be interesting for your as well ^^^ | 14:10 |
| Laibsch | -r | 14:11 |
| ogra_cmpc | Laibsch, works for everything but mono stuff | 14:11 |
| Laibsch | first thing I want to test is scim/uim/ibus | 14:12 |
| Laibsch | then anki ;-) | 14:12 |
| Laibsch | if I go wild, I'll have a look at compiling opie | 14:12 |
| ogra_cmpc | heh | 14:12 |
| Laibsch | but basically, it's more about getting used to ubuntu-arm | 14:13 |
| Laibsch | need to get my feet wet | 14:13 |
| aaron_liu | http://code.google.com/p/chromium/wiki/LinuxChromiumArm | 14:14 |
| aaron_liu | does i need the cross-compile | 14:15 |
| aaron_liu | ? | 14:15 |
| aaron_liu | for build the rootstock ? | 14:15 |
| ogra_cmpc | no | 14:15 |
| aaron_liu | does i need the cross-compile for build the rootstock ? | 14:15 |
| aaron_liu | no need ? | 14:16 |
| ogra_cmpc | no | 14:16 |
| aaron_liu | Get:289........... | 14:16 |
| aaron_liu | right/ | 14:16 |
| aaron_liu | right ? this time ? | 14:16 |
| ogra_cmpc | looks like its downloading packages in the VM | 14:17 |
| aaron_liu | but how long it would be | 14:17 |
| ogra_cmpc | just wait, it takes a while | 14:19 |
| aaron_liu | great | 14:19 |
| aaron_liu | thank for ur kind and help | 14:19 |
| ogra_cmpc | youre welcome | 14:19 |
| aaron_liu | ogra_cmpc witch chip u used | 14:23 |
| aaron_liu | ogra_cmpc witch arm chip u used | 14:23 |
| ogra_cmpc | freescale imx51 and marvell dove ... i also have an old begleboard | 14:23 |
| aaron_liu | I use th tcc8900 | 14:24 |
| aaron_liu | i down't know if can runs | 14:25 |
| aaron_liu | i down't know if it can runs | 14:25 |
| ogra_cmpc | it can run karmic (9.10) but not lucid (10.04) | 14:26 |
| aaron_liu | what 's it take room of ur ubuntu-os for arm | 14:28 |
| aaron_liu | with chromium ? | 14:29 |
| ogra_cmpc | that really depends what kind of desktop you run | 14:29 |
| aaron_liu | i think it need 4G flash at least | 14:29 |
| aaron_liu | i just want to run smallest sys | 14:29 |
| ogra_cmpc | i think with LXDE you can run in around 1G | 14:29 |
| ogra_cmpc | probably 2G | 14:30 |
| ogra_cmpc | never tried it | 14:30 |
| aaron_liu | it's include the x-11 it takes to much room | 14:30 |
| ogra_cmpc | X should only take 1-200MB | 14:31 |
| aaron_liu | it's include the x-11 it takes too much room,and if who port the chromium browser to the gtk+dfb,i think it so great challage | 14:32 |
| lool | persia: First pass http://paste.ubuntu.com/390382/ | 14:34 |
| lool | Untested yet | 14:34 |
| ogra_cmpc | lool, why die if you dont need qemu, just switch silently to std debootstrap | 14:37 |
| lool | ogra_cmpc: Just not implemented yet | 14:37 |
| ogra_cmpc | ah | 14:38 |
| lool | In particular, this should also reject biarch; using qemu-i386 isn't a good idea on amd64 | 14:38 |
| ogra_cmpc | heh, yeah | 14:39 |
| aaron_liu | what's the difference between lucid with Karmic ? | 14:41 |
| lool | 6 months | 14:42 |
| aaron_liu | what's the difference between lucid with Karmic ?i am beganner of ubuntu | 14:42 |
| aaron_liu | who can tell me the difference | 14:44 |
| eFfeM1 | Laibsch: thanks for the link | 14:45 |
| lool | Laibsch: Usually you don't reuse the toolchain to do rebuilds but use a different one unless you're just changing feature flags of the toolchain; if you're going to rebuild for another arch, it's best to rebuild the toolchain (it's part of the list of packages anyway, and you want to make sure that the rebuilt packages are using the new toolchain) | 14:48 |
| ogra_cmpc | lool, so, my hang seems to be related to imagesize ... if i use 1G all the unpacking gets through, if i use something like 4G i get the hang, do you know if there is any limitation in qemu causing that ? | 14:49 |
| Laibsch | lool: hm, you kind of lost me here. | 14:49 |
| lool | ogra_cmpc: You could try using a 4G image with a small block size | 14:50 |
| Laibsch | What I'm trying to do is get something set up so that I can compile packages from the debian archives for use on an arm device | 14:50 |
| lool | Laibsch: For instance if you rebuild with e.g. --no-stack-protector, you don't need to rebuild the toolchain first (I think) | 14:51 |
| Laibsch | If I can get something to run on my spitz that would be great but it is my understanding that is currently being phased out (I certainly hope it will be phased back in) | 14:51 |
| ogra_cmpc | lool, hmm do you think qemu-img makes any difference in blocksizes based on imagesize ? | 14:51 |
| aaron_liu | Get 415 :...... | 14:51 |
| aaron_liu | how many pkgs to download | 14:51 |
| lool | ogra_cmpc: qemu-img no, but mkfs.ext[234] change block size depending on the image size | 14:51 |
| ogra_cmpc | lool, oooh ! | 14:51 |
| * ogra_cmpc never thought of that | 14:52 | |
| lool | Laibsch: Probably the script which I'm working on would give you the proper local setup for qemu syscall emulation | 14:52 |
| ogra_cmpc | aaron_liu, it should have told you somewhere up in the lig | 14:52 |
| ogra_cmpc | *log | 14:52 |
| lool | Laibsch, persia: http://paste.ubuntu.com/390390/ qemu-debootstrap take 2; finishes a bootstrap here | 14:52 |
| Laibsch | lool: I assume I'd want to do that if my target device did not have the stack protector. I don't know, really. I just know the device I have. The good thing in OE is that there are machine configurations where still information is listed centrally. Would something like this be possible for ubuntu-arm? | 14:52 |
| lool | Laibsch: stack-protector is a toolchain feature, not a hardware one | 14:53 |
| Laibsch | my head is spinning | 14:53 |
| Laibsch | OE was good at hiding that kind of complexity | 14:53 |
| Laibsch | I never had to bother | 14:53 |
| lool | Laibsch: I guess it would make sense to have a db of machine <-> features somewhere, but usually we expect hackers doing archive rebuilds for a target device to know it by heart anyway | 14:53 |
| lool | Laibsch: So e.g. if you're targetting a N810, you should know it's v6 + vfp | 14:54 |
| Laibsch | I wouldn't ;-) | 14:54 |
| lool | Laibsch: I think you're correct that it's going to become an improper assumption | 14:54 |
| lool | Laibsch: We should aim at hiding this away | 14:54 |
| Laibsch | over time, yes | 14:54 |
| aaron_liu | lig | 14:54 |
| lool | Laibsch: Do you have fast connectivity? | 14:54 |
| Laibsch | eventually it would be good to "dumb it down" so that even stupid people like me can use it ;-) | 14:55 |
| aaron_liu | ? | 14:55 |
| aaron_liu | lig? | 14:55 |
| ogra_cmpc | *log | 14:55 |
| lool | lig! | 14:55 |
| Laibsch | lool: depends on your definition of fast. When I am in Asia, I usually have 100MBit, but then it's more a problem of latency (really annoying). Over here, I have a few MBit down. Not really that fast by today's standards. Why? | 14:56 |
| ogra_cmpc | Laibsch, stay in asia then ... germany is to cold anyway :) | 14:57 |
| lool | Laibsch: if you want to create an armel chroot as discussed on the link you mentionned earlier, that's relevant | 14:57 |
| lool | Ok; script appears to work; now need to finish the biarch stuff | 14:57 |
| aaron_liu | who knows the irc channal of chromium-browser-arm | 14:57 |
| Laibsch | ogra_cmpc: Asia is not as cold when you look on the thermometer, but inside the poorly insulated houses it's freezing. Summer and winter are more agreeable in Europe, me thinks, and thus spend them here. | 14:57 |
| ogra_cmpc | Laibsch, if you create chroots/images more often, use an apt proxy | 14:58 |
| * Laibsch already does | 14:58 | |
| ogra_cmpc | right, then lool's question is not as important :) | 14:58 |
| Laibsch | OK | 14:58 |
| lool | He still has to fetch them a first time! | 14:58 |
| aaron_liu | i'am in asia | 14:59 |
| ogra_cmpc | right | 14:59 |
| Laibsch | I'm patient ;-) | 14:59 |
| aaron_liu | so cool in this days | 14:59 |
| Laibsch | faster is of course better. but my connection here is not that slow as to be unusable. | 14:59 |
| aaron_liu | so cool in this days in asia area | 14:59 |
| Laibsch | aaron_liu: let me try to cheer you up. We frequently had -20° this winter | 15:00 |
| Laibsch | and just yesterday we had 25 cm of fresh snow | 15:00 |
| aaron_liu | haa | 15:00 |
| aaron_liu | chree up | 15:00 |
| aaron_liu | cheers | 15:01 |
| aaron_liu | where r u | 15:01 |
| Laibsch | lool: I also have access to a build host in a data center. that machine has 100MBit as well. and is much faster CPU as well. | 15:01 |
| Laibsch | aaron_liu: pretty much right in the middle of .de | 15:01 |
| aaron_liu | wecome to shanghai china | 15:02 |
| aaron_liu | i never go aboard , no chance | 15:03 |
| aaron_liu | haa | 15:03 |
| ogra_cmpc | Laibsch, where do you sit atm ? | 15:03 |
| ogra_cmpc | <-- Kassel | 15:03 |
| Laibsch | on a chair ;-) | 15:03 |
| ogra_cmpc | haha | 15:03 |
| Laibsch | ogra_cmpc: a little further west | 15:03 |
| aaron_liu | it's night this time in the shanghai | 15:03 |
| Laibsch | about an hour's drive | 15:03 |
| ogra_cmpc | ah, like solingen etc | 15:04 |
| Laibsch | Sauerland | 15:04 |
| ogra_cmpc | yup | 15:04 |
| Laibsch | lool: log "W:" "$0 is deprecated, please use qemu-debootstrap" | 15:04 |
| Laibsch | should I rather use qemu-debootstrap? | 15:05 |
| aaron_liu | what's time in ur location | 15:05 |
| ogra_cmpc | 4pm | 15:05 |
| aaron_liu | here is 23:05 | 15:05 |
| ogra_cmpc | Laibsch, its just a warning | 15:05 |
| Laibsch | yes | 15:05 |
| aaron_liu | ogra_cmpc but where r u | 15:05 |
| Laibsch | but while I'm starting I may as well use the latest tools | 15:06 |
| ogra_cmpc | but the plan is to make build-arm-chroot arch independent | 15:06 |
| aaron_liu | de have many time zone ? | 15:06 |
| ogra_cmpc | which means it will be renamed to qemu-debootstrap | 15:06 |
| ogra_cmpc | aaron_liu, nope, just one | 15:06 |
| lool | Laibsch: Not sure what you mean | 15:06 |
| lool | Laibsch: It's only when the script is symlinked as build-arm-chroot that the deprecation warning will be printed | 15:07 |
| ogra_cmpc | or if you saved it as build-arm-chroot :) | 15:07 |
| Laibsch | yes, but I was wondering if qemu-debootstrap was preferred over that script | 15:08 |
| lool | Laibsch: That script is qemu-debootstrap | 15:08 |
| Laibsch | hehe | 15:08 |
| Laibsch | maybe s/use/rename\ this\ script\ to/ ? | 15:08 |
| ogra_cmpc | it will be in a package in the end | 15:09 |
| Laibsch | ok | 15:09 |
| ogra_cmpc | users shouldnt rename package content | 15:09 |
| ogra_cmpc | the old name was build-arm-chroot ... the proof of concept stuff i created in karmic is now being generalized by lool to be less hackish and arch independent | 15:10 |
| aaron_liu | canada have a place with the name Hope same with urs | 15:10 |
| * ogra_cmpc likes to do a lot of hardcoding ... lool prefers stuff to have tons of switches | 15:11 | |
| ogra_cmpc | my hardcoding isnt so good for generalizing usually :) | 15:11 |
| lool | ogra_cmpc: Actually I hate switched too, but I hate hardcoding more than switches | 15:12 |
| lool | *switches | 15:12 |
| ogra_cmpc | heh, yeah | 15:12 |
| ogra_cmpc | hardcoding is good for quick shots and proof of concept stuff though | 15:13 |
| Laibsch | will there currently be any tangible benefits for me if I use lool's script instead of ogra's scipt (which I understand is packaged in the repo) to compile for arm? | 15:14 |
| lool | Laibsch: Probably no difference for armel, no | 15:14 |
| lool | Laibsch: but it would help me testing it | 15:14 |
| Laibsch | OK | 15:14 |
| ogra_cmpc | just that you need to learn the new name soon :) | 15:14 |
| Laibsch | I will gladly do that | 15:14 |
| Laibsch | I take that as you soliciting feedback | 15:15 |
| Laibsch | You got yourself the dumbest person on the planet to do your testing | 15:15 |
| Laibsch | I guess that may be a good thing in this case ;-) | 15:15 |
| aaron_liu | my hardware board will come tomorrow, i will debug the board ,hope without a hitch | 15:15 |
| aaron_liu | in the chat room ,who have debug the ddr2 board ,and give me some suggestion | 15:17 |
| Laibsch | lool: http://paste.debian.net/62940/ I did take a look at the script (which I guess won't happen so frequently once it's packaged) but it's really unclear to me how to use it. | 15:17 |
| Laibsch | I guess I may need to set deb_arch or arch or both | 15:18 |
| Laibsch | Or maybe something more | 15:18 |
| lool | Ok this is what I intend to upload http://paste.ubuntu.com/390405/ | 15:18 |
| ogra_cmpc | sudo qemu-sebootstrap --arch armel <dist> <path to chroot> <mirror> | 15:18 |
| lool | has basic bi-arch support | 15:18 |
| ogra_cmpc | Laibsch, the debootstrap docs should apply | 15:19 |
| lool | Laibsch: The new version would work in your case, but it would create a chroot of the same arch as yours | 15:19 |
| lool | Laibsch: You need to tell it "armel" at some point | 15:19 |
| Laibsch | OK | 15:19 |
| Laibsch | Will you be uploading this script now? | 15:20 |
| Laibsch | I'd prefer that over manually copying your latest changes every time | 15:20 |
| lool | Laibsch: I will be uploading it now, but it will need to build on your arch before you get it from the archive, will take some hours | 15:20 |
| Laibsch | no problem | 15:20 |
| Laibsch | what's the name of the package? | 15:21 |
| ogra_cmpc | lool, looks good to me | 15:21 |
| ogra_cmpc | Laibsch, qemu-arm-static or qemu-kvm-extras-static | 15:22 |
| Laibsch | Oh, so it's an update to the currently available packages? | 15:22 |
| Laibsch | that's even better | 15:22 |
| * ogra_cmpc cant get used to the new name | 15:22 | |
| Laibsch | I already have those installed | 15:22 |
| Laibsch | I agree | 15:23 |
| Laibsch | but it's not only arm anymore, right? | 15:23 |
| Laibsch | then it makes sense | 15:23 |
| Laibsch | Did anybody ever use those scripts with pbuilder? | 15:23 |
| ogra_cmpc | i'm specifically unhappy about having kvm in the packagename | 15:23 |
| lool | Laibsch: Exactly, it would work for e.g. ppc | 15:24 |
| * lool should test ppc | 15:24 | |
| ogra_cmpc | Laibsch, persia works on the pbuilder stuff based on this | 15:24 |
| Laibsch | cool!!!! | 15:24 |
| Laibsch | extracool | 15:24 |
| Laibsch | can't wait | 15:24 |
| aaron_liu | i must go to sleep or i would be late for tomorrow working | 15:25 |
| Laibsch | good night! | 15:26 |
| ogra_cmpc | and good luck with your chromium hacking | 15:26 |
| lool | I should have tested native builds before uploading; bah | 15:26 |
| aaron_liu | good Morning | 15:27 |
| aaron_liu | bye | 15:27 |
| Laibsch | Can I get debootstrap to use an apt-cache? I looked at the man page but I only see the option to specify a mirror. Or will debootstrap use the same settings as for the host? | 15:27 |
| lool | Laibsch: http_proxy is picked up by default unless you filter it | 15:27 |
| ogra_cmpc | Laibsch, just yse mirror | 15:27 |
| lool | Laibsch: a mirror can be specified on the cmdline | 15:27 |
| ogra_cmpc | *use | 15:27 |
| lool | third argument | 15:27 |
| Laibsch | OK | 15:27 |
| Laibsch | but it's really not an http_proxy | 15:28 |
| Laibsch | nor is it a mirror | 15:28 |
| lool | Laibsch: what is it? | 15:28 |
| Laibsch | Even though both should work | 15:28 |
| lool | a pool of .debs? | 15:28 |
| Laibsch | I use apt-cacher-ng | 15:28 |
| Laibsch | both approaches should work | 15:28 |
| lool | Laibsch: It's a proxy then | 15:28 |
| lool | (at least I think it is, I don't actually use apt-cacher-ng) | 15:28 |
| ogra_cmpc | sudo qemu-debootstrap --arch armel lucid lucid-chroot http://192.168.2.87:9999/ubuntu-ports | 15:28 |
| ogra_cmpc | Laibsch, ^^^ thats what i use here | 15:28 |
| Laibsch | yes, as I said, both approaches will work | 15:29 |
| ogra_cmpc | the ip is my wlan0 on my laptop | 15:29 |
| Laibsch | But | 15:29 |
| Laibsch | I want an unaltered sources.list | 15:29 |
| lool | Laibsch: fix it after the build | 15:30 |
| ogra_cmpc | debootstrap doesnt create a sources.list | 15:30 |
| Laibsch | And apt-cacher-ng is not an http proxy in the strict sense | 15:30 |
| lool | ogra_cmpc: Hmm I think it does now | 15:30 |
| ogra_cmpc | err ... it does | 15:30 |
| ogra_cmpc | yeah | 15:30 |
| Laibsch | http://paste.debian.net/62945/ is my /etc/apt/apt.conf.d/proxy | 15:31 |
| Laibsch | I'd like to have that the same in the debootstrap | 15:31 |
| Laibsch | but it's not a big deal | 15:31 |
| ogra_cmpc | just cp it after creating the chroot :) | 15:32 |
| lool | Laibsch: It does act as a proxy; it's configured as your APT http proxy; anyway, apparently anything works, so don't worry | 15:32 |
| Laibsch | thanks, guys | 15:32 |
| aaron | i come back | 15:33 |
| aaron | root@aaron-ubuntu:/# du -s /tmp/tmp.Vbz1uwY5yt/ | 15:33 |
| aaron | still 1138632 /tmp/tmp.Vbz1uwY5yt/ | 15:34 |
| ogra_cmpc | did rootstock finish already ? | 15:34 |
| aaron | but building database of manual pages | 15:35 |
| aaron | just setting up.......... | 15:35 |
| ogra_cmpc | yeah, give it time, it takes long ... since it runs in a virtual machine | 15:35 |
| aaron | ok, i go to sleep again | 15:36 |
| aaron | bye | 15:37 |
| ogra_cmpc | it only emulates a 200MHz ARM dont espect it to be fast :) | 15:37 |
| ogra_cmpc | bah | 15:37 |
| Laibsch | ogra_cmpc: what's the non-masked URL to ubuntu-ports? | 15:39 |
| Laibsch | I see | 15:40 |
| Laibsch | ports.ubuntu.com | 15:40 |
| ogra_cmpc | ports.ubuntu.com/ubuntu-ports | 15:40 |
| ogra_cmpc | (non ports use /ubuntu) | 15:41 |
| Laibsch | which leads to the question of "what is a port"? | 15:45 |
| lool | Laibsch: It's just an arbitrary separation to not pollute the main arcihve/publisher | 15:46 |
| Laibsch | ok | 15:46 |
| Laibsch | makes sense | 15:46 |
| lool | everything except i386 is technically a port, even amd64, but we usually refer to ports as in the arches which are on ports.u.c | 15:46 |
| lool | apparently, qemu-ppc is much slower than qemu-arm | 15:48 |
| ogra_cmpc | lool, i talked to vargrant about it, he said ppc only works on a daily base with a lot of luck | 15:48 |
| ogra_cmpc | in debian at least | 15:48 |
| lool | I'm just speaking of the emulation | 15:49 |
| lool | The chroot creation is taking much longer in the configuring packages state | 15:49 |
| ogra_cmpc | well, you are lucky if it finishes at all is what i mean | 15:49 |
| lool | It just finished | 15:49 |
| ogra_cmpc | great ! | 15:49 |
| ogra_cmpc | he wasnt that confident | 15:49 |
| lool | root@bee:/# dpkg --print-architecture | 15:49 |
| lool | powerpc | 15:49 |
| lool | root@bee:/# lsb_release -cs | 15:50 |
| lool | lucid | 15:50 |
| lool | stuff works | 15:50 |
| lool | now I can trash it I guess | 15:50 |
| ogra_cmpc | i'll tell him to throw away these debian packages and use ubuntus instead :P | 15:50 |
| Laibsch | lool: I have installed the lucid qemu-kvm-extras-static package. To help test your script, there's basically nothing left to do then the usual update routine and continue to run the build-arm-chroot script, right? | 15:52 |
| ogra_cmpc | right | 15:52 |
| ogra_cmpc | at some point it will tell you its deprecated | 15:52 |
| ogra_cmpc | then swiatch to qemu-debootstrap | 15:52 |
| Laibsch | good | 15:53 |
| Laibsch | I guess I can do that now ;-) | 15:53 |
| Laibsch | qemu-debootstrap does not have a way to configure it with a dotfile, does it? I loathe those long command-lines, too easy to mess up | 15:54 |
| ogra_cmpc | i dont think so ... | 15:54 |
| ogra_cmpc | patchews accepted i guess :) | 15:55 |
| lool | Laibsch: You can use an alias or a wrapper if you don't want to remember the flags; pretty much everything is a variable though: arch, target, distro | 15:55 |
| Laibsch | I should probably do that | 15:56 |
| lool | Laibsch: I don't like dotfiles for "pure" tools | 15:56 |
| lool | e.g. you don't have a dotfile for cp or expr, they just take their input and produce expected results | 15:56 |
| Laibsch | hm | 15:56 |
| ogra_cmpc | you usually dont use a ton of options for cp or expr | 15:57 |
| lool | if you add a dotfile, you add a point where it might break, a compatibility interface to maintain, another thing to document etc. | 15:57 |
| Laibsch | I have another thought | 15:57 |
| * lool doesn't use a ton of options for debootstrap, I type the cmdline entirely every time | 15:57 | |
| * ogra_cmpc too, but i can understand if people find it hard and would like a config file instead | 15:58 | |
| lool | Laibsch: You can have a higher level tool such as pbuilder pass the right args for you though | 15:58 |
| Laibsch | OK | 15:59 |
| Laibsch | that would work | 15:59 |
| Laibsch | let's see when the pbuilder stuff arrives | 15:59 |
| lool | You dont actually need any pbuilder stuff | 15:59 |
| lool | But there's a wrapper which will help pass the proper pbuilder opts | 16:00 |
| Laibsch | I was thinking that postinst of the package may create a bunch of hardlinks named build-$arch-chroot | 16:00 |
| lool | Laibsch: Would pollute the namespace a lot | 16:00 |
| Laibsch | that's the intention ;-) | 16:01 |
| lool | I could argue we need a build-karmic-chroot and a build-lucid-chroot command too, and there would be no end of combinations ;-) | 16:01 |
| Laibsch | I'm sure ogra_cmp would like it ;-) | 16:01 |
| Laibsch | yes, I just find the releases easier to remember | 16:01 |
| Laibsch | but as soon as you have a matrix of combinations you're better of with a config file :-P | 16:02 |
| Laibsch | better off | 16:02 |
| Laibsch | OK, next try | 16:02 |
| Laibsch | how about bash-completion? | 16:02 |
| lool | Laibsch: feel free; bash-completion for debootstrap and qemu-debootstrap would be nice | 16:03 |
| Laibsch | if the package shipped some information for bash-completion, I'd be happy and shut up | 16:03 |
| Laibsch | OK | 16:03 |
| lool | Laibsch: These are really low-level tools IMO | 16:03 |
| Laibsch | I've never actually made a patch for that | 16:03 |
| lool | Laibsch: I'd rather encourage you to fix this when you have a higher level "build image for board foo" tool | 16:03 |
| ogra_cmpc | Laibsch, you are right, i would like it ... | 16:03 |
| Laibsch | but should be reasonably easy to do | 16:03 |
| lool | Laibsch: I personally use zsh BTW :-) | 16:03 |
| ogra_cmpc | but i argued with lool to often about it already :) he does the work so he may do the dedcisions :) | 16:04 |
| Laibsch | you won't profit, then | 16:04 |
| Laibsch | SOL | 16:04 |
| Laibsch | lool: I agree and I'll wait for the higher level tools | 16:04 |
| Laibsch | I never really call debootstrap on the command line | 16:04 |
| Laibsch | If I do, I would not mind looking at the manpage | 16:05 |
| Laibsch | when I do | 16:05 |
| Laibsch | but stuff I call very often (and I thought I was going to need to call this script very often) I want to be easy to use | 16:05 |
| Laibsch | lool: when do you expect the "build image for board foo" tool? | 16:06 |
| ogra_cmpc | Laibsch, rootstock will grow it for lucid+1 | 16:07 |
| ogra_cmpc | thats already planned | 16:07 |
| Laibsch | ok | 16:07 |
| Laibsch | when should we see prereleases? | 16:07 |
| ogra_cmpc | rootstock is already available | 16:07 |
| Laibsch | what's rootstock anyway? | 16:08 |
| ogra_cmpc | just misses the plugin system that will enable per-board profiles | 16:08 |
| ogra_cmpc | a rootfs builder | 16:08 |
| ogra_cmpc | it would be the tool you would use if you wanted to build a full rootfs thats completely configured ... so you just untar it to an arm device that has bootloader and kernel and are ready to go | 16:09 |
| ogra_cmpc | Laibsch, see the rootfs from scratch wikipage from the topic for more info | 16:12 |
| ogra_cmpc | (i think also its the tool we have the biggest community participation for atm, i'm pondering to make its improvement a summer of code project for an intrested student) | 16:17 |
| ogra_cmpc | lool, what would you think about that ? | 16:18 |
| lool | I have three ideas which relate, but which don't really go in the rootstock direction | 16:19 |
| ogra_cmpc | thats sad since its adopted by so many people alredy | 16:19 |
| ogra_cmpc | why not just improve it | 16:19 |
| lool | I personally think it would be worthwhile to enable armel in vm-builder; vm-builder is widely adopted and will be maintained by the server team; vm-builder is extensible and I'm sure we could come up with per-board plugins | 16:20 |
| ogra_cmpc | i still dont see vm-builder as the right tool | 16:20 |
| lool | I also believe we need to think longer term and invest in a tool to build images after the debootstrap part, I have some ideas about that but it's too early to mention them here | 16:20 |
| ogra_cmpc | but i guess we'll disagree on that part forever | 16:20 |
| lool | and the third bit is that I think we should couple the second tool with a hosted workflow allowing to request image builds remotely | 16:20 |
| ogra_cmpc | right | 16:21 |
| ogra_cmpc | lool, but i'd like us to coordinate the efforts before we drift away in different directions here | 16:23 |
| lool | ogra_cmpc: I think vm-builder is a nice immediate consolidation point | 16:25 |
| ogra_cmpc | i dont think so ... my first criticism point wont ever be solved | 16:26 |
| ogra_cmpc | its not shell | 16:26 |
| lool | It wont be solved no, I'm not sure it's a drawback though | 16:26 |
| ogra_cmpc | rootstock gets so much particiaption from the outside because even a beginner can understand the code and commit a fix very easily | 16:26 |
| lool | It allows offering a python API for instance | 16:27 |
| ogra_cmpc | sure | 16:27 |
| ogra_cmpc | i agree that its definately better for gui integration etc | 16:27 |
| lool | Let's agree to disagree | 16:27 |
| ogra_cmpc | yeah :) | 16:27 |
| ogra_cmpc | sigh so the '-T small' option for mkfs.ext3 doesnt fix the hang | 16:35 |
| * ogra_cmpc tries to just set the blocksize | 16:38 | |
| ogra_cmpc | lool, whats the biggest image you have used yet with lucid qemu ? | 16:41 |
| ogra_cmpc | in armel emulation indeed | 16:41 |
| Laibsch | lool: http://paste.debian.net/62953/ qemu-bootstrap fails | 17:15 |
| lool | ogra_cmpc: Sorry, I'm not sure | 19:30 |
| lool | Laibsch: That's interesting; could you run that command? | 19:31 |
| lool | Laibsch: chroot lucid-armel-chroot dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu10_armel.deb /var/cache/apt/archives/base-passwd_3.5.22_armel.deb | 19:31 |
| lool | or s#dpkg#/usr/bin/dpkg# | 19:31 |
| Laibsch | lool: http://paste.debian.net/62992/ dependency problem? | 19:33 |
| Laibsch | there is no awk package in /var/cache/apt/archives/ | 19:35 |
| Laibsch | same for gawk | 19:36 |
| lool | Laibsch: Could you run chroot lucid-armel-chroot /debootstrap/debootstrap --debug --second-stage ? | 19:49 |
| lool | Laibsch: mawk should have been unpacked by debootstrap | 19:50 |
| lool | (not by dpkg though) | 19:50 |
| lool | oh that's just a warning | 19:50 |
| lool | Laibsch: Your problem is dpkg: ../../src/archives.c:754: tarobject: Assertion `r == stab.st_size' failed. | 19:50 |
| lool | Laibsch: That's the same bug I reported | 19:50 |
| lool | Laibsch: Just create the chroot outside of home directory | 19:50 |
| lool | Laibsch: It's an ecryptfs bug exposed by recent changes to dpkg | 19:50 |
| Laibsch | I see | 19:50 |
| lool | bug #524919 | 19:51 |
| ubot4` | Launchpad bug 524919 in linux (Ubuntu Lucid) (and 4 other projects) "ecryptfs breaks lstat/readlink size assumption (affects: 1)" [High,Confirmed] https://launchpad.net/bugs/524919 | 19:51 |
| Laibsch | I'm restarting in /usr/src | 19:51 |
| Laibsch | that was successful | 20:13 |
| Laibsch | great! | 20:13 |
| === Laibsch1 is now known as Laibsch | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!