[01:18] <watson540> hi I have a smartq v7 arm machine, it's imported into the us and it came with ubuntu arm installed, my issue is that the repo's for the installed version are in china...im sure there is a mirrror in the us though?
[01:19] <persia> There probably isn't, actually.
[01:19] <persia> ports.ubuntu.com has very few mirrors (and I don't know if they are well identified).
[01:19] <persia> Also, do be careful with upgrades of that device.  I think it won't work with lucid, and I'm unsure if it works with karmic.
[01:20] <persia> I'm also completely unaware of which packages got patched how to make it work : I don't remember seeing patch submissions back to Ubuntu from the SmartQN pre-install derivative.
[01:21] <watson540> right it seems like they have blocked certain pkgs by default through apt as well
[01:22] <watson540> though its been so long since i used a debian or derivative im mainoly gentoo
[01:22] <watson540> but things like the proprietarily coded vlc to take advantae of hdmi and the hardware encoder to do 1080p...stuff like that i dont think i want to upgrade
[01:22] <watson540> :)
[01:23] <watson540> was actually hoping to either put gentoo on it or put my customized ubuntu on there
[01:23] <watson540> used ubuntu before debian years ago so i think i remember enough..but where to start..
[01:25] <persia> /etc/lsb-release ought to tell you the base Ubuntu that they started from.
[01:26] <persia> And you should be able to point at the rthe apprpriate release at ports.ubuntu.com to get more packages (if the mirror is incomplete, or if bandwidth is better to p.u.c)
[01:27] <persia> Once you have that, you can probably install/uninstall packages as you like to tweak your install.
[01:34] <lifeless> lsb_release -a and/or lsb_release -d
[01:35] <lifeless> interfaces, ftw
[01:35] <persia> -r is likely to be more useful.  I do wish there was a better way to enforce updates for derivatives.
[01:36] <lifeless> shotguns?
[01:37] <persia> Something with lower transportation costs would be nice.
[01:38] <persia> Seems that the Netwalker has the same issue that the OS vendor didn't change the values.
[03:41] <Ox83> hmmm. playing with rootstock on karmic. seems to hang at "Extracting zlib1g..." after executing "sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --notarball --imagesize 3G"
[03:43] <Ox83> zlib1g and *-dev are installed. known issues...?
[03:46] <persia> There was some discussion about it in http://irclogs.ubuntu.com/2010/02/26/#ubuntu-arm.txt
[07:31] <Ox83> persia: thanks, yes i did see that. just wondering if the solution is still the same? ogra if you are around... any thoughts to share?
[07:32]  * persia thinks it's very early in the morning there, and response may be delayed.
[07:34] <Ox83> lol. not a pressing issue. :D thanks persia... is that where you are geogrphically?
[07:35] <persia> No, it's late afternoon for me.
[07:36] <Ox83> bedtime for me. will check in manana. night!
[08:52] <lool> syadnom: Reason is performance
[08:52] <lool> syadnom: the distro targets netbooks, and potentially desktops and mids
[08:52] <lool> not older hardware
[08:53] <lool> the future is armv7 devices everywhere, and we want to optimize for that
[08:53] <persia> Well, the medium-term future.
[08:53] <persia> ARMv8 will come someday.
[08:54] <persia> But ARMv7 is current, and will last longer than prior generations.
[08:54] <lool> persia: True, let's start building for v8
[08:56] <persia> lool: Can we wait until the next release of Ubuntu?  I'd rather have at least one release available for each instruction set.
[11:58] <ogra> lool, i assume your mono patch doesnt fix the assembly installation yet, right ?
[11:59] <lool> ogra: it hangs instead of crashing
[11:59] <ogra> well, thats the karmic behavior
[12:00] <lool> Really?
[12:00] <ogra> yes, in qemu-user it always hung
[12:00] <ogra> thats why rootstock uses qemu-system for the second stage still
[12:01] <ogra> its my only blocker to switching rootstock to use a chroot from start to end
[12:03] <lool> Apparently, it might be a non-trivial boehm-gc issue
[12:03] <ogra> yes
[12:03] <ogra> i was told so in karmic already
[12:03] <ogra> (i think suihkulokki said it back then)
[12:05] <lool> ogra: Is there a bug open about it?
[12:06] <ogra> i dont think so
[12:06]  * ogra checks
[12:06] <Rishi1> Hi
[12:07] <Rishi1> Can somebody tell me whether I can install Ubuntu 9.04 on my Arm based Nokia N810
[12:07] <ogra> lool, not against mono at least
[12:08] <ogra> Rishi1, only if you have your own kernel and bootloader
[12:08] <ogra> Rishi1, for userspace creation you can just use rootstock (see RootfsFromScratch wikipage)
[12:10] <lool> Rishi1: We don't provide a kernel for it, but the userspace of Ubuntu releases 9.10 and earlier would work
[12:10] <ogra> lool, should i file against qemu or mono ?
[12:10] <lool> ogra: it's a qemu bug
[12:10] <lool> It works unders system emulation
[12:10] <ogra> well, but is boehm gc supposed to work with syscall translation ? :)
[12:13] <lool> qemu is supposed to emulate whatever is needed
[12:13] <lool> It might expose a boehm-gc bug, but I find that unlikely
[12:13] <lool> Anyway, speculation wont lead anywhere here
[12:15] <ogra> hmm, looking at the mono documentation there seems to be an alternative to boaem
[12:15] <ogra> *boehm
[12:16] <ogra> "A new generational, precise and compacting GC is being developed and is currently available from SVN releases of Mono."
[12:16] <ogra> http://www.mono-project.com/Compacting_GC
[12:17] <Rishi1> I have installed Mer on it.. but now Im not able to connect my PenDrive to it
[12:17] <ogra> "The code is still experimental and should not be used in any kind of production environment."
[12:17] <ogra> :(
[12:21] <Rishi1> Mer is I guess a ubuntu for ARM.. correct me if Im wrng
[12:22] <lool> Hmm it's based on Ubuntu sources and built for ARM
[12:26] <ogra> oh, nice
[12:26] <ogra> i filed bug 530000
[12:26] <ubot4> Launchpad bug 530000 in qemu-kvm (Ubuntu) "mono assembly installation under qemu-arm-static hangs (affects: 1)" [Undecided,New] https://launchpad.net/bugs/530000
[12:26] <ogra> nice round number :)
[12:27] <ogra> lool, ^^^
[12:28] <persia> Rishi1: Mer is downstream from Ubuntu (as Ubuntu is downstream from Debian).  It isn't Ubuntu for arm (that's just Ubuntu), but it is based on Ubuntu and compiled for arm.
[12:30] <Rishi1> ok
[12:30] <Rishi1> Thnx for info
[12:36] <Rishi1> How could I enable usb host mode in Mer ??
[12:40] <persia> Were the folk in #mer unable to help you?
[12:40] <persia> I have a feeling that it's a kernel-specific hack, and I'm not sure we have software that does that (although I could be wrong).
[12:40]  * persia would like to help, but has no idea where to start
[12:44] <ogra> lool, that gmane link doesnt open for me
[13:04] <Rishi1> persia: #mer people are not responding... It must be a simple trick.. In Maemo it was so easy.. Mer is a more advanced than Maemo .. but Im not able to find any clue regarding it
[13:05] <Rishi1> In Mer it has a provision that One can connect USB as ethernet ..
[13:18]  * ogra takes a break
[13:52] <lool> ogra: works for me
[14:07] <ogra> weird
[14:15] <rbelem> hi ogra
[14:15] <ogra> hey
[14:16] <rbelem> ogra, is it possible to store two different magic number for the same platform in /usr/share/binfmts/qemu-arm? :-)
[14:16] <ogra> i dont think so
[14:16] <rbelem> :-/
[14:17] <ogra> just create a second binfmt hook
[14:17] <rbelem> ogra, cool! i will figure out how to do that
[14:17] <ogra> cp /usr/share/binfmts/qemu-arm /usr/share/binfmts/qemu-my-personal-binfmt
[14:17] <rbelem> thanks ogra
[14:18] <ogra> edit that and do the binfmt-support magic
[14:18] <rbelem> ogra, and how it will load both?
[14:18] <ogra> (see the qemu-static-user postinst for what to do)
[14:18] <rbelem> cool
[14:18] <ogra> it will load one or the other
[14:18] <ogra> based on your magic number
[14:19] <rbelem> ogra, and how do you get this magic number?
[14:19] <rbelem> i was looking for the magic binary but i did not find
[14:21] <rbelem> i just got a different output with the file cmd
[14:21] <rbelem> but i did not figure out how to get that strange string
[14:27] <persia> rbelem: Why do you need to do this?
[14:27]  * persia expects to learn bundles
[14:27] <rbelem> ehhehe
[14:27] <rbelem> persia, i just got a different file cmd output
[14:28] <rbelem> persia, and the binary is not running
[14:28] <rbelem> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV
[14:29] <rbelem> is it an i386?
[14:29] <persia> That's *supposed* to run under qemu-arm-static, or are you doing binfmt for 32-bit executables?
[14:29] <rbelem> i think it is
[14:29] <rbelem> it runs on my device
[14:29] <persia> Odd.
[14:30] <rbelem> :-/
[14:30] <ogra>  Intel 80386 is definately an x86 binary
[14:31] <ogra> qemu-arm-static cant run that but if your host is x86 it will just run nativelyx
[14:31] <persia> Doesn't mean that the device in question isn't using qemu-static-80386 to run it :)
[14:31] <ogra> if someone builds qemu-static-80386 :)
[14:31] <ogra> i dont think we do in ubuntu :)
[14:32] <ogra> given that qemu only builds on x86 based arches atm
[14:34] <rbelem> hum... i will check it
[14:39] <ogra> hmm, what is myigep.com ?
[14:40] <ogra> ah, omap3530 boards
[14:46] <ogra> wow, thats cute
[14:46] <ogra> http://www.igep-platform.com/index.php?option=com_content&view=article&id=46&Itemid=55
[14:47] <ogra> that set of peripherials is awesome for $145
[17:14] <zumbi> what do you use for uImage debian package creation? it seems make-kpkg does not support uImage. :-/
[17:18] <plars> zumbi: uboot-mkimage
[17:18] <plars> zumbi: well, for kernel/initrd etc
[17:19] <zumbi> plars: yes, kernel/initrd is what i look for, does it replaces make-kpkg? or you use that afterwards?
[17:19] <zumbi> nice, uboot-mkimage - generate kernel image for U-Boot :-)
[19:21] <armin76> zumbi: fail!
[20:21] <Ox83> https://wiki.ubuntu.com/ARM states: Ubuntu jaunty targets the ARM EABI, with an expectation of minimum compliance with the ARMv5t instruction set.
[20:21] <Ox83> my question is: can i compile to armv5t target from karmic?
[20:22] <lool> Ox83: Yes
[20:22] <lool> Ox83: But all libs are built for armv6 + vfp in karmic
[20:22] <lool> So if you build a static binary which links to any lib, it might have some v6 + vfp instructions in it
[20:24] <Ox83> hmmm. any workarounds to avoid that?
[20:24] <Ox83> :D
[20:25] <roxfan> build your own libs
[20:26] <armin76> lol
[20:27] <Ox83> heh. well... any way to emulate jaunty envt to avoid 1) building libs from scratch and 2) ending up with armv6 libs?
[20:31] <Ox83> short answer: install jaunty. any others?
[20:31] <plars> build under chroot?
[22:14] <persia> Ox83: Sticking with Jaunty is really the only option if you need to stay with ARMv5
[22:16] <Ox83> ok. so a dual boot install of jaunty is on its way.
[22:16] <Ox83> btw: anyone try a jaunty build for arm5 system? any pros cons to that vs. deb?
[22:30] <persia> Ox83: I run a jaunty system with some extra backports.  It's a bit faster for some stuff than Debian, if you have the right hardware.  There are more bugs than in Debian.  Unless you anticipate an upgrade path, or need vendor support on a preinstall, I'd recommend Debian for ARMv5 systems.
[22:31] <persia> (vendor support being available for stuff like SheevaPlug, SmartQ5, etc.)
[22:34] <Ox83> sorry to make you repeat yourself persia. : /
[22:35] <persia> Ox83: No worries.  Probably 50-60% of my IRC traffic is duplicate to my previous statements :)
[22:35] <Ox83> but i am grateful for the input. i have been playing with OE to get images for this machine working, but with varied luck. it is nice to have (some) options :D
[22:36] <persia> Which machine again?
[22:36] <Ox83> zaurus sl-5600
[22:36] <persia> Oh, right.  I remember now.  Yeah, even if you jam jaunty on that, you'll likely not be happy with the results.
[22:37] <persia> The lxde stack didn't get happy until karmic, and what GUI stacks are in jaunty weren't tested at that resolution.
[22:37] <Ox83> heh. wisdom. thank you. will play with deb then (another repeat sry).
[22:40] <persia> With luck, someone will release a replacement device that can run future code.  The form-factor seems to have become unpopular (well, except for the RAON Digital products).