[01:28] <Lopi> Is it possible to compile maverick for armv6?
[01:29] <persia> Lopi, Potentially, although you might have to patch a few things.
[01:30] <persia> You would have to recompile the entire archive though, starting with the toolchain, which would be a significant undertaking.
[01:30] <Lopi> I see, I don't have hardware acceleration so unity might not run that great anyway :/
[01:30] <rcn-ee> who does. ;)
[01:31] <rcn-ee> Lopi, if you have enough builders, probally take about a month..
[01:33] <Lopi> rcn-ee: Unfortunately, I'm the only one working on my project at the moment :/
[01:34] <persia> Then it might take six or more months, depending on how much of the archive you need to recompile.
[01:34] <persia> You might consider Debian as a better base for your hardware.
[01:35] <rcn-ee> Yeah, lopi, that'll run Debian squeeze's armel... once you get the filesystem up an running, tweak the libs/packages you need with apt-build..
[01:35] <rcn-ee> it should get you fairly close to as optimzed to armv6 as possible..  or there's angstrom.. ;)
[01:37] <Lopi> I'm currently using karmic with lxde. I may consider switching to Debian. I'm having a hard time deciding the future of my project
[01:38] <Lopi> I submitted a patch to openembedded a month or two ago for my device. I was playing around with the various OpenMoko distributions. I ended up deciding I needed to build something a little more custom.
[01:39] <Lopi> I'm still fairly new to all of this though ;p
[01:40] <rcn-ee> which reminds me.. did lool have a ubuntu 'task/brainstorm' for a building distro from custom compiler options?
[01:42] <Lopi> rcn-ee: what device do you primarily work with?
[01:42] <rcn-ee> here we go... this may or may not be usefull... https://wiki.ubuntu.com/Specs/M/DerivedArchiveRebuild
[01:43] <rcn-ee> Lopi, well, today... the craneboard... ;)  mostly omap3/4's.. some mx5's and at91's..
[01:43] <persia> rcn-ee, There's work going on in Launchpad to define/enable that sort of thing.
[01:44] <persia> But I think it just means that one can copy source and rebuild in LP, perhaps with additional patches.
[01:45] <rcn-ee> yeah, it's just an early spec.. ;) i do like the idea of tweaking the gcc setting and rebuilding..  (even thou you'd probally onlyl do it once..)
[01:45] <lool> oh it's quite advanced actually
[01:45] <lool> it allows maintaining derivatives easily, with a subset of or a whole Ubuntu
[01:45] <Lopi> rcn-ee: Ah, I see. All I'm working with a lowly iPhone3G ;p
[01:46] <Lopi> is*
[01:46] <lool> I don't know how far the implementaiton is
[01:46] <rcn-ee> lool, so if for some reason we wanted to reneable armv5 support in natty++  ;)
[01:46] <lool> rcn-ee: https://dev.launchpad.net/LEP/DerivativeDistributions
[01:46] <lool> rcn-ee: Eh  :-0
[01:46] <lool> rcn-ee: I don't expect us to put efforts into it ourselves, but the tools will be there
[01:47] <rcn-ee> Yeah, i wouldn't see you guys wasteing bandwidth on that.. but for a local farm, rebuilding ubuntu for a custom board would be nice..
[01:48] <lool> rcn-ee: I also think qemu is also good enough nowadays that you could use it almost like real hardware provided sufficiently fast machines
[01:48]  * lool => bed &
[01:49] <rcn-ee> thanks lool  night!
[04:13] <lilstevie> ohai lool
[04:13] <lilstevie> er
[04:13] <lilstevie> Lopi:
[04:13] <Lopi> hey lilstevie :D
[04:14] <lilstevie> Lopi: you taken over iX by yourself now?
[04:14] <Lopi> lilstevie: yeah, been like that for awhile now
[04:14] <lilstevie> ah, since my 3G blew its display driver i got left behind lol
[04:15] <Lopi> ah I see, yeah I'm not really sure what to do with the project anymore
[04:15] <lilstevie> working on getting ubuntu on my android tablet now :p
[04:15] <lilstevie> Lopi: once oib is ported to more devices :)
[04:16] <lilstevie> Lopi: the SGX535 is a much more supported GPU so bring on the fun ;)
[04:16] <Lopi> lilstevie: yeah, I really want to play around with the ipad
[04:16] <Lopi> lilstevie: getting bored of my 3G tbh
[04:17] <lilstevie> yerah
[04:17] <lilstevie> yeah*
[04:17] <lilstevie> i am bored of iDevices TBH
[04:17] <Lopi> I know what you mean, I want something open
[04:17] <lilstevie> once oib works on the a4 i may get debian running on it though
[04:17] <lilstevie> on my ATV*
[04:18] <lilstevie> heh thats what i am loving with the galaxy tab at the moment
[04:18] <lilstevie> the fact that without an exploit i can flash a custom kernel and fs
[04:19] <Lopi> I can only imagine how awesome that is ;p
[04:19] <lilstevie> heh it is amazing
[04:19] <lilstevie> and for being a candidate for ubuntu too
[04:19] <lilstevie> 1024*600 display resolution
[04:20] <Lopi> nice, going with unity interface then?
[04:21] <lilstevie> I guess :p
[04:21] <lilstevie> i need to get this damn kernel to compile
[04:21] <lilstevie> the only bad thing with the tab is that the initramfs is compiled in to the kernel
[04:21] <Lopi> that kind of sucks ;p
[04:22] <Lopi> better then relying on an exploit though
[04:22] <lilstevie> well the kernel is opensource as well :p
[04:24] <ka6sox> the Nook Color pretty much has the same issues
[04:27] <Lopi> the most fun I have had with my 3G was making Mer work, packages are fairly limited on armv6 for Ubuntu
[04:31] <Lopi> lilstevie: Have any suggestions for something new to play with on my 3G?
[04:33] <lilstevie> Lopi: none really
[04:33] <Lopi> lilstevie: bleh, that's what I was afraid of
[04:34] <Lopi> lilstevie: I suppose I'll release Ubuntu with LXDE then wait for the a4 ports to be finished :/
[04:34] <lilstevie> sad to say it but 3G has hit EOL
[04:34] <lilstevie> thus all remaining armv6 devices are discontinued at apple
[04:36] <Lopi> some people in the iDroid community suggested making something more custom, but I don't see the point with the 3G hitting EOL
[04:38] <Lopi> I hate to let iX go inactive for so long, but I'm losing interest :/
[07:24] <sanket> hii
[07:24] <sanket> can any know an efficient ARM emulator so that I can ARM based filesystem
[07:37] <ka6sox> sanket, qemu is the only one I've used.
[07:40] <lilstevie> blah
[07:40] <lilstevie> the initramfs is corrupy
[07:40] <lilstevie> corrupt*
[07:40] <sanket>  can u help me the installation process of qemu on ubuntu-linux...
[07:42] <persia> sanket, What host, and which guest?
[07:42] <sanket> host is i386 and guest is ARM
[07:52] <persia> apt-get install qemu-kvm-extras should get you the emulator.  From there, boot in your favourite kernel and rootfs.
[07:52] <persia> I believe that the current set only supports the versatile processor, although I know work has been ongoing for omap and a fast virtual variant.  I don't happen to know the current status of those efforts as reflected in the Ubuntu packages.
[07:57] <lilstevie> versatile goes well
[08:02] <persia> lilstevie, Doesn't it still need hacking to have more than 256MB memory?
[08:11] <lilstevie> persia: i mean for qemu
[08:11] <lilstevie> what device has less than that these days
[08:11] <persia> So do I.
[08:12] <persia> My understanding was that qemu only had 256MB emulating versatile, but could go up to 1GB emulating omap.
[08:12] <persia> I could be misinformed.
[08:12] <lilstevie> ah
[08:12] <lilstevie> i dont bother emulating more
[08:13] <lilstevie> because an emu inside a vm is not fun
[09:56] <sanket> I m getting an error while using qemu .... qemu: fatal: Trying to execute code outside RAM or ROM at 0x30008000
[09:56] <sanket> can anyone help me what is this error and how to solve it?
[11:24] <lilstevie> i really wish rootstock would cache packages
[11:34] <sveinse> Why do you get like 70 console-kit-daemon processes?
[11:59] <ogra> sveinse, are you looking at threads ?
[12:00] <ogra> you normally dont get 70 of them but there can easily be 70 userland threads
[12:09] <sveinse> ogra, yes I think they are. They show up in pstree, but not in ps
[12:09] <ogra> right
[12:09] <ogra> thats fine
[12:10] <ogra> 70 processes would be odd
[12:10] <sveinse> It's the sheer number of processes/threads I'm curious of
[12:10] <sveinse> I seem to have a HW problem linked to the serial port, as getty ttyO2 keeps respawning. Could it be related to it?
[12:11] <ogra> every process in userspace is wrapped in CK
[12:11] <ogra> no
[12:11] <ogra> that rather smeppls like an issue with upstart
[12:11] <ogra> *smells
[12:11] <ogra> what kind of kernel do you use ?
[12:11] <sveinse> yeah, ok. I'll keep my eyes open then
[12:11] <ogra> there are certain features udev and upstart need enabled
[12:12] <sveinse> ogra, custom since its a custom board
[12:12] <ogra> right
[12:12] <ogra> dont ask me which features that are (dont know from the top of my head) but if certain features are missing udev and upstart wont work correctly
[12:12] <ogra> one i remember is signalfd
[12:13] <sveinse> ogra, which... hahaha, you got ahead of me. I'll take a look the the versatile kernel or something and diff against it. Thanks
[12:13] <ogra> better take the omap3 or 4 configs
[12:13] <sveinse> which one is that?
[12:14] <ogra> from the linux-image-...-omap3/4 packages
[12:14] <ogra> we ship configs in /boot/config-<kernel version> in the packages
[12:15] <lilstevie> i am having a bit of fail getting bootup in qemu :/
[12:16] <ogra> versatile isnt really cared for since lucid iirc ... it wasnt touched by anyone ... and it is likely to go away in natty
[12:16] <lilstevie> hm
[12:17] <persia> ogra, Why is it going away?  Does qemu do omap well enough now?
[12:17] <ogra> there is work going on to merge omap in, yeah
[12:17] <sveinse> ogra, yes. I'll take a look at linux-image-2.6.35-24-omap.. Think that's closest to our HW. (we're running 2.6.37, so there's some other diffing issues)
[12:17] <persia> My memory of UDS was that the qemu guys didn't expect to have something ready for natty, and wanted to stick with versatile, and then go for something else for natty+1, but I haven't been following progress.
[12:17] <ogra> sveinse, natty has a .37 omap kernel
[12:18] <lilstevie> so for now is it better to just do everything in chroot?
[12:18] <ogra> persia, afaik slangasek is working on merging it into our branch now, ask janimo_ for details
[12:18] <persia> Oh, cool.  I'm glad to hear the work made it.
[12:18] <ogra> lilstevie, ??
[12:19] <rsalveti> new qemu should be a lot better
[12:19] <rsalveti> and work with omap 3 kernel
[12:19] <lilstevie> well i need to set some things up in the image, that i would usually do while it is running in the emu
[12:20] <ogra> lilstevie, well, qemu (at least the arm side) nor the kernel should have changed much since maverick
[12:21] <lilstevie> it kinda screws up on boot and just halts
[12:21] <ogra> if that would be the case rootstock wouldnt work at all
[12:21] <ogra> and afaik that works
[12:21] <ogra> so it must be something in your rootfs thats messed up i'd assume
[12:22] <lilstevie> but i havent changed a thing in the rootfs
[12:23] <lilstevie> using the instructions on the wiki, versatilepb and cortex-a8
[12:23] <ogra> well, file a bug, attach the logs
[12:23] <sveinse> A little off-track question: I created my rootstock branch yesterday, and commited some proposals to it. I planned on submitting a merge request, however I discovered a rather stupid error in the commit message. Would it be important to fix the commit message prior to merge, or doesn't it matter?
[12:24] <ogra> doesnt really matter
[12:24] <ogra> i make typos all the time in mine :P
[12:25]  * ogra is famous for typing teh instaed of the
[12:25]  * persia notes that bzr supports uncommit in case it's really something one is ashamed to have posted
[12:25] <ogra> heh, and apparently for mistyping instead
[12:26] <sveinse> Well, that's typo. I wrote "added --apt-clean option to rootstock" when the real option is --apt-update. Somewhat more significant error IMHO
[12:26] <ogra> well, as persia said ... you can uncommit
[12:26] <sveinse> thanks, I'll do that for the correctness of things
[12:26] <rsalveti> yup, uncommit, commit again and force the push
[12:26] <ogra> if you have pushed already you need to use --overwrite for the push command
[12:29] <sveinse> Heh. That was far easier than expected
[12:29] <sveinse> Uncommit in subversion isn't exactly trivial
[12:29] <ogra> thats why we have bzr ;)
[12:33] <janimo_> persia, pm215 from linaro is workiing on selecting omap bits from qemu-maemo and this will be packages with slangasek's help into a new source
[12:34] <janimo_> which will rpvide binari packages for the current non-x86 binariesm leaveing current qemu-kvm x86 ony and be used by server team
[12:34] <persia> Excellent.  last I heard was in October, when it was thought to not be possible in time for natty.
[12:34] <persia> In this case I'm *really* glad to be wrong.
[12:34] <janimo_> persia, indeed for natty it is still not possible to have omap in upstream - which would be ideal - so a temporary solution is anew source package
[12:34] <rsalveti> pm215 is doing a quite good work with qemu
[12:35] <rsalveti> lots of old bugs fixed already
[12:35] <rsalveti> so we should have a more stable one for natty
[12:35] <janimo_> persia, but the last details were still beiong discussed at the rally so no wonder the october info is out of date
[12:35] <persia> new source package?  Ugh.  Oh well.  I suppose, if that's considered less effort than maintaining versatile another cycle (not that versatile is all that useful, really)
[12:36] <janimo_> rsalveti, indeed he gets the fixes in very fast, the bottleneck and the boring part is getting the packaging (and possibly backports) right
[12:36] <janimo_> persia, versatile annoys kernel people as it adds extra build time
[12:37] <janimo_> and it would be better to have qemu support one of our official images - I am not sure versatile runs those?
[12:37] <persia> Nope.
[12:37] <sveinse> ok. Now I've created my very first merge request. I presume it's either orga or rsalveti who will review this.
[12:37] <janimo_> so omap3 as omap4 is not yet nearly functional in qemu
[12:38] <rsalveti> sveinse: yup, thanks for creating it, will take a look later
[12:39] <sveinse> sure, np. Just wanted to see if I got things right
[13:09] <janimo_> is a rename to unity-2d planned?
[13:09] <janimo_> or a new metapackage of that name added?
[13:09] <rsalveti> janimo_: hm, why?
[13:09] <ogra> janimo_, yes, i'm working on that
[13:09] <janimo_> rsalveti, I seem to remember ogra mentioning it a while ago, and for clearer naming
[13:09] <janimo_> we have unity already
[13:09] <ogra> (merging unity-2d-default-settings into the unity-2d source)
[13:09] <janimo_> having the default-settings package be the top level one seems unusual
[13:09] <rsalveti> that makes sense, but I don't understand why rename unity-2d
[13:10] <janimo_> rsalveti,I meant rename an existing package to unity-2d
[13:10] <rsalveti> if it's just this merge, then ok
[13:10] <rsalveti> ok :-)
[13:11] <janimo_> so that gnome-session can Recommends gnome-panel | unity | unity-2d and do not pull in gnome-panel all the time
[13:11] <persia> The traditional reasoning behind the foo-default-settings packages is that they set defaults for various configuration subsystems that are unique to a selected interaction model, and may not always be appropriate for some specific package.  If unity-2d-default-settings is doing this, it would be better not to merge.
[13:11] <persia> If it's just setting stuff for the unity-2d package, then it doesn't matter.
[13:12] <janimo_> persia, makes sense, espcially since those settings are ubuntu addons to upstreams.
[13:12] <janimo_> anyway a to plevel meta[pavkage with a short and sane name is desired
[13:12] <janimo_> :)
[13:12] <persia> Indeed.  For comparison, consider xubuntu-default-settings, kubuntu-mobile-default-settings, etc.
[13:12] <persia> Maybe.  Depends if it's a flavour or not.
[13:13] <persia> I'd claim that the right choice would be ubuntu-desktop or similar, to get that experience.
[13:13] <janimo_> unity on debian or fedora will probably not use our themes or autostart settingd
[13:13] <persia> Right, which is why -default-settings doesn't belong in that source.
[13:13] <janimo_> I agree
[13:13] <janimo_> I thikn the source should contain what the upciek team writes
[13:13] <persia> (assuming that we seek null packaging, where feasible, in pursuit of automation)
[13:14] <persia> Excellent.  I'll let you argue with everyone else whilst I sleep then :)
[13:15] <janimo_> this is a tangent though to what I was askking - to have a clean and final name we can stick into gnome-session Recommends: field :)
[13:17] <persia> Create some virtual supplied by all unity interfaces, and then control which meets the requirement through seeding, defaulting to "unity"
[13:18] <janimo_> packages like flash-kernel that in addition to the package source have a bzr trunk in LP need to be changed in both places ?
[13:19] <janimo_> I did not see it satte that it is mainatined in bzr which makes it more ocnfusing
[13:57] <ogra> janimo_, change it in the bzr tree and build the package from there
[13:59] <ogra> change, commit (UNRELEASED), change debian/changelog to natty), debcommit -r, push, bzr builddeb (or manually bzr export) and upload
[14:00] <janimo_> ogra, thanks. I have not yet built from bzr before.
[14:06]  * janimo_ misses almost everything from git when working with bzr
[14:07]  * rsalveti understands janimo_ 
[14:07] <rsalveti> but I must say I'm quite used with bzr already again
[14:08] <rsalveti> god how I hate to debug qt
[14:08] <rsalveti> a simple make takes an incredible amount of time
[14:08] <rsalveti> that touches just one lib
[14:08] <janimo_> I hope I'll get used to it again, switching to git 3 years ago was equally awkward I think
[14:11] <hrw> janimo_: git-bzr-ng provides you one way to get bzr into git (push is broken)
[14:12] <janimo_> hrw, thanks, I can work with bzr just don;t like it that much anymore
[14:13] <hrw> my fingers also type git when I work with bzr
[14:27] <ogra> persia, could you take a look at the control file at http://paste.ubuntu.com/558125/ ?
[14:28] <ogra> purpose is to merge the -default-settings package into unity-2d source and create a metapackage ... i'm unsure about the conflicts/replaces and also aboutnot the fact if i need a transitional package or
[15:31] <SaidKLE> Does anyone know how to install ubuntu natively on an arm MID?
[15:33] <ogra> there is no such thing as "an ARM MID"
[15:33] <ogra> :)
[15:33] <ogra> you need to be more specific
[15:33] <ogra> (SoC model etc)
[15:34] <SaidKLE> The haipad m701 is an MID that claims it runs android 2.2.  I want to be rid of android completely and install ubuntu on it natively, if that's possible.
[15:35] <SaidKLE> Here, I'm looking up the specifics...
[15:35] <rcn-ee_at_work> that's a Telechip TCC8902, one of my buddies has it.. i think it's arm9..
[15:35] <ogra> ah, no recent ubuntu then
[15:38] <SaidKLE> Is there an older version, say 9.04 or something, that would work on it?
[15:39] <ogra> 9.04 would work buut it is unsupported (EOL)
[15:39] <rcn-ee_at_work> wow, it's actually arm11... (armv6)
[15:39] <rcn-ee_at_work> so karmic..
[15:39] <ogra> yeah, that should work then
[15:40] <ogra> and karmic is actually still not EOL until april
[15:40] <ogra> so you have three wonderful months :)
[15:40] <rcn-ee_at_work> SaidKLE, was that the one on woot? about a week ago?
[15:41] <LetoThe2nd> SaidKLE: hint: ubuntu has a relatively conservative older brother which is still supporting arm9. :-)
[15:41] <ogra> hey, we strill support arm9 (for three months) :P
[15:41] <Amaranth> LetoThe2nd: I thought squeeze dropped arm for armel?
[15:41] <ogra> Amaranth, they did
[15:42] <ogra> but they didnt go -march=armv7
[15:42]  * LetoThe2nd is running an openrd here on deb5.0. :-)
[15:42] <ogra> i think they still support armv5te
[15:42] <ogra> even with armel
[15:42] <Amaranth> ogra: Oh, I thought that was the point of changing the port name :)
[15:43] <rcn-ee_at_work> well the old arm port did armv4..
[15:43] <ogra> right
[15:43] <ogra> and no thumb
[15:43] <SaidKLE> So, I should probably run karmic?  I'm fine with that, but how does one go about actually getting ubuntu onto the device?
[15:43] <ogra> for openmoko compatibility ;)
[15:44] <ogra> SaidKLE, you should know everything about your bootloader and kernel
[15:44] <ogra> then just make them use an ubuntu rootfs (see topic)
[15:44] <SaidKLE> I don't.  I've tried to figure that out, but haven't managed it yet.
[15:44] <LetoThe2nd> SaidKLE: there's a manual for the openrd providing a guide to flashing ubuntu. read it, combine it with what ogra said and there you go :-)
[15:44] <ogra> right, thats the first step as ubuntu doesnt have either for you
[15:45] <SaidKLE> okay.  I'll be looking that up...
[15:45] <sveinse> SaidKLE: What HW are you sitting on?
[15:45] <ogra> your kernel needs to have all options builtin for the udev used in karmic
[15:45] <SaidKLE> once I know that though, do I just put a certain ubuntu file where the boot loader expects to find it?
[15:45] <ogra> else it wont work
[15:46] <SaidKLE> Haipad m701 telechip tcc8902
[15:46] <ogra> mind you, its usually not a beginner task to get another OS on such devices
[15:46] <LetoThe2nd> SaidKLE: nö, its first about getting your bootloader and kernel right, including config and layout on bare flash.
[15:46] <ogra> and you will likely have to rebuild your kernel etc
[15:47] <ogra> and know about flashing or how to run the OS off an SD card
[15:47] <sveinse> from past experience, if you have a bootloader and kernel (config) available, then its a lot easier to get ubuntu up and running
[15:47] <LetoThe2nd> SaidKLE: if you're a beginner and don't have access to advanced debricking tools (i.e. a good jtag interface) i guess it's advisable to go either hunting for some existing port or leave the thing as is.
[15:48] <sveinse> all boards I have worked with in the past had a linux demo kit with kernel which I could use with ubuntu
[15:48] <LetoThe2nd> at the moment we don't even know the bootloader type... :-/
[15:48] <ogra> nor what kind of kernel is used
[15:48] <LetoThe2nd> yeah, basically we know - nothing.
[15:50] <sveinse> I know this is a wrong place for the question, but what is console-kit? If I'm building a system with no interactive uses (only services), can I live without it?
[15:53] <sveinse> my system is not going to run X -- only a Qt QWS application, and without DBUS
[16:15] <ogra> persia, updated paste at http://paste.ubuntu.com/558148/
[20:16] <persia> ogra_, I don't know precisely how the pieces fit together, but I'm opposed to merging a -default-settings package into anything that has code, and don't see the point of metapackages except as expressions of flavours.
[20:22] <GrueMaster> We may have a problem with images next week.  X is getting updated Friday.  May cause turbulence.
[20:25] <persia> ogra_, Looking at your changes to control: Please don't call something a "metapackage" if it has content (and isn't in section: metapackages).  The mechanics of replacement look acceptable, although take care with versions (there's no changelog entry in the diff, so I don't see that).
[20:34] <ogra_> persia, well, how should i call it ?
[20:35] <ogra_> it depends on the rest of unity-2d but indeed ships gconf bits and postinst
[20:36] <persia> Hmm.
[20:36] <persia> Well, there's two ways to do it.  the one I like, and the one you seem to be pursuing.
[20:36] <ogra_> effectively it does the same a metapackage does
[20:36] <ogra_> i only do what upstream will do anyway
[20:36] <persia> The common way is to have a metapackage (which is empty by definition) on a per-flavour basis, and have that pull -default-settings.
[20:37] <jhobbs> i noticed there is a omap4 ubuntu server daily build now
[20:37] <jhobbs> where does the package list that goes into that come from?
[20:37] <persia> jhobbs, Does it work for you?
[20:37] <ogra_> well, thats exactly what upstream wants to get rid of
[20:37] <jhobbs> i haven't tried it yet, but i'll let you know
[20:37] <persia> jhobbs, It's the server stuff from the ubuntu.natty seed
[20:37] <persia> ogra_, Why?
[20:37] <ogra_> we are supposed to have a unity-2d as we have a unity package in the end
[20:38] <ogra_> the prob is that the binaries in unity-2d can be used separately
[20:38] <ogra_> so there are four binary packages and we need some toplevel that has to be called unity-2d
[20:38] <ogra_> which depends on the other binaries
[20:38] <persia> In that case, don't claim to be a metapackage.  unity is "Unity is a graphical interface designed for Ubuntu Netbook Edition".  That's unfortunate, as I heard that Ubuntu Netbook and Ubuntu Desktop were merging, but it's close.
[20:38] <ogra_> the toplevel is supposed to ship the session and config
[20:39] <persia> Just have the description say "Unity 2D is a graphical interface providing the Unity experience, but relying only on 2D acceleration" or similar.
[20:39] <persia> Just stay away from "metapackage", because that means something specific, which this isn't.
[20:49] <GrueMaster> btw:  The une-efl session bug still exists in today's image.
[20:49]  * GrueMaster thought it was fixed.
[20:49] <persia> Which bug is that?
[20:50] <GrueMaster> bug 707014
[20:50] <ubot2> Launchpad bug 707014 in netbook-launcher-efl "Ubuntu Netbook Edition 2D fails to launch from gdm by giving "No valid session found"." [Undecided,Fix released] https://launchpad.net/bugs/707014
[20:50] <persia> Which version of netbook-launcher-efl do you have?
[20:52] <GrueMaster> 0.3.2-0ubuntu5.  It doesn't appear to have been properly Fix Released.  I don't see a commited entry in the bug.
[20:52] <persia> It claims to have been fixed in 0.3.2-0ubuntu6, so that's expected behaviour (based on https://launchpad.net/ubuntu/+source/netbook-launcher-efl/+changelog )
[20:52] <persia> rsalveti forgot to add LP: foo in the changelog, that's all.
[20:53] <GrueMaster> Still, it should be in the pool.
[20:53] <GrueMaster> checking.
[20:53] <persia> It is, from what I see.
[20:53] <rsalveti> GrueMaster:  Failed to upload on anacardiaceae (armel)
[20:53] <rsalveti> that's the error I saw here
[20:53] <persia> Ah, source is in pool.  Binary failed.
[20:54] <persia> rsalveti, Have you asked the LP folks about that yet?
[20:54] <rsalveti> not to build, but to upload
[20:54] <rsalveti> persia: not yet, just saw it
[20:54] <rsalveti> persia: should I ask for help at the lp channel?
[20:54] <persia> Fail to Upload usually indicates something wonky with soyuz.  It's almost always worth asking in #launchpad
[20:54] <rsalveti> or is more related with ubuntu itself?
[20:54] <persia> No, it's #launchpad.
[20:55] <GrueMaster> Let me check if an update will pull it.
[20:55]  * rsalveti asking
[20:55] <GrueMaster> I'm not seeing anything on lp that indicates fail to publish.
[20:56] <GrueMaster> Looks like it was just posted after the image build started.  No worries.
[20:56] <rsalveti> well, I got an email with it
[20:56] <GrueMaster> apt-get update;apt-get install netbook-launcher-efl has found the updated package.
[20:56] <persia> Odd, indeed.
[20:57] <GrueMaster> It'll be in tomorrows image (assuming pool churn doesn't clobber the image build).
[20:58] <GrueMaster> I am a little worried about A2.  We have a new QT, X stack, and now I find we are getting 2.6.38 kernel.
[20:58] <GrueMaster> All for A2.
[20:58] <rsalveti> probably it failed but then soyuz tried to publish it again later on
[20:58] <GrueMaster> Possible.
[20:59] <rsalveti> haha, probably lots of new bugs :D
[20:59] <GrueMaster> yea.
[21:00] <rsalveti> GrueMaster: did you try latest omap 3 image already?
[21:00] <rsalveti> I still didn't check to see if the x-loader got into the image correctly
[21:01] <GrueMaster> btw:  rsalveti:  when you post a bug fix, add (LP: #<bug id>) to the changelog.  Then LP will handle marking the bug as Fix Released.
[21:01] <rsalveti> I know, I was going to do that after you tested the bug
[21:01] <GrueMaster> And no, I haven't tried the omap 3 image.  Beagle is put away, and I haven't gotten an XM yet.
[21:01] <rsalveti> but then janimo pushed my debdiff
[21:01] <GrueMaster> oops.
[21:01] <rsalveti> as I created the debdiff before actually opening the bug
[21:01] <GrueMaster> Ah.
[21:02] <rsalveti> was planning to update it after the test :-)
[21:02] <GrueMaster> bass ackwards.
[21:02] <GrueMaster> :P
[21:02] <rsalveti> ok, will download latest omap 3 image then
[21:03] <GrueMaster> whee.  46 upgrades since today's image was built.
[21:03] <persia> !ohmy > GrueMaster
[21:03] <ubot2> GrueMaster, please see my private message
[21:44] <rsalveti> well, omap 3 image seems to be working again
[21:44] <rsalveti> at least going into resize
[22:17] <rsalveti> GrueMaster: awesome, omap 3 image seems to be working quite well
[22:17] <rsalveti> time to activate the console and see the boot messages
[22:18] <ka6sox> has anyone heard of anybody getting ubuntu-arm booting native on a nook color?
[22:41] <rsalveti> yup, no issues and no kernel traces
[22:41] <rsalveti> GrueMaster: so it seems ok, finally :-)
[22:54] <persia> ka6sox, Are you able to boot arbitrary kernel against arbitrary rootfs yet?
[23:01] <ka6sox> persia, arbitrary? I have a rebuilt kernel from Android (have the source and have rebuilt it)
[23:01] <ka6sox> and also have the openembedded.org reference distribution called Angstrom booting
[23:02] <ka6sox> so thats pretty random
[23:02] <rcn-ee_at_work> ka6sox, where does it stop booting?
[23:02] <persia> Well, hardly random, but at least one of your choice.
[23:02] <rsalveti> if you already have a common distro running on it should be easy to run ubuntu
[23:02] <persia> Have you tried with an Ubuntu rootfs?
[23:03] <ka6sox> rcn-ee_at_work, it boots all the way up
[23:04] <ka6sox> persia, I didn't know about the maverick-omap till later
[23:05] <persia> ka6sox, So it works for you?
[23:05] <persia> How is the screen refresh?  Is X behaving nicely?
[23:05] <ka6sox> rsalveti, the main issue is that we used a no-initrd setup on Angstrom
[23:05] <ka6sox> persia, x isn't quite there...mostly because they don't seem to have the latest sgx running but we are using FB.
[23:05] <rsalveti> hm, it'd be good to have initrd to boot ubuntu, but I believe you can make it work with current setup
[23:06] <persia> Does the nook not support an initrd?
[23:06] <rsalveti> if you have access to the bootloader, it should be fine
[23:06] <ka6sox> (funny because the guy who does Angstrom was the guy who worked on beagleboard.
[23:06] <ka6sox> rsalveti, we don't really...
[23:06] <ka6sox> its kind of kludgy...
[23:07] <rsalveti> ka6sox: how are you flashing a newer kernel and booting it?
[23:07] <ka6sox> 2 partitions on an SD
[23:07] <ka6sox> 1 vfat with kernel initrd and MLO
[23:07] <ka6sox> 1 ext2 with rootfs
[23:07] <ka6sox> shove it in and away you go
[23:08] <rsalveti> so you alread have an initrd
[23:08] <ka6sox> an Android one
[23:08] <ka6sox> ubly
[23:08] <ka6sox> ugly
[23:08] <rsalveti> if it's possible to load a valid kernel and initrd, then you can regenerate one for ubuntu
[23:09] <rsalveti> but then it could have size restrictions
[23:09] <ka6sox> they are using 2.6.29 for the existingkernel.
[23:09] <rsalveti> urgh
[23:09] <ka6sox> I was trying *not* to have to redo the kernel...but I can
[23:09] <rsalveti> weird that they are still way behind, as it's basically an omap3
[23:10] <ka6sox> vendor choice as to which version you use...they are stuck on 2.1
[23:10] <rsalveti> but still, you can generate an initrd for it
[23:10] <ka6sox> I have a working chroot of maverick on it.
[23:10] <rsalveti> well, you have the sources, then you can check what they changed for it
[23:10] <rsalveti> lot of work probably, but still something
[23:10] <persia> Redoing the kernel is part of the point, I'd think, so that you could have a distributed sourceful kernel package for reliable bugfixing.
[23:11] <rsalveti> ka6sox: the image for ac100 is also using 2.6.29
[23:11] <rsalveti> once you got the correct kernel and modules, copy them to the ubuntu rootfs, regenerate the initrd and it should be fine
[23:11] <rsalveti> if you're booting with correct cmd args
[23:11] <ka6sox> the biggest problem is that they didn't send nice "patches" or even tell us what they started with before they started *their* patches.
[23:11] <rsalveti> hehe, usual
[23:12] <rsalveti> source == big and ugly tarball
[23:12] <ka6sox> rsalveti, generated on a windows machine (Documents and Files dir was there)
[23:12] <rsalveti> hehe
[23:13] <persia> What VCS tools need is a "discover" function, where they compare past revisions against a given source, find the set of commits that appear to have been applied, and construct a virtual history including prior commits (split point + cherrypicks) and then a massive commit including the rest of the diff, which can then be picked apart at leisure.
[23:13] <ka6sox> okay so what I'll do is unpack the uImage of the kernel and get the modules out of the initrd thats there and put them in maverick chroot...then regenerate teh initramfs.
[23:14] <rsalveti> yup, or even build the kernel on your own
[23:14] <rsalveti> and install the modules at a custom path, then you can easily copy the modules
[23:14]  * ka6sox reprogrammes the LF servers that check for GPL compliance to do that :D
[23:14] <rsalveti> or just deb-pkg (iirc) that will generate a kernel deb file
[23:14] <rsalveti> that you can install at your arm chroot
[23:14] <rsalveti> and regenerate the initrd
[23:15]  * persia notes that lots of extra points accrue for creating a source package that generates the appropriate binary packages and uploading to the archive so everyone can share
[23:15] <ka6sox> I've never tried building cross with make-kpkg kernel_image :D
[23:15] <persia> Could build native.  Would take a bit on the Nook, but not forever.
[23:15] <rsalveti> make -j 6 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
[23:15] <rsalveti> cross compiling
[23:16] <rsalveti> with any kernel source tree
[23:16] <rsalveti> just need the proper .config file in place
[23:16] <ka6sox> okay I have the defconfig that they used and the patched source
[23:16] <rsalveti> if you're running maverick, just install the ubuntu/linaro cross compiler
[23:16] <ka6sox> still on lucid
[23:17] <ka6sox> I'm an infra guy so I generally stay with LTS
[23:17] <persia> On lucid, you should be able to run `mk-sbuild maverick` to generate a maverick schroot, which you can then use to install and run the cross-compiler.
[23:17] <ka6sox> kk
[23:17] <rsalveti> ka6sox: check https://launchpad.net/~linaro-maintainers/+archive/toolchain then
[23:17] <rsalveti> the backported linaro/ubuntu cross compiler
[23:18] <ka6sox> okay good.
[23:18] <persia> Unless you have another reason to install all of ubuntu-dev-tools, you might want to just cherrypick that script from it.
[23:18] <ka6sox> okay so I'll have to generate the kpkg and have to bust it out though to create the uImage.
[23:19] <ka6sox> I don't recall mkuImage being able to read a .deb
[23:19] <rsalveti> generally I just install it, regenerate the initrd and then use mkimage to create the uImage and uInitrd
[23:19] <rsalveti> all that inside a valid arm chroot
[23:19] <ka6sox> okay great...thanks.
[23:19] <ka6sox> the omap3 image should be closest to what we have.
[23:20] <ka6sox> 3621
[23:20] <rsalveti> yup, I'd get first a minimal ubuntu rootfs (maverick)
[23:20] <rsalveti> and try to make that work
[23:21] <ka6sox> ya, I need rndis and ssh support mostly
[23:21] <rsalveti> http://people.canonical.com/~rsalveti/lamont/beagle/
[23:21] <rsalveti> this image should work for you
[23:21] <rsalveti> is a minimal maverick image
[23:21] <rsalveti> that I generated for beagle xm
[23:21] <ka6sox> okay thanks. I'll use that
[23:22] <rsalveti> guess same one we're using at our xm builders
[23:22] <ka6sox> I've been playing for years on things like the Slug and Pre but first time I"ve "ported" an OS on a device
[23:23] <rsalveti> :-)
[23:24] <rsalveti> would like to buy a nook color to play, but kind of expensive around here
[23:24] <ka6sox> oh?
[23:24] <ka6sox> out of country I suppose
[23:25] <rsalveti> yup
[23:25] <rsalveti> brazil
[23:25] <ka6sox> appreciate the help...I'll stop by later with a report...
[23:26] <ka6sox> we ported what we call "optware"  (linux apps running on Android)
[23:26] <ka6sox> so we have the tools we need to port this.
[23:26] <ka6sox> (like chroot)
[23:27] <ka6sox> later..thanks.
[23:27] <persia> ka6sox, Good luck.
[23:28] <rsalveti> cool, later
[23:57] <tmzt> ka6sox-away: do you have a chroot version of init that works under bionic?