#ubuntu-arm 2009-02-16
 * Tscheesy_ should take a buils-system larger then the atom next time - build is 6h and going on..
<Tscheesy_> ogra: no success - and not a big log: http://pastebin.ca/1338573
<ogra> Tscheesy, well, i didnt mean the shell output when i said please keep the log ;) have you kept the actual logfile thats mentioned in the output ?
<Tscheesy> ogra: yes - but in the pastebin is also the last bit of the shell
<Tscheesy> the logfile only contained : I killed
<ogra> no, it should have the actual output from apt-get above
<Tscheesy> i guess it's the jaunty-state is braking the b uild
<Tscheesy> ogra: i always got this tiny logfile
<ogra> well, the actual error is between line 2 and line 6 in your paste ...
<ogra> way above before the stuff you captured
<Tscheesy> hmm.. really the loggs are all 15byte big.. booting up the build-sys..
<Tscheesy> line 22-31.. aren't these the packages which are breaking the build?
<ogra> yes, thats apt telling you about the packages it couldnt install ... but the info why they couldnt be installed is at the actual package install moment way above in the log
<Tscheesy> ah now i get you.. way above in the shell output..
<ogra> what you showed me is only apt's summary
<ogra> thats why i want the full log :)
<ogra> the logfile should actually have everything before apt dies
<Tscheesy> k.. needs's to output the std_out in a file?
<ogra> the output should be in /home/tscheesy/openmoko/kubuntu/build-arm-rootfs-200902151752.log
<Tscheesy> nope - only this line i mentioned - line 2
<ogra> hrm
<ogra> thats a bug in the script then, weird, it should log in parallel
<ogra> and it does that fine here
<Tscheesy> do i need tto be root? or only sudo skript is enough?
<ogra> sudo is fine
<ogra> hmm, i dont see any issue with the script
<ogra> did you modify it in any way ?
<Tscheesy> no - only options when calling it
<ogra> what was your commandline (without the password indeed)
<Tscheesy> mom..
<Tscheesy> this was without specifiing a mirror..sudo ./build-arm-rootfs --fqdn ubuntu --login kubuntu --password kubuntu --imagesize 3G --seed kubuntu-desktop
 * ogra does a testrun
<ogra> hmm, logging works fine here
<Tscheesy> hmm.. has my atom as abuild-sys any influence? - gona test the new atom-Live anyway..
<ogra> ah
<ogra> delete line 207 in the script
<Tscheesy> yes?
<ogra> it saves the log twice it seems if it dies with an error
<ogra> so it overwrites the existing log with a second one
<ogra> then you will get a proper log next run
<Tscheesy> ok.. making a new run - after setting up the sstem for a long uptime ;) but i thing kubuntu-jaunty is too instable
<ogra> fixed script uploaded
<Tscheesy_> ogra: if your interestet.. here's my recent log http://pastebin.ca/1339413 - had a quick look - dependencys..
<ogra> oh, it shouldnt log the panic :)
<ogra> hrm, it cant start hal it seems
<Tscheesy_> z5834 yes
<ogra> right, i'll do some testing tomorrow ... i will only be around very late tomorrow though
<ogra> the rest of the errors are just subsequent fallout
<Tscheesy_> easy - i'll be interestet for hints
<Tscheesy_> thanks anyway - g'n8
<rwhitby> morning
 * rwhitby leads the nslu2-linux.org project
<ogra> hey rwhitby
<rwhitby> lool: got your email - ping me when you come online and we can talk about the nslu2-linux.org project sponsoring NSLU2 hardware for the ubuntu-arm effort.
<rwhitby> ogra: g'day
<rwhitby> I must admit I was unaware of the ubuntu-arm effort until the other day - how long has it been underway and where can I see the status?
<ogra> d-i is nearly fully functional ;) still have to solve some preseeding differences between ubuntu and debian
<ogra> well, we dont have an actual status tracking page, main objective for 9.04 was to get all of the main archive building and have at least a qemu (versatile) and one image that runs on real HW
<rwhitby> ogra: if there are any outstanding questions about apex, flash layout, etc, feel free to ping me here. I'll add this channel to my bouncer list.  Does anyone object if I drop a logger in the channel (http://logs.nslu2-linux.org/livelogs/) ?
<ogra> (which currently is the nslu2 )
<ogra> i doubt anyone will object
<persia> rwhitby, The channel is currently logged to irclogs.ubuntu.com.
<ogra> which doesnt mean we mind a second logbot indeed :)
 * persia isn't objecting, but pointing out possible duplication of resources
<ogra> best resource to see the status is probably http://qa.ubuntuwire.com/ftbfs/
<rwhitby> ogra: who in the project can best use NSLU2 hardware?
<ogra> well, i have one, lool is surely the best to decide who else should get one
<ogra> we currently have two devices in the team
<rwhitby> how many core developers are on the team?
<persia> Hard to answer that one: some people chase down build failures for non-ARM reasons, and most of the people chasing ARM are also chasing other things.
<ogra> well, the canonical team cosists of five members, i cant tell much about the community, people come and go here ... there are also other teams where it proably makes sense to have the HW for test though
<ogra> *tests
<rwhitby> ogra: who is on the canonical team?
<ogra> persia, StevenK, NCommander, lool and me atm but as i said it extends beyond these people there are many others that actively work on the arm port but only in a specific area
<ogra> i also think the actual canonical team might be well enough equipped, we have access to quite powerful arm HW in the datacenter and to the builder machines, i guess getting HW to the community is more intresting, but on the other hand its hard to name specific people ... ubuntu on arm is still very young
<rwhitby> ogra: the goal of the nslu2-linux.org project is to get the nslu2 supported by major embedded distributions.  We'd achieved that for OpenEmbedded, Debian, OpenWrt, and now it seems Ubuntu should be the next on the list.
<ogra> well, we're nearly there ... i'd say i'll have a fully working d-i by end of the week
<ogra> the next build will work fine but needs a serial console since there are some remaining d-i questions before it kicks off the ssh server
<ogra> everything beyond d-i is just general packages :)
<ogra> which should generally work
<rwhitby> nod
<ogra> .. already ...
<rwhitby> how is Ubuntu handling recovery on a headless device like the nslu2?
<rwhitby> (e.g. when your disk needs an fsck on boot, and you have no serial port to type Ctrl-D on ...)
<ogra> we have all the debian tools packaged so currently the same way as debian, all docs should apply
<rwhitby> debian currently doesn't handle it at all
<ogra> oh, right
<ogra> well, thats something we can surely attack :)
<rwhitby> if your disk has a problem, you can't boot the machine to any level of functionality to debug it
<rwhitby> All other embedded distros for the nslu2 except Debian have a recovery rootfs in flash so you can ssh into that to debug rootfs on disk problems
<ogra> we have a hacked sulogin already, making that work wiht something like sshd in a special maintnance system from flash might be possible
<rwhitby> there is some work going on in debian to have the initrd running openssh or dropbear for recovery purposes.
<ogra> so make a failed fsck reboot immediately and change the cmdline to have something like a "recover" keyword or some such
<rwhitby> but it's not in Lenny as far as I know
<ogra> ah, yeah, tahts easy to achieve
<ogra> though it grows your initramfs to a certain size ...
<rwhitby> the key thing is that there is 8MB of flash on an nslu2, and after d-i finishes it's work it should install an initrd in there that can do recovery actions on an attached disk
<ogra> prob is ... we're having feature freeze by thursday
<rwhitby> ah, ok.
<rwhitby> next release then.
<ogra> so i fear 9.04 might only have basic install support
<rwhitby> BTW, Debian also have an outstanding inefficiency in the way they handle swapping of kernel and initrd.
<ogra> but we have personal package archives on launchpad ... these can provide extra functionallity so such a feature can be developed out of the release cycle
<rwhitby> they chose the wrong way to start, and now they have to swap twice instead of just letting Apex do the work for them.
<rwhitby> if you change a single setting in Apex, you no longer need to swap anything when you flash - you can use the built kernel as-is and flash it directly without needing to byteswap it
<ogra> right
<rwhitby> trouble is that they had an installed base and couldn't change it.
<ogra> the prob here is that we sync our packages from debian
<rwhitby> this only affects the kernel and initrd flashing - doesn't affect userspace packages at all
<rwhitby> (i.e. it's still armel)
<ogra> if we would work i.e. with an unswapped kernel, flash-kernel needs changes etc
<ogra> same goes for d-i
<ogra> and we'd need to build the kernel with different endianess
<rwhitby> right - ok, if you want to remain compatible with Debian at that level then you will also need to keep the inefficiency.  It's not a big deal - you just get questions from people who try and write the kernel without swapping it and it fails.
<ogra> surely something to address ... but a bit to much for 9.04 i think
<rwhitby> kernel has same endianness - it's just swapped on load by Apex rather than being pre-swapped in flash.
<ogra> no, i'm all for adressing any inefficiency :)
<rwhitby> inefficiency is probably the wrong word - it's more just clarity and complexity.
<ogra> but introducing new deltas means extra work which is rather something for 9.10
<rwhitby> if you have units in the field with 9.04 as-is, then it's just too hard to swap the scheme later.
<rwhitby> and it's not a real problem anyway, so best just to leave as-is.
<ogra> ok
<rwhitby> it's transparent to users as long as they use the correct script for flashing
<rwhitby> (which they have to do anyway due to the 16 byte header and hard-coded ramdisk offset header)
<ogra> well, its ubuntu ...
<ogra> you rarely use any scripts manually, we normally try to integrate with the packages
<ogra> or the tools
<rwhitby> right - postinst on kernel package
<ogra> i.e. if you upgrade a kernel you wont have to do any manual steps, you just call update manager
<ogra> well, a bit more than that
<ogra> but also the kenrel package postinst
<rwhitby> for those reasons, it's all transparent to users.
<ogra> righ
<ogra> t
<rwhitby> so I guess we just need to work out an apex config which gives you the flexibility you need for kernel and initramfs sizes, and is upwardly compatible for Debian if they reflash apex on an existing device.
<rwhitby> shouldn't be hard to do if it's just vma address changes
<rwhitby> (and not flash layout changes)
<rwhitby> btw, I maintain the upstream slugimage script, which packs the 8MB image from parts
<ogra> yeah, i had to change the apex VMA default address to 4MiB today ... so it doesnt overwrite parts of the kernel
<ogra> ah, cool
<rwhitby> so I have intimate knowledge of the nslu2 flash layout, and the tricks in Apex and slugimage needed for > 1MB kernels
<ogra> i'm (though coming from perl) slightly horrified by perl nowadays :)  ... to much python in my life since i work on ubuntu
<rwhitby> yeah, if I rewrote it today it would be in python
<rwhitby> 4 years ago I didn't know enough python to write slugimage
<ogra> well, it spoils you ...
<rwhitby> perl was the path of least resistance for a quick hack script which is now in use for over 4 years ...
<ogra> over the years i noticed that i returned to shell and C for stuff i want to be fast
<ogra> and keep python usually for the things that involve guis
<ogra> but i guess other ubuntu devs work differently ... i have just been burned to often during rewriting ltsp where i have to handle low specced HW a lot
<ogra> and if you realize your thin clients suddenly take 5 mins to boot while they can do the same if you write everything in C within less than a minute you start to praise python less :)
<rwhitby> indeed
<ogra> right tool for the right task ;)
<ogra> btw our kernel uses compcache by default ... so you get 48M by default on the nslu2
 * rwhitby googles compcache ...
<ogra> its a slightly insane way of providing compressed swap in ram
<ogra> but it works well :)
<ogra> despite the insanity of the idea
<rwhitby> freaky.  so what would have been in that RAM anyway is then compressed and stored in that part of the RAM as a swap space instead.
<ogra> right
<ogra> as i said, insane ...
<ogra> but works
<rwhitby> insanely devious
<rwhitby> (in a good way)
<ogra> you can easily add 20-50%
#ubuntu-arm 2009-02-17
 * lool waves
<lool> Hi rwhitby
<lool> rwhitby: So I think Oliver answered most questions; there are two things I'd like to get back to
<lool> rwhitby: The first one is on sponsoring hardware, that's great!  We usually planned to buy hardware (slugs) for ourselves a couple of weeks ago for our sprint, but a luggage with 2 of them was lost and when we soldered serial consoles on the other 3, one didn't work
<lool> So NCommander has his own NSLU2 with a non-working serial console, and NCommander and ogra received "Canonical" slugs with serial console
 * NCommander hasn't even tried to plug in either slug yet since I got home
<lool> rwhitby: So more hardware is welcome (the mobile team at canonical is NCommander, StevenK, persia, davidm, ogra and myself); however we might not spend as much time on the NSLU2 once d-i works and Ubuntu runs decently on it -- we have a lot of other boards to enable
<lool> rwhitby: Concerning changes such as a recovery sshd (I think you mentionned dropbear), this would be welcome!  we don't have big plans to work on this because this is quite specific to headless devices and our main mid-term target boards have a display; however we would love helping you or other people achieving this in Ubuntu; usually this starts by a "blueprint" where you spec the idea, this usually gets discussed at UDS, then you write the ...
<lool> ... details of the implementation steps in the spec, and proceed to implementation over the next cycle
<lool> rwhitby: Some people here are confortable with initramfs and the associated Debian/Ubuntu tools, and I'm sure will be happy to help if someone is interested in implementing that
<rwhitby> lool: saw your comments in my bouncer backlog - thanks for the details.  I'll follow up on the hardware donation question on email.
#ubuntu-arm 2009-02-18
<lool> rwhitby: What TZ are you in?  I'm in UTC+1 and I see you popup overnight; you probably see me popup during your night as well :)
<rwhitby> lool: GMT+9:30+1
<lool> rwhitby: Oh Australia?
<Dillizar> hi
<Dillizar> they told me to ask here if i can install ubuntu on AMR9 processor
<ogra> you bshuld be able to use a rootfs for arm, thought its unlikely that we have a matching kernel, what device/board is this ?
<ogra> *should
<rwhitby> lool: yep, Australia
 * Stskeeps tries to understand the sanity behind debian-setup-keyboard in 10-x11-keymap.fdi in hal
<Stskeeps> since it is a callout it is executed post evaluation by all other fdis, and only way to override is by making another callout..
<Stskeeps> and even if fdis set up correct info the callout just goes ahead and removes the values, or replaces then, not merge or the likes..
#ubuntu-arm 2009-02-19
<lool> rwhitby: So AIUI, NSLU2 images will now boot into the installer, but they fail due to OOM; our kernel seems to be too large
<lool> rwhitby: It might be that we need to drop stuff from our large kernel
<lool> rwhitby: ogra will be working on this, but I suggested he gets in touch with you; the bug to track this issue is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331510
<lool> rwhitby: BTW daily images are at http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/ixp4xx/netboot/
<lool> kernel + initrd for netboot into Ubuntu's d-i, and flashable image
<lool> netboot will likely not work though
<ogra> rwhitby, though for now i'll just try to adjust our kernel to the debian lenny config
<ogra> lool, well, it works up to some point
<lool> ogra: Can you use an initrd with redboot?
<lool> I mean a remote initrd
<ogra> on the nslu2 ?
<ogra> i dont think so
<lool> I fear redboot sets the atag to what it expects
<lool> ogra: Right, so the netboot image is relatively useless
<ogra> ??
<ogra> the netboot image uses apex by default
<lool> ogra: You mean the firmware image
<ogra> oh, you mean the split one
<lool> Yes
<ogra> heh, yeah, i doubt that works for anyone, but you can for example modify the initrd.gz and roll your own firmware image with slugimage
<ogra> so it has some use, even though its a massive corner case ...
<ogra> like in the outer tip of the corner :)
<lool> Yeah, I wanted to underline that the kernel and initrd are mostly useless as they stand; I don't even know whether's it the apex initrd or the one which should be wrapped in an apex initrd
<ogra> the one that should be wrapped
<ogra> its plain
<lool> Right, so one has to do some devio + apex dance to rebuild a firmware, not trivial really
<ogra> not to hard either if you have the script
<ogra> :)
<ogra> i sould probably dump that on the wiki
<ogra> though i have bigger probs to solve atm
<ogra> than to add hacks for corner cases
<lool> ogra: This was just a note for rwhitby
<ogra> yep
<ogra> i dont think cjwatson uploaded the d-i with the fixes for the kbd qeustions yet btw
<ogra> might only fully work with next d-i upload
<lool> That's minor though
<lool> ogra: (You mean the fact that you're asked for console setup while you're not using a keyboard right?)
<ogra> yes, before ssh starts
<ogra> so its useless without serial port
<ogra> since it waits for input on the kbd questions
<ogra> the next upload rips out all kbd stuff from d-i
<lool> Great
<ogra> i decided its better than to preseed it ...
<ogra> saves some ram for the keymaps
<ogra> and its unlikely people use slugs as desktop systems i bet :)
#ubuntu-arm 2009-02-20
<rwhitby> lool: because debian chose the wrong swapping, you do need to do both devio and apex dance.  If they had chosen not to swap and let apex do it, then the devio would not be required.
#ubuntu-arm 2009-02-21
<goshawk> hi
<Meizirkki> hey, goshawk
<goshawk> is there any possibility to run ubuntu on armv4?
<goshawk> i read that the ubuntu arm version will be for armv5
<goshawk> but there are devices, like the well known Openmoko Freerunner, that uses armv4
<ogra> the ubuntu port is actually focused on armv7 ...
<ogra> thought since it is based on debian it inherits armv5 compatibility by default
<ogra> there might be some v7 optimized libs soon though
<ogra> v4 isnt actually in focus
<goshawk> wait.. as long as i know debian focuses on armv4, in fact there is debian running or Freerunner.
<ogra> right, but ubuntus port is based on the armv5 port
<ogra> and even that is a compromise
<ogra> there are currently performance tests going on about v7 vs v5 optimized builds
<ogra> you lose a lot if you are building for armv4 but target v7
<goshawk> but can i still run the code?
<goshawk> i don't care performances
<ogra> we dont build for armv5
<ogra> as i said above
<goshawk> ok
<ogra> i doubt armv5 compiled binaries run right away on armv4
<goshawk> oki
<goshawk> thanks :)
#ubuntu-arm 2010-02-22
<5EXAAEK4A> Hello ppl , Has any one tried building the ubuntu rootfs from sources ?
<persia> bandwidthcrunch: I don't know of any recent efforts to reconstruct it, but it's exclusively generated from uploaded sources.
<bandwidthcrunch> Wanted to be able to regenerate it from uploaded sources at my end persia. Was wondering if there was a way i could rebuild the jaunty/karmic for armel without using rootstock
<persia> Well, there's two steps involved.
<persia> The first is converting sources to binaries, and the second assembling binaries into an image.
<persia> Do you need to do both, or just one?
<bandwidthcrunch> I wanted both . A build process like pbuilder (targetting armel) and the binaries in a rootfs populated automiatically
<persia> OK.
<persia> So the main issue is the bootstrap.
<bandwidthcrunch> Wanted to comeup with a distribution targetting custom arm hardware.
<persia> I don't think there's an easy way to do it.
<persia> You'd probably want to build your toolchain against Ubuntu, and then rebuild Ubuntu against that toolchain.
<persia> Which requires setting up your own archive environment (dak, soyuz, etc.)
<persia> The pbuilder from lucid works on armel (either native or emulated) just fine, but won't scale to what you want.
<persia> Once you have that, just use your rebuilt rootstock.
<persia> Unless you have mountains of hardware, this process will probably take 3-4 months at a minimum.
<bandwidthcrunch> Ok. and what are dak and soyuz ?
<persia> dak is the tool used to manage the Debian archive.  soyuz is the tool used to manage the Ubuntu archive.
<bandwidthcrunch> i do have atleast 6 600mhz arm devices
<persia> Getting it done in 4 months is optimistic then.
<bandwidthcrunch> I will be getting grey hair by then :) . is there anyway to achieve the same on cross platform. Build it on i386 ?
<persia> You can do it with emulated builds, but it's still a few months.
<persia> (again, unless you have mountains of hardware)
<persia> There are heaps of packages that don't cross-compile well, so trying to do cross-compilation would be it's own sort of pain.
<bandwidthcrunch> Thanks persia. I dont see a way out of this one. Let me check up if openembedded guys have gotten a way of integrating ubuntu sources and churning it out
<persia> bandwidthcrunch: I can't imagine you really need to do this.
<persia> Simply because there chance that there's a good reason to provide 20,000 rebuilt binaries is vanishingly low.
<persia> s/there/the/
<bandwidthcrunch> Sometimes  i can wait for ubuntu to keep releasing armel builds but for for certain applications i will need source control.
<bandwidthcrunch> Maybe i can just build those on ubuntu servers ?
<persia> Do you need modified sources, or sources built over a modified toolchain?
<bandwidthcrunch> Both . example openoffice doesnt fit well over my 7inch screen. need to hack the sources to trim it to a window and have our own toolchain bake it
<bandwidthcrunch> ideally have our toolchain build all the packages but again as u mention it is going to take a while doing that
<persia> OK.  The application changes are easy.  The toolchain is more fussy.  Why do you need a special toolchain?
<persia> On a separate note, the problem with openoffice isn't that your screen is 7", it's that your screen doesn't have enough pixels :)
<bandwidthcrunch> Fr application developers we need to provide an SDK with a toolchain
<persia> Can't you just tell the application developers to use Ubuntu and pbuilder?
<persia> (or sbuild : doesn't really matter)
<bandwidthcrunch> Would they be able to do that for armel ? create applications without me passing them my rootfs and a toolchain ?
<persia> Yes.
<persia> Well, under some constraints.
<persia> So, let's assume you start from the Ubuntu archives.
<persia> Then your developers either run pbuilder on native hardware or run pbuilder with emulation on foreign hardware.
<persia> That's how we develop Ubuntu today.  I don't see any reason that someone couldn't use the same procedure elsewhere
<bandwidthcrunch> Is there a wiki somewhere where i can readup on howto go about the same ?
<persia> (and, honestly, we don't always do the build on armel if it's not an arch-specific thing, and just trust the archive to build the armel binary from the single upload of source)
<persia> !pbuilder
<ubot4> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<persia> You'd need to be running lucid to get the emulated pbuilder working, but that is created by running `pbuilder-dist lucid armel create` on i386 or amd64.
<persia> (assuming ubuntu-dev-tools to be installed).
<persia> So, the developers can do their testing / development using a combination of native i386/amd64, native armel, and emulated armel for development and testing (depending on the specific feature being changed).
<bandwidthcrunch> I have most of the requirements , let me take it out for a spin and see what comes up ... I have 64bit lucid and a core i7.
<persia> Where you find issues, you can modify sources.  You can put the sources either in a PPA or in some other archive somewhere.
<persia> If you put the modified sources in a PPA, you'll need to set up some armel devices to track the PPA, pull any new sources, build them, and stick the results somewhre.
<persia> (because PPAs don't build armel).
<persia> If you use some other archive, you'll need to build for each architecture you want to work.
<persia> You'll probably want to put the entries for your modified packages in the sources.list for your pbuilder chroots and test devices.
<bandwidthcrunch> what about thr toolchain ? How does pbuilder set that up ?
<persia> It just downloads from the archives listed in sources.list
<persia> So if you upload a modified toolchain, it uses that.
<persia> But be careful: if you change the ABI, you end up needing to rebuild everything (which takes months).
<bandwidthcrunch>  pbuilder-dist lucid armel create
<bandwidthcrunch> Error: Â«armelÂ» is not a recognized argument.
<bandwidthcrunch> Please use one of those: create, update, build, clean, login, execute
<persia> You may have to modify rootstock to use your archive, but that modified rootstock would let you build rootfs images.
<persia> This is lucid?
<bandwidthcrunch> It is karmic
<bandwidthcrunch> i will have to uprage it i guess
<bandwidthcrunch> Let me get on with it..
<persia> Yeah.  I didn't add the support to build emulated chroots until a few weeks ago, and the emulation stuff still ad lots of issues until near the end of last week.
<persia> so you'll be working on the edge, but the idea is to create an environment so that nobody needs to traffic in big SDKs anymore, if they use Ubuntu.
<bandwidthcrunch> Thanks persia, makes a lot of sense now..
<persia> bandwidthcrunch: If this works for you, and you end up with patches you think would be good for general application, please file them in launchpad.
<persia> We'd really appreciate the help in making Ubuntu strong (and it reduces your future effort in merging your patches against the next release).
<bandwidthcrunch> Done persia. I will push them to lauchpad
<persia> Thanks :)
<bandwidthcrunch> Appreciate the help. Will keep us posted on the happenings
<persia> I don't know if you're planning to use bzr, but there's been a lot of work by the Distributed Development team to try to make working with Ubuntu sources in bzr extra easy.
<persia> https://wiki.ubuntu.com/DistributedDevelopment has some links that might be interesting.
<persia> (Depends on your team size, facility with operating debian-style archives, etc.)
<bandwidthcrunch> I tried using bzr but that was a month two back .. Let me check them up..
<persia> There's no requirement to use bzr, but if you have a large team that plans to cooperate on a small number of packages, it may be helpful.
<bandwidthcrunch> Ahh ok. We have a small team so i dont think we will really be more of a bzr ppl for the time being
<persia> Fair enough.  I just wanted to make sure you knew about the variety of tools available.
<asac> heyho folks!
<persia> Selfishly, I'd prefer to see your team working with Ubuntu and using Ubuntu tools, rather than building a derivative distribution :)
<persia> (although I recognise that if you are targeting some specific device, there are probably commercial requirements that require some variation from the set of packages that have general application)
<bandwidthcrunch> I agree in the uniformity concept rather than have fragmentations
<bandwidthcrunch> Ours is a custom device and has a bit of changes that come in for the platfrom but otherwise we like sticking to vanilla ubuntu
<persia> Excellent.
<persia> Note that there are some restrictions on trademark usage.  I forget the precise phrasing, but it comes down to not being able to call the OS "Ubuntu" if it has modified sources, especially in product marketing and branding, etc.
<persia> I believe "based on Ubuntu" or similar is accepted.
<persia> But I'm not qualified to give precise advice: you'd want to check with your counsel.
<ynezz> Where can I find modules for vmlinuz-2.6.31-rc3versatile1-cortex-a8 kernel? Seems like I need modules http://ynezz.true.cz/qemu.png
<persia> From where did you get the kernel?
<ynezz> I'm following steps here https://wiki.edubuntu.org/ARM/BuildArmPackages
<ynezz> it's this URL http://people.canonical.com/~ogra//arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8
<lool> ynezz: The modules aren't available
<lool> ynezz: I recommend you use the lucid versatile kernel instead
<lool> ynezz: http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.32-14-versatile_2.6.32-14.20_armel.deb
<lool> ynezz: Unpack this with dpkg-deb -x, and you'll get a boot/vmlinuz and a lib/modules tree
<asac> http://code.activestate.com/recipes/146306/
<ynezz> lool: thanks, trying now
<asac> JamieBennett: ^^ (thats httplib though)
<persia> ynezz: From where did you find instructions to use that kernel?  I'd like to replace that documentation with what lool has just supplied.
<ynezz> persia: that edubuntu link
<lool> persia: I guess that's rootstock doc
<lool> Did rootstock switch to pulling the lucid kernel now?
<ynezz> persia: "If development machine is running Karmic"
<asac> odd ... isnt there  a soup python binding in the archive?
<ynezz> persia: here https://wiki.edubuntu.org/ARM/BuildArmPackages
<persia> ynezz: Found it.  Thanks.
<persia> lool: Do we have a good kernel for running karmic, or should one use the lucid kernel there as well?
<lool> Gah who copied that page
<persia> copied?
<lool> Yeah
<persia> from where to where?
<persia> wiki.*buntu.com are just different themes on the same content (or so it is supposed to be)
<lool> I know
<lool> :)
<persia> Oh, heh :)
<lool> cooloney: Heya
<lool> cooloney: Would you have some minutes for me?
<hrw> morning
<lool> cooloney: I'd like to discuss two things related to qemu/versatile kernels with you
<lool> cooloney: First is: did you manage to find out what's breaking kexec?
<lool> hrw: morning
<lool> cooloney: The second is: I'm having issues with initramfses -- they don't work in qemu versatile, only initrds do; would you be able to help with that?
<hrw> lool: versatile does not support >armv5te iirc
<lool> hrw: We patched that
<hrw> kernel simple patch? I had such one in old Poky days to run armv6 in qemu
<lool> It works with qemu cortex a8 emulation in our case
<lool> hrw: Yup, just basically select v7 instead of select arm11something
<hrw> good choice
<hrw> versatile is best arm qemu target
<lool> I'm not sure anymore
<hrw> scsi, usb, video, network
<lool> network, usb and network are all related to PCI support IIRC
<hrw> yep
<hrw> and usb gives you working touchscreen emulation
<lool> And actually realview versatile has gained PCI support upstream and... cortex a9!
<lool> So I have a secret plan to move to this if time permits and people agree with it -- but it's secret, don't tell anyone on #ubuntu-arm
<hrw> ;D
<lool> Another good target seems to be omap3, but it's based on another qemu tree and probably works best with the linux-omap tree
<hrw> yep
<hrw> OpenEmbedded linux-omap recipes have lot of good patches added to get it better
<ogra> yeah
<ogra> angstrom too iirc
<ogra> (for userspace)
<hrw> ogra: angstrom uses OE
<ogra> i know
<ogra> i was referring to userspace :)
<hrw> anyway many of our (OE) patches came from Debian or Gentoo
<lool> hrw: So you're a poky and OE developer?
<hrw> some from other distros etc
<hrw> lool: yes, I am
<hrw> nearly 6 years in OE
<ogra> debian wont help with v7 or thumb2 specific stuff though
<lool> hrw: Dump OE and come over here!
<ogra> i would expect to find more intresting stuff for that in OE than in debian :)
<ynezz> lool: hm, it boots now, but I can't get after "mountall: Could not connect to Plymouth"
<hrw> lool: do you give free devboards?
<lool> ynezz: That's just a warning
<hrw> :D
<ogra> ynezz, serial ?
<lool> ynezz: How did you create your root fs?
<ynezz> rootstock
<ogra> do you use a monitor or a serial console ?
<lool> hrw: If you sign to help us for the next 6 years, I'll ship you one of mine!
<ogra> note that for serial you need to use the --serial option in rootstock else you wont get a login prompt
<hrw> ogra: you use monitors?
<ynezz> ogra: ah, I'm new to qemu, didn't know about it :)
<hrw> I do not remember when last time I connected beagleboard to lcd
<ogra> hrw, we build netbook live images, indeed i do :)
<ynezz> ogra: was following probably wrong wiki page...
<hrw> sim.one was never conencted to screen even ;D
<ogra> ynezz, it might be, yeah, the above page you pasted is very confusing
<cooloney> lool: yeah, we found ARMv7 does not support kexec as well as others
<ogra> i wonder why that was duplicated from BuildARMRootfs
<cooloney> lool: we got some patches from omap maintainer
<ogra> err
<ogra> RootfsFromScratch rather :)
<cooloney> lool: eric tested them on dove, i plan to test them soon on imx51 and versatile
<persia> Does anyone have a recommendation for a TFTP server?
 * persia sees both atftpd and tftpd and is unsure which to use
<ogra> tptpd-hpa
<lool> cooloney: Ok, thanks
<ogra> *tf
<persia> ogra: Heh.  Neither of the ones I thought.  Thanks :)
<ogra> heh
<lool> persia: I had an experience where both atftpd and tftpd failed working in a specific case and tftpd-hpa worked
<cooloney> lool: so for the initramfs, is there any bug tracker for that.
<ogra> its the one used in ltsp ... the one thats maintained most in ubuntu
<ynezz> ogra: seems like that eLinux page is more up-to-date then those on Ubuntu :)
<cooloney> lool: i can take a look at that
<lool> cooloney: LP #524893
<ubot4> Launchpad bug 524893 in linux (Ubuntu) "Can't boot initramfses (affects: 1)" [Undecided,New] https://launchpad.net/bugs/524893
<ogra> persia, another good choice seems to be dnsmasq
<lool> Hmm right, never tried dnsmasq, but that's certainly a good tool -- it's used in libvirt to provide dhcp and DNS proxies I think
<persia> ogra: I think dnsmasq is more than I need: I'm just trying to work around the lack of a soldering iron right now.
<ogra> yeah, it does everything you need for a netboot
<ogra> dhcp, dns, tftp
<hrw> dnsmasq is nice
<lool> cooloney: So I'm not sure whether it's a qemu or versatile kernel bug
<ogra> and can work as proxy dhcp ... so you dont get races between dhcp servers if you have multiple ones and do netboot
<lool> cooloney: Do you manage to get an initramfs to unpack on real boards?
<cooloney> lool: no problem, assigned to me, will take a look,
<lool> cooloney: Note that "junk in compressed archive" appears twice in the boot source code
<cooloney> lool: i think we are using initramfs in imx51 board for a long time,
<lool> cooloney: Note that we have CONFIG_CRAMFS=y in imx51
<lool> cooloney: So we might be using initrd instead, without noticing
<lool> cooloney: If you have a recent dmesg, I could tell
<lool> Anybody has a recent non-qemu dmesg?
<lool> (with an initrd)
<cooloney> lool: hold on
<lool> dmesg | grep -i initramfs or something
<cooloney> lool: http://pastebin.ubuntu.com/381535/
<cooloney> roc@babbage:~$ dmesg | grep -i initramfs
<cooloney> Trying to unpack rootfs image as initramfs...
<lool> cooloney: And the next line?
<lool> cooloney: grep -A2 -i initramfs ;-)
<lool> Also, grep for initrd, that might say: Freeing initrd memory: 8924k freed; that's also interesting, I'm not sure that's done for non-initramfs
<lool> the dmesg in http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1981259.html looks like it's working correctly (supports initramfs), so it's not arm specific, either versatile or qemu
<lool> http://launchpadlibrarian.net/33211547/dmesg has another one
<lool> cooloney: So I would suspect the qemu initrd loader is broken   :-/
<lool> cooloney: it'd be nice to enable CONFIG_CRAMFS=y in the mean time
<cooloney> lool: right, did you test a kernel with CONFIG_CRAMFS=y before?
<cooloney> lool: for versatile,
<ogra> lool, thats weird, i know it works in debian
<ogra> vagrantc does arm based thin client development in qemu, initramfs support is essential for ltsp
<lool> cooloney: I know CONFIG_CRAMFS=y works
<ogra> so it must have regressed between our and debians qemu version
<lool> cooloney: I tested a Debian kernel
<lool> ogra: Was it initramfs or initrd?
<ogra> initramfs
<ogra> ltsp doesnt use initrd
<lool> Note that it's the same format
<ogra> and i know for sure he regulary tests client setups
<lool> ogra: Was this on ARM?
<ogra> yes
<lool> ogra: How can he be sure that it didn't pick up an initrd?
<ogra> he improves my proof of concept code for arm thin clients atm
<ogra> he picks up whatever update-initramfs generates
<lool> ogra: That will work as an initrd as well
<ogra> i will ask him if he gets up what exactly he uses to test
<ogra> (he's a portlander :) )
<lool> cooloney: Do you have a qemu tree?
<cooloney> lool: sorry, no
<cooloney> lool: i plan to clone one and test for a while
<cooloney> heh
<lool> cooloney: Either clone upstream or apt-get source qemu-kvm
<lool> cooloney: The relevant file is hw/arm_boot.c
<lool> It works the ATAG stuff and loads the initrd in RAM
<cooloney> lool: ok, no problem.
<lool> cooloney: http://ftp.debian.org/debian/dists/squeeze/main/installer-armel/current/images/versatile/netboot/ has a kernel + initrd with v5 kernel + v4 binaries which have CONFIG_CRAMFS=y along others and load properly in qemu with -initrd
<lool> cooloney: Do you want me to send a patch for the versatile kernel configs?
<cooloney> lool: yes, please.
<cooloney> lool: i can test that on my side.
<cooloney> guys, have to head out for dinner
<cooloney> talk to you later
<lool> Chers
<lool> Cheers
<lool> cooloney: sent
<persia> ogra: So, tftpd-hpa didn't actually meet my need (because the documentation claiming that when DHCP failed, the device would use a specific address and *then* use TFTP didn't work), so I'm trying dnsmasq.  This seems to have decided to only work with my virbr interfaces, but I'm having trouble finding where that is defined.  Any ideas on how to add eth0 there?
<ogra> lool, hmm, i thought all filesystems that can possibly be used for booting are supposed to be builtin not modules nowadays
 * ogra just notes that there are a lot CONFIG_CRAMFS=m for non armel in lool's patch
<ogra> persia, can you start from the ground up ? what exactly are you doing ? :)
<ogra> and whats your exact setup up to now
<persia> I'm trying to get my kurobox working again.  I last used it for an abortive install of jaunty the day the orion5x kernel was dropped.
<ogra> whats a kurobox ?
<persia> It appears that the current state of the device is that it's running the default firmware with a modified password.
<persia> http://buffalo.nas-central.org/wiki/KuroBoxPro
<lool> ogra: That's because CONFIG_CRAMFS=m was the default on all arches
<ogra> lool, ah
<ogra> i was just wondering ...
<lool> So it was in the common config and is moving up in per-arch configs
<ogra> i might even not be up to date wrt module/vs builtin
<lool> persia: Don't add eth0 to virbr0
<persia> DHCP does work, and I should be able to TFTP boot.  I ask here not because Ubuntu supports the target, but because I figured that folk here would have more experience with host/client connections than in other channels.
<ogra> but i thought that was the decision for lucid
<lool> persia: It's meant to be a proxy interface
<lool> It's only bridging your vms together
<persia> lool: My issue is that dnsmasq is *only* listening on virbr0, and I only want it to listen on eth0.
<lool> and a place for dnsmasq to listen too
<lool> persia: Is it the dnsmasq you launched?
 * persia doesn't care about vms at the moment, as real hardware is the current toy
<lool> persia: Cause libvirt is spawning one with a non-default config too by default
<persia> It started from /etc/init.d
<persia> But I had libvirt installed and didn't have dnsmasq installed before.
 * persia is now confused.
<lool> persia: libvirt-bin depends dnsmasq-base
 * ogra doesnt get why you have libvirt at all 
<persia> Aha!  So I previously must have had dnsmasq-base and just installed dnsmasq.
<ogra> dnsmasq works without it
<persia> ogra: I have libvirt for entirely different reasons, completely unrelated to the current project.
<lool> persia: dnsmasq-base has the binaries
<ogra> right
<persia> So the dnsmasq I see in ps is really the libvirt one, and I need to do something to create a default one?
<lool> persia: In theory, dnsmasq listen on all interfaces by default, but you can set interface=eth0
<lool> persia: Yes
<lool> Probably you see something like:
<lool> nobody    1342  0.0  0.0  21404   888 ?        S    Feb20   0:00 dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file=  --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253
<persia> Right.
<lool> that's the libvirt one
<persia> And I'm unsure why I only see that one, because /etc/default/dnsmasq has "ENABLED=1"
<lool> persia: Did it actually invoke-rc.d dnsmasq start upon install?
<persia> (and that, like the init script, comes from dnsmasq, rather than dnsmasq-base)
<lool> Just restart it
<persia> Aha!  "dnsmasq: failed to create listening socket: Address already in use"
<lool> persia: That's because it tries listening on virbr0 too I guess
<persia> That's my thought.
<lool> persia: Try listing interface=eth0 explicitly, that might help
<persia> I suspect we ought silence that :)
<lool> Silence it?
<ogra> no you shouldnt
<lool> persia: except-interface=
<persia> Patch the default configuration to ignore virbr by default.
<persia> Right.
<ogra> but it should report the interface its failing on like dhcpd does
<lool> persia: Yup
<persia> Actually, libvirt-bin should probably drop something in /etc/dnsmasq.d to achieve that.
 * persia files a bug
<lool> persia: there's a catch: it will override any user-set except-interface, so it might actually break things to add this
<lool> I prefer the approach in theory, but in practice it might work better to patch the default config
<lool> So if someone had except-interface=virbr0,important-interface it will break badly
<persia> Except that breaks user configurations where virbr is not libvirt managed.
<lool> I find it less likely
<persia> except-interface isn't additive if multiply defined?
<lool> persia: The command-line flags are actually additive, I'm not sure about the .conf
<persia> I think it is, from what documentation I'm finding
 * persia looks harder before pressing "submit" on the bug
<persia> bug #231060 seems to imply that ttx thinks it ought get sorted with adding a file.
<ubot4> Launchpad bug 231060 in libvirt (Ubuntu) (and 1 other project) "packages dnsmasq and libvirt-bin conflict with each other (dups: 2)" [Low,Triaged] https://launchpad.net/bugs/231060
<ogra> NCommander, dyfet, are you guys working on the FTBFS list ? it seems a bunch of new stuff showed up there over the weekend and A3 is ahead
<lool> persia: Ok, it's the same parsing for opts on cmdline and opts in the conffile
<lool> persia: So additive as well, my bad
<persia> No, it's better we check :)
<lool> (one_file() calls one_opt() and getopt ultimately calls one_opt())
<persia> Right.
<NCommander> ogra: looks like the breakage took place in universe/multiverse. Main doesn't look that much different thenI remember, but will investigate
<ogra> NCommander, some indicator things and keyring stuff
<ogra> is what i see on a first glance
<NCommander> ugh
<ogra> and pulse
<ogra> please priorize work on that together with dyfet we need these packages for A3
<persia> pulse managed to segfault in a shell script.
<persia> I believe StevenK was looking at it with crimsun
 * persia remains unsure how to segfault a shell script
<ogra> err, sorry, i have given back pulse this morning
<ogra> it built fine, ignore that :)
<ogra> persia, thats the typical buildd hiccup we see randomly ...
<persia> segfaults in bash scripts?
<ogra> or anywhere else
<persia> If you can ever reproduce locally, I want a stacktrace.
<ogra> you cant reproduce it locally
<ogra> thats the point
<ogra> its a buildd HW issue
<ogra> imho
<persia> Ugh.
 * persia wants nice reliable retail hardware in the DC.
<ogra> ++
<ogra> we'll get there
<ogra> probably even before end of the cycle, who knows
<persia> lool: You seem to have commented usefully in the bug before I finished dealing with the me too link and duplicate fixups.
<persia> lool: Are you adding such a snippet, or shall I?
<persia> (ttx already wrote it, in comment 7)
<lool> persia: Do feel free to add it
<lool> persia: I didn't think through about bind-interfaces
<lool> It's not clear to me why libvirt doesn't pass a list of interfaces and doesn't set bind-interfaces too
<lool> Actually it does set --bind-interfaces, sorry
<persia> lool: I just didn't want to duplicate work :)  I'll check with ttx about it, etc. and get it fixed.
<lool> persia: I would personally wonder why libvirt-bin does --except-interface lo instead of --interface x,y,z
<persia> lool: I suspect it's to catch all of virbr*, but given that it targets a specific address, it's a good question.
<persia> Thanks for the hints: I'll see what can be sorted.
<lool> It might target multiple devices,not sure
<ynezz> ogra: still fighting with that serial console in qemu, I have /etc/init/ttyS2.conf in my image (added by rootstock, --serial ttyS2 option), then I have tried to put "console=ttyS2,115200n8" in qemu kernel boot option and I should have console in qemu monitor mode ctrl+alt+3 right?
<ogra> if you use qemu the tty has a different name
<ogra> ttyAMA0 or some such
<ynezz> ah
<ogra> you should see the actual name in the boot output of the kernel
<ynezz> no, I don't have it backlog
<ynezz> but it's working now, thanks
<ogra> btw, didnt you say you wanted to build packages ?
<ynezz> yes
<ogra> using qemu-arm-static for that is wasy less effort and surely a little faster than running a full VM
<ogra> *way
<ogra> though the VM is indeed best for testing the results
<ynezz> I've never used qemu before and seems, so exploring it and learning how it's working together
<ynezz> s/and seems//g
<ogra> qemu-arm-static just enables your x86 machine to execute armel binaries so you can create a chroot to build your packages inside
<ynezz> ah
 * ogra glares at   288 syslog    20   0 39196 6216  820 S 85.4  1.3   7:12.27 rsyslogd on his babbage board
<ogra> does anyone else see rsyslogd eating all CPU ?
<lool> ogra: Sounds like your kernel is lacking the relevant options
<lool> ogra: lp #523468
<ubot4> Launchpad bug 523468 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd gives 100%CPU (dup-of: 523610)" [High,Triaged] https://launchpad.net/bugs/523468
<ogra> there are kernel options syslog uses now ?
<ubot4> Launchpad bug 523610 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd spins CPU on older kernels (affects: 34) (dups: 4)" [High,Triaged] https://launchpad.net/bugs/523610
<ogra> ah
<ogra> apw, ^^^ i see that one with your imx51 testkernel
<asac> ogra: i see that on the normal kernel too
<asac> its everywhere
<ogra> i dont see it on my laptop
<ogra> 2.6.32-13-generic-pae
<ogra> no messages in kern.log
<ogra> well, at least gtk isnt broken on armel ...
<ogra> unlike on i386
<ogra> my babbage is actually faster than my laptop atm when i use the new gtk libs :)
<hrw> ogra: some of my devices are faster then my 2000y pc
<ogra> rinning the same desktop ? :)
<ogra> *running
<hrw> ogra: I keep my devices headless most of time
<ogra> right
<ogra> thats different :)
<hrw> ogra: and in 2000 I used gnome 1.4, then wmaker+roxfiler
<ogra> we rarely do headless suff except for building packages here
<ogra> one day we'll support the server flavour though ...
<ogra> that might change it
<hrw> ogra: one day I will connect video cables
<ogra> heh
<ogra> bah, pybootchartgui crashes again
<ogra>   File "/usr/lib/pymodules/python2.6/pybootchartgui/parsing.py", line 78, in _parse_proc_ps_log
<ogra>     userCpu, sysCpu, stime= int(tokens[13+offset]), int(tokens[14+offset]), int(tokens[21+offset])
<ogra> IndexError: list index out of range
<ogra> GRRR !
<ogra> that was fixed already !
 * persia does headless stuff all the time, but only with ubuntu-minimal+pbuilder, which isn't actually useful for doing that much
<ogra> gah, who ever wrote pybootchartgui needs a training in python indendation
<dmart> asac: Hi... were you going to send out a reminder on the ubuntu-mobile list about the proposed IRC sprint session on Thursday?
<lool> dmart: Heya
<lool> dmart: Thanks for following on the x264 NEON stuff; do you think you could write the NEON runtime detection in x264 based on /proc/self/auxv instead of SIGILL?
<lool> dmart: I poked on #x264dev, and the person I was in contact with was receptive
<dmart> I hadn't got that far yet, but I'll have a go.  It didn't look too difficult.
<lool> dmart: http://paste.ubuntu.com/381628/
<dmart> x264 does at least seem to run on my Babbage3 (but encoding /dev/zero is not a great test :P)
<lool> dmart: They do care to have a portable fallback, so you probably want to keep SIGILL on !linux
<lool> I have to say I have little sympathy for spending extra cycles supporting chips where NEON is plain broken in hardware with no possible kernel workaround, so I would personally not bother supporting that
<lool> But that should work by default if you move to auxv
<lool> dmart: The ARM x264 maintainer upstream if Yuvi
<suihkulokki> /proc/self/auxv bad. why not read /proc/cpuinfo ?
<lool> suihkulokki: Why is /proc/self/auxv bad?
<dmart> cpuinfo: contents more volatile than auxv, and also requires parsing
<lool> Yeah
<dmart> lool: Agreed--- it shouldn't be too much work to have both.
<lool> dmart: Thanks
<suihkulokki> qemu linux-user :>
<lool> dmart: sirestart is reviewing my x264 packaging changes; I think they should be enough for us for now, modulo the SIGILL stuff
<lool> suihkulokki: So linux-user emulates cpuinfo now?
<apw> ogra, what we seeing there?
<ogra> ApOgEE, rsyslogd eating up my CPU
<ogra> but apparently thats not armel specific (though i dont see it on my -pae kernel heer on my laptop)
<apw> ogra, depends if they have fixed that bug with rsyslogd to not use dd ...
<ogra> weird
 * ogra checks versions on armel vs x86
<ogra> same versions
<apw> yeah i think we may be being hurt by the fix for bug #517773
<ubot4> Launchpad bug 517773 in rsyslog (Ubuntu Lucid) (and 1 other project) "Drop the dd process (affects: 4)" [Medium,Fix released] https://launchpad.net/bugs/517773
<apw> let me confirm that ...
<apw> ogra, ok it looks like they have applied the fix for that to userspace, that means that the kernel requires a fix which is only in the .32 kernels; distro and mvl-dove both have it, but not imx51 ... i'm looking at a backport now, should have a test kernel for you shortly ...
<ogra> ah, sweet
<apw> fingers crossed that is the cause ... its building now
<ogra> did i say already, you rock !!
<dmart> asac, are patches we add against e.g., mono automatically pinged to Debian?
<ogra> nope
<asac> dmart: no. debian will complain ;)
<asac> dmart: but we are trying to push all patches to them
<ogra> we need to file bugs
<lool> apw, ogra: Right that's what I suspected, kernel fix missing; thanks for looking into it
<asac> dmart: at best our patch would work for them
<ogra> lool, thanks for saving me to search LP for the issue :)
<apw> versions skew sucks ... at least the dove kernels get these fixes for free via rebase
<apw> makes life > 2x harder
<lool> dmart: usually, we either send them on the spot or during merges (beginning of a cycle), sometimes we send them straight to upstream, that works well too
 * apw sorly wishes that arm kernels would build as fast on the buildds as they do on his hoover
<ogra> just send your hoover to the DC ?
<lool> apw: True; TBH I'm slightly worried that we're building our userspace against 2.6.32 headers and then running a 2.6.31 kernel on top
<ogra> lool, we had plenty discussions about that already :)
<lool> e.g. eglibc picked up pselect() support thanks to it landing upstream, and that exposed the fact that it was missing in qemu -- not a big deal, but it's also missing in linux-fsl-imx51 for instance
<ogra> (sprint discussions)
<apw> yeah ... its not in the least bit idea
<apw> i wish the arm vendors would just to the sensible thing, and track mainline
<lool> apw: Marvell isn't too bad here though
<ogra> lool, cooloney does what he can to backport features we find
<hrw> apw: ha! who would not...
<ogra> but what we dont find wont be backported
<apw> lool, indeed they are most enlightened
<hrw> I have device here with .27.2 kernel as production one
<apw> i only have to rebase their kernel and i don't hit this issue
<ogra> hrw, would have issues with recent ubuntu :)
<ogra> our userspace often ties deeply into kernel features
<dmart> asac: not sure if you saw my message earlier--- was someone going to send out a reminder about the IRC porting sprint on Thursday?
<lool> ogra: similarly with epoll and plymouth
<lool> Did you folks backport epoll_create(0 and friends to linux-fsl-imx51?
<lool> *epoll_create()
<lool> dmart: Sprinting on Thursday sounds bad
<lool> A3 this Thursday
<lool> We will likely be stuck in the European morning
<apw> but everything we are doing has to be done by tommorrow
<ogra> lool, i dont think so, but i dont see the issue i see in qemu on imx51
<apw> so one would expect anyone not on the release team to be lying by the pool (obviously)
<lool> ogra: It might have been part of the pselect support patch
<ogra> ah
<asac> dmart: yes, i have to
<apw> i thought pselect was one of those which was dynamicaly selected at runtime
<dmart> Sounds from lool that it might be better to move it?
<ogra> apw, not generally, but just for A3, no ? i mean kernel freeze is still a bit or not ?
<apw> kernel freeze is march the 11th officially, which means i need it by the 8th
<lool> oh yeah kernel freeze is march 11
<ogra> so there is still a week past A3
<ogra> for bad stuff we identify
<ogra> and beyond that if its a bug it should still be fixable post-freeze, no ?
<lool> Hmm I don't see pselect support in fsl-imx51, am I reading this wrong?
<apw> after freeze we move to an sru style bug fix policy
<ogra> uuh
<apw> lool i don't think i expect it to be there no
<apw> i thought it was fakes (badly) in libc
<ogra> yes
<apw> you'ld surly know by now if it was an issue
<apw> as you are testing with those kernels ... today
<lool> (I'm not testing imx51)
<apw> you as in mobile
<lool> Ack, just clarifying
<apw> and anyone changing libc better be testing with mvl-dove and fsl-imx51 ... lest we have to send boys with big cluebats round to visit them
 * lool whistles and notes not to touch libc
<apw> :)
<apw> ogra, ok some new kernels with that additional patch, apw2 kernels here: http://people.canonical.com/~apw/fsl-imx51-lucid/
 * ogra wgets
<apw> feedback appreciated as soon as you can :)
<ogra>   504 syslog    20   0 33280 1296  828 S  0.3  0.3   0:00.12 rsyslogd
<ogra> apw, looks fine
<apw> ogra, awsome, good catch ...
<apw> i'll get that puppy uploaded now
<ogra> kern.log is quiet too
<ogra> \o/
<apw> ogra, would i be right in saying we don't really have any out of tree drivers for mvl-dove (indeed any arm branches)
<ogra> no idea, NCommander does dove
 * NCommander points apw to ericm as the dove kernel guy
<NCommander> apw: as far as I know, we don't aside from any DKMS'ed kernel modules a user may install (although I'm not sure any would work for ARM)
<ogra> virtualbox on dove !
<apw> yeah ... eric isn't available in the timeframe for this decision.  i am trying to avoid uploading the mvl-dove kernel just for a compiler bump ... if there arn't any out of tree drivers then i don't need to bother and can save 6 hours of buildd time
<ogra> plars, can you check if go-home-applet works on your babbage ?
<ogra> its a no-op on mine
<ogra> and seems to cause the system to crawl
<plars> ogra: did they fix the dependency stuff with it?
<ogra> well, it depends on netbook-launcher
<plars> ogra: it used to depend on the 3d launcher, which removed efl launcher
<ogra> since we install netbook-launcher by default now in the images it is installable
<ogra> the dep was solved
<ogra> but i doubt that fixes anything
<ogra> at least it doesnt for me here
<plars> ogra: ah, I'll check it out
<plars> ogra: trying it a dove live image at the moment
<plars> ogra: it seems to come up, but doesn't work well
<ogra> go-home or the image ?
<plars> ugh
<plars> it looks like it actually restarts the launcher when you click it
<ogra> yeah
<plars> doesn't bring it to the foreground
<NCommander> apw: then assume we don't have an out of tree module; if there are, theres nothing critical as I've booted systems without any external modules before
<ogra> i saw multiple launcher processes here
 * NCommander is 99% sure we don't
<plars> ogra: yes, that's exactly what it's doing - starting a new netbook-laucnher-efl each time you click it
<apw> yeah NCommander i tend to agree i cannot imagine there are any
<ogra> plars, sick !
<plars> ogra: I'll put a bug in on it, unless you care to
<ogra> no, feel free :)
<plars> ogra: I wonder if that's how it foregrounds it with the 3d launcher, but the 3d one is smarter about checking to see if there's already a process and just foregrounds it instead of starting a new one
<ogra> m,ight be
<ogra> it doesnt minimize anything though
<ogra> what i always wonder is what go-home gains us over show-desktop
<ogra> we should probably just use a modified show-desktop
<plars> ogra: it does interact with webfav
<ogra> do we use anything like that in the 2D image ? #
<plars> ogra: you should be able to drag a url to gha and have it add the favorite to the desktop
<ogra> ah, right
<plars> presently, it does not seem to work
<ogra> plars, log out doesnt work for me either it seems
<ogra> i get an apport report
<plars> ogra: there's a bug about that
<plars> ogra: I just asked for more information on it
<ogra> yes, i just saw your comment and clicked it :)
<ogra> (clicked log out here)
<plars> ah, ok
<plars> worked when I tested it, hmm
<ogra> the efl window pops up, i click log-out and the launcher dies
<ogra> are you up to date with the latest ?
<plars> ogra: I'm running off the dove live image at the moment, so it should be close if not absolutely current
<plars> I did not update from there though
<plars> oh wait
<ogra> 0.2.2-0ubuntu3
<plars> which logout did you click?
<ogra> the one of the launcher
<plars> ogra: the one in the... yeah
<plars> I don't think that one should exist
<ogra> right
<plars> I filed a separate bug about that
<ogra> but as long as it does thats indeed a bug :)
<plars> the correct logout using indicator-applet-session does work though
<plars> ogra: certainly
<ogra> it makes the launcher commit suicide
<zul> hi, If possible can someone look at this for me? http://launchpadlibrarian.net/39001967/buildlog_ubuntu-lucid-armel.squid_2.7.STABLE7-1ubuntu5_FAILEDTOBUILD.txt.gz
<persia> zul: Related to what I was saying in -mobile, have you tried with an emulated pbuilder or sbuild locally?
<zul> persia: trying it now
<zul> persia: heh still broken
<persia> zul: emulated, or give-back?
<zul> give-back
<persia> OK.  Next best test (assuming you don't have hardware) is to try an emulated build.
<persia> There's a few syscalls that don't work, so this doesn't work for everything (e.g. gh6 can't be built), but generally with lucid one can build an emulated chroot that works fairly well.
<persia> There's also some support in karmic, but that doesn't support as many syscalls, so one ends up with massive build logs.
<persia> Do you have a lucid install available for i386 or amd64?
<zul> yep
<persia> OK.  Do you prefer pbuilder or sbuild?
<zul> sbuild
 * persia checks the current ubuntu-dev-tools for the tool name
<persia> OK.  So run `mk-sbuild-lv --arch=armel ${VG} lucid`, and you should end up with an emulated build chroot.
<persia> After that, running `sbuild -d lucid-armel *dsc` should try to build you armel binaries.
<zul> persia: cool thanks
<persia> Thanks for helping out with the porting.  Please come back if you get stuck.
<persia> Some people have various hardware and can test various things, but hardware is variable and thin on the ground right now.
<ynezz> linux-image-2.6.32-14-versatile_2.6.32-14.20_armel.deb should work with karmic qemu image? Seems like it hates me http://ynezz.true.cz/qemu.png
<ynezz> and lucid image with that kernel ends with http://ynezz.true.cz/qemu-lucid.png
<lool> ynezz: Which image is that?
<ynezz> rootstock's
<lool> I'm not sure what rootstock does for karmic and /dev; in theory, it should be possible to start a karmic userspace with this kernel
<lool> In fact I think I did last week
<lool> With a slightly older kernel and slighlty older karmic userspace
<lool> Concerning lucid, I suspect you're not getting to the network up state, so gettys aren't spawned
<lool> Usually this is due to lack of etc/network/interfaces or NetworkManager
<lool> ynezz: For karmic, I'd try loop mounting your fs and checking what's in /dev
<ynezz> this is command for karmic http://pastebin.com/f3f1b0023
<ynezz> lool: I tried that, /dev seems ok and populated
<lool> ynezz: Does /dev have a /dev/pts dir?
<ynezz> yep
<lool> Ok, probably a tmpfs gets mounted instead of /dev and isn't filled properly
<lool> You could probably workaround by poking at /lib/init/fstab in the image, but that's only a hack
<ynezz> looks so
<lool> I would need to reproduce, but I don't have an up-to-date rootstock here
<lool> I'll leave that one with a more recent environment that mine
<ynezz> I can upload that image if it helps you
<lool> ynezz: What you can do is look into the early boot scripts, these are etc/init/mount*.conf
<lool> ynezz: They have dependencies between each other
<lool> I usually start by changing the mountall.conf one to be a task instead of a job and to not daemonize and to be verbose
<lool> ynezz: something like http://ynezz.true.cz/qemu.png
<lool> err sorry http://ynezz.true.cz/qemu.png
<lool> Uh
<lool> my paste buffer is broken
<ynezz> happens to me all the time
<lool> How anoying, I can't paste into that xterm
<lool> ynezz: http://paste.ubuntu.com/381816/
<lool> ynezz: For your lucid one, either add NM or add a etc/network/interfaces with the lo interface, e.g. "auto lo" and "iface lo inet loopback"
<ynezz> lool: will try, thanks
<lool> zul: Only happens in -O2 builds, does not happen with -O0
<lool> zul: You have a bug?
<zul> lool: sure gimme a sec
<zul> lool: #519897
<DanaG> hmm, are there any plans to provide official beagleboard kernels?
<DanaG> RIght now, I get this issue: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/523610
<ubot4> Launchpad bug 523610 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd spins CPU on older kernels (affects: 34) (dups: 4)" [High,Triaged]
<lool> Bah squid isn't dpkg-buildpackage -j safe  :-(
<lool> DanaG: Not yet, no
<lool> DanaG: Your issue is fixed in newer kernels, but we should also fix it in userspace
<DanaG> Are there any ubuntu-official beagleboard kernels?
<DanaG> I'm using this kernel, for now: http://rcn-ee.net/deb/kernel/beagle/lucid/v2.6.32.8-l8.0/
<DanaG> (also, I keep getting "class suspend failed for cpu 0".)
<DanaG> when I try to echo mem > /sys/power/state
<lool> zul: I got it to crash under qemu as well, but I couldn't gdb from the qemu-arm-static env, so I ran a real vm and there gdb would work but had no debug info
<lool> zul: Rebuilding with -O0 -g and it wouldn't crash
<zul> lool: k thanks
<lool> zul: Looks like a toolchain issue or a bug in the generator
<lool> DanaG: These are the most officials one, but they are still unofficial  ;-)
<DanaG> ah.
<DanaG> And the -33-rc ones seem to not exist.
<lool> DanaG: Perhaps you can backport the relevant commit, or just wait for the userspace fix
<DanaG> I can just wait for now.  Or compile my own kernel, yeah.
<lool> DanaG: Check with rcn; he might have some .33 kernels somewhere
<lool> DanaG: You could also disable rsyslog or something
<DanaG> What's weird is that, on my host, even 2.6.33-rc8 has the same cpu-spin (on my laptop).
<lool> zul: I've sub-ed ~ubuntu-armel
<lool> DanaG: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=e86296585519f091bb24b17f84950a8edcbf0cc1
<lool> that's the 2.6.31 backport
<lool> DanaG: upstream commit is 002345925e6c45861f60db6f4fc6236713fd8847
<lool> Not sure from which tree though, apparently not torvalds
<lool> http://lkml.org/lkml/2010/2/2/13
#ubuntu-arm 2010-02-23
<james_l> My apologies, but is anyone familiar with zubuntu here?
<persia> james_l: No apologies needed.  Omegamoon was hanging out in here for a while some time back, but we never managed to get the Zubuntu kernel into Ubuntu.
<persia> And only Ubuntu 9.04 can even run on that hardware: more recent versions require newer processors.
<persia> (unless you're talking about https://launchpad.net/zubuntu , but I wouldn't expect this to be the right forum for that)
<james_l> That's a pity (I'm trying to get a working setup of either zubuntu or angstrom, and so far I've found little out about zubuntu, so I figured I'd ask)
<persia> Well, you *shoud* be able to install Ubuntu on your Zaurus, as long as you restrict yourself to 9.04.
<james_l> Why is 9.04 the latest?
<persia> Be warned that most of the default applications don't work very well at 640x480, so you may need to construct a special rootfs (the rootstock tool can help with this).
<persia> Because the processor in those devices is old, and newer versions of Ubuntu require newer instruction sets that aren't supported.
<persia> Same issue with the SheevaPlug, SmartQ series, etc.
<persia> actually, I think the SmartQ series or Nokia n810 can run 9.10, but won't be able to run 10.04.
 * persia isn't quite sure
<persia> Note that *all* of these devices need custom kernels.
<james_l> Yeah, I've played with that, unfortunately for every kernel I've tried, it's dying after Kernel Panic: aiiee attempted to kill init.
<james_l> Even ones that work (minus a few things) on angstrom, so I'm kind of at a loss on them.
<persia> If you want something that supports the newer instruction sets, the Netwalker and Efika MX seem to be widely available.  LOts of people use the BeagleBoard as well, but it's low on RAM
<persia> (and these also all each require custom kernels).
<persia> Hrm.  I suspect there's something special in the kernel configs.  Take a look at the kernel config for one of the Ubuntu-supplied kernels for 9.04 (-versatile might be a good candidate or the nslu2 kernel), and see if there are any obvious differences.
<james_l> Custom kernels aren't much of a problem, I just can't seem to find the kernel command line options that it wants, does ubuntu use the standard init, or something else?
<persia> Ubuntu uses upstart
<james_l> Where is that stored?
<persia> How do you mean?  Where can you download it, or where is it stored in the image?
<james_l> Where it's stored in the image
<james_l> ie, is it started as /sbin/init
<persia> If you have an initrd or initramfs, it's going to be in there.  It provides /sbin/init, /sbin/initctl, /sbin/reboot, etc.
<persia> Definitely /sbin/init
<james_l> So it's not actually stored on the rootfs image?
<persia> No, it's in *both* places.  If you're using initrd or initramfs, you need to have a copy there to deal with early boot, and you'll also have a copy in the rootfs to deal with keeping the system running.
<james_l> Ok, sorry the way you mentioned it made it sound as if it was only in the initial ramdisk.
<persia> Sorry.
<james_l> Do you know if it requires a minimum kernel version?
<persia> I don't offhand, but it's usually best to try to use the kernel that was released with a given release of Ubuntu.  For 9.04 that was 2.6.28
<james_l> Thanks, I'll keep messing with it.
<persia> Good luck.  If you get it working, please share: having a clean procedure to install Ubuntu on the Zauri would be appreciated by many.
<james_l> Do you know where Omegamoon went? I've tried to contact him about a few things, but alas have had no response.
<persia> I don't.  I haven't seen traffic from him in about a year in this channel.
<james_l> Anyone else work on zubuntu?
<james_l> persia: Any idea why when it boots, it would be killing init?
<james_l> Huzzah, got it to not kill init.
<james_l> On the other hand the touchscreen doesn't work
<james_l> Ooops
<persia> That's just a driver thing :)  Nice work.  What was the magic change?
<james_l> Not much, I'm using the 1.0 from http://www.oesf.org/forum/index.php?showtopic=26510&st=0 on a tosa
<james_l> tosa = SL-6000
<james_l> I know the kernel works for TS, and I think I should have fixed that.
<james_l> or not
<persia> Oh, that should work.  The 2.0 stuff seems suspicious to me because I *know* that large chunks of the archive were recompiled for an instruction set not available on those devices.
<james_l> Why was that, and does ubuntu have a build system capable of rebuilding them as armv5 (or even armv4)
<persia> If you want ARMv4, I'll strongly recommend Debian armel.  The team there has been maintaining support for this ISA, and does a great job.
<persia> Its potentially possible to attempt to rebuild everything that has changed since 9.04 with a toolchain that supports ARMv5, but that's 1) going to take months, and 2) likely to require a significant number of build machines and a separate archive.
<persia> I know it *can* be done, because some people recompiled 7.04, 7.10, and 8.04 for armel even before it was properly supported.
<james_l> I've got two SL-5500 which are strongarm (armv4 (l?)), and a SL-6000 which is armv5 (something or other)
<james_l> months?
<persia> But I expect that such an effort would take 4-8 months.
<persia> Yeah, there are thousands of packages involved.
<james_l> Why is ubuntu's build system so slow compared to others?
<persia> I'm not sure to what you're comparing it, but I suspect the answer is that it's all native builds.
<persia> I think our builds are faster than Debians.
<persia> I'm not sure about other places.
<persia> But to complete the answer to your question, ARMv7 was the initial target for Ubuntu armel, but it was impossible to get hardware at the time the project started.  As hardware has become available, each release has gotten closer to the target.  I'm hoping that we'll have enough hardware to be able to have a sane, stable, supported platform for buildds with our October release, but the path to get there has been confusing.
<james_l> Well, I've done cross compiling with a number of things, gentoo, angstrom, and even some debian and while each is probably far smaller than ALL the packages, it hasn't been that bad. Maybe a week for any of those.
<persia> Yeah.  Recompiling for a target rootfs is usually at most a tenth the size of recompiling the archive in terms of package count.
<persia> But there's a couple other issues involved, as follows:
<persia> 1) Not all packages in Ubuntu are set up for correct cross-compilation
<persia> 2) Build-time test-suites run under cross-compilation don't tend to generate the expected results
<persia> 3) The combination of native-built and cross-compiled binaries is poorly tested, and it's unknown whether there may be ABI changes.
<persia> Since working around 1) involves 20,000 patches, we chose native compilation.
<persia> And because of 3) we discourage cross-compilation because we don't know how it would affect things.
<persia> 2) is a bit more of a happy accident, but would have likely been dealt with if we had to patch for 1)
<ynezz> d'oh http://pastebin.ca/1806500
<james_l> To be honest, that's a bit disappointing, considering that debian had the best CC years ago
<persia> Well, it depends on the package.  Anything that cross-compiles well in Debian likely cross-compiles well in Ubuntu.
<persia> But the vast majority of packages have never been tested.
<persia> *so*, if you're just looking to do something small, you could rebootstrap with cross-compilation.
<persia> But if you want the entirety of the archive, it's not necessarily safe.
<lool> ynezz: I saw that double free once, but it's usually not fatal
<lool> ynezz: Try with MALLOC_CHECK_=0
<ynezz> ok, building again
<ogra> lool, usually not fatal ? it usually kills apt during package install :)
<ogra> lool, i think we should target that one for release and get doko on the case if possible
<ogra> ynezz, hey, the screenshow in your new bug looks different from the old one :)
<ynezz> it's same URL, isn't it? :)
<ogra> ynezz, --serial ttyS2 .... vs console=ttyAMA0,115200 ;) you didnt build your image with the right serial device
<ogra> rootstock needs to use --serial ttyAMA0 in this case
<ericm> ogra, what did imx51 do to enable the serial console at boot by the way?
<ericm> ogra, by modifying flash-kernel?
<ogra> ericm, adding console=ttymxc0,115200 to the cmdline
<ericm> ogra, I mean not in boot loader
<ogra> no, we dont touch flash-kernel, the default cmdline is set durign image build
<ericm> ogra, but the default will only be used when no cmdline is passed
<ogra> right
<ogra> as always
<ericm> and u-boot will read the boot.scr scripts on disk to setup the command line, which is configured by flash-kernel
<ynezz> ogra: ok, rebuilding with correct --serial
<ericm> so for dove - I guess to modify flash-kernel will be a better approach
<ogra> ericm, no, we dont want to have a console option by default in any of the images
<ogra> we only added that for the dev release and will drop it in one of the betas
<ogra> the cmdline on arm should not differ from the default in any other images
<ericm> ogra, I'm going to close bug 452737
<ogra> the boot.scr for dove is created by the image build scripts on the cdimage server
<ubot4> ericm: Bug 452737 on http://launchpad.net/bugs/452737 is private
<ogra> ericm, hmm, while its a bit late to enable that for lucid it might be helpful for L+1 until beta
<ericm> ogra, ok - got you
<ogra> ericm, but essentially it is fixed btw
<lool> ynezz: note that you need to set MALLOC_CHECK_ in the installer script which gets copied by rootstock into the VM
<ogra> see my last comment
<ericm> ogra, right - if it is only wanted a way to enable that instead of every time
<ogra> lool, i'll set that by default in my next upload(risking that we lose duplicate copunt for the bug)
<ogra> ericm, yes, the liveimage specifically got that serialtty= option in casper to create the console
<ogra> ericm, but it will only come up after boot for the login prompt, what i suspect Li wants on that bug is kernel bootmessages :)
<ericm> ogra, exactly what he was talking about
<ogra> right, so he needs to set console= on the images boot.scr ... its not that hard to do from an x86 system on the mounted USB key/SD card
<ogra> (manually before booting)
<ericm> ogra, see - so I'll close that one
<ogra> yeah, but add proper comments :)
<hrw> morning
<ynezz> lool: something like that? http://paste.ubuntu.com/382126/
<ogra> ynezz, yes
<ogra> i'll add the same to rootstock as well
<ynezz> ogra: I've rebuild that karmic image with this http://paste.ubuntu.com/382129/
<ynezz> ogra: and it's same, that serial device had no effect on it
<ogra> try without the --kernel-image parameter
<ogra> thats actually only for the beagel board
<ogra> better apt-get install linux-versatile after first boot manually :)
<hrw> btw - rootstack under Debian/sid + DIST=lucid hangs after extracting last package
<ogra> though you should get a login prompt
<ogra> hrw on first stage ?
<ogra> note that rootstock isnt really written for debian and i dont even test it in that context
<ynezz> Kernel image must be specified
<ogra> ynezz, no
<ogra> not in rootstock
<ogra> --kernel-image is an addition for the beagleboard and it extracts a kernel directly, circumventing the package system
<ogra> (because beagle has no kernel in the archive yet)
<ynezz> ah
<hrw> ogra: http://hrw.pastebin.ca/1806559
<ynezz> hm, had the same issue
<ogra> hrw, yeah, problem with the difference of our qemu packages i think
<ynezz> it's missing qemu-arm-static
<ogra> debian doesnt have qemu-arm-static in any stable release ... and in testing its named differently
<hrw> ok
<ogra> (if it even entered testing already, not sure, might still be unstable)
<ogra> ynezz, thats why we have packages for rootstock ;) they install the needed deps
<ynezz> there was no qemu-arm-static in 9.04
<ogra> right
<ogra> thats why the 9.04 package uses a VM for that stage
<ynezz> ah, ok
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | got package build issues in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 | no, we do not cross compile
 * ogra thinks it became a FAQ so makes sense to have it in the topic :)
<hrw> ogra: which HW is used for native builds?
<ogra> imx51
<hrw> cpu speed? memsize?
<ogra> 800MHz, 512MB
<hrw> where are times when 64MB 400MHz was good machine ;D
<ogra> heh that was when we were young :) ... back then
<hrw> I still have slower devices on desk
<hrw> ogra: rootstock should have option to just generate images. as all is done in temporary dir it is harder to find where is image which was generated/used/failing
 * ogra too
<ogra> hrw, thats done with the --keepimage or --notarball options
<ogra> apart from that both, the gtk GUI and the script tell you wheer the image was stored at the end of the build (the GUI also has an option to select the target dir)
<hrw> dpkg-divert: cannot open diversions: No such file or directory
<hrw> eggonlea: Second stage build in Virtual Machine failed !
<hrw> eggonlea: Please see the log to see what went wrong.
<hrw> ian_brasil: Cleaning up...
<hrw> ~curse irssi tabcompletion
<hrw> ian_brasil, eggonlea: sorry
<ogra> lool, so i'm considering to change the image fs from ext2, what would you prefer, ext3 or 4 ?
<ogra> hrw, heh
<hrw> ext2 is fine for images
<ogra> hrw, no, it causes fsck to kick in if the clock is off
<ogra> ext3 should be common on all kernels nowadays
<hrw> so go for ext3 and disable fsck by tune2fs
<ogra> i wont screw around ion the rootfs :)
<ogra> so no tune2fs
<ynezz> ogra, lool: little change in error message :) http://paste.ubuntu.com/382146/
<ogra> rootstock is supposed to build as identical installs as possible to a normal ubuntu
<ogra> which is why the --user and --passwd options are not used by default anymore in the latest commits for example
<ynezz> ogra: I've rebuilt that karmic image with http://paste.ubuntu.com/382148/
<ynezz> ogra: but it's same
<ogra> thats weird, it should work
<ogra> do you see dmesg output on boot ? and do you see ttyAMA0 in there ?
<ynezz> yes I see dmesg
<ynezz> that screenshot was just the last part
<ogra> you should be able to scroll back and there should be some message about ttyAMA0
<ynezz> and I see ttyAMA0 there
<ogra> very weird
<ynezz> 1,2,3 too
<ogra> then it should work
<ynezz> the problem is with devtmpfs I think
<ogra> no
<ogra> devtmpfs is in all ubuntu kernels for lucid
<ynezz> it get's mounted and is missing /dev/pts /dev/shm etc.
<ogra> that should be handled by udev
 * ogra goes for some breakfast
 * hrw goes though rootstock and removes all removals
<hrw> ~hail 25Mbps download
<hrw> hmm. rootstack generated rootfs thinks that only dpkg is installed ;(
<lool> ogra_cmpc: Please use ext4 for images of karmic+
<lool> and if you care, ext3 for << karmic
<persia> Why, particularly?
<lool> ynezz: that's "interesting"
<lool> ynezz: Do you reproduce with "ldconfig"?
<lool> persia: are you asking me?
<persia> lool: Yes, and specifically about your filesystem selection suggestions.
<lool> ynezz: Yes, that might be the issue, but mountall should cope with that I think
<persia> I don't disagree: rather I'm curious why one ought select those.
<lool> persia: because ext4 was the default fs starting with karmic installs
<lool> And I think all Ubuntu subprojects should be consistent here
<lool> Just like we patched vmbuilder to do this as well for instance
<persia> This makes lots of sense.  Thanks for the explanation.
<ynezz> lool: how do you mean that 'ldconfig' ? mount that image and run it manualy using qemu-arm-static?
<lool> ynezz: boot with init=/bin/sh
<ynezz> lool: sorry, you're talking about that apt-get segfault?
<lool> ynezz: Yes
<lool> ynezz: I htink it's ldconfig
<ynezz> lool: since it crashed I need to create qemu image manualy and copy the unfinished fs from /tmp/ right?
<lool> ynezz: Sorry, I'm not sure about that part
<lool> Probably there's a leftowver .img somewhere, unless it cleans it up on crash
<ynezz> it cleans it
<ynezz> ok I'll rebuild without that cleanup task and try it
 * lool &
<ynezz> ah it's in /tmp also, good
<ynezz> lool: if I run /sbin/ldconfig nothing happens
<ynezz> lool: running it with --verbose it do something
<lool> ynezz: try apt-get install vim ... as in the log instead?
<lool> ynezz: It would be great to have a smaller testcase than running rootstock
<lool> I saw that once myself, but couldn't trigger it again afterwards
 * ogra doesnt see it at all under lucid 
<ogra> and i'm doing about ten testbuilds with rootstock per day currently
<ogra> though most of the time only minimal with no seeds
<ynezz> ogra: would you mind trying this 'sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 2G --seed wget,vim,network-manager --dist lucid --serial ttyAMA0'
<ynezz> ?
<ynezz> it does happen to me when there's network-manager in the seed...
<ogra> i'll try it in the next gui test later today
<ynezz> ok, thanks
<ynezz> without seed it's ok
<ogra> ##################### REMINDER: mobile team meeting in #ubuntu-meeting in 5 min ######################
<lool> ogra: Did you look at where rootstock would pull lucid kernels from?
<ogra> i didnt change the code you know
<lool> ogra: You might want to check 431790
<lool> lp #431790
<ubot4> Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] https://launchpad.net/bugs/431790
<ogra> but its not active yet either
<ogra> oh, thanks
<ogra> looks good, what key would be used, the normal archive key ?
<lool> I guess
<ogra> lool, so it seems i can reproduce the issue with --seed wget,vim,network-manager here
<ogra> i get the same segfault
<lool> ogra: Ok great, can you investigate?
<lool> Starting by a bug report etc.
 * lool is about to leave for the day in 20 minutes or so
 * ogra too
<ogra> but i'll put it on my list
<kiko> lrg, ping when you're around!
<ogra> lool, the segfault does only happen with the non archive kernel ... i cant reproduce it with the archive kernel here, i guess i'll switch on the rootstock code to pull the deb with the next commit :)
<asac> ok uploaded libv4l with workaround for arm gcc issue
<asac> off
<ogra> yay
 * ogra is off too
<lool> ogra: Could you comment on whether you intend to use d-i kernel in https://bugs.launchpad.net/bugs/431790 ?
<ubot4> Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New]
<lool> ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~/c
#ubuntu-arm 2010-02-24
<plars> GrueMaster: are you testing on imx or dove currently?
 * persia wonders why this is -arm and not -testing material.
<GrueMaster> Finished testing imx live (well, may test more deeply).  Installer is still broken and fix is released but not built yet.
<plars> GrueMaster: same installer bug you mentioned in the meeting earlier today?
<GrueMaster> yes.
<plars> ouch
<plars> GrueMaster: you are going to have the same problem on dove
<plars> GrueMaster: we have ubiquity 2.1.24 on dove, assuming the same on imx
<plars> snap
<GrueMaster> That's what I thought.  yes.
<GrueMaster> So, respin it is.
<GrueMaster> wheee.
<plars> GrueMaster: is there any workaround for it?
<GrueMaster> Yes.  Install 2.1.25 as soon as it gets built.
<GrueMaster> (I know, not a good answer)
<plars> GrueMaster: well, if you want to get unblocked...
<plars> it's a 1-line change
<GrueMaster> Correct me if I'm wrong, but it seems to me we hit this bug at least once per release.
<plars> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3830#ubiquity/components/ubi-partman.py
<GrueMaster> Does python rebuild the pyc file automatically?
<plars> GrueMaster: hopefully that's true, and our one time is over :)
<plars> GrueMaster: you can force it if needed by deleting the .pyc file
<plars> it's going to be 1-2 hours before I can get much more testing done, but may be moot since it looks like we'll need a respin
<GrueMaster> I've made the change and will test it quickly.
<DanaG> hmm, marvell dove... what actual board uses that?
<DanaG> I can find Kirkwood just fine (that Sheeva thingy), but what's Dove?
<DanaG> What I have is BeagleBoard (OMAP3).
<plars> GrueMaster: thanks, let me know, gotta go afk for a bit
<GrueMaster> see you.
<GrueMaster> DanaG: The sheeva plug is an older generation.
<DanaG> I thought it was the other way around... kirkwood newer than dove.
<DanaG> oh, I see.
<persia> Age of processor != Age of instruction set revision :)
<DanaG> http://armin762.wordpress.com/2010/02/14/armv7-socs-freescale-i-mx51-babbage-ti-omap3-marvell-dovearmada-qualcomm-snapdragon/
<DanaG> ah
<GrueMaster> http://www.slashgear.com/marvell-plug-computer-3-0-updates-sheevaplug-with-wifi-bluetooth-hdd-0567674/
<DanaG> Do any of you talk directly to Marvell?
<DanaG> http://www.flickr.com/photos/22046787@N03/sets/72157623160058996/
<DanaG> I saw comments on Engadget, asking essentially: why cripple battery life by using a tiny battery?
<DanaG> Product suggestion: take that same thing, and give it a normal-size battery (for insane-o battery life).
<persia> DanaG: I've had the "why cripple" discussion with a hardware vendor before.  Apparently the goals are low cost and low weight with market-acceptable battery life.
<persia> DanaG: The impression I get is that marketing teams don't believe people will pay more for heavier devices just for extended runtimes
<DanaG> Ah, it'd be nice if they could make interchangeable different-size batteries.
<DanaG> http://www.engadget.com/2010/01/05/marvell-shows-off-an-odm-smartbook-thinner-than-strict-decency-p/
<persia> Some do, but not enough :)
<persia> armin76: Do you have a link for the "Prototype" identified as an i.MX51 product, or did you just mean "Various prototype devices"?
<DanaG> As it is, 4 hours is no better than I get with my full-size laptop -- and lower than many Atom netbooks.
<persia> Well, yeah, but it's "The thinnest thing around", which is the highlight point.
<persia> There was talk about the "20-hour laptop", which is perfectly doable at about 1.5Kg, and we can hope someone releases one.
<DanaG> If they put the battery at the back, then they could do one design to satisfy both.
<DanaG> http://gigapple.files.wordpress.com/2009/04/hp_battery.png?w=161&h=149
<DanaG> old pic, but that's the idea.
<persia> Either that, or something like the 3/6/9/12 cell modular batteries available for some laptops.
<DanaG> oh, and are there plans for an official in-repo beagleboard config (or at least kernel)?
<persia> I think not for the current generation.  There is an expetation of 192MB RAM in Ubuntu (or maybe that got bumped to 256MB or even 384MB), and I thought the BeagleBoards only had 128MB.
<DanaG> I believe it has 256, actually.
<persia> Oh, then I've been misinformed :)
<DanaG> I'm running Lucid on it just fine right now -- http://elinux.org/BeagleBoardUbuntu
<DanaG> I think Rev.A had 128; it changed to 256 later.
<persia> Oh, I know it works.  We have lots of Beagle users.
<persia> Ah.  That explains the confusion.
<persia> I think it's too late for this development cycle (although I might be wrong), but it would perhaps be something to raise with the kernel team during planning for the next cycle.
<persia> It depends on the level of effort that is expected from them, and the number of people willing to volunteer to support it, etc.
<persia> If we just ask the existing team "Please also do this" the answer is almost certain to be "No" unless it's trivial to do.
<persia> If we can get more volunteers to help join the team, and the question becomes "Please accept these patches that we'll help maintain", it'S easier.
<DanaG> Even something like the kernel-ppa (that is, not even a 'real ppa' that you can add to sources.list) would be good.
<DanaG> Just, something like a "sanctioned list of kernels you should try".
<DanaG> Or something like that.
<persia> Well, PPAs don't handle armel very well.
<persia> Best current recommendation for Beagle users is to use rcn-ee's kernel, which tends to be in good shape.
<DanaG> oh yeah, and speaking of batteries... the way HP business notebooks work: 8-cell primary, PLUS either 8 or 12-cell secondary.
<DanaG> oh yeah, though none of the .33-rc kernels are there for Lucid.
<persia> That's also a reasonable model.
<DanaG> And 8 is bigger than necessary for ARM stock battery.
<DanaG> =Ã¾
<DanaG> You could go all day on 8.
<persia> Lucid isn't using .33-rc right now for anything.  It's 2.6.32 still.
<persia> "All day" isn't necessarily enough :)
<DanaG> taken absurdly literally, "all day" is 24 hours.
<DanaG> =Ã¾
<DanaG> er, at least 18.
 * persia has a laptop that (when the batteries were new) got 12 hours on two batteries.  With travel, sleep, etc., this should have been enough (especially because the batteries recharge in 3.5 hours), but I've still run completely out of power.
<DanaG> My laptop got 4 hours when new, on the 8-cell standard battery.  Now I have like 17% wear, one year later.
<DanaG> Oh, and what's Marvell's GPU, anyway?
<DanaG> (two questions: open source? capable of compiz?)
<armin76> persia:  http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/
<eggonlea> DanaG: OpenGL ES instead of OpenGL, so not capable of compiz.
<DanaG> Bleh.
<DanaG> Compiz is like 90% of the opengl I use in Linux.
<DanaG> =Ã¾
<eggonlea> hi all, I did not see any ARM port of daily livecd. what's wrong with that?
<DanaG> ARM + CD drive... does not compute,
<DanaG> .
<DanaG> Try "root filesystem image" or something.
<eggonlea> I mean the livecd.img instead of .iso.
<eggonlea> we usually had it everyday.
<DanaG> ah.
<eggonlea> Hope one day both of compiz and launcher chould have both of GL and GL ES backend. :P
<eggonlea> Like ChromeOS
<persia> armin76: Ah, that makes sense.  I was thinking it would be interesting if someone tried to brand "Prototype" :)
<lool> ogra: poke
<ogra> ouch !
<ogra> :)
<lool> ogra: I need to give my input on the priority of bug #431790; would need to know whether you plan to use d-i kernels or archive kernels
<ubot4> Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] https://launchpad.net/bugs/431790
<lool> (To implement signing of these files in soyuz)
<lool> for rootstock that is
<ogra> lool, see if my comment suffices
<lool> ogra: that helps, thanks
<ogra> lool, btw, probably link bug 437636 to it (or make it a duplicate of 431790)
<ubot4> ogra: Bug 437636 on http://launchpad.net/bugs/437636 is private
<lool> ogra: I mentionned that it would be nice if the feature was available in the next weeks or month; feel free to give a more sensible deadline if you have one
<lool> ogra: I dup-ed; I don't really care if it's separate or not, up to you
<ogra> no, thats fine
<ogra> ynezz, a fix for your segfaulting installs should be in the latest bzr
<ynezz> ogra: thanks, which revision is that?
<ynezz> ogra: did you get this "11:20:17 < ynezz> ogra: thanks, which revision is that?" ?
<ogra> ah, no, i didnt
<ogra> commit 78, the very last one
<ogra> the kernel that was used up to now for licud builds was compiled under karmic, the new code now makes it use the lucid archive kernel
<ogra> apparently that fixes it ... i had the code in there but disabled since i didnt want to hack around the gslice/malloc issue
<ogra> ynezz, so make sure you have the hack from commit 73 as well ;)
<persia> Aha!  is that why all the buildds were disabled for a while.  That should make everything better.
<ogra> persia, ??
<persia> At some point recently I looked at lp.net/builders and 4 of the armel builders were disabled.  Based on your comments, I now beleive that to be due to the kernel upgrade.  Given the differences in kernels, I'm hoping lots more stuff builds.
<ogra> i was commenting on rootstock issues :)
<ogra> and you know we cant update the kernels on the buildds :)
<persia> Ah, I hadn't realised rootstock had a special kernel poke that was different.  And I suspect the kernels on the buildds could be updated, but yes, we can't do that.
<ogra> the kernels cant be updated as long as nobody makes it work ... which would require someone havin the HW to roll a new kernel with the required patch and to work out the flashing
<ogra> bah, crap ... 1000 steps are not enough for the rootstock progressbar when doing a netbook install
<persia> Right.  That's why we can't do it: the hardware is special :)
<ogra> well, not *that* special
<persia> No ?!?!
<ogra> its just that nobody has it
<persia> That's what makes it special.
<ogra> i surely would be able to make it work if i had such a device here
<persia> Well, there are new dev boards announced regularly using supported chips, so we can hope there's retail boxes with real network, real disk, enough memory, and auto-boot-on-power-connect in the future.
<ogra> ah, sure, we're about to replace the machines anyway ... its in the process
<persia> Oh cool!
<ogra> no idea how long it takes though ... might be past lucid
<ogra> but i'm starting to get tired of doing a handfull give-backs per day for random build failures
<ogra> so i hope rather sooner :)
<ynezz> ogra: ah, ok
<ynezz> ogra: will try later today and will let you know
<hrw> hi
<hrw> any infos when armv7a 12" 1GB ram systems will hit market? :D
<ogra> *soon*
<ogra> :P
<hrw> I am more and more tired with cursing intel developers after each update of debian on my laptop
<persia> hrw: You could install Ubuntu, and then you wouldn't have to curse them after debian updates anymore :)
<hrw> persia: I will curse after each 'apt-get upgrade' anyway
<hrw> persia: i855gm is forgotten baby
<hrw> and distro does not change it
<persia> is there a patch that doesn't break anything for anyone else?
<suihkulokki> indeed.. intel x11 has been broken for thinkpad x40 with a old intel chip for several upstream releases..
<Noisi>  hi there! i try to cross compile with arm-linux-gcc a sqlclient in c++ to arm720t and i need lib mysqlclient. Must i compile it from soucre? How?  it would give me great pleasure for some tip.
<ynezz> ogra: it still segfaults here :p
<ogra> whats your host release ?
<ogra> i'm running it on a lucid host as well
<ogra> so using the lucid qemu
<ynezz> karmic here
<ynezz> I'm building same image/params but for karmic and will tell you result
<ynezz> ogra: karmic builds on karmic
<ogra> yeah, thought so
<ogra> you could run in a lucid chroot :)
<ynezz> I'll try kvm
<ogra> i doubt thats fun
<ogra> running one vm in another will be horribly slow
<ogra> if it works at all
<ynezz> I wonder about that too
<ynezz> I don't share same opinion about speed tho
<ogra> qemu-system is very slow in itself
<ogra> at least the armel version
<ogra> running that inside kvm (which is what rootstock does) will likely be lots slower than on real iron
<hrw> ogra: run it on x86-64 instead of plain x86
<ogra> that doesnt change the fact that you stack VMs
<ogra> i dont have any amd64 machines around to prove that ... nor any kvm capable HW though
<ogra> but i cant imagine running a VM in kvm can be any faster or equally fast than running it in a real chroot
<ynezz> I don't think it will be faster
<ynezz> slower, but not that much to be unusable
<ogra> mikeul, ah, you are already here :)
<ogra> so whats the problem you see ?
<mikeul> First of all, I installed rootstock using apt in Karmic.  But I've also built it with a copy from bazaar, and I'm having the same problem.
<mikeul> rootstock seems to run fine to completion, and I have e.g. qemu-armel-201002241455.img (I ran with --keepimage)
<mikeul> then, following instructions from https://wiki.ubuntu.com/ARM/RootfsFromScratch "Using a qemu image", I try booting with it inside qemu.
<mikeul> using the exact same qemu-system-arm line from that site, it fails to boot completely.  The last 3 lines of the boot sequence are...
<mikeul> VFS: Mounted root (ext2 filesystem) readonly.
<ogra> thats using a jaunty kernel, if you built a karmic system you need a different kernel
<mikeul> Freeing init memory: 136K
<mikeul> ah ha
<ogra> http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8
<lool> ogra: Can we start pointing people at the versatile lucid kernel?
<mikeul> OK, I'll go give that a go...
<lool> mikeul: I'd be interested if you could try http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/
<ogra> lool, well, that means unpacking the deb
<lool> vmlinuz
<ogra> until d-i built it for versatile
<ogra> oh ?
<ogra> since when is that there ?
<lool> mikeul: The vmlinuz there should allow booting anything from jaunty to lucid included
<ogra> mikeul, yes, do what lool said
<ogra> i wasnt aware that kernel exists yet
<lool> I did the changes perhaps a week ago and d-i was uploaded perhaps a couple of days ago
<ogra> that explains why i didnt see it on the weekend when i checked :)
<mikeul> alright, I'll try lool's suggestion.  brb.
<mikeul> you mean that the lucid kernel (at URL given) can boot with my karmic RFS?
<ogra> yes
<ogra> the kernels are backwards compatible  ... just not forward :)
<chimp> Here is a weird issue I'm wondering if anyone else has run into. The rootstock filesystem I created using karmic results in my arm board not creating usb device nodes in /dev/bus/usb , I actually sorted the problem by replacing the line in /lib/udev/rules.d/50-udev-defaults.rules that creates the device nodes to the line that was there in jaunty (they differ). This solves the problem but I'm wondering if anyone else has come across this and if i should file
<ogra> you were cut after " and if i should fil"
<chimp> file a bug report
<chimp> It results in lsusb not seeing any devices
<mikeul> I must be doing something wrong.  Both the ...-cortex-a8 kernel and the vmlinuz kernel cause qemu to crash almost immediately.
<mikeul> using the karmic kernel, I get a bunch of lines, "arm_sysctl_write: Bad register offset 0xc94", etc.
<mikeul> then a reg dump and qemu exits
<mikeul> booting with the lucid kernel lool pointed to doesn't cause qemu to spit out quite as many lines, but still ends in "qemu: hardware error: pl050_write: Bad offset 44"
<mikeul> That line shows up at the end of the karmic kernel boot attempt, too (but with "c94" instead of "44")
<ogra> and you run that on a karmic system as well (i.e. the qemu you use is the one from ubuntu)
<mikeul> yes, qemu was installed by apt upon installing rootstock.
<ogra> is your host machine amd64 or i386 ?
<mikeul> uname -a says i686
<lool> mikeul: What's your qemu?
<mikeul> 'qemu -version' => QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0)
<mikeul> was that the right answer?  Same result with 'qemu-system-arm -version', of course.
<lool> mikeul: Sorry, I'm not sure what the issue is; your expectation is a console prompt, but you don't get any, is that correct?
<mikeul> lool: affirmative
<lool> mikeul: This is usually the result of either the network not coming up, or the prompt coming on the serial console
<lool> mikeul: For the network to come up, you either need to setup /etc/network/interfaces or install network-manager
<lool> For serial console, it depends how you launch rootstock and qemu, but you should have it with Ctrl-Alt-2 IIRC
<lool> or -3
<mikeul> But I don't think this is a qemu setup issue, because when I download the kernel and RFS (rather than build my own RFS), I can get a prompt in qemu.
<lool> mikeul: Ok; so it's likely the network of console setup
<mikeul> i.e. following the directions in http://people.canonical.com/~ogra/arm/qemu/kernel/README, I can get it to boot.
<mikeul> lool: I don't understand that conclusion- you mean the network or console setup of qemu?  Or of the RFS?  Because the RFS never gets a chance- qemu crashes immediately, long before the kernel boots or the RFS is mounted.
<lool> mikeul: no, in the image
<ogra> lool, well, if it crashes before loading the kernel ....
<lool> mikeul: Either no console is spawned because serial console was chosen (I'm not sure what rootstock does there), or the consoles (tty1 tty2...) don't come up until network comes up
<lool> mikeul: It doesn't crash anymore, does it?
<mikeul> Yes, qemu crashes immediately.  Perhaps I misspoke a second ago with "long before kernel boots"- it seems to crash immediately upon booting the kernel.
<lool> mikeul: How do you start it?
<mikeul> Here's my qemu command line just to be clear...
<mikeul> qemu-system-arm -M versatilepb -kernel ../downloaded/vmlinuz-lucid -hda qemu-armel-201002241455.img -m 256 -append "root=/dev/sda mem=256M ro"
<mikeul> sorry for the delay, it's a different machine, I can't cut-and-paste here...
<mikeul> ...where "../downloaded/vmlinuz-lucid" is of course the kernel you pointed me to, renamed
<ogra> that should definately not crash on unpacking the kernel
<lool> mikeul: You miss -cpu
<lool> mikeul: You want -cpu cortex-a8
<ogra> and the wikipage does as well
 * ogra slaps forehead
<mikeul> indeed, now it boots.
<ogra> fixed
<ogra> well ... if the wiki ever saves
<mikeul> lool, ogra, you have made me happy(er)
<ogra> mainly lool :)
<lool> mikeul: I wish you'd list here all the pages which need fixing
<lool> or places
<mikeul> I still haven't landed at a prompt, but perhaps I should play around with that myself a bit...
<mikeul> lool: you mean you want me to indicate which web pages were outdated?  I can do that.  Really, I was only using RootfsFromScratch, so I can summarize which parts of that page could be updated.
<lool> mikeul: Which broken docs you came across basically
<lool> mikeul: Well we can continue debugging for the prompt part
<lool> mikeul: What does it do on boot now?
<mikeul> (a few lines to follow)
<mikeul> mount: mount point /dev/pts does not exist
<mikeul> mountall: mount /dev/pts [45] terminated with status 32
<mikeul> mountall: Filesystem could not be mounted: /dev/pts
<mikeul> [repeats for /dev/shm and /dev/pts (again) and /dev/shm (again)]
<mikeul> Mount of root filesystem failed
<mikeul> A maintenance shell will now be started.
<lool> That's probably devtmpfs again
<lool> Problem is karmic's mountall with a lucid kernel which has devtmpfs mount
<mikeul> then let me try with -cpu correct and the karmic kernel...
<lool> mikeul: Please pass devtmpfs.mount=0 on the kernel cmdline
<lool> mikeul: I'd personnally recommend staying with the lucid kernel and just turning off devtmpfs mounting as above; the kernel has been fairly tested at this point, and we'd probably do best in supporting only one kernel which is able to work on all dists given the number of other issues we have to resolve
<ogra> ++
<mikeul> lool: fair enough, but I already tried it :) it hung up in the same manner as lucid is with "devtmpfs.mount=0".  The both say:
<mikeul> One or more of the mounts listed in /etc/fstab cannot yet be mounted: (ESC for recovery shell)
<mikeul>  /: waiting for /dev/root
<mikeul>  /tmp: waiting for (null)
<mikeul> and then it doesn't make it any further.
<lool> mikeul: It would help if you could paste the full output; to do so, pass console=ttyAMA0,115200 on the kernel cmdline and "-nographic" to QEMU
<lool> That should output the kernel and userspace error messages on your terminal as to copy-paste
<lool> mikeul: You can paste to e.g. paste.ubuntu.com
<lool> At least the last lines of the kernel output and all of the userspace output of a boot with devtmpfs.mount=0 would be nice
<ogra> note that you need a second terminal from where you stop qemu then
<ogra> ctrl-C wont work
<mikeul> yeah, I just noticed that :)
<mikeul> lool: Here are the last few lines of the boot (that paste.ubuntu.com is really handy!)
 * ogra struggles with proper quoting for the rootstock /bin/installer script ... 
<mikeul> [    5.560643] md: ... autorun DONE.
<mikeul> [    5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
<ogra> why is preserving variables in here documents so hard .... sigh
<mikeul> [    5.603695] Freeing init memory: 152K
<mikeul> One or more of the mounts listed in /etc/fstab cannot yet be mounted:
<ogra> mikeul, sudo chown $USER <path to rootfs image>
<ogra> i guess i should build that into rootstock somehow
<ogra> (the point is that i never use qemu but real HW) ...
 * ogra files a reminder bug
<mikeul> I intend to be using real hardware, too
<lool> mikeul: can you please give us the URL?
<lool> mikeul: The point of paste.ubuntu.com is to send the output there and give us the URL
<mikeul> you mean you want my qemu-armel-*.img to be the same user that's running qemu?  It already is.
<mikeul> "Oh, that makes sense", he said embarrassed, "here's my paste": http://paste.ubuntu.com/383077/
 * ogra filed bug 527159
<ubot4> Launchpad bug 527159 in project-rootstock "rootstock script should produce world writable qemu images (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527159
<ogra> mikeul, its not your fault, dont be embarrassed ...
<lool> mikeul: So you don't have the /dev/pts errors etc. at least
<ogra> i should be :)
<lool> mikeul: Could you paste the contents of your fstab?
<ogra> or lool for fixing the wikipage but not filing a bug :)
<ogra> originally we had a sudo in front of the qemu command there ;)
<mikeul> ogra: I already was the owner of the *.img because I had copied the original.
<mikeul> lool: here's my fstab: http://paste.ubuntu.com/383084/
<ogra> mikeul, i bet he meant the one in the image :)
<ogra> lool, by default rootstock adds /proc and nothing else
<mikeul> ogra: you're probably right, then I posted the wrong one of course.  I'll go get the one from the image.
<lool> mikeul: sudo mount -o loop <yourimg> /mnt; then paste the contents of /mnt/etc/fstab
<ogra> it will onyl contain a line for proc
<lool> Don't forget to umount
<ogra> unless you modified it manually
<mikeul> proc /proc proc defaults 0 0
<ogra> i think mountall is misleading here
<lool> I just have / in my fstab
<lool> Something like:
<lool> UUID=a5a3cdd1-1f8a-4070-8b86-5eb22d754897 /               ext3    relatime,errors=remount-ro 0       1
<ogra> you should have proc too
<ogra> afaik d-i adds it
<ogra> at least it did
<ogra> though having it wont do any harm
<ogra> hmm, you said your image was writable now ?
<ogra> [    5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
<ogra> that somehow doesnt indicate it is
<lool> mikeul: Here it boots a karmic chroot with just / added
<lool> mikeul: i do need that devtmpfs.mount=0 too though
<ogra> i think the fstab error is bogus and just a wrong errormessage
<mikeul> that "ro" came from my kernel cmd line.
<lool> mikeul: You don't need /proc
<ogra> it tries to mount / rw but cant
<lool> mikeul: But you want / in fstab
<mikeul> what's "d-i"?
<lool> debian-installer
<ogra> you dont need / in fstab
<lool> ogra: Well let's see if it helps
<mikeul> I lied- I didn't have "ro" in my args anymore.
<lool> mikeul: Please add a / line in /mnt/etc/fstab
<lool> mikeul: Change the UUID to the one you get with "file <your image>"
<ogra> lool, i never had any other fstab than the one created with rootstock for my qemu images
<ogra> Mounted root (ext2 filesystem) readonly is a clear indicator that something with the image permissions is wrong
<ogra> mountall might remount it rw if it finds it in fstab indeed
<lool> I get the same read-only mount output, the same / and /tmp output, but then it proceeds, I'm pretty sure adding / in fstab will help
<ogra> sure, because mountall remounts with the fstab options if something is added
<ogra> but it works without so the image permissions are wrong
<ogra> do you remember asking me if my img is writable when we discussed the need of sudo ?
<lool> I don't think it's the same issue
<lool> mikeul said he owns the image already
<ogra> well, but i definately never needed an fstab entry
<ogra> and if that would become a requirement i'd remove the .img option from rootstock
<ogra> which is a sideeffect anyway, rootstock isnt intended as image builder
<ogra> but i'm sure it isnt a requirement ...
<ogra> else casper wouldnt work either :)
<ogra> or ltsp ... or anything else that doesnt use an fstab
<lool> You can't compare these, they are initramfs based
<ogra> well, still
<ogra> it used to work all the time ... why should that suddenly become a requirement
<ogra> especially on a released system
<mikeul> OK, I added the / line in fstab and now it hung up in a strange place... http://paste.ubuntu.com/383113
<ogra> try running it without the serial console now
<lool> ogra: So I would recommend you generate a / entry in fstab
<ogra> lool, no
<ogra> lool, i would like to know why thats suddenly needed if i didnt need it throughout the whole karmic cycle and until last week when i used my last qemu image with lucid
<mikeul> from your chatter earlier, it sounded like I would be better off to create the img file from the tgz?
<ogra> no
<lool> ogra: I'm not sure I have the time to debug why it's needed, but you mentionned that d-i writes a /proc entry, it certainly writes an entry for / too, and you really want one
<ogra> rootstock is designed to crate a tarball ... so you can untar that to your root device for any system, the .img file is just used to run qemu actually ... but since people found it convenient i added the --keepimage option
<ogra> lool, it was never needed before
<ogra> not through the whole of karmic and not until last week in lucid
<mikeul> can I kill the qemu process w/o breaking my img?
<lool> ogra: You can stand on your argument, in practice it didn't work without it
<ogra> sure
<ogra> lool, i wouldnt have added --keepimage if it hadnt worked without it
<lool> ogra: So is there a process for people to create a bootable qemu image from root tarballs?
<ogra> i'm still sure it can be handled differently, and if not i'll drop --keepimage because it goes far beyond the purpose of rootstock to do anything HW related like writing UUIDs
<ogra> i'm actually working on fixes that even remove the persistent rules from udev to make sure there are no HW related bits
<ogra> lool, well, you know the process ... dd an image together, loop mount and untar
<lool> ogra: I'm asking where I can point people who want to achieve this
<lool> ogra: Including the fstab part
<ogra> feel free to add a rootstock errata page somewhere
<lool> I mean obviously it doesn't work without / in fstab right now; it's best to have it there anyway, so I'd like to make sure people who want to run qemu against an .img get it setup in some way
<ogra> mikeul, would you do me a favor ?
<mikeul> ogra: yes, I owe you one
<ogra> and mv fstab in your image to fstab.bakl, then touch fstab so you create an empty one and then run qemu with sudo ?
<ogra> *bak
<mikeul> btw, I have a console in qemu now.  I'm quite happy about that.
<ogra> you can move it back afterwards if it doesnt work
<lool> ogra: Were you using an initrd?
<ogra> lool, never
<ogra> lool, an i had the same prob the first time when i didnt use sudo because you insisted i wouldnt have to ...
<ogra> a chmod 766 solved it for me back then
<lool> ogra: I can reproduce mikeul's problem here without sudo being involved in anyway
<lool> Just commenting out / from my fstab
<ogra> and if you use sudo ?
<lool> It wont change a thing
<ogra> under karmic ?
<ogra> i really dont get why it worked for so many people including me all the time
<lool> Yes
<lool> Well I have an idea, but I didn't demonstrate it completely
<lool> It's quite time consuming to find out and I know adding / in fstab is really best
<ogra> well
<ogra> can we assume people using --keepimage will never use the filesystem on a real machine ?
<ogra> i guess its a two liner in /bin/installer to add it based on teh --keepimage option ... but it massively bugs me that it worked all the time without a single issue
<mikeul> ogra: I did your favor. Starting qemu as root, using an empty fstab, it again stopped after "One or more of the mounts listed in /etc/fstab cannot yet be mounted:"console
<ogra> ok
<ogra> thanks
<ogra> i'll follow lool's suggestion then and add the two lines to dump the img UUID into fstab for --keepimage and have a sleepless night over why it worked all the time :/
<mikeul> ogra,lool: I haven't understood everything that's happened here- why doesn't passing the "root=/dev/sda" kernel arg to QEMU work to boot the RFS?
<ogra> somehow mountall fuzzes around with the fstab entries during boot
<mikeul> I much appreciate the help.
<ogra> well, you also helped a lot :)
<mikeul> I'd like to continue to help, you might not have seen the last of me :)
<mikeul> lool, you wanted me to summarize suggested changes to RootfsFromScratch?
<ogra> great !
<lool> mikeul: Yes
<mikeul> Should I e-mail them?  Post them here?  Bug report somewhere?
<lool> You could do them in the wiki page, or mention them here
<ogra> ++
<mikeul> OK. That won't be until tomorrow.
<lool> I think it's a bug in mountall; either you need to pass rw to your kernel or you need to have the fs in fstab
<ogra> ah
<ogra> hmm, right, when we discussed the sudo stuff first thing i tried was rw on the cmdline ...
<ogra> only then it struck me that the img was readonly ... i re-used the same qemu command afterwards
<lool> So I just confirmed that without an fstab and with rw on the cmdline, it boots
 * ogra hugs lool
<ogra> lool, sorry for being such a hard opponent sometimes
<ogra> i know i annoy you with that
<lool> It's very energy consuming to fight each and every claim
<ogra> i'll try to improve but i knew it was working before and i didnt want to change code without knowing what was going on
<lool> I still believe people would be better off with a fstab with / on real systems (even virtual)
<ogra> yes, i'll add the code for --keepimage
<lool> mikeul: So recipe is vmlinuz from ports + rw and devtmpfs.mount=0 on cmdline
<ogra> for real systems we can add documantation
<mikeul> yeah, I just removed the UUID from fstab and booted with rw on the cmdline to test, and it worked.
<mikeul> How is devtmpfs getting in the way?
<ogra> udev in karmic didnt know about it, i think it steals /dev, not sure though
<ogra> devtmpfs is something new that only showed up in 2.6.32 kernels
<ogra> it pre-populates /dev so udev doesnt need to execute all its scripts to find the devices
<lool> I filed LP #527216 on the mountall issue
<ubot4> Launchpad bug 527216 in mountall (Ubuntu) "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527216
 * ogra subscribes
<ogra> heh, its tagged amd64 :)
<mikeul> I see.  Well, thanks again lool and ogra. I'm signing off.
<ogra> ciao
<ogra> oh, finally !
<lool> mikeul: devtmpfs doesn't have the /dev/pts dirs etc.
<ogra> my here document quoting works !
<lool> mikeul: lucid's mountall can cope with that, but not karmic's
<lool> mikeul: You don't need the devtmps arg for a lucid vm
<ogra> lool, i guess it wont do harm to use it with lucid though, would it ?
 * ogra thinks about a universal cmd we can put on the wiki
<ogra> i think it would just boot a little slower
<lool> ogra: Yes, I did mean for mikeul to document using "devtmpfs.mount=0 rw" for all dists, not just karmic
<ogra> right, given that i changed the kernel link on the page i'll do that for now
<ogra> http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/80
<ogra> lool, ^^^ fyi
<lool> ogra: Do you want to hardcode ext3?  I'd put auto there perhaps
<ogra> well, we format it ext3 anyway, but yes
<ogra> changed
<|nfecteD> does anyone have any idea why my beagleboard doesn't seem to want to use USB devices when running ubuntu arm?
<|nfecteD> i have a powered USB hub, yes
<|nfecteD> and USB devices work with angstrom and android
<|nfecteD> it does find the hub and devices during boot, but the blue lights that indicate that using are plugged in and ready for use never light up
<|nfecteD> got the same problem with debian too
<|nfecteD> (not the same kernel)
<Hoonse> hi guys
<rcn-ee> |nfecteD, web irc log only goes back to the start of the hour.... did your usb port work?
<rcn-ee> kblin, some news... I moved hardware around and i've been able to trigger musb problems on my rev Bx..  Strangely my C2 isn't having the issue..
<|nfecteD> rcn-ee: it works with angstrom and android, yes
<rcn-ee> |nfecteD, what board (bx/c2-3/c4) ehci/musb?
<|nfecteD> C4 ehci
<rcn-ee> okay..  have you touched u-boot at all... (my wiki relies on you leaving it at the factory version..)
<|nfecteD> i've changed the u-boot, yes
<rcn-ee> what version?
<|nfecteD> lesse...
<rcn-ee> i think 'version' prints it out... (in u-boot)
<|nfecteD> http://rcn-ee.net/deb/tools/u-boot-beagleboard-2009.08+r37+gitr1590f84007e2b50ad346a482fff89195cb04ff4e-r37.bin
<|nfecteD> should be that one
<rcn-ee> that's the problem...
<|nfecteD> U-Boot 2009.08 (Dec 01 2009 - 05:37:28)
<|nfecteD> (from beagleboard)
<rcn-ee> the C4 is still too new...  the ehci power setup is controlled thru u-boot, only the version on the C4 and the one listed here: http://www.angstrom-distribution.org/demo/beagleboard/u-boot.bin will work...
<|nfecteD> ah
<|nfecteD> thanks for clearing that up
<rcn-ee> no problem...
<|nfecteD> NEXT QUESTION (hoho)
<|nfecteD> rootstock...
<rcn-ee> i need to update the elinux wiki page...  (there's a note about the C4 at the top about it, but i need to test it on all boards)
<|nfecteD> I can't get it to enter stage 2
<|nfecteD> E: Second stage build in Virtual Machine failed !
<|nfecteD> is this because i try to build a lucid image in a karmic ubuntu?
<rcn-ee> what os/version are you initiating the rootstock call from?
<|nfecteD> Ubuntu 9.10
<|nfecteD> x32 (if it matters)
<rcn-ee> well the version that came with karmic, doesn't support lucid...  you need to tweak the rootstock script..
<|nfecteD> got a quick tweak on hand or should i just install lucid on the dev computer?
<rcn-ee> support for lucid was added to the trunk of rootstock, no *.tar.gz release files yet with the lucid change: "bzr branch lp:project-rootstock"  will get you what you need..
<Hoonse> can i delete the --serial ttyS2 flag from rootstock AFTER i made the image?
<rcn-ee> Hoonse, depends, but why did you add the flag?
<Hoonse> i made the image with rootstock and all works fine but now i dont want that the terminal listens on the ttyS2 port all the time
<Hoonse> i set the flag by making the rootstock image from ubuntu
<Hoonse> sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --dist lucid \
<Hoonse> --script fixup.sh --serial ttyS2 \
<rcn-ee> Hoonse, it'll be "/etc/event.d/ttyS2"
<|nfecteD> rcn-ee: thank you very much
<|nfecteD> hopefully now i'll be able to help myself for a while
<Hoonse> thanks i will try this now
<rcn-ee> Hoonse, just remove that file and it'll never start at boot...
<Hoonse> k i will try...
<rcn-ee> |nfecteD, your welcome, most things should be straightforward.. any other issues just post to the beagleboard group, as i'm not on irc at work...
<|nfecteD> alrighty :)
<rcn-ee> Hoonse, sorry, that was for Jaunty.. For karmic+ it's "/etc/init/ttyS2"
<rcn-ee> "/etc/init/ttyS2.conf"
<Hoonse> remove this?
<rcn-ee> Yeah, upstart reads that...
<Hoonse> and the ttyS1 3 4 ...?
<rcn-ee> --serial only modifies one... the rest are ubuntu default setups...
<Hoonse> k i am rebooting right now
<rcn-ee> Hoonse, the kernel will still post message on boot, so don't forget to remove "console=ttyS2,115200n8" from your boot.scr... the early bootstuff takes a kernel recompile...
<Hoonse> i did this before on the bootargs and on the ubuntu.cmd file (=boot.scr)
<Hoonse> i deleted the file but its still there...
<rcn-ee> Hoonse, by deleting the file, the 'login' part shouldn't show up... eveything else is just kernel message...
<Hoonse> the problem not the file
<Hoonse> but the login part still shows up...
<Hoonse> ohh wait a sevond
<Hoonse> second
<Hoonse> there is the ttyS2 file
<Hoonse> i will delete this...
<rcn-ee> well that doesn't make sense.. upstart -> "/etc/init/ttyS2.conf" calls "getty" -> prompt..
<Hoonse> yes sorry i deleted the tty2 not the ttyS2 file...
<rcn-ee> oh, easy miss...
<Hoonse> omg thanks now it works =) call me whenever you are in austria i will buy you a beer =)
<Hoonse> thanks
<rcn-ee> with 'console=ttyS2,115200n8' and '/etc/init/ttyS2.conf" gone, there will still be the intiall serial traffic.... something like 'quiet' in boot.scr would make it even less..
<rcn-ee> good to here Hoonse
<|nfecteD> oh yeah! rootstock entered stage 2
 * |nfecteD crosses fingers
<armin76> ogra: lool: NCommander: is dove gigabit eth?
<NCommander> armin76: it is
<NCommander> 1000 Mb/s, full duplex, flow control disabled
<armin76> oh nice, thanks
<NCommander> Makes shooting stuff across my LAN so much easier
<armin76> NCommander: when i'm getting one? *g*
<lool> armin76: I think only one port is native though
<zumbi> armin76: the question is when is dove-next (a comercial laptop) going to be selled out on the market :-)
<NCommander> armin76: when you sell your soul to Marvell :-)
<armin76> NCommander: oh, nice, i can sell it :D
<|nfecteD> can the GPIO pins in the expansion connector be used to trigger scripts?
<|nfecteD> when ubuntu is running that is
<|nfecteD> perhaps i should mention that im talking about the beagleboard :P
<lool> armin76: You already sold your soul 4 or 5 times
<lool> armin76: no mode hardware for you now
<armin76> i did? :D
<kblin> rcn-ee: pong
<kblin> rcn-ee: ok, for me it seems to be the hub's fault. I've switched hubs between my two beagles, and now the c3 is fine and the b6 is having problems.
<|nfecteD> rcn-ee: looks like rootstock locks up while unpacking the debs in stage 2... any idea what that might be?
<|nfecteD> Unpacking usbutils (from .../usbutils_0.86-2ubuntu1_armel.deb) ...
<|nfecteD> thats where it is
<|nfecteD> and has been for 30 minutes
<termitor> hello
<termitor> how to have the same theme on pc ?
<mygalaxia> hello
<mygalaxia> or can I find the theme for an arm platform x86 ubuntu thanks you
<persia> termitor: mygalaxia: The themes are precisely the same as on other architectures.
<rcn-ee> |nfecteD, can you pastebin your rootstock log?  i'll be back in a bit, tweaking a server..
#ubuntu-arm 2010-02-25
<persia> Noisi: Hey.  Did you not get an answer about your mysqlclient question yesterday?
<Noisi> only go to #sql , but i got no answer there
<persia> Bother.
<persia> Sorry I didn't answer you then: I ended up falling asleep.
<persia> So my memory is that you had a cross-compile environment but you wanted to try binaries without needing to compile them, is that correct?
<mikeul> ogra, it looks like you made all the necessary changes to RootfsFromScratch that we discussed yesterday.
<ogra> mikeul, yes, sorry, i didnt want users to run into problems
<mikeul> no problem, that makes sense.
<mikeul> I'll just have to find another problem I guess.
<persia> mikeul: What kind of problem do you like?
<mikeul> I'm not really looking for problems, they usually find me.
<persia> OK.  I usually have a reserve of issues available if you're looking for something :)
<persia> Also, we're having a mini-sprint on Thumb2 porting in about an hour, if you'd like to participate.
<asac> o/
<ogra> hmm, all languages are gone from our images again
<ogra> that wasnt the plan :/
<ogra> * Languages: es xh pt de fr bn
<ogra> * language-pack-${Languages} [i386 amd64 powerpc]
<ogra> oh, sigh
<dyfet> hmm...yea...
<ogra> StevenK, ^^^ can you change that post freeze ?
<asac> ok ... X is crashing badly on me :/
<asac> on x86 luckily ;)
<ogra> on armel or x86 ?
<ogra> ah
<ogra> in what way ?
<asac> i hit ctrl+enter -> boom
<asac> but only sometimes
<ogra> weird
 * asac upgrades and hopes there was a fix
<dmart> Hi guys
<ogra> hrm, a rootstock build of ubuntu-netbook hangs reliably in "unpacking iso-codes"
<asac> hey dmart
 * ogra wonders why that is
<ogra> hi dmart
<dmart> Hi there, sorry I'm late--- got sucked into a discussion about gdb
<asac> ogra: did we figure why ooo is pulled in for us now?
<ogra> all fixed and gone :)
<asac> cooool
<ogra> seems someone added language-support-$lang for all languages and all arches above
<ogra> the -support packages pull in thesaurus and packages that in turn pull in oo.o
<asac> hmm
<lool> dmart: You mean you hanged in a discussion with gdb
<ogra> usually we only have -pack and -pack-gnome
<asac> lol
<dmart> lool: ?
<lool> dmart: hanging... gdb...
<lool> oh well
<dmart> lool: well, segfaulting
 * lool tried to do silly jokes
<lool> I suspect asac has pity for my jokes
 * dmart was slow on the uptake
<dmart> Anyone ready to take a look at https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<dyfet> we can step you through it...
<asac> so ...
<asac> i think it would be time to add a column for the current status there
<asac> or move all the fixed/invalid bugs to a separate table
<lool> Just drop them?
<lool> There's wiki history, we don't need to clutter the page for fixed bugs do we
<asac> not sure
<lool> dmart: Got blocked on the gcc atomic builtins qemu changes by their ppc maintainer who objects to using them in general, and for ppc in particular; need to redo the patch to only use these for arm/thumb    :-(
<asac> having a page that shows what was done isnt that bad either
<asac> are there instructions how to do that without gcc atomics? ... /me checks
<dmart> I added some info on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<dmart> Still a bit high-level, but better than nothing (hopefully)
<lool> << On ARMv7, there is a DMB instruction which performs this operation. There is also an MCR p15, ... operation which is backwards-compatible the earlier architecture versions.  >>
<lool> Frankly, I much prefer getting the code to use atomic builtins in, even if only for arm/thumb in my case
<dmart> If you use the atomics, you shouldn't need to use these low-level barriers.
<dmart> ...which are obviously totally arch-specific and non-portable.
<lool> I think it would help portability to use them by default, but apparently the ppc qemu maintainer prefers holding to comments from 2005 to judge of their usefulness
<dmart> Did you understand why the qemu guys were resistant>?
<lool> dmart: Yeah we're on the same line
<lool> dmart: No; let me find the thred
<lool> http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01142.html
<dmart> Also, it's easier to write buggy atomics code than almost any other sort of code... so the KISS principle definitely applies ;)
<lool> I checked with another qemu maintainer what he thought of it, and that's the person who suggested I should ask for benchmarks
<lool> dmart: I'm also pretty sure the code is getting abused in the case of qemu
<dmart> What are atomics used for in qemu anyway?
<lool> Heck, I could have proposed a patch to use pthread mutxes, that would have been fun
<lool> dmart: locks
<lool> Which actually sucks
<StevenK> ogra: That's a silly change, sigh
<dmart> Does qemu use multithreading to emulate high-level processes, or something?
<ogra> StevenK, yeah, agreed
<lool> dmart: Hmm good question, it can emulate two CPUs though
<lool> I suppose that's only possible with threading or multiple processes, but suspect they use something closer to threading to share memory
<lool> (it actually uses multiple hosts CPUs when emulating multiple guests CPUs)
<dmart> Right.  Well, you can certainly implement fast spinlocks using exclusives and barriers if it's really needed, but that's probably in issue to worry about when the spinlocks are found to be a bottleneck?
<lool> dmart: Interestingly, the gcc atomics doc recommends not to use them for spinlocks
<dmart> Really, I missed that
<asac> to not use what? the gcc built ins
 * dmart looks
<asac> ?
<lool> Hmm actually I can't find that reference any more
<asac> ;)
<dmart> Certainly you should use __sync_lock_* for spinlocks (and not the other funcs)
<asac> lool: he seems to be fine to use those for thumb2 ... so whats the problem?
<lool> dmart: Sorry, got confused by this comment http://sourceware.org/ml/libc-alpha/2005-06/msg00132.html
<dmart> They (can) have reduced barriers which make them less of an overhead.
<lool> dmart: ack, that's what I used
<lool> dmart: There's no technical problem here, it's mostly politics
<lool> the ppc maintainer didn't even say which part of the 2005 discussion he was referring to
<asac> right.
<asac> but do we care about ppc
<lool> i.e. performance, should be in libc or whatever
<asac> they seem to be fine if we submit that for arm
<dmart> Not sure about the comment there--- certainly if you try to take a spinlock and find it's contended, then you can't just loop, because the kernel does not know to schedule the lock holder.
<lool> asac: Yes, only choice I have for that bug
<asac> i dont see that beging a problem
<asac> if folks are happy with their current ppc solution etc.
<dmart> You need to do a thread yield (and even that's inefficient--- the kernel still doesn't know what to schedule next)
<asac> then let them keep that
<dmart> If we can use the GCC atomics for arm as a first step, that's probably the best approach.  They can be optimised later if this looks like a significant benefit.
<dmart> This is certainly no worse than arch-specific implementations in general.
<lool> I wonder whether they would accept a configure flag to use them
<dmart> #ifdef __arm__ ?
<lool> I was thinking #ifdef ppc, use_gcc_atomics=no
<lool> :-)
<lool> Anyway, it's politics; I will eventually sort it out with upstream
<dmart> Maybe.  The other arches might have a view on this though.
<lool> there's no complexity here
<dmart> ok
<lool> I wanted to share the discussion with you because of the comments on gcc atomics
<dmart> Sure, that's useful, thanks.
<dmart> The main reason for emphasising the atomics is we want to quickly port to an implementation which works with v7 and Thumb-2, without everyone needing to understand the low-level details (which make my brain hurt a bit ;) )
<dmart> But anything can be optimised in the future
<dmart> ...
<dmart> asac, all: Should we review through the status of items on https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ?
<dmart> We should identify unfixed or blocked packages.
<asac> yes
<asac> so erlang
<asac> is TODO
<asac> and gmp still
<asac> dyfet: ^^
<asac> we already discussed gmp last time, so we dont need to do that
<asac> not sure if we want to go through ffmpeg
<asac> maybe that would make sense
<persia> erlang has code-generation.  As does parrot.  That might be an interesting set of topics.
<asac> libmad is another candidate
<dmart> ffmpeg has optimised assembler, but that was already dealt with
<asac> ffmpeg is done?
<asac> oh right
<asac> its in the last column
<dmart> It would be good to note on this page whenever something is resolved
<asac> 12:10 < asac> i think it would be time to add a column for the current status there
<asac> 12:10 < asac> or move all the fixed/invalid bugs to a separate table
<asac> so yes
<dmart> Would it make sense to trawl quickly through the issues with bugs raised to classify them?
<dmart> I can add a resolved column
<asac> yes
<asac> ok i can cancel my edit
<dmart> Oh, ok
<asac> either you say which packages are still not resolved
<asac> or the other way around ;)
<dmart> Shall we work through?  Probably won't take long.
<asac> ok boost*
<asac> is done
 * asac updates the wiki if thats ok
<dmart> ok, if you want
<asac> cacao-source?
<asac> thats still open
<dmart> hang on
<asac> bugwise
<persia> cacao was recently removed in Debian.  Do we need it?
<dmart>  boost1.38 is not resolved, what happened to that?
<persia> Should have been dropped from the archive.
<dmart> Also, the boost1.41 source package was not changed (or this isn't documented in the bug)
<asac> dmart: its not in the archive anymore
<asac> https://edge.launchpad.net/ubuntu/+source/boost1.41/+changelog
<asac> boost is fixed
<asac> except 1.38 ... but thats not in the archive anymore (too old)
<dyfet> 38 was dropped, 40/41 was patched
<dmart> Ah, ok, I didn't scroll far enough up the bug.
<dmart> asac, can you note those?
<asac> yes
<asac> already done ;)
<dmart> ok, thanks!
<asac> djvulibre
<asac> -> done (we checked that last week and evven added a safety belt)
<asac> erlang
<asac> -> not done
<asac> evolution-data-server -> done
<asac> ffmpeg resolved
<asac> gcc-4.4 -> was never considered an issue, e.g. is probably right (
<dmart> gcc-4.4 is under continuous maintenance, so we can mark that an not needing specific action here.
<asac> ack
<asac> glib2.0 -> done (atomics by dmart ;))
<dmart> hmmm, I remember now
<asac> gmp -> not yet done ... discussed last time; dyfet is on it and i was told he bumped prioritiy now
<dyfet> there is an upstream issue with configure tests...
<asac> for glib?
<dyfet> gmp
<asac> ah
<dmart> politics or technical? ;)
<dyfet> yeah...
<dyfet> they want never to do try_compile tests, and use the tripplet to identify archs only...
<asac> they are dumb ;)
<dyfet> of course armv7/thumb2 is still "arm" as far as target arch's go...
<asac> try_compile isnt that bad
<asac> try_run is bad
<dmart> Hmmm, that only works on x86 where the triplet identifes the arch version...
<dyfet> a bit like lool's issue in qemu ;)
<asac> i dont see that we can do it without try_compile, can we?
<dmart> Just checking the GCC version number might be considered adequate.  But try_compile felt more reliable...
<asac> i agree with dmart
<dyfet> me too
<asac> dmart: what version number is lower bound?
<asac> 4.1.0?
<dmart> I'm assuming lucid GCC is the bound (i.e. 4.4.3)
<dmart> This is not quite true, but it's a reasonable approximation
<asac> hmm
<asac> anyway.
<asac> i think we can use try_compile and just patch it
<asac> push it to debian
<asac> and let democracy decide at some point
<asac> most likely other distros will pick it up too and then upstream is alone ;)
<dmart> (by "reasonable approximation" I mean "safe approximation")
<dyfet> okay
<dmart> You might also run nm on libgcc.a.  But there's no guarantee the functions won't turn fully into builtins in the future...
<asac> dyfet: lets just get the work done first and then care about politics
<asac> also CC me on upstream discussion ;)
<dyfet> well, we need to know in this case if we are thumb2 or not otherwise we break debian on armv4, etc...
<dyfet> so try_compile seems the safest way by far
<asac_> right
<asac_> reconnect ;)
<dmart> ok, so gmp is in progress
<asac_> dyfet: so you have the patch?
<dyfet> I did not do a try_compile patch, but I can do so quickly after the sprint
<asac_> give it to me ... also forward me upstream discussion you had so far ... so i can poke them too ;)
<asac_> ok
<asac_> seems gmp will be fixed today
<asac_> i think the next two are all not-for-us (klibc, libgc)
<asac_> then we have libmad
<asac_> which isnt fixed
<asac_> and llvm
<asac_> both not fixed
<dmart> Who is handling klibc?
<asac_> dmart: i thought it was toolchain/kernel folks
<asac_> actually i thought there are no real issues there.
 * asac_ grabs the filtered files
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:1:  mov     pc, r3
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S:     mov     pc, lr
<dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S:     mov     pc, lr
<dmart> I'd need to look at the source package to see whether that matters.
<asac> yeah
<asac> i think it matters
<dmart> Probably we should raise a bug on this one.
<asac> we should use BX lr
<asac> unless i am mistaken ;)
<asac> dmart: right
<dmart> Yes... though I also see #ifndef __thumb__ ... #ifdef __thumb__ ; I don't know which one is actually built
<dmart> (in setjmp.S)
<asac> hmm
<asac> bug 527720
<ubot4> Launchpad bug 527720 in klibc (Ubuntu) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527720
<asac_> dmart: even for thumb it uses #else /* __thumb__ */
<asac_> mov pc, lr
<asac_> line 78
<dmart> Yes, that's probably bad (actually, worse than using it in ARM)
<asac_> feels like its safe to use bx lr there
<dmart> Probably yes.  I'm wondering whether anyone builds this for Thumb-1
<dmart> duh
<dmart> that doesn't matter, ignore me ;)
<asac_> mov     pc, r3
<asac_> thats just bx r3?
<asac_> dmart: ?
<persia> Yes.
<dmart> Providing r3 is derived from a return address
<dmart> (I think that's the case here)
<saeed> latest lucid-netbook-armel+dove doesn't aultomatically login, any idea which user&password should I use?
<asac_> ok let me do the patch then
<lool> saeed: ubuntu no password
<persia> dmart: Why wouldn't bx r3 work for an arbitrary branch address?
<saeed> lool: thanks
<dmart> persia: generally, yes.  But if the address is detemined by some arithmetic or something the thumb bit (0) might not be set correctly
<persia> Aha.  Thanks for the explanation.
<asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch
<asac_> attached to bug 527720
<ubot4> Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720
<dmart> We still need to check this code isn't built with -marm
 * dmart greps for -marm
<dmart> not found, probably OK
<dmart> ...
<asac_> dmart: the patch only touched ifdef __thumb__
<dmart> Ah, actually there is a problem
<asac_> so it should be safe even if we build with -marm ;)
<asac_> dmart: what problem ?
<dmart> The assembler always defaults to ARM
<asac_> right
<asac_> so we build with arm here ;)
<asac_> but we could build with __thumb__ now
<asac_> using this fix
<dmart> This is preprocessed assembler, to __thumb__ will be defined (by the GCC defaults)
<dmart> *so
<dmart> So I think we're OK
<dmart> Actually the functions will get assembled as Thumb because they both have the .thumb_func firective.
<dmart> *directive
<dmart> So this is probably fine.
<asac> ok
<asac> so ... i think we are set with this patch?
 * asac thinks someone should try that out
<dmart> vfork.S needs patching too
<asac> dmart: i patched that ;)
<asac> check the patch
<asac> 13:02 < asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch
<asac> oh
<asac> i even failed ;)
<dmart> -er- I mean setjmp.S needs patching
<asac> yes
<asac> i just failed to produce a patch ;)
<asac> new patch attached
<asac> http://launchpadlibrarian.net/39762270/klibc-thumb.patch
<dmart> Yes I think that looks OK.
<persia> Um, not all the changes in vfork.S from the first patch appear in the second patch.
<asac_> persia: ?
<dmart> I think the second half of the first patch is a headerless non-unified diff of setjmp.S (or something)
<asac_> persia: forget the first patch ... not sure why it was busted
<asac_> right ... what dmart said
<asac_> i am sure i had >> for the second part
<asac_> but apparently i missed -u
 * dmart is just making it up really
<persia> Ah.
<persia> Yes, that does look right (if confusing)
<asac_> so lets continue (i marked it as "has patch" in table
<asac_> libgc is next
<asac_> that one is doko business
<asac_> doko: fixed in 6.8-1.2ubuntu1
<asac_> so now to libmad
<asac_> what are the hits?
 * asac_ checks filtered files
<dmart> Looks like an attempt to address an inline data or jump table -- should be a simple fix
<dmart>  ./libmad-0.15.1b/imdct_l_arm.S:    add     r2, pc, #(imdct36_long_karray-.-8)
 * asac_ looks at porting page
<asac_> so just adr r2, pc ?
<asac_> hmm
<asac_> nope
<asac_> adr r2, imdct36_long_karray-.-8
<asac_> err
<asac_> adr r2, imdct36_long_karray
<dmart> The trouble is that the pc is a bit unpredictable depending on the code alignment
<persia> And this is likely to be an alignment issue, right?
<dmart> Search the porting page for "getting the address of local data in the text section"
<asac_> right
<asac_> i think we already discussed that last week ... and i remembered that adr is the right way ;)
<dmart> Looking at it though, I don't know what the data is doing in .text
<dmart> Maybe it would be better to push it into .rodata
<dmart> (it's not code)
<asac_> #define K14  0x0cb19346
<asac_> if thats used it means we have preprocessed assembler?
<asac_> e.g. we can use #ifdef __thumb__ ?
<dmart> This is really a cleanup change, so we probably don't even need that: we just want to switch from a less portable to a more portable way of addressing the data.
<asac_> are we sure the data isnt modified?
<dmart> I don't think it will be.  It's in .text which is not usually made writable
<dmart> My guess is this is a table of precomputed data to speed up the imdct calculation.
<asac_> right
<dmart> The simplest option is to leave it where it is and use adr to address it.
<asac_> heh ;)
<asac_> would be interested in how to do it with rodata though too
<asac_> anyway let me do the patch ... one moment
<asac_> oh .. adr is #ifdef __thumb__ or > armv4t ?
<asac_> dmart: ?
<dmart> I suggest no #ifdef.  adr really is the same instruction (just via a pseudo op which makes sure it's really correct)
<dmart> Oh, hang on a minute... this code is built as ARM (as default behaviour again)
<dmart> I suggest to do the adr patch anyway; it's cleaner
<asac_> yeah
<dmart> Or if you want we could try building it in Thumb with
<asac_> ok
<asac_> one sec
<dmart> #ifdef __thumb__
<dmart> .code 16
<dmart> #endif
<asac_> .code 16?
<dmart> (Or .thumb, it's a synonym)
<asac_> ah
<asac_> let me first do the adr patch
<asac_> dmart: adr exists since a certain gcc/assembler version or what?
<dmart> I'll work on the other, since I did not explain myself well...
<asac_> http://pastebin.com/M6V3aqiW
<asac_> that would be the libmad adr patch
<asac_>  ;)
<asac_> let me attach that to the bug unless you shout
<dmart> asac_: I think adr has been there for a long time; unless someone is using really ancient tools it should work
<asac_> yeah
<asac_> cool
<asac_> ok attached
<asac_> next is llvm
 * asac_ goes and greps
<asac_> hmm. that seems to be more extensive ;)
<dmart> There is an ongoing bug thread conversation for this one.  Basically, the jumping in/out of JITted is not interworking aware.
<asac_> http://paste.ubuntu.com/383646/
<asac_> :/
<asac_> ok ... so is on the poirting page what to do for this kind of jump in/out from arm to thumb and vv.
<asac_> ?
<dmart> I think so; I pointed Xerxes RÃ¥nby at this, but I haven't had feedback yet.
<dmart> Probably modifications are only needed in a few places, but it will take someone familiar with llvm to know where
<asac_> hmm
<dmart> Probably best to label this as under discussion for now.
<dmart> Do we know the priority of llvm?  Does much depend on it?
<asac_> so
<asac_> needs investigation; potential code gen; doko: only used in openjdk-6-jre-zero when using shark
<asac_> thats the comment
<asac_> doko seems to think its ok
<asac_> oh
<asac_> well not sure if one can interpret that out of the comment
<dmart> I think it's not used for openjdk-6 by default (some separate, Thumb EE based JIT is now contributed)
<dmart> ...in openjdk-6
<asac_> according to our table llvm has zero rdepends
<asac_> (priority)
<asac_> i think we can move on and come back to llvm later
<asac_> mono ... i have the cherry pick staged on my disk
<asac_> the one we discussed the other day ... besides that we found to be fine?
<asac_> or still "needs more investigation" ?
<dmart> I can't remember the discussion now... was there interworking stuff to fix (in addition to the atomics)?
<asac> dmart: we had discussion in #mono ... with vargez ... from what i recall we found one more patch
<asac> but besides from that the outcome was that it should be ok wrt to interworking
<dmart> oh yeah, I'd forgotten that was about the same topic...  yes I agree
<asac> i have that patch locally ... waiting for a3 freeze to be lifted
<asac> that hd isnt wired up, so i can show it right now
<dmart> OK, I'm happy to wait :)
<dmart> Next package?
<asac_> 15:43 < dmart> <vargaz>Ihttp://lists.ximian.com/pipermail/mono-patches/2010-February/166945.html
<asac_> thats the patch ;)
<asac_> yes
<asac_> bug 514232
<ubot4> Launchpad bug 514232 in newlib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514232
<asac_> " investigate if its used - affected code is on places like crt0.S where it may not be a problem (dmart)"
 * asac_ apt-get source newlib
<asac_> dmart: why do you think its not used?
<asac_> oh
<asac_> seems that it uses ifdef _-thumb__
<asac_> like:
<asac_> #if defined(__thumb__) || defined(__thumb2__) blx   r3
<asac_> #else mov     lr, pc mov     pc, r3
<asac_> #endif
<asac_> .LC24:
<asac_> in ./libgloss/arm/crt0.S for example
<asac_> so ./libgloss/arm/crt0.S definitly is fine ... checked all uses of mov
<dmart> Yes, this package generally looks like Thumb-2 was thought about by someone.
<asac_> then we have ./libgloss/arm/redboot-crt0.S: ... which probably is marm
<asac_> but even that has thumb ifdefs
<asac_> so ... cool. lets scratch it
 * asac_ marks it invalid and drops comment in bug
<dmart> OK
<asac_> next is ocaml
<asac_> bug 514235
<ubot4> Launchpad bug 514235 in ocaml (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514235
<asac_> i marked that as invalid already
<asac_> so the assembly isnt used it seems
<asac_> i think i checkd build system and also even added bogus code to the asembly that would trigger a build failure ... to no result
<dmart> ok
<ogra> did you note that a full new ocaml eneterd from debian yesterday ?
<ogra> *entered
<asac_> ogra: new upstream?
<ogra> bug #526073
 * ogra checks
<ubot4> Launchpad bug 526073 in xstr (Ubuntu) (and 51 other projects) "[OCaml 3.11.2 transition][round 3/6] Please rebuild packages involved in OCaml transition (universe) (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/526073
<asac_> they do a transition during freeze?
<asac_> thtas annoying
<ogra> ah
<ogra> its the same ocaml
<asac_> ok ;)
<ogra> just the depending packages
<persia> Please check with sgnb about that.
<ogra> sorry for the noise :)
<persia> It's on hold right now.  james_w is expecting to do the next round of syncs once the freeze lifts.
<asac_> ocaml-3.11.2$ find | xargs grep arm.S
<asac_> ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */
<asac_> so there is no match for that arm.S file that has the code
<asac_> not sure if i am missing something
<ogra> oh, wait, i'm wrong
<ogra> a new ocaml came in of feb 15th
<ogra> silly version numbers
<persia> And the transition is in process, and the transition team is working to make sure it builds on armel.
<asac_> dmart: do you see any way that arm.S could be used in that project?
<ogra> 3.11.1-2 to 3.11.2-1
<asac_> persia: they do thumb2 porting ;)? i doubt that
<asac_> most stuff doesnt fail to build
<ogra> well, i think the new ocaml at least deserves a new grep run on the new package
<asac_> i did now
<persia> asac_: They are testing against qemu-arm-static and lool's qemu, so they should notice breakage as well.
<asac_> also i did the last run last week
<dmart> I guess so.  Probably there has been no change relevant to us...
<ogra> i think its unlikely something changed but you never know
<asac_> the grep above is from the current lucid
<asac_> 13:53 < asac_> ocaml-3.11.2$ find | xargs grep arm.S
<asac_> 13:53 < asac_> ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */
<asac_> ok ... moving on.
<asac_> openssl
<asac_> we didnt create a bug for that because:
<asac_> "seems ok - only armv4 files affected - verify that those are not used for modern arm "
<asac_> so we should double check that now to scratch it forever
 * asac_ apt-get source openssl
<asac_> we have a .pl file with assembly :) ...
<asac_> ./openssl-0.9.8k/crypto/aes/asm/aes-armv4.pl:	mov	pc,lr			@ return
<asac_> i think that file is used
<asac_> there is no other arm file in aes/asm
 * asac_ looks at build log
<asac_> https://edge.launchpad.net/ubuntu/+source/openssl/0.9.8k-7ubuntu6/+build/1492868
<asac_> http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz
<asac_> hmm ... dont see that armv4 is used somewhere
<asac_> http://paste.ubuntu.com/383659/
<asac_> thats the grep
<asac_> any idea how those .pl files are used in that build system?
<asac_> next one would be pixman
<asac_> bug 514237
<ubot4> Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514237
<asac_> seems i marked it as invalid
<asac_> "Checked this. Its a false positive. the mov isn't used in combination with pc etc. ... the only use of it is in a ifdef _MSC_VER block ... e.g. windows only."
<asac_> so its a MS thing
<asac_> dmart: ^^
<asac_> ?
<dmart> I think so; pixman is actively developed against Thumb-2 anyway I think.
<asac_> postgresql-8.4 -> is fixed in bzr or even uploaded in archive already
<asac_> was just atomics
<asac_> qemu-kvm -> not sure ... bug 514252
<ubot4> Launchpad bug 514252 in qemu-kvm (Ubuntu) "[arm] (might) need porting to thumb2 (affects: 1)" [Low,In progress] https://launchpad.net/bugs/514252
<asac_> lool: ?
<ogra> i think lool is on that ?
<asac_> did you do the swp atomics?
<asac_> or do you need help? or is this the issue we talked about above?
<asac_> ok seems it has a patch
<asac_> http://launchpadlibrarian.net/39067738/0001-Detect-and-use-GCC-atomic-builtins-for-locking.patch
<asac_> lool: planning to upload that?
<dmart> ^^ For openssl, some nasty hacks are used to enable compatibility with interworking, but the hacks look like they should work
<asac_> dmart: do you understand the .pl files and how they are used?
<asac_> lool: qemu-kvm just uses atomics for resetlock and testandset ?
<asac_> or is the patch just a first revision?
<persia> The .pl files for openssl are neither used in the build system nor installed int he package, and there seems to be a sufficiently comprehensive test suite that we'd notice an issue.
<asac_> persia: we wont notice mov.*pc style things unless we are using smp afaiu
<asac_> we could add some bogus syntax stuff and see if it causes some failure
<persia> Ugh, so we'd have to run the test suite on SMP to know if it's an issue?
<asac_> no ... we have to read the code ;)
<asac_> and find out if its run
<asac_> if its run its an issue ... if not, its not
<dmart> The mov pc issues will show up independently of SMP
<asac_> dmart: how will it show up?
<dmart> crashes
<dmart> The issue for SMP is the atomics
<asac_> hmm ok
<persia> Then I'm *really* confident that openssl is just fine.
<asac_> isnt openssl testsuite run during build?
<persia> That's a massive test suite.
<asac_> yeah
<asac_> so its not run? /me would think security would be damn hard about having that enabled
<dmart> openssl looks OK to me (if a bit nasty)
<asac_> dmart: where do you see the nasty bits? (just for education)
<persia> asac_: It is run during build, and it succeeded in http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz for all four runs.
<asac_> like you said there was interworking ... where do you spot that?
<asac_> persia: nice
<asac_> so yeah. openssl is off our list then
<asac_> postgres is covered, qemu-kvm seems to be in progress (lets wait for lool)
<asac_> next would be qt4-x11
<asac_> is commented to have a webkit copy
<asac_> webkit is invalid i found: bug 490371
<ubot4> Launchpad bug 490371 in qt4-x11 (Ubuntu) "Atomic operations not safe for ARMv7,Thumb-2 and multicore (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/490371
<asac_> bug 514255
<ubot4> Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255
<asac_> ok so webkit part is invalid (we can check that when we come to webkit)
<asac_> and qt4-x11 needs atomics
<asac_> though odd that it builds
<asac_> NCommander: qt4-x11 builds?
<asac_> NCommander: e.g. is bug 490371 a none issue?
<asac_> "In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM"
<asac_> seems its built using armv6?
 * asac_ waits for qt4-x11 sources to arrive
<ogra> i think there was a bug cjwatson worked on
<ogra> which he could only solve by switching to v6
<asac_> from v5?
<asac_> or v7?
<ogra> from using the default (v7)
<dmart> I think this uses LDREX/STREX, if building for ARMv6.  Originally the build system did not recognise ARMv7 and fell back to the older SWP code causing ftbfs
<dmart> This was since bodged to lie to the build system about the architecture version so the v6 code is used, IIRC
<asac_> oh
<asac_> right
<asac_> so we might want to fix the build system
<asac_> or leave it as it is
<asac_> NCommander: can you fix the buildsystem of qt4-x11 to understand v7?
<NCommander> asac_: its on my TODO behind OOo
<asac_> NCommander: arent you idle all the time witing for ooo to build?
<NCommander> asac_: no, because i don't do full builds
<asac_> NCommander: also i think that ooo is not higher priority than thumb2 ... its same priority
 * NCommander just rebuilds the libraries I need, and wait at most 30 minutes for a full rebuild
<ogra> qt4-x11 (4:4.6.0-1ubuntu2) lucid; urgency=low
<ogra>   * Make libqt4-dev depend on libx11-dev
<ogra>   * In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM
<ogra>  -- Jonathan Riddell < jriddell@ubuntu.com>   Tue, 08 Dec 2009 13:30:39 +0000
<ogra> there we go
<NCommander> asac_: I was informed otherwise by davidm
<asac_> NCommander: but you wait 30 minutes ;)
<dmart> asac_, NCommander: we should probably note down qt4-x11 for a SMP safety review
<asac_> you can surely work on something ;)
<asac_> anywway
<asac_> dmart: wouldnt that show up in our greps?
 * ogra goes to look for Riddell 
<NCommander> dmart: if you have a few minutes, can you help me grok the C++ ABI?
 * NCommander has found where OOo blows up
<asac_> ok i have a call in 10 ... so i think we are over
<asac_> we are down to four packages or so
<dmart> Not really - this is about whether barriers are used correctly.  It's mainly an issue for packages which have their own hand-crafted atomics using the ARMv6+ primitives (LDREX/STREX) where SMP may not have been fully tested
<asac_> out of which most are fixed
<asac_> dmart: oh ok
<asac_> so anything using ldrex etc. is subject to review
<dmart> Ideally
<asac_> but afaik we grepped for ldrex
<dmart> Oh, yes.
<dmart> I mean grep can't tell us if it's wrong; but it does identify what's worth looking at.
<asac_> bug 451553
<ubot4> Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553
<asac_> dmart: right. thats what i meant
<dmart> I forgot we grepped for that too
<dmart> ok, I guess we are pretty much done
<dmart> Unless people have questions
<asac_> the rest is: thunderbird -> fixed
<asac_> upx-ucl -> i think in invalidated that
<asac_> bug 514254
<ubot4> Launchpad bug 514254 in upx-ucl (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514254
<asac_> oh no ;)
<asac_> but webkit:
<asac_> bug 514255
<ubot4> Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255
<asac_> bug 514257
<ubot4> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514257
<asac_> so upx-ucl and xine-lib are still todo for main/important
<asac_> and the qt4-x11 smp review
<asac_> wiki page should be more or less up-to-date
<asac_> ok me prepares for a call ;)
<dmart> OK, thanks
<NCommander> dmart: if your around in about an hour, I need to pick your brain on unwind tables, and the fun of ARM C++ exception handling :-)
<asac_> thanks dmart for your time again
<ogra> <ogra> Riddell, in qt4-x11 4:4.6.0-1ubuntu2 you set -arch armv6, do you remember the reason for that ?
<ogra> <Riddell> I did?
<ogra> <Riddell> where?
<asac_> and everyone else ;)
<ogra> <cjwatson> ogra: I do, it was because there was a specific armv6 implementation of some bits
<ogra> * sabdfl hat die Verbindung getrennt (Read error: No route to host)
<ogra> <cjwatson> the default was arm, and wasn't good for armv7
<ogra> * sabdfl (~sabdfl@ubuntu/member/sabdfl) hat #ubuntu-devel betreten
<asac_> bug 509006
<dmart> NCommander: Not something I know too much about, but I'll see if I can draft in someone else
<ogra> <ogra> do you remember if it was assembler ?
<ubot4> Launchpad bug 509006 in linux-mvl-dove (Ubuntu) "[dove] hibernation failed to resume (affects: 1)" [High,Confirmed] https://launchpad.net/bugs/509006
<ogra> <cjwatson> the armv6 code doesn't handle multicore, but is otherwise much better than what was there before
<ogra> <cjwatson> yes
<armin76> spam
<asac_> ogra: ... cant you paste tsuch huge pastes in pastebin?
<NCommander> dmart: that would be useful
<asac_> bug 509006
<asac_> bug 451635
<ogra> asac_, ah, come on ... 10 lines ...
<ubot4> Launchpad bug 451635 in alsa-driver (Ubuntu Karmic) (and 1 other project) "Sound not working on dove Y1 board (affects: 1)" [Medium,New] https://launchpad.net/bugs/451635
<asac_> bug 452156
<ubot4> Launchpad bug 452156 in linux-mvl-dove (Ubuntu) (and 1 other project) ""Write-error on swap-device" while installing Ubuntu (affects: 1)" [Undecided,New] https://launchpad.net/bugs/452156
<ogra> but yes, i'll do in the future
<asac_> bug 451553
<ubot4> Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553
<asac_> bug 527148
<ubot4> Launchpad bug 527148 in linux-mvl-dove (Ubuntu) "dove fails to shutdown (affects: 2)" [Undecided,New] https://launchpad.net/bugs/527148
<asac_> ok that were my 10 ;)
<dmart> ogra: OK, I guess if "the armv6 code doesn't handle multicore" it needs looking at, so definitely add this to the SMP safety review table.
<ogra> yeah
<dmart> Thanks for checking
<ogra> added
<ogra> (if the wiki ever saves)
 * dmart wonders why the wiki is so slow
<lool> asac_: I think the gcc atomics patch is uploaded already??
<lool> It still FTBFS but not due to thumb/asm
<lool> dmart: Suggestions on how to fix the failure are actually welcome
<lool> It's float comparisons and gcc logic
<dmart> lool: which package is this?
<lool> dmart: /build/buildd/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm'
<lool> dmart: qemu-kvm
<lool> Oh
<lool> it's actually not th eplace I thought it was
<lool> I was looking at the wrong function the first time
<lool> dmart: http://paste.ubuntu.com/383679/
<lool> dmart: probably if defined(__arm__) && !defined(__thumb__)?
<lool> dmart: what's rndd/rnddm etc.?  I grepped the ARM asm reference card and the VFP one for "RN" and couldn't find it
<lool> Might be some gas syntax
<dmart> Hmmm, yes, I was just looking at that
<dmart> I think these opcodes (and the "f" asm constraint) are probably related to the obsolete FPA architecture (which is what the netwinder fp emulator code in the kernel emulated)
<dmart> This code won't work on any Ubuntu armel release
<lool> can't find it in http://sourceware.org/binutils/docs/as/ARM-Opcodes.html#ARM-Opcodes
<lool> dmart: Oh, so an older FPU?
<dmart> Yes.  Well, an older FP architecture.  I'm not sure whether there was ever much silicon implementing it...
<dmart> You can probably make GCC accept the code with -mfpu=fpa or something, but unless this code is being built to run inside qemu (and qemu emulates the instructions) I can't see how it's going to work...
<lool> dmart: Bah, I'm wasting our time
<lool> the asm was dropped upstream
<dmart> ah... good thing too :)
<lool> float64 float64_round_to_int( float64 a STATUS_PARAM )
<lool> { return rint(a);
<lool> }
<lool> (can't they just errr call rint()?  :-)
<ogra> probably something uses float64_round_to_int in the code ?
<ogra> and they were lazy
<persia> Or maybe they use this to force a cast somehow?
<lool> Nah I just think it's historical
<lool> rint is C99 just like qemu
<dmart> NCommander: looks like our tools guys aren't available this afternoon.  Would 1500 UTC tomorrow be OK for you?  I can try and grab someone for then.
<NCommander> dmart: that would work
<dmart> ramana: Hi
<dmart> NCommander: Looks like someone is available after all
<dmart> Ramana has been working with some of the Ubuntu guys (doko etc.) on the tools
<NCommander> hey ramana!
<ramana> hi NCommander
<NCommander> ramana: how goes your morning
<ramana> Ncommander: Not too bad.. it's now afternoon where I'm sitting ... It's not raining and that's a plus :)
<ramana> how goes yours ?
<NCommander> ramana: early morning conference calls
<ramana> NCommander: sounds like fun
<NCommander> ramana: I'm dealing with crashing on ARM with OOo with modern toolchains, which is being caused by a direct call to __cxa_throw
<ramana> ok
<NCommander> ramana: it begins to unwind the stack, and then blows up with a phase2 failure
<NCommander> __cxa_throw calls std::terminate
<NCommander> ramana: I know there were unwind table changes between jaunty->karmic (gcc 4.3 to 4.4/glibc to eglibc)
<ramana> do you know for what frame unwind_phase2 is in ?
<NCommander> ramana: not sure how to get that
<NCommander> I'm guessing is marked CANTUNWIND that shouldn't, or the inverse
<NCommander> ramana: the stack gets completely trashed so the debugger is of limited help
<ramana> can you get a backtrace from the point before it hits the throw to see what the frames are ?
<NCommander> ramana: I can try. OOo does some very very strange and evil things that make debugging it extremely difficult
<ramana> NCommander: The last time I tried looking at this was in September and I was stymied by not knowing enough about OOo.
<NCommander> ramana: I think I need to do an entire debug build of the entire stack
<NCommander> ramana: thats a multiday love affar :-/
<ramana> yes that sounds prudent to have.
<NCommander> ramana: unfortunately, since I don't have a small test case for this
<ramana> NCommander : Is this the standard OOo in the lucid packages or is this in your PPA ?
<NCommander> ramana: I'm working upstream; saner to build
<ogra> the std oo.o in lucid uses a jaunty lib that works around that bug
<ramana> ok
<NCommander> (although sanity in this case is extremely relatively)
<NCommander> *relative
<ramana> NCommander: is there any place where I or dmart could have a look at your chroot or libraries ? We can try doing some disass on the libraries / binaries ?
<NCommander> ramana: I'm just using standarding ubuntu jaunty, karmic, and lucid chroots
<ramana> NCommander: and the OO build tree you might have ?
<dmart> Presumably that's just apt-get source?
<dmart> Or are you working on something not yet in the archive?
<ramana> dmart: I think NCommander is working on upstream OOo
<dmart> (the bug is old though...)
<asac> NCommander: can you tell ramana how to build the package without the jaunty workaround so they can see the actual problem?
<asac> ogra: you said doko made packages available for you
<NCommander> asac_: that won't be useful without being able to debug it
<asac> that have that issue ... did doko als opush source for that?
<ogra> asac, yes, on jocote in his home
<ogra> not sure about the source
<NCommander> ramana: you can cause the issue by going into /usr/lib/ure/lib, and replacing libgcc3_uno.so with libgcc3_uno.so.karmic
<asac> NCommander: well. they want a way to reproduce. if you have a better way, then just go for that
<ogra> i always only got a bunch of .so's
<asac> NCommander: reproduce from source that is
<NCommander> asac_: you have to build OOo then from scratch
<NCommander> http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#ccache
<lool> asac: IIRC, the two binaries (really built and from jaunty) are installed in the libdir
<asac> NCommander: package sounds esaier ,)
<asac> debuild -b
<asac> wait
<asac> wait
<asac> ;)
<lool> asac: So the current builds of oo.o ship the borken binary in a different path
<NCommander> asac_: that won't work because it won't build OOo with debugging
<asac> fine if you can reproduce with upstream instrcutions
 * ogra kicks and punches qemu so it has dents and wrinkles 
<ogra> i dont love you anymore you darn thing !!!
 * ogra goes into a corner and sulks
<alecrim> i'm with some problem to bootup a minimal ubuntu image with N810. I freezes as you can see here http://pastebin.com/41gRjZuF
<alecrim> s/I/it/g
<Stskeeps> jaunty?
<Stskeeps> out of curiousity, got serial console
<Stskeeps> ?
<Stskeeps> and you are possibly running into the watchdog
<alecrim> Stskeeps, I generated rootfs using this procedure : sudo rootstock --fqdn n810 --login ubuntu --password ubuntu --imagesize 500M
<Stskeeps> ok, so lucid?
<alecrim> Stskeeps, karmic
<Stskeeps> mmk
<Stskeeps> and .33 is quite experimental there
<alecrim> Stskeeps, maybe the boot finished, but it does not show the serial. Old versions of ubuntu contain a /etc/inittab that I could force a login by serial, but not this one.
<Stskeeps> ah
<alecrim> Stskeeps, any idea?
<Stskeeps> check event.d? should be tty*
<alecrim> Stskeeps, thanks! I'll check it. I'll try lucid version, instead of karmic next time. let me see if I can get console
<Stskeeps> no, lucid is armv7
<Stskeeps> will not work on n810
<alecrim> Stskeeps, I didn't know :(
<NCommander> ramana: I've tied three babbage boards and one dove board into the OOo build
<NCommander> Which shoul dget drastically cut build times down
<NCommander> ^- armin76 :-)
<ramana> nice :)
<NCommander> ramana: the issue is I'm still not sure I'm going to get a proper backtrace
<NCommander> ramana: the UNO call pulls CXX exceptions across multiple threads/processors/evil
<NCommander> So even having a proper backtrace before the throw might not help
<NCommander> And I'm not sure stepping into the _Unwind_* will give me anything I'm going to be able ot grok
<ramana> joy
<NCommander> (although I'll prepare to do a debug build of libgcc)
<NCommander> ramana: is there a good way to debug the _Unwind_* functions and friends?
<alecrim> Stskeeps, it's working. http://paste.ubuntu.com/383843/
<alecrim> Stskeeps, actually /etc/init/ttyS2.conf is the correct place
<Stskeeps> close enough
 * DanaG wonders how much power it would take to get a mere Radeon 7500 sort of horsepower in an ARM.
<DanaG> Specifically, for the sake of compiz.
<Stskeeps> alecrim: does your lcd work?
<alecrim> Stskeeps, it's a basic image using linux-omap latest version(2.6.33). I got serial using a special HW from Nokia
<Stskeeps> ah, good
 * alecrim is a privileged person 
<alecrim> hehe
<Stskeeps> yeah, i have one too :P
<ramana> NCommander: I've never personally done this but I can dig around.
<NCommander> ramana: that would help. Google hasn't told me a lot of phase2 unwinder failures except they exist
<alecrim> Stskeeps,  I'm gonne work to get version 2.6.33 fully working like 2.6.29 version (http://franciscoalecrim.com/blog/2010/02/05/preparing-mamona-03-sync-with-openembedded-alpha/)
<Stskeeps> cool :) even with wifi and dsp?
<Stskeeps> i will bookmark
<Stskeeps> 2.6.33 on n8x0 would be cool
<Stskeeps> you saw the release of MBX 3d drivers too?
<Stskeeps> gpl kernel driver
<DanaG> MBX?
<Stskeeps> omap2 3d accelerator
<armin76> NCommander: cheater
<NCommander> hehe
<Stskeeps> alecrim: you have git tree for kernel somewhere?
<Stskeeps> for your patches
<NCommander> armin76: there is somethng for being able to simply throw more hardware at a problem
<DanaG> what I have is the beagleboard.
<ssvb> alecrim: there is user luke-jr on #maemo and #gentoo-embedded channels and he tried to do something with the latest kernels on N810 too (at least he was the last to update http://elinux.org/N800 page)
 * armin76 prefers to throw NCommander at the problem and keep the hardware
<alecrim> Stskeeps, linux-omap tree. I sent patches with corrections a few weeks ago.
<Stskeeps> k
 * NCommander sighs
<NCommander> trying to build OOo from source is like trying to drive in reverse on I-90 from Boston to Seattle
<armin76> thats how is it on arm :)
<armin76> you should be glad you don't have to work with a marvell orion and the like
<Martyn> *ugh*
<Martyn> No, building oOo is rally a pain in the ass
<Martyn> I'm still trying to build various MPI applications and libraries for our platform
<Martyn> and it's NOT fun
<Martyn> Plus I still have no work from Pegatron how the heck I can restore the image on their i.mx51 whitebox ( similar to the genesi box )
<DanaG> Pegatron as in split-off-from-ASUS?
<DanaG> Pegatron sounds like an el-cheapo brand... it's a bad choice of name, in my opinion.
<ojn> Martyn: just boot from external SD card. $20 of hardware saves you how many hours of work?
<Martyn> ojn : It's not booting
<Martyn> ojn : And I have no debug cable so I can't change the configuration of the u-boot
<ojn> Martyn: if you change the switches it'll load u-boot from SD
<Martyn> ah!  That's new info
<Martyn> 0001?
<ojn> Can't remember and I'm not in Austin this week
<Martyn> no worries
<ojn> My offer of borrowing the debug card also holds, but I guess it's more fun to fumble in the dark. :)
<Martyn> I forgot you were in the same city as me :)
<Martyn> When you're back, ping me
<armin76> ojn: it is!
<NCommander> Martyn: well, at least I managed to isolate the crash
<NCommander> Fixing it still going to be a real trick
<NCommander> Martyn: try using ooo-build, I think it will make it easier
<Chocobo> Do any of you know of a good tutorial for interworking ARM and THUMB code?  For example... if I have a bunch of C code I want to compile in ARM and a small ASM routine I want in ASM...  what I need for compile flags
<lool> Chocobo: You can get the actual architecture reference manuals from arm.com, if you register and accept the license
<ogra> lool, no go with rootstock :( ... installing an ubuntu-netbook task makes qemu hang in iso-codes ... just installing iso-codes works fine though
 * ogra wasted the whole day on it and is out of ideas
<|nfecteD> qemu is whacky
<|nfecteD> locked up here too when i gave it too much to chew on
<ogra> it wasnt for the last two releases
<|nfecteD> anyway... got it to build my rootfs when i removed lxde and gde from the seed
<ogra> right, minimal isnt a problem
<|nfecteD> mmhmm
<|nfecteD> not that the damn thing wants to boot on my beagleboard
<|nfecteD> init: plymouth main process (625) terminated with status 71
<|nfecteD> and such
<|nfecteD> yay
<|nfecteD> guess i'll try another kernel just for hell of it
<asac> dyfet: hey
<asac> dyfet: so you wanted to discuss mono ;)?
 * persia notes that the easiest way to get a high-end GFX card on armel is to find hardware with PCIe slots.
<dyfet> yea, I see several different issues
 * persia also notes that "Pegatron is a cheap brand" is somewhat tricky to parse, as Pegatron is one of only 5-6 companies that build 96% of laptops shipped worldwide and not the one with the least market share
<asac> dyfet: so lets talk ;)
<asac> dyfet: where would you start? i thought looking at the failed test cases and then understanding why the fail might be a good way to start
<dyfet> I was not aware of the status of that.  But I am also concerned what does it currently block building
<asac> dyfet: i dont think it blocks anything from building
<asac> only problem is that the runtime behaviour is borked
<asac> which makes good chunk of the archive unreliable to use ... which is bad ;)
<asac> luckily mono hasn't spread out that muc in the archive, but still there are apps we would like to have working ;)
<dyfet> out of curiosity, have the test cases also failed in qemu arm build?
<asac> havent tried to build it there yet
<dyfet> because it might offer an environment for testing where people don't have hardware, if it reproduces the behavior
<dyfet> while pulling down latest which tests do fail?
#ubuntu-arm 2010-02-26
<NCommander> persia:Dove boards have PCIe slots :-)
<rcn-ee> users who have used ubiquity/oem-config before...  anyway to force it to run on both tty0 and ttyS2 on first boot?
<rcn-ee> ping for ogra, this must be an oem-config bug.. on first boot after you create your first user, oem-config exits, then restarts oem-config again from scratch...  force a reboot, then on the next boot oem-config starts again... however user does exist if you switch to tty2...
<bobrown> Is it possible to buy an ARM laptop today and easily install the latest Ubuntu Linux on it?
<ogra> woah, mounting /proc in a qemu-arm-static chroot and then installing mono explodes in a funny way
<lool> ogra: So how does it fail?
<lool> ogra: Could you file a bug about that?
<ogra> lool, well, it tries to enable binfmt :)
<ogra> i doubt there is any easy way around
<ogra> apart from having a fake proc, afaik persia and lifeless had some fuse based ideas for that during the sprint
<lool> It didn't fail for me
<lool> update-binfmts: warning: /usr/share/binfmts/cli: no executable /usr/bin/cli
<lool> found, but continuing anyway as you request
<lool> update-binfmts: warning: found manually created entry for python2.6 in
<lool> /proc/sys/fs/binfmt_misc; leaving it alone
<lool> (apt-get install mono-runtime)
<ogra> right and then it tries to use the existing cli handler during package install
<ogra> ah
<ogra> i did apt-get install tomboy
<ogra> lool, did you ever have contact with hppfs ?
<ogra> seems that could work as a fake proc in a chroot
<lool> No
<lool> I'm not sure I'm in line with the fake proc idea
<lool> I think qemu-arm would have to emulate some of it due to the emulation it does
<ogra> well, how else would you handle stuff that needs proc in a foreign chroot
<ogra> right, so you still need to fake something
<lool> I'd personally prefer to use containers if we want to support this
<ogra> thats a lot of overhead
<lool> No
<lool> It's almost zero overhead
<ogra> well, we only need proc containers do so much more
<ogra> and are quite complicated to set up for a user
<ogra> lool, http://paste.ubuntu.com/384298/
<ogra> so ita a SIGABRT and i guess because it sees the binfmt handler and tries to exec it
<lool> ogra: Could you file a bug?
<ogra> gar, apport doesnt know about qemu-arm-static
<lool> The unsupported syscall 242 ones are probably harmless (affinity stuff)
<lool> The unuspported syscall 26 is just a consequence of trying to run gdb under qemu-arm, wont work because ptrace() isn't emulated (and far from trivial I'm afraid)
<ogra> yep
<ogra> bug 528377
<ubot4> Launchpad bug 528377 in qemu-kvm (Ubuntu) "qemu-arm-static fails installing mono assemblies if /proc is mounted in the chroot (affects: 1)" [Undecided,New] https://launchpad.net/bugs/528377
<ogra> i actually only started experimenting with mono in chroot again out of desparation, i have no idea what to do with the iso-codes hang
<ogra> seems no matter what kernel or config i use, installing the ubuntu-netbook task hangs reliably at iso-codes unpacking
<ogra> i thought its caused by swapping but that was a red herring
<lool> ogra: So the way you word the bug report, it sounds like of /proc is NOT mounted in the chroot, one can actually install mono; is this correct?
<ogra> no
<ogra> but i dont get the segfaults
<lool> What do you get?
<ogra> it simply doesnt execute the installation of the assmeblies
<ogra> and dpkg fails
<ogra> i'll add a log for comparison once my machine has spare cpu cycles (rootstock running atm)
<asac> hi doko ;9
<ogra> oh, a rare guest :)
<asac> hehe
<doko> I was forced :-/
<doko> NCommander: you might want to look at Mikael's comments in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860 (tracked down to the very same binutils change)
<ubot4> gcc.gnu.org bug 40860 in libgcj "[4.4/4.5 regression] regressions in libjava testsuite on arm-linux" [Normal,Unconfirmed]
<rcn-ee> hey ogra, oem-config question...   Should it run in an endless loop in lucid? ;)
<ogra> no, it shouldnt, boot with debug-oem-config on the cmdline and file a bug with /var/log/oem-config.log attached please
<ogra> against ubioquity
<rcn-ee> Thank so, debug-oem-config's the trick... First thing i'll do when i get to work..
<ogra> thanks :)
<rcn-ee> anyluck with the weird iso-codecs lockup today? ;) i'm seeing it to on my machines...  Whats weird In debian it's actually locking up at I: Extracting zlib1g...
<ogra> with debians qemu ?
<rcn-ee> squeeze.. so (ssh's in)
<ogra> i'm trying to debug that since yesterday but given the time it takes to get to the hang its might still take more :)
<ogra> i'm just trying it in a normal VM so that i can exclude rootstock here
<ogra> rcn-ee, btw, if you file a bug for oem-config under rootstock, please subscribe ubuntu-armel
<ogra> so we get the mails in the arm team
<rcn-ee> i know what you mean.. (QEMU PC emulator version 0.11.1)... what's weird, when i was building 'google os' images in a chroot, it locked up on that same package file..
<ogra> i think its something in qemu not handling a certain amount of CPU load or disk I/O
<ogra> but its so damned hard to track down
<ynezz> isn't that "I: Extracting zlib1g..."
<ynezz> oh damn keyboard
<ogra> funnily i can just install iso-codes just fine if i install it standalone
<ogra> ynezz, thats not in the VM
<rcn-ee> seems very reasonable.. do you guys have a dedicated qemu hacker at ubuntu?
<ogra> rcn-ee, well, lool is very passionate to get all qemu bugs solved and has the knowledge ...
<ogra> he's not a "dedicated qemu hacker" per se i think though :)
<rcn-ee> yeah he's good.... anything show up weird in the vm machine log's file?  (i could dump it too..)
<ogra> i'm only just running it in a VM
<ogra> before i suspected rootstock to be at fault ... thats to closed
<ogra> hmm, fun
<ogra> my VM doesnt even boot
<ogra> whoops typoing the command doesnt really help :P
<asac> /tmp/ccQPoJy6.s:1847: Error: selected processor does not support `rsc r7,r7,#0'
<asac> hmm
<ogra> whats that ?
<lool> reverse substract with carry
<asac> right
<asac> is that thumb only instruction?
<asac> or too old
<lool> only available on ARM, not Thumb
<asac> in the arm reference i have open its named in the thumb section
<asac> yeah thats what i expected
<lool> asac: there's a regular substract though
<lool> asac: sbc r7,#0,r7?
<lool> Hmm don't think you can pass an immediate as first arg though
<asac> what i find odd is that its not even marked as arm only in the reference quick card ... strange
<lool> asac: I certainly see it marked as such
<lool> asac: RSC is 5th in the substract instructions, and the fifth entry in Notes is "A"
<lool> So not in Thumb
<asac> oh right. i misinterpretetd the table
<lool> there's a blank which is hard to read
<persia> ogra: lool: Did you want the breakdown of the fuse proc idea?  I think StevenK fiddled with some initial implenetation stuff.
<ogra> persia, i would, seems lool doesnt ... he wants containers
<persia> containers are a more correct solution.
<ogra> but way more complex
<lool> no
<ogra> and do they guarantee i dont see the system kernel in /proc ?
<lool> no
<ogra> right
<persia> The fuse hack was just to use fuse.pm to check the filename and if it matched one of a set of predefined files, perform some operation (either cat a fake file, or run the real file through a filter).  If it doesn't match, feel the original file (or feed through an identity filter, depending on operation)
<ogra> what we need is a /proc that emulates a generic arm machine
<ogra> hrm, now i cant even purge iso-codes from my VM
<ogra> just sits there in the ldconfig triggers
<persia> ogra: The fuse hack can give us that (at least enough to fake most stuff).
<persia> Just needs someone to write up the perl.
<ogra> yeah
<lool> persia: I find it hard to imagine that we will get cpuinfo emulation in containers in the short term
<persia> Your python is better than your perl, right?  How are you at python regexes?
<lool> persia: However I do believe we should use containers for things like binfmt
<ogra> persia, i come from perl ... just needs a little refresh i guess
<persia> lool: So you think it makes sense to combine a container and the fuse-proc hack?
<lool> persia: The cpuinfo hack could either be done with fuse or in qemu; I think I find it more useful in qemu though
<persia> ogra: StevenK suggested perl was the better language for it because it's mostly just matching regexes and then running text filters.
<lool> I find things are complex and fragile enough that I'd prefer not to have to fiddle with fuse, personally
<ogra> yeah
<ogra> lool, to run containers you need to do massive changes to yxour chroot (which is the part i find complex)
<persia> lool: The advantage of fuse over qemu is that it's trivial to write such a hack in perl, but fixing qemu requires real thought.  If you're up for doing it, it would be loads better.
<lool> ogra: No
<ogra> huh ?
<ogra> you need at least to create lots of stuff in /dev, need to hack mountall defaults etc
<persia> ogra: Shouldn't it be as simple as http://blog.bodhizazen.net/linux/lxc-configure-debian-lenny-containers/ ?
<ogra> no
<ogra> lenny is way easier :)
<ogra> no upstart ... etc
<ogra> he wrote one for lucid too
<ogra> http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-lucid-containers/
<ogra> but effectively /proc will stil show you the host CPU and features
<persia> Why doesn't udev work?
<ogra> so its pointless to use containers imho
<lool> Again, containers are not going to solve the cpuinfo problem
<persia> Containers solve other issues.
<persia> They don't solve /proc
<lool> They actually help a lot with /proc, but not for cpuinfo
<persia> (well, they solve other /proc issues, but mostly of type /proc/nnnn)
<persia> Right.
<persia> Well, also not proc/[a-z]* mostly.
<ogra> would they be able to solve binfmt ?
<ogra> (i doubt that)
<ogra> given that binfmt would still need a qemu-arm-static wrapper around the interpreter calls
 * ogra goes for some lunch
<ogra> urgh
<ogra> maximizin the qemu window while it does something and then restoring it to its original size reults in massively blurry fonts
<ogra> the funny think is that its only blurry in the center of the window ... top and bottom are crisp
<mikeul> I have a couple of patch suggestions for rootstock, where should I submit them?  On launchpad?
<lool> mikeul: Ideally, submit them as merge proposals
<mikeul> via launchpad
<ogra> yes
<lool> mikeul: bzr branch lp:project-rootstock my-feature; cd my-feature && hack && bzr commit; bzr send
<mikeul> they're trivial, but it'll be a good getting-to-know-launchpad exercise.
<mikeul> bzr send?  I did bzr push"
<lool> mikeul: Checkout "bzr help send" then  ;-)  bzr push is when you want to do things manually
<ogra> lool, send requires an email setup, no ?
 * ogra checks the help
<ogra> ah, not a local mailserver, just a client
<mikeul> why?  who gets an e-mail?
<lool> mikeul: the email contact of the lp project
<lool> mikeul: if you prefer, you can just submit your branch for merging via the web ui
<ogra> right
<mikeul> OK, so having pushed it to a personal branch, can I do that with "Propose for merging"?
<ogra> yep
<mikeul> Or should I push it to the project-rootstock page instead and propose-for-merge there?
<persia> mikeul: I usually push to some personal lp page (e.g. lp:~mikeul/project-rootstock/make-everything-better ) and then do the merge proposal on LP.
<ogra> mikeul, hmm, why do you add rmdir $BUILDDIR to the usage() function ?
<ogra> $BUILDDIR wont exist if usage() is executed
<ogra> mikeul, i think that requires more restructuring, i'm not really comfortable with creating $BUILDDIR just because non root users call --help, could you move the variables around a bit instead of adding the rmdir ?
<ogra> its a good approach though
<mikeul> $BUILDDIR _did_ exist when usage() is executed.  I called "sudo rootstock --help" a few times and ended up with several empty /tmp/tmp.xxxxxx dirs.
<ogra> right, thats the actual bug :)
<mikeul> I'd be happy to move some things around to fix it differently.
<mikeul> e.g. to avoid creating /tmp/tmp.xxxxxx in the first place.
<ogra> yes, BUILDDIR= and all variables that use ${BUILDDIR} need to move down a bit ... best is below the uid 0 check
<ogra> (the script started as 50 lines ... and grew functions in several directions)
<mikeul> ogra, I'm familiar with that.
<ogra> :)
<mikeul> OK, then move all the variable defs to after the cmdline parsing.  I'll move the qemu-system-arm and debootstrap checks, too, since they're also not needed e.g. for --help
<ogra> be careful though, some need to be initialized before the cmdline parsing
<ogra> best to only move everything with $BUILDDIR in it
<mikeul> Oh yeah, that's why I went the quick-and-dirty rmdir route.
<mikeul> OK, can you give me an overview of how to handle that with bazaar?  I can start from scratch and just post a new branch, but I'm guessing there's a different way.
<ogra> just delete the rmedir with your next change ... the moving of the uid 0 check is fine
<ogra> *rmdir
<mikeul> ah, OK, so just dump more commits on top of my existing ones?
<ogra> right "revert last change and .... "
<mikeul> fyi, I'm a git'ter.  Do you mean a) I can change the history in bzr to remove mention of 'rmdir' or b) I should make the changes "on top of" the existing ones.
<ogra> i would just do it on top
<mikeul> OK
<mikeul> easy peezy
<ynezz> whois mikeul
<ynezz> oops
<ynezz> :)
<mikeul> FYI, I'm not going to get around to doing even those small changes today, will get to it soon.  Signing out.
<ogra> lool, so i am testing the same iso-codes issue in a real VM now instead of using rootstock, i'm at the point where apt stops moving in "unpacking iso-codes" ... i see nothing in the logs, apt-get and dpkg dont seem to consume to much CPU, one intresting thing i see is that dpkg.log seems to be behind and getting slowly filled ... dou you have any idea where else to look at ?
<ogra> mikeul, dont worry :)
<ogra> mikeul, thanks for doing the work :)
<mikeul> Kein Problem, ogra, have a nice weekend.
<ogra> du auch :)
<ogra> grmbl ... i should have installed iotop first
<ynezz> ogra: build karmic image today, using rootstock r82 and it boots :)
<ogra> cool !
<ogra> sigh ... no strace either in ubuntu-minimal
<lool> ogra: Are you swapping?
<lool> ynezz: We figured out the mountall issues with mikeul BTW
<ogra> i created a swapfile on the virtual disk after it hung already for 20min
<lool> ynezz: Missing rw on the kernel cmdline
<ynezz> ogra: can't login tho, maybe it's related to useradd http://paste.ubuntu.com/384439/
<ogra> yeah, looks like a bug
<ynezz> lool: yep, saw it in bzr log, thanks
<ogra> i switched the default to install oem-config instead ... i havent tested with username/pw for a while ... its on my list
<ogra> ynezz, i fear you need to mount your image and chroot into it to create the user
<ynezz> did it already, no problem
<ogra> ah, k
<ynezz> just letting you know
<ogra> yeah, thanks
<ogra> seems the options are wrong, i'll look into it on the weekend
<ogra> lool, so swapon after it was already stuck didnt help ...
<ogra> even though i see 204 bytes of the swap being used now after 1h
<ogra> err, 240
<ogra> apt-get now jumps between 80 and 95% CPU
<ogra> but nothing happens beyond that
<ynezz> ogra: it's missing " around one param http://paste.ubuntu.com/384443/
<ogra> oh, right, it used to live directly in the installer script ... when i moved it i didnt add proper quoting
<ogra> ynezz, thanks !
<ynezz> np, that was easy :p
<ogra> (in fact i didnt really care about it because oem-config should become the default)
<ogra> but i'll add your fix with the next commit
<asac> bug 507503
<ubot4> Launchpad bug 507503 in linux-mvl-dove (Ubuntu Lucid) (and 3 other projects) "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes (affects: 1)" [High,Fix committed] https://launchpad.net/bugs/507503
<NCommander> ramana: morning (or afternoon)
<asac> bug 528524
<ubot4> Launchpad bug 528524 in pulseaudio (Ubuntu Lucid) (and 1 other project) "Sound not working in all apps on dove (affects: 1)" [High,New] https://launchpad.net/bugs/528524
<alecrim> I got this problem with ubuntu karmic http://paste.ubuntu.com/384586/ . I fixed it at Mamona with this patch (http://gitorious.org/mamona/openembedded/commit/4d4933fd97b85a52e48a5fa1a97bd34532864e32). Anyone with this problem?
<NCommander> ARGH($*)(@*#$)(*@!$#@$
 * NCommander hates OOo
<lool> alecrim_: Could you file a bug with your patch?
<lool> alecrim_: I'm pretty sure I saw this in the past, I think it was on the sheevaplugs
<lool> alecrim_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314334
<ubot4> Debian bug 314334 in apt "apt: APT doesn't work on filesystems without shared writable mmap(), like JFFS2." [Wishlist,Open]
<alecrim_> lool, ok!
<|nfecteD> rcn-ee: you around?
<NCommander> ramana: ping?
<|nfecteD> anyone want to give me whatever boot.scr they are using for lucid alpha 3?
<NCommander> |nfecteD: what are you trying to do?
 * NCommander is the boot.scr writer guy
<|nfecteD> getting it to boot :/
<NCommander> |nfecteD: which SoC?
<|nfecteD> beagleboard
<|nfecteD> init: plymouth-log main process (227) terminated with status 111
<NCommander> |nfecteD: Beagleboard isn't officially supported by Ubuntu
<|nfecteD> thats the last thing i get during boot before it seems to hang
<NCommander> |nfecteD: http://elinux.org/BeagleBoardUbuntu - but here's the best set of directions I can give
<NCommander> oh wow
 * NCommander feels honored
<NCommander> Beagle adopted my boot.scr mechanism
<NCommander> or something similar
<NCommander> |nfecteD: sounds like your making it to the initramfs and then its crashing.
<|nfecteD> yup
<|nfecteD> seems so...
<NCommander> I'd recommend trying #beagle and if no response, come back here
<|nfecteD> plymouth needs kms/framebuffer and initramfs i believe...
<|nfecteD> early patch, i'm messing with:
<|nfecteD> http://bazaar.launchpad.net/~robertcnelson/project-rootstock/initramf...
<|nfecteD> and boot.scr needs to be updated (simple) to also load the initramfs
<|nfecteD> into ram..
<|nfecteD> found that on the beagleboard group now
<|nfecteD> i would think rcn built the newest rootfs with that patch so what im missing is what goes in the boot.scr
 * |nfecteD pokes rcn-ee
#ubuntu-arm 2010-02-27
<bobrown> Anyone around now?
<lifeless> shoot
<persia> So, we were talking about the Fuse.pm hack recently.
<lifeless> oh yes
<persia> And there was also talk about using containers to better handle other stuff in /proc
<lifeless> my fault I believe
<persia> Containers seem to address issues with some classes of access to /proc (because the instruction set that might be doing that might not match some of the contents of /proc/nnn, etc.), but not some of the base stuff (e.g. cpuinfo).  The Fuse.pm hack has the opposite set of benefits and detriments.
<persia> Do you see any reason why they two approaches would conflict?
<lifeless> I haven't heard of containers
<lifeless> point me at docs, I can think about it later
<persia> Also, it was suggested that rather than using Fuse.pm, qemu should be hacked to force-produce false data without needing special configuration.  Do you see any drawbacks to that?
<lifeless> sounds like layering buggery to me
<lifeless> and yes, I do see drawbacks
<persia> http://lxc.sourceforge.net/ http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-karmic-containers/
<lifeless> as a VM it would be the kernels responsibility
<persia> Please share :)
<persia> Remember, we're not talking about full VM stuff here: just emulated userspace (chroots is my main use case, but running arbitrary-architecture code on a system is another)
<lifeless> as an instruction set translator for one program, all the logic to deal with aliases, chroots, funny mounts etc will have to live whereever does the mounting
<lifeless> so, fuse /is/ a filesystem and can fit into the existing mount stack
<lifeless> doing it in qemu itself doesn't see to fit the layering, tome.
<persia> That makes sense.  Thanks for your input.
<lifeless> lxc seems to live in the same place
<lifeless> (namespaces, user isolation)
<lifeless> so putting in lxc approx == putting in fuse, at first glance. still way cleaner than qemu :P
<lifeless> can you enlarge on 'some classes of access to /proc (because the instruction set that might be doing that might not match some of the contents of /proc/nnn, etc.),'
 * persia experiments locally to provide a more informed opinion
<lifeless> because, I'm thinking 'isn't linux32 going to have the same issues'
<lifeless> so, lets look at what it does, figure out prior art
<persia> That's a brilliant idea :)
<persia> Looking at a /proc/nnnnn tree, I've confirmed my previous opinion that some of those contents are going to be architecture-dependent, and that it's easily confused by using binfmt and qemu.
<persia> I'm not awake enough to think about it in depth now, but I think you've convinced me that the magic trio is qemu + lxc + personalities (although this gets kernely)
<lifeless> persia: right, but is that a real issue or theoretical
<lifeless> I'm definitely not awake enough.
<lifeless> I don't know that lxc is needed or desirable here
<lifeless> it depends on what we are /aiming/ for
<lifeless> for now, gnight
<persia> Heh.  gnight.  Maybe lool and ogra will have a better explanation.  I know that some stuff FTBFS because of /proc inspection, but can't remember the details right now.
<suihkulokki> persia: no need for lxc. just add virtual /proc files to qemu
<lool> suihkulokki: lxc for a different purpose
<suihkulokki> or personalities
<lool> I do wish we'd advocate use of lxc instead of plain chroots to run ARM builds
<lool> suihkulokki: Right, we definitely want some cpuinfo emulation
<lool> suihkulokki: Do you have any interest in mono under qemu-arm?
<lool> suihkulokki: I would love some tips in debugging it; it's hanging on exit right now
<suihkulokki> you might want to try to get a simpler boehm gc app to work first
<lool> suihkulokki: do you have pointers on this issue?
<lool> suihkulokki: I tried a hello world mono app, it works as far as printing hello world, but dies on exit
<lool> Well it hangs actually, two threads are in futex() and another one in sleep(); it could be related to the GC
<persia> lool: Can you share more why we want lxc vs. chroots?  Is there a reason we wouldn't want that for all chroots?  Is this worth patching schroot to achieve?
<lool> persia: it's probably equally valid for all chroot use cases
<lool> persia: Problem is that people are apt-get installing stuff in these chroots
<lifeless> suihkulokki: no need for qemu to fiddle with userspace file access; fuse is much better at that.
<lifeless> anyhow, really going. ciao.
<lool> persia: so that might kill processes from outside the chroot, or leak details such as the binfmt setup or /proc/mounts
<lool> We typically want the type of abstraction which lxc provides to hide the desktop system running the container from the arm container
<lool> It might actually miss binfmt abstraction though
<suihkulokki> lifeless: it already fiddles.
<persia> lool: In fact, the primary, secondary, and tertiary uses of schroot are likely to involve apt-get (other use cases may not).
<suihkulokki> all syscalls go through qemu - anything you want to show/hide from arm processes can be done there.
<lool> persia: Ack; it's ok to use lxc for pbuilder/sbuild etc., but it's not strictly required; you don't actually want to start init scripts and the like in build environents
<persia> lool: Last I looked, lxc-on-ubuntu was sufficiently nontrivial that it's not something that can easily be done with scripted schroot setup.  Do you know if work is being done on lxc+upstart?
<persia> lool: Um, have you *looked* at the build logs?  Heaps of time it ends up installing mail servers, and it very often grabs dbus (and starts it).
<persia> These happen to work, but that's a coincidence.
<lool> suihkulokki: that seems to describe the problem you mention http://www.mail-archive.com/qemu-devel@nongnu.org/msg08229.html
<lool> suihkulokki: Do you have pointers on debugging apps running under qemu-arm?
<lool> I can use gdb against qemu, but I wish there would be a way to poke at the emulated program somehow
<roxfan> run it under gdbserver
<lool> Where's the list of packages to port to thumb2 again?
<lool> I'd like to strike qemu-kvm of the list
<lool> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
#ubuntu-arm 2010-02-28
<Ox83> just taking a peek at this. is rootstock/armel/qemu an alternative to the OE/bitbake system?
<persia> I'm not at all familiar with OE/bitbake but rootstock/armel/qemu certainly allows one to build packages (although there are some bugs).
<persia> Personally, I've been working with sbuild&qemu-static, but that has more bugs (although the interface is easier as one doesn't have a full virtual system).
<persia> Ox83: What are you seeking to accomplish?
 * persia becomes extra laggy for a while
<Ox83> pesia: am interested in building an ubuntu rootfs that can boot on my sharp zaurus (model sl-5600 with arm5tel processor).
<Ox83> there is a zubuntu project out there, but it is aimed at newer machines.
<kblin> Ox83: current ubuntu systems don't support arm5 processors anymore, you might want to have a look at debian instead
<persia> Ox83: For the 5600, I'd also recommend Debian.  On a SL-C series, Ubuntu can work, but only Ubuntu 9.04 (and it's not upgradeable).
<persia> That said, I suspect there's a way to hack rootstock to be able to use that to generate Debian rootfs artifacts.
<persia> The effort to port Ubuntu 9.10 (or newer) to the Zauri is doomed to either failure or an incomplete archive (unless someone has a spare 300G of storage space to dedicate to hosting the archive).
<persia> Because the newer releases require newer chips.
<Ox83> sounds like deb then :)
<persia> Just as a side note for those not familiar with the Zauri: models other than the SL-C series has sub-VGA graphics, wheras the SL-C series was full VGA (some with and some without hard drives).
<persia> (and I know Ubuntu has issues at 800x600, so I don't expect 320x240 or 480x320 to be anywhere near enough or well tested, etc.)
<Rishi1> Hi
<Rishi1> Can we install Ubuntu Netbook remix on arm based devices ?
<Rishi1> If yes, please provide me link to download the varient...
<persia> Rishi1: It's very much possible to do so.  For lucid, I believe the only flavours being built on armel are ubuntu-netbook, kubuntu-netbook, and server (although I plan to confirm on Monday, as there was some confusion related to Alpha 3).
<Rishi1> Thanks Persia for reply.. Actually I want to install Ubuntu on my Nokia n810
<Rishi1> It is based on Arm
<persia> But for earlier releases (ones that don't change daily and have some expectations of not being buggy), you'd have to install some other variant and then apt-get install "ubuntu-netbook-remix".  rootstock can also do this.
<Rishi1> and it has OS maemo OS2008
<persia> I think I heard that the n810 can't run lucid (processor too old), so you'd be stuck with Jaunty or Karmic.
<persia> Also, the resolution (800x480) is too small for the netbook variant.
<Rishi1> Any pointer regarding how to install Jaunty on it ?
<persia> I'll recommend you explore the Mer project, which is based on Ubuntu, and targets that resolution.
<persia> I don't know of one, sorry.
<Rishi1> I would like to see Jaunty on my n810 :)
<persia> I think you'd be happier with Karmic, which I believe works (although I've not tried it, so I may be mistaken).
<Rishi1> Would it not be heavy for a 400Mhz
<persia> It depends on what interface you use.  The netbook interface is almost certainly too heavy.  Something like LXDE seems to be about right.
<persia> For lucid, there's a new netbook interface available that's lighter, but it won't work on the n810 because of changes in the instruction set.
<Rishi1> Is it possible to remove Maemo from n810 and install ubuntu jaunty on it ?
<persia> I don't know.  I *think* you need to stick with the Nokia kernel.  Most folks seem to dual-boot (based on the results of a web search)
<Rishi1> Dual boot will be the best option
<Rishi1> need to search a lot on it.. The story behind doing this is that I want to connect my Internet USB dongle to N810
<persia> I really think the Mer project will have something more well suited to what you want (and you should be able to use any Ubuntu package with that, based on the information I have previously received).  If not, just search for "Ubuntu N810" or similar, and you'll get a lot of blog posts.  Some of them appear to have some directions, but I can't vouch for how well they work.
<Rishi1> Though I have managed to Use USB Keyboard and USB Pen Drives and USb Hardisks even... :)
<persia> If you get it working, please let us know.  I'd like to be confident telling people it works: I just don't have any reports that it's a good solution on that hardware yet (and since lucid and following releases won't work there, support for Ubuntu on that hardware will likely completely expire in early 2011~
<Rishi1> Will surely inform you
<Rishi1> I guess you stay in this channel with name Persia only
<Rishi1> Actually This is first time im on freenode
<sgnb> hello
<sgnb> coq consistently fails to build on armel
<sgnb> I've no idea where the problem comes from
<sgnb> I've been told that I could get help here
<sgnb> (FWIW, coq builds successfully on armel in Debian)
<sgnb> and I am unable to create a working ubuntu chroot on my SheevaPlug... mount crashes with illegal instruction on karmic and segfault on lucid
<armin76> :D
<armin76> sgnb: karmic/lucid isn't going to work on the sheevaplug ever
<syadnom> hello!
<syadnom> my first time here, i usually live over in ubuntu-montana.
<syadnom> anyone here running a guruplug or a sheevaplug?
<armin76> syadnom: you'll find more ppl on #openplug
<syadnom> well, ubuntu is available on the guruplug and I was wondering if anyone had gotten vbulleting running on one?  I just dont know how php and apache run on the arm platform.
<syadnom> vbulleting=vbulletin if my typo wasnt obvious.
<syadnom> along those line, does mysql run well on arm.
<syadnom> I'm considering an experiment with running a guruplug to start a basic vbulletin site, and then splitting that to a MySQL guruplug+webserver, then mysql+2 web servers etc etc with apache load balancing.  Before I invest in a couple plugs and wanted to know if anyone had run php and mysql on one of these plugs yet.
<lool> syadnom: There aren't a lot of people still running Ubuntu on these because only Ubuntu jaunty can run on the devices -- they are armv5
<lool> syadnom: We target armv7 in the current development version of ubuntu
<syadnom> lool: "we" means your an ubuntu dev?  any reason to target arm v7 instead of v5?
<syadnom> lool:  is this just a kernel issue?  could you roll your own kernel to work around it or are all the libs etc arm v7 only?
<juan__> hi! can anybody help me in order to update an arm linux kernel installation?
<juan__> ...
<syadnom> juan:  come back tomorrow, this is a sleepy irc day
<syadnom> oh! missed him
<NCommander> syadnom: its for performance reasons. ARMv7+Thumb2 gives a massive performance boost
<persia> sgnb: The SheevaPlug can't run newer Ubuntu (see interim backscroll).  Depending on the instructions used, you may be able to get an emulated lucid chroot working on an amd64 or i386 machine (either running in qemu or with qemu-static).
#ubuntu-arm 2011-02-21
<danders> cooloney_, ping
<cooloney_> danders: hey, man
<danders> cooloney_, hey bud
<cooloney_> danders: you changed your nickname here?
<danders> doh
<danders> just reloaded a pc at the house
<danders> forgot to change my nick
<prpplague> cooloney_, hey you know a matt copeland in stitsville ?
<cooloney_> cooloney_: oh, no, don't know that
<prpplague> cooloney_: there is a matt copeland on your linkedin.com contacts that is in the ottawa area
<cooloney_> prpplague: oh, god. actually, i might not know everyone on my linkedin.com
<prpplague> cooloney_: hehe
<cooloney_> prpplague: did he contact with you? or make you unconfortable?
<prpplague> cooloney_: hehe, no, its a personal matter, just a weird item that his linkedin page showed that he was connected via you to me
<cooloney_> prpplague: np, let me check my linkedin.
<prpplague> cooloney_: see /msg
<prpplague> cooloney_: bizarre sunday evening
<XorA> morning
<XorA> is the panda es1.0 still supported without hacks?
<ogra> no
<ogra> it never was supported in a release
<ogra> maverick beta should run on it
<ogra> but es1.0 support was dropped after beta
<persia> maverick beta may be hard to find
<ogra> why ?
<ogra> should be on the cdimage server
<persia> Old betas get deleted without announcement
<ogra> bah
<ogra> k
<ogra> yeah, its gone
<XorA> because I have an ES1.0 board lying around
<persia> Well, if you can find a suitable kernel patch that makes that work as well as the production models, without regression..
 * XorA lacks ubuntu capable hardware :-D
<ogra> XorA, i think rsalveti kept a x-loader and u-boot biary around soemwheer (i might misremember) but i dont know about the kernel patch
<XorA> ogra: x-loader/u-boot easy enough to frig up from somewhere
<XorA> ogra: I never used a Ubuntu generated one anyway
<persia> If you have a kernel that works on it (even an old one), you can probably run for a while.
<ogra> there is a counter builtin ?
<ogra> (or why "for a while") ?
<ogra> janimo, did you already take a look at nux ?
 * ogra notices that images are still failing 
<XorA> if its more than 1/2 a days effort I probably wont attempt it, ES1.0 is missing a lot of functionality anyway
<persia> Because as the kernel drifts, userspace tends to drift to match, and there is increasing potential for incompatibilities.
 * XorA has a convenient b1n to file old boards into
<ogra> persia, oh, you talk about upgrading
<persia> Saving them up to deliver to the acid-etching folk for gold recovery?
<persia> ogra: No, I talk about staying current.
<XorA> persia: recycling place has a place for old electronic
<XorA> what they do after that I dont know, probably illegally ship to africa or something
<janimo> ogra, yes, and have a merge request with the fix
 * ogra hugs janimo 
<ogra> awesome !!!
 * janimo hugs ogra
<ogra> :)
<persia> When I ran a electronics reclamation agency (we'll haul by the half-pallet at no charge!), it was mostly a matter of removing the metals from the boards.  The chips were worthless and the boards indestructible.
<janimo> however a new nux needs toi be uploaded for unity to build against
 * XorA amusingly still has some form of ubuntu rootfs on the zoom3
<persia> That probably has better support
<XorA> it does?
<persia> It's omap3, right?
<XorA> yeah, but until 2.6.38-rcX wasnt bootable in mainline
<janimo> ogra, persia I also filed a merge request for ubuntu-cdimage . No idea how to test that easily, it is mostly copying what is already there for the netbook project
<janimo> https://code.launchpad.net/~jani/ubuntu-cdimage/preinstalled-headless-arm
<persia> linux-omap from natty is mainline 2.6.38-rcX
<XorA> persia: ah, worth a look then, I can always file a defconfig update
<persia> janimo: Testing it requires setting up a complete image building environment.  My general recommendation is to leave it for the cdimage team to critique.
<persia> XorA: source package is "linux"
<XorA> persia: board is 5 miles away and turned off at moment :-)
<janimo> persia, indeed
<XorA> persia: thanks for taking care of my friday, was awesome
<persia> XorA: Well then, when you have a couple hours :)
<janimo> but I thought I'd let you too know
<persia> I'm glad you liked it.
 * XorA is less likely to kill all hardware designers now :-)
<persia> janimo: I'm confused by the case $PROJECT bit in etc/config: I wouldn't have expected you to add arch limitation there matching i386.  (I'm not cdimage, but I've looked at that code a bunch)
 * janimo checsk
 * persia is looking at https://code.launchpad.net/~jani/ubuntu-cdimage/preinstalled-headless-arm/+merge/50568
<janimo> persia, I copied the case for ubuntu-netbook, that is unless ARCHES is set default to i386
<rsalveti> XorA: ogra: I should have the pointers to make a valid kernel for it
<janimo> I assume for ubuntu-netbook ARCHES is set to armel
<rsalveti> just need to find at the irc log, many asked this when the es2.0 was out
<persia> janimo: Right.  I probably would have defaulted to armel in that case, for this image.  Doesn't matter that much.  Also, it's probably worth glancing at the -server or -desktop models, as examples where it pulls from a common seed (ubuntu)
<XorA> rsalveti: dont hunt too hard, I was just vageuly wondering, wont spend real work on it
<janimo> persia, I saw not place except the germinate from seed file where I thought diverging from ubuntu-netbook would make sense
<persia> Ah, OK.
<janimo> persia, I am sure things can be done better, but not knowing the code and being aware it is full of legacy boobytraps I am not trying to do anything smart
<janimo> I suppress my desire to cut and refactor stuff
<persia> I don't know if things can be done better, and my understanding is that this code mostly grows organically anyway.
<janimo> yes, lots of organic weed too there
<persia> Someone should probably refactor it at some point, but it's never a priority, and the risk of getting it wrong is fairly high.
<janimo> right, probably Colin and a few others know what is safe to nuke but since few people work on it few are hindered by it as it is
<XorA> that sounds like a job for someone with asbestos pants
 * persia gets excited about libasound2 1.0.24.1-0ubuntu1
 * XorA worries about persia 
<persia> XorA: Contains support for UCM
 * janimo google UCM
<persia> (and just hit natty very recently)
<XorA> ah, good old Slimlogic product that :-)
<persia> Yep
 * XorA thinks he has zero lines of code in there though, so dont blame me
 * XorA has had enough headaches with DAPM over the years to avoid UCM coding :-)
<rsalveti> XorA: http://paste.ubuntu.com/570052/
<rsalveti> this is for maverick
<XorA> rsalveti: cheers
 * XorA actually saw a mythical Pandora at FOSDEM
<ogra> janimo, could you have NCommander review the debian-cd bits (or possibly cjwatson), i'm traveling this week and am happy if i get unity-2d done before FF
<janimo> ogra, sure it was more of a heads-up not a request for review
<ogra> janimo, looking at it, you shouldnt put the image type into the flavour name
<janimo> you mean preinstalled?
<ogra> ubuntu-preinstalled-headless should become ubuntu-headless instead
<janimo> I was trying to be descriptive, some of the other project names are vague
<janimo> and the project naming so far does not seem to follow a guideline, some are one others two words
<persia> vague is good in terms of product naming: it provides semantic flexibility
<ogra> what if i want a d-i ios with ubuntu-headless on it =
<ogra> ?
<ogra> *iso
<persia> They are all transitioning towards two words.
<ogra> for-project is invoked with the type attached usually
<persia> So images end up being some combination of ${BRAND} ${PRODUCT} ${TYPE}
<persia> e.g. "Xubuntu Desktop Preinstalled"
 * persia isn't sure that one will ever exist, but as an example
<ogra> for-project <flavour> <imagetype>
<ogra> i.e.
<ogra> for-project ubuntu-headless cron.daily-preinstalled
<ogra> or a headless live image:
<ogra> for-project ubuntu-headless cron.daily-live
<janimo> persia, well in source code I prefer descriptivness over vagueness :)
<ogra> the flavour naming goes beyond source code ... thats the point
<persia> Indeed, and as Brands and Products get more important in terms of advocacy, this trend will only continue.
<ogra> if you ever create a d-i iso or a dvd with headless they would be called *-preinstalled
<janimo> I am happy with any name actually just to get this spec done and have headless images
<janimo> :)
<ogra> right, just remove the type
<persia> You want ubuntu-headless (${BRAND}-${PRODUCT})
<ogra> the rest looks actually fine
<ogra> you could s/preinstalled/chicken/
<ogra> *g*
<janimo> I'll do that :)
<ogra> that would result in ubuntu-chicken-headless images
<janimo> pigeon
<persia> Please don't.
<ogra> yeah, even better :)
<persia> Please pick a vaguely descriptive product name ("Headless" is good)
<ogra> and chicken-headless isnt ?
<XorA> you all running around random like?
<ogra> :)
<persia> vague is good, but too vague requires PR coordination, which tends to cause headaches, joint pain, and premature drowsiness in coders.
<persia> (and I refuse to help with PR coordination for any product with a fowl name)
<sveinse> rsalveti, you around?
<rsalveti> sveinse: yup
<sveinse> What's the story about powervr-omap3 ?
<sveinse> I'm uncertain if I should build my own or use the package
<rsalveti> sveinse: well, using the one available at our repo should be fine
<rsalveti> there's a newer version, that still didn't have time to test
<rsalveti> but the changelog didn't say much, and says it wasn't tested with x11
<sveinse> I glanced briefly at it... The package contains (as usual) a lot of build output files :(
<sveinse> and repeated files
<rsalveti> yeah =\
<sveinse> I managed to compress a 600M tar.gz to a 150M git repo, which clearly indicates that the same file is repeated many times
<rsalveti> sveinse: and were you able to test it?
<sveinse> No, not yet. But I will in the next two weeks or so
<rsalveti> if you say it's better I can try to update it
<sveinse> ..on 3530
<rsalveti> ok, should be fine
<sveinse> But it hasn't been approved for mainline yet, have it?
<sveinse> I remember some issues with udev permissions
<sveinse> *sigh* it's quite an effort finding the useful/needed files from the "build junk". I have to admit I'm a little surprised by the state of the package they release
<rsalveti> sveinse: to include it at ubuntu we should be fine, but first I'd like to make sure it runs well with x11
<rsalveti> sveinse: and it's better than what we had in the past
<persia> Ought test quick: FF is Thursday
<ogra> FF exceptions are just paperwork though
<persia> They're more than that: extra testing precautions, assertions of quality, etc.
<sveinse> I'm not working towards X11. I'm targeting Qt/QWS, so I won't be testing X11. Sorry
<rsalveti> persia: even for universe/multiverse?
<rsalveti> sveinse: that's fine, if it works for you is already something
<rsalveti> then I can test with x11 later
<ogra> persia, indeed implying that you do the testing etc before asking for them
<persia> rsalveti: Yep.  universe and main aren't really that different.  The only meaningful bit is the code review part of the MIR, in my opinion.
<rsalveti> persia: ok, that's fine
<sveinse> is the powervr license compatible for multiverse? I know I accepted an license for downloading it, but admit not reading it...
<rsalveti> sveinse: if the newer version has the same license as the one we already have at multiverse, then we're fine
<rsalveti> but the package is total mess hehe
<sveinse> oh indeed times 10
<XorA> heh I should fix that :-)
<XorA> no idea who to send the patches to though
<ogra> XorA, to rsalveti
<rsalveti> and I need to find who to send then :-)
<rsalveti> sgx-omap 4 people are not the same from sgx-omap 3
 * XorA is probably not supposed to stil have the source code though
<persia> Everyone who wants to be pvr-omap3 upstream, please raise your hand
<XorA> Im surprised anyone still making omap3 packages
<XorA> with TIs history of abandonment
<sveinse> I really hope that isn't true. We're working on a prototype product based on OMAP3 and are waiting for kernel features to be implemented
<sveinse> Like USB OTG for AM3517 and similar
<persia> sveinse: The rules are probably a little different for silicon customers compared to volunteer projects
<XorA> sveinse: will be different if your buying chips
<XorA> sveinse: but for us, omap3 is effectively dead
<XorA> sveinse: apart from small team at ASP who do beagle
<persia> Well, at least the parts dependent on binary blobs
<sveinse> It depends. Unfortunately we're competing (sizewise) agains the mobile industry. As an industrial mfg. we are a drop in the ocean in the big picture
<persia> sveinse: The comparison we usually consider is more the difference between buying one more beagleboard  or overo, so your scale is hugely larger in that sense.
<lilstevie> persia: solved that issue with X and touch
<lilstevie> it was the driver
<persia> lilstevie: Cool!  You have a patch?
 * XorA would just need TI permission to work on subject, already got the NDAs
<vstehle> XorA, rsalveti: if you send me patches I can try to "route" them inside TI (to ASP folks, maybe).
<vstehle> (pvr patches, that is)
<sveinse> persia, yes. The interesting note that the factor between you and us are probably in the same order of magnitude between us and the mobile industry
<XorA> anyway it is time to get bus home
<rsalveti> vstehle: do you have the pointers to where I can get the omap 3 code?
<XorA|gone> vstehle: I keep forgetting you still hang here :-)
<rsalveti> vstehle: would be nice if we could get some bugs fixed, like the soname and etc, but then I'm not sure if I can have access
<persia> sveinse: Sure, but it's probably threshold between "spare time" vs. "low-priority funded project" :)
<rsalveti> or work on it
<lilstevie> persia: no
<vstehle> I hang "more" since I setup some highlight keywords :)
<persia> lilstevie: No patch required?
<lilstevie> persia: the evdev driver isnt compatible with the type of touch panel
<lilstevie> switching to mtev solved it
<lilstevie> on the galaxy tab we now have unaccelerated graphics, touch wifi
<persia> In that case, you need to fiddle the udev rules, and it's all good.
<vstehle> rsalveti: I am not sure where the sources are. I think folks like koen use the DDK1.6 w/o DRM, currently.
<vstehle> koen would be my first bet :)
<rsalveti> vstehle: yeah, will try to ping him
<lilstevie> aparently sound can be achieved with a little fiddling
<rsalveti> I forget he's also TI now
<rsalveti> :-)
<lilstevie> graphics are going to be the hardest though
<persia> lilstevie: From our experiences with sound, 99% of the issue is driver bugs, which often aren't solved because it's far too easy to fiddle userspace.
<lilstevie> yeah
<lilstevie> persia: from what the guy said who got sound it was fiddling that got it to work
<lilstevie> unfortunantly though graphics is SGX54-
<lilstevie> 540*
<persia> Once the fiddling with asound.conf and pulse is done, there's usually enough information to fix the driver.
<persia> Talk to Samsung: they may be able to make a binary driver available (as TI does for the omap)
<lilstevie> we have the kernel binary
<persia> No kernel source?
<lilstevie> hell if you dive into nexus s kernel you have kernel source as well
<rsalveti> you should be able to get at least the kernel source
<lilstevie> we dont have the pvr kernel module source
<persia> Oh, kernel binary for graphics: yeah, you'll need a new one whenever the ABI changes though :(
<lilstevie> the soic is similar to the nexus s though
<lilstevie> and that does have it as source
<lilstevie> there is talk about samsung open sourcing the driver Q4 2011
<lilstevie> also something I have noticed
<lilstevie> android RTC and what linux expects are different lol
<sveinse> rsalveti, which cpu's use the gfx_rel_es2.x since it's included in the opengles-sgx-omap package?
<rsalveti> sveinse: old beagles, 3430
<sveinse> ah, thanks
<akk> Does anyone know if the Ubuntu armel toolchain will work for the ARM chips in sheevaplugs (Marvell kirkwood)?
<akk> I've been told it won't, but I'm having trouble finding anything describing what versions armel covers.
<suihkulokki> ubuntu armel targets minimum armv7, kirkwood is armv5
<akk> Thanks! Good to have a definite answer.
<armin76> akk: http://plugcomputer.org/plugforum/index.php?topic=885
<armin76> "Is there any hope that ubuntu will support armv5 in the future again?" <- lol
<akk> Hmm, that says Debian still supports it. Wonder if that's true, or if they just mean "because Debian won't release a new version for a long time"?
<armin76> lol
<armin76> akk: afaik debian has no plans to drop the support for armv4t, which is the minimum they support
<armin76> suihkulokki: right?
<akk> Cool. I had assumed they didn't because of emdebian: http://emdebian.org/tools/crosstools.html
<akk> which seems to be saying that you need that repo to get the cross-compilation tools.
<suihkulokki> armin76: we might to got ARMv5t, if upstream gets flimsy on ARMv4t and the openmoko people don't fill in
<suihkulokki> to got -> go to
 * XorA|gone hates mysql
<prpplague> fyi for anyone interested, TinCanTools will be doing a production run of RevB Trainer Boards, if anyone has feedback on changes needed please submit them by the end of the week http://www.elinux.org/BeagleBoard_Trainer , Trainer works with the PandaBoard as well
#ubuntu-arm 2011-02-22
<ogra> ndec, have you seen natty-changes ? alsa is uploaded
<ndec> ogra: ok. thx
 * XorA pukes on Unity
<persia> XorA: Careful: when we disagree we try to do so with respect.  apt-get install xubuntu-desktop or lubuntu-desktop if you prefer.
<XorA> persia: its quite literal, it gives me sea sickness :-)
<XorA> persia: probably an effect of only having intel graphics so everything lags
<ogra> ??
<ogra> its rteally fast on recent intel chipsets
<XorA> eee 901 isnt recent
<ogra> well, there is at least a 945 or some such in it, no?
<ogra> i know there are issues with the 8xx series
<XorA> yeah
<ogra> because intel dropped driver maintenance
<XorA> I do really like the theme improvement in natty for gnome desktop though
<suihkulokki> the stort of linux 3d.. either too new hw with drivers existing only some experimantal git branch or old hw with maintainance already dropped :P
<XorA> since we lost being the 64bit test platform for UT codebase there is no money in linux 3d anymore :-(
<hrw> ogra: 8xx do not have intel driver anymore in ubuntu
<XorA> hrw: how goes?
<hrw> XorA: they killed it in intel x11 driver
<hrw> I have a laptop with 855 at home and only fbdev works on it
<ogra> hrw, really ? I thought there is still one in universe
<ogra> but who cares about intel anyway ...
<ogra> arm is the future
<hrw> 855 was pita anyway
<ogra> :)
<XorA> we just need 8 core arms, 7 cores to run mesa and one for desktop :-)
<hrw> ogra: there are rumours that there will be laptops which can replace my ul30a in 2014 ;D
<ogra> yeah, that saves all the 3d headdache
<ogra> just do it all in SW
<hrw> ogra: you do it already on your ac100 ;D
<ogra> heh, indeed
<ogra> metacity composite is really impressive here
<ogra> even in pure framebuffer
<XorA> few of my arm devices have screens :-)
<hrw> from arm devices which are around my desk only one does not have a screen option
<hrw> ogra: https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplicationForUniverseContributor
 * ogra opens
<persia> hrw: No video out, no USB, no expansion connector?
<hrw> persia: sheevaplug has usb but I do not have usb2vga dongles
<hrw> and do not plan to have such ones
<persia> I claim it has a "screen option", and you choose not to exercise it :)
<XorA> note I said no screen, not the lack of option for one :-)
<ogra> GRRRR !
 * ogra hates symbols files
 * prpplague pokes ogra in the eye with a sharp stick
<ogra> *sniff*
<prpplague> ogra: don't speak ill of symbol files
<prpplague> ogra: they are your frienemy
<ogra> heh
<ogra> they are fine if you generate them with the same toolchain you try to build under
<ogra> sadly i didnt do that with my last upload
<ogra> so i have  to start over again and redo half a day of work
<prpplague> ogra: doh
 * prpplague needs coffee, brb
 * prpplague returns like a bad case of athletes foot
<davidm> prpplague, panda daughter cards just got urgent, the Panda boards shipped from DIgikey, all of them
<ogra> \o/
<davidm> prpplague, what is the thread size of the metal standoffs you use? I ordered the wrong size for my test, I had to drill out the holes but it did not matter for the test rack
<prpplague> davidm: they pandaboards currently use 4/40 threads
<davidm> prpplague, thanks, I'll order up a proper supply today
<davidm> prpplague, the recommended power supply is 5VDC 4A, do you know how much of that is spare?
<prpplague> davidm: 2A would be if you weren't using any usb devices
<prpplague> davidm: talk to ctyler, he's been testing running multiple pandas from a single power supply
<hrw> davidm: 2 usb ports = 1A extra if they are used
<prpplague> hrw: 4 ports on the panda so, 2A extra
<davidm_> prpplague, thanks, I'm just seeing what powersupply to order today
<davidm_> Since we are planning on USB disk I'll make sure to allow the extra then
<prpplague> davidm_: http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=4558896&csid=ITD&body=MAIN#productresources
<prpplague> davidm_: thats what ctyler is using
<davidm_> Woot Panda boards just arrived YEA!!!!
<GrueMaster> Cool.
<davidm_> prpplague, thanks, that supply won't work for me but it's good to know a combined supply works I'm going to order an 80A 5VDC with a 12A 12VDC supply
<prpplague> davidm_: dandy
<davidm_> The 12V is for the relay controls, the relays run on 12V  I'm going to wire it for NC applys power to Panda, NO applys power to latch on daughter card
<prpplague> davidm_: which relays are 12V?
<davidm_> The serial control relays the ones that give us remote control over the panda boards
<davidm_> not the one you are using for the latch
<davidm_> I am going to use a rack of 24 relays, only 20 wired that we can connect to via serial control to activate and deactivate the panda boards
<davidm_> think of it as a remote reset on power
<davidm_> Since I'm using a single power supply and not 20 power supplys
<prpplague> davidm_: ahh
<NCommander> hey all
<davidm_> I'm going ot have to be quite careful of the power supply, you can weld at 80 apms of power
<davidm_> s/apms/amps/
<davidm_> I'm starting to think that I might want to use some fuses inline with all that power
<GrueMaster> heh, reminds me of the custom powersupplies we had at Intel.  3.3v 320 amp, 5v 200 amp.  And they had two lugs for the wiring harness to bolt on to, about 2 inches apart.
<rsalveti> davidm_: awesome
<LajonSZ> Hello, I'd like to ask how it'd be possible to prepare fs for ubuntu arm with androidal init.rc? Anybody know how to write sth like that? (sorry for poor English)
<LajonSZ> I have already img of ubuntu
<NCommander> LajonSZ: android's init.rc system is pretty much completely different and incompatible w/ upstart
<LajonSZ> So, it is not possible?
#ubuntu-arm 2011-02-23
<sebjan> Hi, while testing the Natty Alpha2 image on panda, I need to run a 'sudo dhclient -4 usb0' to get an IPv4 allocated (else, I seem to have an IPv6 only). Is this expected / known behavior?
<ogra> not expected and i dont see it on my panda
<ogra> NM just does what it's supposed to
<sebjan> ogra: I don't see the nm-applet in the bar, and ifconfig does not provide a IPv4. after the above trick, I can get a network connection through usb0, but still do not see the nm-applet (I'd like to configure my wlan connection with in in fact)
<rsalveti> sebjan: check if you have nm-applet running, if so then check if the network manager daemon is running
<rsalveti> otherwise it's not going to show itself at the bar
<sebjan> rsalveti: nm-applet is running actually, but not hint on network-manager (it shall be called like this?)
<rsalveti> sebjan: NetworkManager
<sebjan> rsalveti: ok, not running either
<sebjan> I suspect that it fails to run properly since I activated the wlan: I need to make some tricks to be able to use the wlan, and this may upset network manager...
<rsalveti> sebjan: try service network-manager start
<rsalveti> could be
<rsalveti> sebjan: run NetworkManager --no-daemon --log-level=DEBUG
<rsalveti> then you can check why it's failing
<sebjan> rsalveti: ok, thanks, I'll do that
<ogra> sebjan, and make soure you didnt touch /etc/network/interfaces ;)
<ogra> else NM will ignore your interface
<sebjan> damn, network manager segfaults...
<rsalveti> sebjan: are you using maverick?
<sebjan> rsalveti: no, Natty alpha2
<rsalveti> sebjan: hm, if you didn't update than this maybe fixed already with latest upload
<rsalveti> sebjan: we had some issues and instabilities with NM during the alpha2 time
<sebjan> right, I will make an upgrade: I just see that during gdm start, network manager is started/dies/re-started/dies/...
<slangasek> rsalveti: hi there!  we're looking at the question of building qt4-x11 with gles2 enabled on armel instead of opengl; if we did this in the official package in natty, do you know if that would cause regressions?
<slangasek> i.e.: I don't think there are any accelerated full-opengl drivers available in Ubuntu, but I know we have gles2 for panda, so it's a win there... but what about unaccelerated systems?
<rsalveti> slangasek: would affect some kde packages, and some others from universe
<slangasek> affect them adversely?
<slangasek> is that because it would introduce ABI changes, or for other reasons?
<rsalveti> bug 707794
<ubot2> Launchpad bug 707794 in qt4-x11 "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,Confirmed] https://launchpad.net/bugs/707794
<rsalveti> slangasek: the main problems is a conflict that happens when you have an application that needs GL and uses libqt4-opengl
<rsalveti> once we build qt with the gles backend, the symbols will conflict
<slangasek> symbol collision> oh, interesting
<rsalveti> because Qt lets the user to use GL directly, together with Qt
<slangasek> yes
<slangasek> so those libraries should really have symbol versions applied, but I guess that may technically be a violation of the standard ABI
<slangasek> thanks for the bug reference.  Do you know of any issues besides what's mentioned in that bug?
<slangasek> worst case, we will probably provide a gles2 build in our ppa for this cycle
<slangasek> but I would like to dig deeper to see if we can resolve the symbol problem for the short term, without compromising future development work on the proxy library
<rsalveti> slangasek: for the moment I believe having it on a ppa should be enough
<rsalveti> the problem of sharing many symbols
<rsalveti> and also, if you link with libqt4-opengl it'll bring EGL and GLES2
<rsalveti> headers collision and more
 * ogra would really like to see the core libs to be GLES on arm ... ignoring the few packages that will break until they are fixed properly
<slangasek> it's "enough", but ppas are only 2GB and if we put qt4 in our linaro overlay ppa, that's a good chunk gone :)
<ogra> imho its a failure of the apps to be programmed in a broken way
<rsalveti> well, Qt gives you the liberty to use GL together with Qt
<rsalveti> and also support different backends
<ogra> how about having a libqt4-gles ?
<rsalveti> so it's not something like clutter, that you only use the clutter API
<ogra> (arm only indeed)
<rsalveti> ogra: and in what that will help us?
<rsalveti> then we would need to change all the packages we want to link with the new libqt4-gles package
<ogra> yes, it would need some buildd sided magic i guess
<rsalveti> and probably need some work in qt to generate both libs without many issues
<rsalveti> without having 2 different qts in the archive
<ogra> yes
<slangasek> no, building libqt4-gles is not a good solution
<ogra> its surely a lot of work (and surely nothing for natty)
<rsalveti> that's why having it on a ppa would be easier for the moment
<rsalveti> while we don't have the proxy lib and the gles support for glew
<slangasek> I'm going to have a look at symbol versioning on the gles2 side
<ogra> i would still prefer to rather ignore the handfull of apps
<slangasek> as a fallback, we might disable the opengl-needing packages in discussion with the Kubuntu team
<rsalveti> yup
<ogra> ++
<rsalveti> software rendering with opengl on arm is basically having nothing
<rsalveti> very very slow
<rsalveti> so, no use
 * slangasek nods
 * ogra disagrees :)
<ogra> you should see composite on framebuffer here on the ac100
<ogra> no noticeable difference to non-composite metacity
 * hrw confirms
<rsalveti> hm, cool, good to know :-)
<ogra> seems to depend on the HW :)
<hrw> ogra: how fast is membus on ac100?
<ogra> 400MHz ?
<ogra> not sure
<hrw> ok
<GrueMaster> So, the image doesn't have initrd.img in /boot on the second partition.  Why?
<vinay__> Hello, I am trying to get cross-compiling environment (including autotools) for Arm on Ubuntu 10.04. What is the best way to proceed?
<rsalveti> GrueMaster: probably something is broken at the update-initramfs part
<rsalveti> or the hook while installing the kernel
<GrueMaster> The uImage is on the boot partition, and there is a link in /boot, but no actual file.
<rsalveti> so it could be a problem at the update-initramfs
<rsalveti> try mounting and installing with qemu
<rsalveti> to see if the the update-initramfs is called at the postinst
<GrueMaster> rsalveti: It is something with the image generation.  uImage wouldn't exist if update-initramfs failed.
<GrueMaster> And it works fine on an installed image.
#ubuntu-arm 2011-02-24
<TheUni> rsalveti: ping
<rsalveti> TheUni: pong
<rsalveti> TheUni: was looking for you :-)
<TheUni> heh
<rsalveti> TheUni: was checking xbmc code and etc now
<TheUni> rsalveti: just wanted to let you know that one of our devs has a gstreamer POC up and running
<rsalveti> TheUni: yeah, I remember topfs2 said he made it work, but was still going to release the code
<TheUni> also that we've spoken to the enna devs some. they would rather work on openbricks and let us work on the mediacenter part :)
<rsalveti> TheUni: is this at master already?
<rsalveti> TheUni: yeah, xbmc is the future
<TheUni> no, not yet
<rsalveti> TheUni: want to work with you at least to have a working PPA
<rsalveti> daily would be good to have
<TheUni> yep, i've been working on that for the last week
<TheUni> pbuilder currently chugging away on my laptop
<rsalveti> nice, too bad I've being busy with some other stuff :-(
<TheUni> it's no problem. it needs lots of help. i'm adding one hack after another to get it building. once nightlies are working, we can work on cleaning it up
<rsalveti> TheUni: cool
<rsalveti> TheUni: were are you putting all these modifications?
<rsalveti> any branch?
<TheUni> i'm almost embarrassed to show you :)
<rsalveti> well, at least pointers so I can try to help :-)
<TheUni> heh
<TheUni> https://github.com/xbmc/xbmc-packaging
<rsalveti> hehe, I still need to learn to love github
<TheUni> as i've said, it's built on years of shoving things in with not cleanup
<TheUni> ooh, the love will come.
<rsalveti> np, after finishing this enna testing will jump right at xbmc
<TheUni> i'm on (i hope) the last build failure now. sec for log
<TheUni> we bundle our own ffmpeg builds, though we support external as well. packager can't find our internal ones...
<rsalveti> got the latest PVR driver available at the omap ppa, so I want to test xbmc with it :-)
<rsalveti> see how it goes
<rsalveti> and after test the gstreamer support
<rsalveti> hm
<rsalveti> bundle your own ffmpeg helps a lot, but it's evil
<TheUni> https://launchpad.net/~team-xbmc/+archive/unstable/+buildjob/2280569
<TheUni> yea, but we carry ~45 patches
<rsalveti> not that much
<TheUni> ffmpeg is a bumpy road in the last month, anyway ;)
<rsalveti> :-)
<rsalveti> hm, failed at dh_shlibdeps
<TheUni> rsalveti: more importantly though, we run on win32/osx as well
<TheUni> so it's nice to know that all OSs are running the same version of ffmpeg, built the same way
<rsalveti> yeah, makes sense
<TheUni> rsalveti: any tips for using LD_LIBRARY_PATH ? i can't seem to get it hooked up properly
<rsalveti> TheUni: but are you setting it at build time?
<rsalveti> let me check
<TheUni> google says it should be in the pbuilderrc. but not very helpful when uploading to launchpad
<TheUni> so i tried setting it in the debian/rules as a test, but no luck
<rsalveti> dh_shlibdeps also has the -l option
<TheUni> right, but i couldn't figure out how to override it
<ruckuus> Hello all, I am the guy from two weeks ago asking about ubuntu ARM on s3c6410
<ruckuus> I am trying to specify the kernel to use on rootstock command, but I can't figure it out
<ruckuus> Do I have to create .deb package for the kernel, then --seed linux-kernel-image-s3c6410 (the name of the kernel package)?
<ruckuus> Anyone can give me a hint?
<ruckuus> Thanks in advance
<rsalveti> TheUni: did you try creating an override for dh_shlibdeps?
<rsalveti> ruckuus: it's easier if you have the deb package
<rsalveti> you can also use --kernel-image http://foobar/kernel.deb
<TheUni> rsalveti: hmm, did see that i could override that
<ruckuus> rsalveti: thank you. So, what I have to do now is to cross compile the kernel, then dpkg-buildpackage with the result .deb then use this package?
<rsalveti> ruckuus: yup, if you want to generate the rootfs with the kernel deb, yes
<rsalveti> ruckuus: you can also compile your kernel and then copy to the rootfs
<ruckuus> rsalveti: or this packaging must be done in chroot jail with ARM based RFS?
<rsalveti> with the correct modules
<rsalveti> ruckuus: I usually use the kernel deb-pkg rule
<rsalveti> make -j 3 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
<rsalveti> for example, will cross compile and then create a deb for it
<rsalveti> not perfect, but works
<ruckuus> rsalveti: thank you, I will try that
<ruckuus> rsalveti: by using specified kernel, do I have to take care also the libc version?
<pcacjr_> rsalveti: one question: once built the kernel with the deb-pkg stuff, that deb package will contain the *arch* specified by the ARCH= ? (e.g package_armv7el.deb)
<rsalveti> pcacjr: yup, that's why it's useful while cross compiling it
<rsalveti> ruckuus: you shouldn't
<pcacjr_> rsalveti: hm, ok
<ruckuus> rsalveti: OK, thank you
<pcacjr_> rsalveti: I've had problems while compiling the kernel for x86_64 arch on an x86 one. the deb genereted by the make deb-pkg is always i386 instead of x86_64
<rsalveti> pcacjr_: hm, how are you building it?
<pcacjr_> rsalveti: make -j 3 ARCH=x86_64 deb-pkg
<pcacjr_> rsalveti: however the binaries which it has are all 64-bit ones
<rsalveti> pcacjr_: interesting, could be a bug at the packaging part
<pcacjr_> so I had to use --force-architecture to install it on an x86_64
<rsalveti> just putting i386 for everything
<pcacjr_> rsalveti: perhaps
<pcacjr_> rsalveti: yep
<rsalveti> actually it's being quite a while that I don't build my own kernel for x86 :-)
<pcacjr_> rsalveti: hehe :-)
<rsalveti> just ARM atm, unfortunately my main host is still x86
<pcacjr_> ahahah
<pcacjr_> let's just wait the quad core ARMs
<rsalveti> TheUni: if you're building locally you can try the debian rules calls by hand, without the need to rebuild everything
<rsalveti> like fakeroot debian/rules binary
<pcacjr_> rsalveti: I'll try to reproduce the bug again later on
<rsalveti> pcacjr_: :-)
<pcacjr_> rsalveti: time to get some sleep. g'night
<rsalveti> pcacjr: c-ya
<TheUni> rsalveti: thanks for the tip. obviously deb packaging is new to me.
<rsalveti> TheUni: not a problem :-)
<rsalveti> TheUni: and where can I find the branch with initial gst support?
<rsalveti> if already available somewhere
<TheUni> rsalveti: i think topfs2 has them local. i'll ask him to publish next time i see him
<TheUni> as i said, it's just a POC. but he had playback in xbmc in 2 days, so think it's very reasonable
<rsalveti> cool, will ping him when he's around here
<rsalveti> nice
<rsalveti> persia: ping
<rsalveti> persia: I'm thinking if it's worthy creating a task for our set-up-box blueprint, and how it'd be called
<rsalveti> we currently already have many tasks related with mythtv
<rsalveti> that's kind the official and supported set-up-box solution at ubuntu
<rsalveti> but for arm we would still need a lighter solution, as enna is atm
<rsalveti> and soon xbmc
<rsalveti> so for us this task would basically install enna, and possibly lirc
<sveinse> Are there any particular restrictions on the X-loader / MLO file when booting from SD?
<hrw> other then mistic 'it has to be first file' or 'partition should start at X and end at 666'?
<hrw> I would suggest to wait for ubuntu/arm guys to wake up and arrive
<sveinse> My point being today the boot is MLO->U-Boot->kernel, but perhaps it would be possible to do MLO->kernel or perhaps the MLO could be the kernel itself (with some customization)
<sveinse> Sure, I can wait
<hrw> iirc you can add some headercode to kernel instead of mlo but I do not remember details
<sveinse> hrw, are there any new updates to gcc 4.5 armel-cross in the loop (for maverick)?
<hrw> sveinse: omap(3,4) cpu has bootrom which loads xloader (mlo) which initialize board and goes with booting
<hrw> sveinse: next week will bring something
<hrw> sveinse: I am at emdebian sprint this week
<sveinse> hrw, sure, thanks. I just keep fighting compiling Qt with gcc4.5. It's either bugs in Qt or bugs in gcc4.5.. The ironic thing is that downgrading to gcc4.4 makes it compile, but its not maintained by linary iirc
<hrw> gcc 4.4 is still supported by linaro
<hrw> but not for long - 4.6 is on a way to release
<lardman|home> morning
<lardman|home> I've got a question about my rootstock generated image for the Galaxy Tab, basically I'm trying to work out where/how Xorg is started (as I need to poke a sysfs entry to switch the LCD screen back on after X starts)
<lardman|home> my rootstock was built using --seed netbook-launcher-efl,onboard,ubuntu-netbook-efl-default-settings,wicd,wicd-curses,wicd-cli
<lardman|home> I can't find a gdm binary nor an X* binary anywhere in the bin/sbin directories; do they hide elsewhere?
<lardman|home> or is my --seed wrong and needs more options added?
<ogra> you didnt specify them in your --seed
<ogra> and nothing of the packages you listed depends on them
<lardman|home> are they not pulled in as part of the other --seed meta packages?
<lardman|home> ah ok
<lardman|home> is there a list anywhere of a recommended --seed list?
<lardman|home> I see here https://wiki.ubuntu.com/ARM/RootfsFromScratch that one can specify --seed xubuntu-desktop - presumably that will pull in all the X deps unlike the netbook-launcher-efl I specified?
<lilstevie> hey lardman|home
<lardman|home> hi lilstevie
<lardman|home> in the absence of anyone knowing how to get multitouch working in Meego ARM, I'm having a go with Ubuntu
<lilstevie> is there a way to change where the battery manager grabs its battery levels from?
<lilstevie> ah damn, meego on the tab would have been cool
<lardman|home> well I'll get there in the end, but I need some help working out what to enable in Qt and whether it still supports mtev, etc
<lilstevie> ah
<lardman|home> and really I'd like to be able to use the beast in the meantime :)
<lilstevie> :)
<lilstevie> I think samsung were just blowing me off by saying they handed my request to the development team
<lilstevie> havent heard anything since
<lardman|home> Well see what happens, you might have to give them a few days
<lardman|home> few more that is
<lardman|home> then start shouting about it
<lilstevie> heh
<lardman|home> ok, so I'll try a rebuild - I didn't get any kernel panics, so I guess the stock-ish Android kernel will work with Ubuntu too
<lardman|home> which would mean dual boot is back in, and for those without the internal memory card, booting from an external card (which is the setup I'm using now)
<lilstevie> heh yeah
<lilstevie> problem is audio drivers are going to need some mods
<lardman|home> did that rootstock list you put on the wiki work for you? There's apparently no Xorg in there...?
<lilstevie> and possibly the V4L Driver
<lardman|home> kexec it is then
<lilstevie> lardman|home: yeah I grabbed that out of my .bash_history
<lardman|home> hmm strange
<lardman|home> I'm going to try with this, for want of any better ideas: rootstock --fqdn GalaxyTab --login ubuntu --password ubuntu --imagesize 5G --seed xubuntu-desktop,netbook-launcher-efl,ubuntu-netbook=efl-default,onboard,wicd,wicd-curses,wicd-cli,build-essential,openssh-server
<lilstevie> add gdm though
<lardman|home> ah, I guess gdm might pull X in, which would solve the problems
<lardman|home> tbh I don't like that efl launcher anyway, so might just go for the default xubuntu-desktop one
<lardman|home> rootstock doesn't seem to cache packages...
<lilstevie> no it doesnt :(
<lardman|home> lilstevie: did you install mtev or just copy the binary in?
<lardman|home> and do you have a copy of the patched binary handy?
<lilstevie> I copied the binary in from cb22
<lilstevie> wait until a bit later when he shares the new one or do you want it now?
<lardman|home> I'm happy without the wierd and wonderful tap 3 times and hold your nose to left click stuff ;)
<lilstevie> I don't have that stuff
<lilstevie> I have a left mouse button only vers
<lardman|home> so yes, just the basic one which emits a click event would be useful
<lardman|home> just so I can add it now and get something up and running, can try the new all singing and dancing version later on
<lardman|home> ouch, another 450MB being downloaded
<ericb2> hello
<ericb2> are there pre-installed Ubuntu versions for OMAP3 available, and hat we can use with a screen 1024x768 only (BeagleBoard xM) ?
<rsalveti> ericb2: https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<rsalveti> ericb2: you can change the boot args and put the resolution you want/need
<ericb2> rsalveti: I already tested these images, and I didn't find how to change that. Was simply not working. But maybe it was my fault.  Ok, I'll retry :)
<rsalveti> ericb2: https://wiki.ubuntu.com/ARM/BeagleEditBootscr
<rsalveti> ericb2: it should work, so ping me back if it fails again for you
<ericb2> rsalveti: ok, I'll try. Thanks a ot
<ericb2> rsalveti: btw, I did an ARM version of OOo4Kids, and I'm searching testers
<ericb2> rsalveti: http://ftp.educoo.org/home/OOo4Kids/Linux_ARM/OMAP3/
<ericb2> rsalveti: I optimized a critical part using assembler, but I didn't put online the version. Will do tonight or tomorrow
<rsalveti> ericb2: cool!
<ericb2> rsalveti: it works on sakoman version, not sure it will work on Ubuntu
<ericb2> rsalveti: would be great to confirm
<rsalveti> well, it should :-)
<ericb2> rsalveti: I used ARCH_FLAGS+=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -D__SOFTFP__
<ericb2> rsalveti: I'm not sure add -D__SOFTFP__ is a great idea, but was efficient
<ericb2> rsalveti: is Ubuntu compatible with such flags ?  Was Steve Sakoman who suggested most of them
<rsalveti> ericb2: yeah, you should be fine with it
<ericb2> rsalveti: ok, great :)
<ericb2> sakoman: ping ?
<sakoman> pong
<ericb2> sakoman: hello
<ericb2> sakoman: after some investigations, looks like the flex issue was caused by a bad m4 path
<ericb2> sakoman: in the recipes add #define M4 "/usr/bin/m4"   helped
<ericb2> sakoman: and most of the issues were solved
<ericb2> sakoman: I meant add this in the config.h  , in the recipes
<sakoman> ah, OK
<ericb2> sakoman: the fix has been not been found by me, but I report it
<sakoman> is there anything that I could do to avoid the need for this?
<ericb2> sakoman: no idea. Maybe flex was built before m4 being installed ?
<sakoman> perhaps, I will take a look at the recipe for flex
<ericb2> sakoman: ok, thanks :)
<sakoman> it might not have set m4 as a dependency
<ericb2> sakoman: could be
<ericb2> sakoman: btw, I did the assembler part, and indeed, its faster
<ericb2> sakoman: but I need to continue, because I'm over 10s at first launch, and that's prohibitive
<sakoman> ericb2: looks like flex is indeed missing m4 as a dependency
<sakoman> so it likely got built prior to m4
<ericb2> sakoman: good. So it might explain
<sakoman> I'll fix that and we can see if that helps next time you do a build from scratch
<ericb2> sakoman: sure. Just tell me when I can update
<ScottK> ogra: Correction from the meeting.  The kernel for n900 was uploaded, but rejected.  Needs a bit more work.
<ogra> ah
<ogra> still a chance it makes it before FF ?
<ScottK> Usually with archive-admin rejected pacakges they can be reuploaded after FF.
<ScottK> I don't think it'll have a hard time getting an FFe if needed.  The whole plasma-mobile effort (of which that's a part) is still tech preview.
<ogra> yeah
<GrueMaster> ogra: Is there a reason that the initrd.img-`uname -r` is missing from /boot on the preinstalled images prior to first boot?  The link is there, but the actual initrd is missing.
<GrueMaster> I have checked several images since A2.
<ogra> GrueMaster, we dont need it
<GrueMaster> We will.  I will need it for test automation.  I need to be able to rip it apart and add scripts from my desktop prior to first boot.
<GrueMaster> I can't do that with uInitrd.
<ogra> GrueMaster, did we use to have it ?
<dmart> ericb2: /quit
 * ogra dorsnt think so
<GrueMaster> Not sure.  But the link is there, so it is being generated during image build.  And uInitrd has to come from somewhere.
<ogra> it is never generated *inside*  the rootfs, but separately
<ogra> thats why i sak
<ogra> *ask
<ogra> if it was there before A2 and isnt anymore it must be a change we introduced
<GrueMaster> Then what creates the link in the image?
<ogra> livecd-rootfs
<sveinse> Have anyone tried to let X-Loader load the kernel directly and not via U-Boot? I don't see why I want to use U-Boot on a SD-card, since its removable.
<GrueMaster> ogra: Doesn't make sense to create a link to a non-existent file.
<rsalveti> sveinse: I know people that created the http://gitorious.org/0xlab-bootloader/qi-bootloader to load the uImage directly
<rsalveti> but I believe currently it only supports omap 3
<ogra> GrueMaster, no, it rolls the initrd and during that process the link gets created
<GrueMaster> sveinse: I believe I heard someone doing this on beagle.  Not sure.
<rsalveti> at least for omap 3 it's very fast, and avoids loading u-boot
<GrueMaster> ogra: ok.  But why keep the link and not the file?
<sveinse> fast is music :D
<XorA> if you on an omap 3630/3730 you dont need x-loader, kernel can load directly
<XorA> just need someone to write a script to generate the correct header
<sveinse> XorA, I'm on am3505 and omap3515, so the MLO is limited to 128k IIRC
<XorA> sveinse: then you have to have some form of bootlader :-)
<sveinse> XorA: yup, and the idea was to add the kernel init to X-Loader.
<sveinse> XorA, today MLO/X-Loader loads U-boot which loads the kernel
<ogra> GrueMaster, the file reappears after update-initramfs was run .... its a space decision stemming from x86
<XorA> did you try renaming uImage to u-boot.bin :-)
<XorA> that might even just work (tm) :-)
 * ericb2 yet not understood what dmart wanted to say 
<XorA> need to hardcode the CMD_LINE and machine number of course
<ogra> GrueMaster, on live and preinstalled, that file is never used for booting, after ubiquity/oem-config has run the actual file to run the system is created (and differs quite a lot) on x86 isos it saves about 5M to not have it in /boot
<ogra> GrueMaster, if we want to keep that file that will need some hackery in livecd-rootfs
<sveinse> XorA, hmm, that I'll try. However the bootprompt is not setup by X-Loader in that case
<XorA> sveinse: Id be interested if you do code it to put it into OE
<GrueMaster> ogra: On x86 iso it does exist.  /casper/initrd.lz
<ogra> GrueMaster, thats the equivalent of uInitrd ;)
<ogra> GrueMaster, what you talk about would be /boot inside the squashfs
<GrueMaster> At least with x86, I can lzma -dc <initrd.lz >initrd.img and muck with it from there.  I have yet to successfully rip the uboot header from uInitrd.
<GrueMaster> Even using dd to strip the 64 byte header.
<GrueMaster> Or is it lz compressed as well?
<GrueMaster> Nope.  Decoder error.
<GrueMaster> Nevermind.  Figured it out.  It is gzip, but the file meta gets clobbered sometimes.  Very odd.
<prpplague> fyi, tomorrow is the last day to provide feedback for rev2 of the Trainer Board for use with the Beagle and Panda boards : http://www.elinux.org/BeagleBoard_Trainer
<sveinse> Poll: Which device do you use for JTAG debugging?
<prpplague> sveinse: hehe, i'm biased but i use the flyswatter
<prpplague> sveinse: and soon the flyswatter2
<sveinse> how soon?
<prpplague> sveinse: testing prototypes now, so i'd say probably 90 days
<prpplague> sveinse: flyswatter is fully tested with openocd and openocd has support for a wide range of processors and debugging methods
<sveinse> openocd, right? Do you know if openocd has scripts for omap3515 and am3505 ?
<prpplague> sveinse: not specific to those but omap3 and cortex-a8
 * sveinse *googling*
<prpplague> sveinse: shouldn't be hard to add
<sveinse> Hmm. I've tried that once. Had to abandon it because I was missing docs for the properitary JTAG muxer inside the SoC
<prpplague> sveinse: this page is probably a little out of date but has the basic info - http://www.elinux.org/BeagleBoardOpenOCD
<prpplague> sveinse: yea that has been resolved
<prpplague> sveinse: TI has provided enough info for openocd to handle it
<sveinse> Where can I sign up for flyswatter2 preorder? ;)
<prpplague> sveinse: send an email to rusty@tincantools.com
<prpplague> sveinse: i know these guys are doing a bunch of openocd work http://www.ok-labs.com/leadership/bio/daniel-potts-phd
 * ogra feels it getting cold ...
<ogra> freeze is in effect
<GrueMaster> and I just thought it was my wife. :P
<lardman> lilstevie: ping
<lilstevie> pong
<lardman> so, after about 13s I get a dmesg message that the power has been set on on the LCD
<lardman> but it then goes off immediately
<lilstevie> interesting
<lardman> so looks like it's up and running ok, just need to do some tweaking of where the sysfs echo is happening
<lardman> Does your image use gdm?
<lardman> and do you have to login, or does it happen automatically?]#
<lilstevie> I use GDM
<lilstevie> and i have autologin set
<lardman> was that set by default?
<lilstevie> no
<lardman> just wondering if the X server is restarted when the login happens, and I don't get to call the sysfs stuff again
<armin76> Guest91304: i like your new nick :D
<ScottK> janimo: python-qt4 built, so I can retry kdebindings here in ~20 minutes.
<ScottK> janimo: OK.  Let's see how it goes.
<ScottK> lardman: By default when you logout, GDM does restart it, but KDM doesn't.  Don't think either one does on login.
<lardman> thanks ScottK
<lardman> am just trying to work out where to switch the LCD back on after X starts (which for some reason turns it off)
#ubuntu-arm 2011-02-25
<TheUni> rsalveti: you around?
<TheUni> rsalveti: i got xbmc building, but need some 'best-practice' advice
<rsalveti> TheUni: cool, good to know
<rsalveti> yeah, will try to help on that
<TheUni> rsalveti: this worked: https://github.com/xbmc/xbmc-packaging/commit/b3e4b7042bf389afcc92c85b10b0cea02928b996
<TheUni> but i'm unclear if i should use debian/tmp/usr/lib, debian/usr/lib, or debian/xbmc-bin/usr/lib/
<TheUni> or if it matters at all
<fairuz> hi morning
<ericb2> Morning good people :)
<fairuz> :D
<fairuz> someone can help me on device driver?
<fairuz> on how to flush L2 cache (PL310)
<riscky> alright alright alright
<riscky> sup all
<riscky> does anyone know if ubuntu supports the nvidia tegra 2 platform yet?
<riscky> really hoping i'll be able to load ubuntu when the kal-el chip hits later in the year
<riscky> fairuz i guess the question i was really asking is, has ubuntu been optimized for arm
<riscky> oh natty is nicely nicely vincent pricely
<riscky> time to roll up
<riscky> damn
<riscky> fairuz, are you around bruv
<fairuz> yes
<riscky> http://tegradeveloper.nvidia.com/tegra/downloads < needs to be in the topic
<LetoThe2nd> oO( why should it... )
<riscky> 92'efrs and not a peep
<riscky> then again it is 4am.
 * LetoThe2nd thinks that someone here is just talking in a weird, random language.
<ikonia> I thogutht hat too
<ikonia> that
<ikonia> 92'efrs ?
<riscky> fairuz thanks for the help i'm going to try to build ubuntu on a Nvidia Tegra 250
<riscky> its not random there are 92 users in the channel
<riscky> efrs = fuqers = fuckers
 * LetoThe2nd suggests that somebody gets quietened.
<ikonia> ahhh ok, 1.) you'll find it easier if you talk in clear english 2.) the swearing isn't needed or welcomed
<riscky> hence efrs instead of the later
<riscky> get it
<riscky> ikonia please dont act as if this did not carry over from #ubuntu
<ikonia> I do get it
<ikonia> riscky: I'm not
<riscky> if you get it then why bring IT up
<ikonia> riscky: it would be helpful though if you could speak in clear English as I genuinly can't understand most of what you're saying,
<ikonia> I do get it now
<ikonia> I didn't when you said it, you've just explained it
<LetoThe2nd> well, at least in my local languages ubuntu channel, this behaviour and quit message would get him banned. my $.02
<ikonia> it would do too
<ikonia> he's already banned from other ubuntu channels for a similar incident
<LetoThe2nd> ah yes.
<ikonia> I guess just move on, I'm interested in the cross-compile info in the topic
<lag> rsalveti: Hi
<rsalveti> lag: hey
<lag> rsalveti: Have you heard any more about bug 694059?
<ubot2> Launchpad bug 694059 in qemu-kvm "qemu fatal cp15 message report and image creation block" [Undecided,Fix released] https://launchpad.net/bugs/694059
<rsalveti> lag: not yet fixed for maverick
<rsalveti> but should be fine with natty
<rsalveti> should be easy to fix
<rsalveti> will put this to my todo
<rsalveti> sebjan: we're trying to call the toll free number, but it's failing
<sebjan> rsalveti: argh, we are connected right now...
<lool> persia: hey; do you know how the sb patches stand WRT to upstream inclusion?  did anybody prepare a merge request for Nicolas?
<rsalveti> NCommander: janimo: I believe we can close the mono bugs and create a new one just for the smp issue
<rsalveti> easier to track
<tgall_foo> say do any of these packages really have an application on arm ?  : libdrm-radeon1, libdrm-nouveau, libdrm-intel1    ... plymouth claims a dep but I suspect that's not the case on arm
<rsalveti> tgall_foo: hehe, not at all
<rsalveti> we have some more extra if you want
<rsalveti> like tons of xserver drivers
<tgall_foo> rsalveti, that's ok :-)
<Sarvatt> debian/scripts/vars.arm*  changes in the xorg meta package to just have it install what you want would be appreciated, its just a skeleton copied from other arches :)
<GrueMaster> rsalveti: I'll open a new bug on mono regarding SMP and get NCommander to fill in what he knows.
<rsalveti> GrueMaster: cool, thanks a lot
<GrueMaster> Actually, bug 619981 has already been reassigned to mono.  Do we really need a new bug?
<ubot2> Launchpad bug 619981 in mono "Banshee crashed while sitting idle on omap4" [High,Confirmed] https://launchpad.net/bugs/619981
<GrueMaster> I can change the description to be more mono specific.
<GrueMaster> Something like "mono apps crash on omap4 due to no smp support"
<rsalveti> GrueMaster: yeah, could be
<GrueMaster> I changed the description.  I also pinged NCommander to add his info to it (since he is assigned the bug and actually doing work on it).
<rsalveti> cool, thanks a bi
<rsalveti> *bit
<lag> If I were to take an Arm Ubuntu filesystem, what would I have to do to the kernel to make it work?
<lag> I've heard mumbles of Ubuntu SAUCE
<rsalveti> install and boot
<rsalveti> :-)
<rsalveti> I already booted with upstream based kernel
<rsalveti> so don't know you'll face issues with ubuntu sauce
<lag> rsalveti: Okay, cool
<lag> rsalveti: So I'm probably looking at a "hardware is not supported correct" error
<lag> s/correct/correctly
<lag> rsalveti: Which mainline kernel did you take?
<rsalveti> 38
<rsalveti> with omap 3
<lag> rsalveti: And it just worked out of the box?
<rsalveti> yup, after installing, creating the initrd, writing the uImage and uInitrd
<lag> rsalveti: How'd you fancy giving this one a stab?
<lag> rsalveti: http://snapshots.linaro.org/11.05-daily/linaro-netbook-efl/latest/0/images/tar/linaro-natty-efl-tar-20110225-0.tar.gz
<rsalveti> lag: what is this, just the rootfs?
<rsalveti> anyway, 40 min to download, very slow
<lag> rsalveti: Yes, rootfs
<janimo> rsalveti, agree wrt mono bug
<GrueMaster> janimo: which part do you agree on?
<Oxwivi> Hello, I want to install Ubuntu on an aPad (Chinese iPad rip-offs running Android), and the processor is ARM926EJ-S rev 5. Which image do I use?
<Oxwivi> *yawn*
 * Oxwivi yawns.
<Oxwivi> Hello, I want to install Ubuntu on an aPad (Chinese iPad rip-offs running Android), and the processor is ARM926EJ-S rev 5. Which image do I use?
<suihkulokki> there is no image that will help you
<suihkulokki> first of all you'll need to get the apad maker to give you the sources of the apad kernel
<Oxwivi> What aPad kernel?
<Oxwivi> suihkulokki, what aPad kernel do I need to get from the manufacturer? Isn't Android itself using Linux's kernel?
<janimo> GrueMaster, what rsalveti said, making 1 mono bug
<armin76> Oxwivi: ubuntu can't run on that processor, well, until 9.04 it can
<Oxwivi> Huh? So what if I insstall 9.04 and upgrade it to the latest, armin76?
<GrueMaster> janimo: I rewrote the description for bug 619981.  I hope to kick NCommander into adding his notes to it soon.  No sense opening a new bug.
<ubot2> Launchpad bug 619981 in mono "mono apps crash on omap4 due to no smp support for armel" [High,Confirmed] https://launchpad.net/bugs/619981
<janimo> GrueMaster, well right. One bug and to reflect is it mono
<janimo> indeed I remember seening the subject change on that bug
<GrueMaster> I'll add info on my f-spot testing as well.
<GrueMaster> Right now I need food.  Getting shaky.
#ubuntu-arm 2011-02-26
<dptech> Hello, where can i take tutos for ubuntu arm in my ePAD ZT-180 (ARM11) with 512Mo RAM and 4Go HD ?
<dptech> up ?
<ericb2> hello
<ericb2> rsalveti: after I bought a new monitor, I was able to launch the natty version on my bb xM
<ericb2> rsalveti: the OOo4Kids I built on sakoman OMAP3 + GNOME install set runs ok
<ericb2> rsalveti: but I'm building from scratch, to verify that's ok too with Ubuntu
<dptech> Hello,could you help how can i install in tablet PC ?
<armin76> dptech: ubuntu is not going to work on your processor
<armin76> dptech: your processor is only supported up to 9.10, and you need to have a kernel
<dptech> armin76: also arm11 ? (ZT-180)
<rsalveti> ericb2: cool, good to know
<dptech> rsalveti: i found images for ubuntu arm, is it functionnal for ZT-180 (arm11) ?
<rsalveti> dptech: just the old ones
<rsalveti> like 9.10
<rsalveti> you'd need a armv7 cortex a8 to run lucid or maverick
<armin76> dptech: you need to have a kernel for your device
<armin76> which are hard to find for such devices, tbh
<dptech> ok thanks a lot...
<lilstevie> is there a way of restoring an image back to total default settings
<lilstevie> like if I am preparing a rootfs for distribution for a platform, but I have used wifi/ssh to set up the image
<ericb2> rsalveti: FYI :  http://wiki.ooo4kids.org/index.php/EnvironmentSetup/Linux#Angstr.C3.B6m_Linux_ARM.28v7_mini.29_case
<ericb2> rsalveti: I'm not yet done with Ubuntu, but I put some usefull information (I hope so), like first boot. Feel free to ask if you need something else
<ericb2> rsalveti: Ubuntu case is somewhere below , in the page
<rooferdave> I now its a long shot...., no one at cyanogen (compiling kernel using this http://wiki.cyanogenmod.com/index.php?title=Building_Kernel_from_source&oldid=9167 duing compiling i get this :http://cyanogenmod.pastebin.com/zPVcFMet
#ubuntu-arm 2011-02-27
<desrt> hello!
<desrt> anybody home? :)
 * desrt is wondering if ubuntu makes it easy to install a non-eabi crosscompiler for building uboot
<desrt> there is mention of it here: https://wiki.linaro.org/Platform/DevPlatform/Specs/LinaroCrossCompilers but it seems like there hasn't been much progress...
 * desrt pretends to know what he's doing, tries a build...
<lool> slangasek: Looks like my recent binutils-multiarch change breaks your upload and hrw's; let's discuss this on monday?
<slangasek> lool: ok
<_bruce> i am using the ubuntu-netbook-10.10-preinstalled-netbook-armel-omap.img on my beagleboard XM. it is a bit slow but usable nevertheless. the problem is that it does not automatically set the ethernet card's IP addresses/subnet for me until i login
<_bruce> (i primarily login to the bbxm using ssh so i want this to set automatically)
<_bruce> how do i go about doing so?
<_bruce> ahh, /etc/network/interfaces
#ubuntu-arm 2012-02-20
<scientes> ATP you said LVDO which isn't usb
<scientes> try tail -f /var/log/kern.log and the unplug and replugin the device
<GrueMaster> TheMuso: I would assume so.  The alsa issue on panda was pretty much resolved with my patch to the ucm configs and a kernel patch.  Unfortunately, we didn't have images for a week, so I only spotted it Friday.
<TheMuso> GrueMaster: Right, well I did announce a call for testing for alsa-utils, I know the ubuntu-audio-dev PPA is not building for ARM atm, but I thought you guys would have seen the cft, pulled and rebuilt at least...
<twb> TheMuso: I have a TF101, I remember there was a problem with oneiric's alsa-utils and I fixed it by cherry-picking precise's...
<twb> Something festival was triggering
<twb> Probably unrelated, so ignore me and carry on
<pnphi> joined
<pnphi> help me
<pnphi> ERROR: An error occurred while enabling: mailmerge.py Cause: (com.sun.star.registry.CannotRegisterImplementationException) { { Message = "ImplementationRegistration::registerImplementation() InvalidRegistryException during registration (destination registry is read-only!  cannot merge!)", Context = (com.sun.star.uno.XInterface) @0 } }  unopkg failed.
<pnphi> what errors ??
<twb> I don't even want to look at that
<pnphi> ERROR: An error occurred while enabling: mailmerge.py
<pnphi> Cause: (com.sun.star.registry.CannotRegisterImplementationException) { { Message = "ImplementationRegistration::registerImplementation() InvalidRegistryException during registration (destination registry is read-only!  cannot merge!)", Context = (com.sun.star.uno.XInterface) @0 } }
<pnphi> unopkg failed.
<micahg> ok, uploading chromium which will hopefully build on armhf
<pnphi> udo rootstock \         --fqdn ubuntu \         --login ubuntu \         --password ubuntu \         --imagesize 3G \         --seed ubuntu-desktop
<pnphi> this command ! !
<twb> I thought rootstock was deprecated
<pnphi> hjx
<infinity> micahg: \o/
<micahg> it's started to compile, it's not on a panda, so it might be another 17 hours until we know for sure if it worked
<infinity> Err, what?
<infinity> Grr.
<infinity> Who took the beagles off manual? >:(
<micahg> they've been off manual all weekend
<infinity> micahg: Not true.
<micahg> well, since sat night my time AFAIR
<twb> infinity: that beagles line took me *way* too long to understand
<infinity> micahg: Looks like they only went off manual about 5h ago.
<infinity> micahg: Anyhow, hleoung fessed up to it at least.  Maybe I'll get your builds killed.
<micahg> well, they were rebalanced apparently about that time as well
<micahg> infinity: sounds good to me :)
<infinity> micahg: No, I rebalanced and put them on manual around a day ago.
<infinity> micahg: Keep up. ;)
<micahg> ah, ok :), I slept at some point in there, so it's all blurring together :)
<infinity> Pfft.  "sleep"?
<infinity> micahg: I notice that firefox hates PPC again. :/
<micahg> yeah, upstream is fighting about it :)
<infinity> Fun.
<twb> IME mozilla hates everyone
<micahg> nah, it's just the JIT components change frequently and powerpc isn't a tier 1 platform, so there's no check if it breaks when stuff is committed
<micahg> infinity: crud, armhf failed, seems like missing libc headers which is worrysome: https://launchpadlibrarian.net/93446095/buildlog_ubuntu-precise-armhf.chromium-browser_17.0.963.56~r121963-0ubuntu3_FAILEDTOBUILD.txt.gz
<infinity> micahg: That seems... Odd.
 * infinity digs deeper.
<infinity>  /usr/include/arm-linux-gnueabihf/bits/predefs.h
<infinity> Looks there to me...
 * infinity upgrades linux-libc-dev to see if it went poof.
<micahg> right, I thought it was odd
<infinity> micahg: Does chromium do anything suspect with toolchains, like zero out and rewrite the standard include paths?
<infinity> micahg: (And maybe get it wrong for armhf?)
<micahg> I can't say a definite no to that, it's possibke
<micahg> *possible
 * micahg checks the Debian patch
<micahg> Debian's stuff is still building, but they don't seem to do any path hacking
<infinity> Well, predefs.h exists in the same place on amd64 and armhf (except for the triplet, of course)
<infinity> So, about the only way this could go wrong is a multiarch/triplet goof.
<infinity> And if the armhf toolchain was broken, you surely wouldn't be the only package failing.
<infinity> Or, one would think not. :P
<infinity> Eww, chromium is cdbs?
<micahg> not my choice and I'm too lazy to rewrite it
<micahg> # BUILD_ARGS=SYMBOLS=1 BUILDTYPE=Release CFLAGS="" CXXFLAGS="" CPPFLAGS="" LDFLAGS="" -j3
<micahg> that would be the only thing I can think of
<infinity> I hate build systems that obfuscate the compiler command line. :/
<infinity> But I have a sneaking suspicion there's some -nostdinc action going on there.
<infinity> And then manual reconstruction of stdinc.
<infinity> For no sane reason.
<infinity> But that's just a wild guess.
 * infinity boggles.
<infinity> Why does the chromium source contain pre-compiled compilers?
<infinity> I think I just vomited a little.
<infinity> micahg: Tell me none of this bundled stuff (like ffmpeg) is included in the build?
<micahg> infinity: umm, it shouldn't be using any of them
<infinity> Kay.  Just checking.
<infinity> Cause it makes some radical assumptions about arm=softfp.
<micahg> google ships their own toolchain for nacl, but I can't get it to build yet
<infinity>   // Ubuntu 11.10 (Oneiric) places the libraries here.
<infinity> #if defined(ARCH_CPU_X86_64)
<infinity>   paths.push_back(FilePath("/usr/lib/x86_64-linux-gnu/nss"));
<infinity> #elif defined(ARCH_CPU_X86)
<infinity>   paths.push_back(FilePath("/usr/lib/i386-linux-gnu/nss"));
<infinity> #elif defined(ARCH_CPU_ARMEL)
<infinity>   paths.push_back(FilePath("/usr/lib/arm-linux-gnueabi/nss"));
<infinity> #endif
<infinity> ^-- Might relate to our issue.
<infinity> crypto/nss_util.cc
<micahg> yep, the multiarch path hack
<micahg> I remember that now
<infinity> But, still, unless they're using that file to then define their include paths for the compiler, I don't see how it being incorrect/incomplete would lead the the build failure.
<infinity> But, again, obfuscated build log means I have no effin' idea what it's doing. :/
<infinity> I might have to do a local test build tomorrow.
<infinity> Or you could do it on scheat.
<micahg> yeah, that doesn't seem to make sense for this failure though
<infinity> And none of the native_client/tools/llvm stuff gets used, right?
<infinity> Cause it's wildly in need of learning about armhf.
<micahg> no
<micahg> native_client is NaCL which is disabled on all archs ARM
<infinity> Hrm.
<micahg> that snippet you gave will cause a runtime issue on armhf though
<infinity> Certainly, yeah.
<infinity> Other than that, though, I can't find anything obviously broken outside native_client and third_party...
<micahg> I guess I can kick off a build when I start tomorrow on scheat and poke a little
<micahg> err, later today
<pnphi> help me ...
<pnphi> what the error ?
<pnphi> An error occurred while enabling : mailmerge.py
<xranby_ac100> pnphi: no-one uses rootstock    the last release was from 2010-08
<pnphi> and unopkg failded
<xranby_ac100> pnphi: do the ubuntu install images work on your board?
<pnphi> and unopkg failed
<pnphi> on qemu
<pnphi> sudo rootstock \         --fqdn ubuntu \         --login ubuntu \         --password ubuntu \         --imagesize 3G \         --seed ubuntu-desktop
<pnphi> i run the command
<xranby_ac100> pnphi: why do you use rootstock?
<pnphi> i see on the Wed
<pnphi> so i use this
<xranby_ac100> its not anything that are supported officially
<pnphi> From step --> Setting up xulrunner-1.9.2 .... this process stop
<pnphi> so what do i use ?
<xranby_ac100> pnphi: people use ubuntu.core
<xranby_ac100> ubuntu-core
<pnphi> what is ubuntu-core ??
<pnphi> this can create the image ubuntu for ARM
<xranby_ac100> pnphi: the reccomended way to install ubuntu on arm are to use the release images
<pnphi> i want to know...how to create this image
<xranby_ac100> pnphi: please read https://wiki.ubuntu.com/Core
<xranby_ac100> pnphi: rootstock that you tried to use are depricated and no longer maintained
<xranby_ac100> pnphi: see https://wiki.ubuntu.com/ARM/RootStock
<pnphi> help me..how use the ubuntu-code to make the image ubuntu for ARM
<pnphi> i run on Qemu
<xranby_ac100> you can also use live-build
<pnphi> clearly ? ?
<pnphi> link or Document ?
<xranby_ac100> pnphi: http://live.debian.net/manual
<xranby_ac100> pnphi: ubuntu uses live.build to build all its live-images
<xranby_ac100> you can install the tool by running apt-get install live-build
<pnphi> does this link help me to create the image ?
<xranby_ac100> pnphi: sorry i cant help you further since i only use the live images produced and uploaded to http://cdimage.ubuntu.com/daily-preinstalled/current/
<xranby_ac100> pnphi: yes it do
<pnphi> ok thank you so much
<pnphi> can i give your email ?
<xranby_ac100> pnphi: so in a nutshell if you want to be able to create your own image identical to how ubuntu produce their images you will have to learn how to use live.build
<xranby_ac100> no
<xranby_ac100> please ask questions here
<pnphi> yes
<xranby_ac100> there are probably other developers who know live-build better
<xranby_ac100> than I
<pnphi> i want to create the image ubuntu desktop for ARm,run on Qemu ! ! !
<pnphi> so..i learn from this link
<pnphi> thank you
<xranby_ac100> youre welcome
<pnphi> so hard ! ! !
<xranby> pnphi: https://wiki.linaro.org/LiveHelper/Hacking     try this linaro guide
<xranby> pnphi: linaro use live-build to build a lot of arm images
<pnphi> wow..thank you so much
<pnphi> why rootstock deprecated ?
<xranby> pnphi: because debian and ubuntu use live-build
<xranby> to build their daily images
<xranby> i really do not know any specifics
<pnphi> wow..yes,
<pnphi> thanks xranby
<pnphi> i try ! ! !
<berco> ndec_: j'ai pushÃ© libdrm, libdri2 et xf86-video-omap dans omap trunk. je crois que tu en avais besoin. both armel et armhf builds
<berco> ndec_: pour pvr, je bosse avec Xavier dessus
<berco> ndec_: ha yes
<berco> ndec_: nevertheless, you get the info ;)
<ndec_> fortunately i speak french ;-)
<gildean> google does too
<ATP> does anyone know how i can change my dvimode? I tried uenv.txt already...
<ppisati> GrueMaster: bug 937051
<ubot2`> Launchpad bug 937051 in linux-ti-omap4 "Cannot set MAC address via kernel boot parameters" [Undecided,New] https://launchpad.net/bugs/937051
<ATP> if anyone answered please say again , my browser crashed >.<
<royale1233> hi
<royale1233> hi
<Epsilonorion_> Does anyone know of the best way to setup wireless ad-hoc within ubuntu server.  I attempted to edit the interfaces file (all in CLI) and haven't had any luck.  The network is being created because I can see it via another computer, however I cannot ping from the computer
<gandhijee_> because i am trying to build some packages for ubuntu 10.04 on inside by ubuntu 11.10 chroot to 10.04
<gandhijee_> and it doesn't build it the same as my 10.04 machines...
<xranby_ac1001> gandhijee_: thats normal since all the build tools and compilers are newer in your chroot
<gandhijee_> ? xranby i have a 10.04 chroot in my 11.10 build... i would expect i had the same tools as i do on my stand alone 10.04 inside of my 10.04 chroot.
<xranby_ac1001> ok then i misunderstood you
<gandhijee_> yeah, it is a bit confusing.
<xranby_ac1001> well debug symbols inside binarys will contain the location of the sourcefiles that where used
<xranby_ac1001> so binarys will not be 100% identical
<xranby_ac1001> what kind of difference do you see?
<gandhijee_> thats not really the problem.  when it goes makes the actual deb file, it get populated with different things.
<xranby_ac1001> sounds like a bug for that package
<gandhijee_> and i can't figure out why, as i tarred it from the actual system and moved it to the chroot and it doesn't work
<gandhijee_> but i can untar it on the actual system in a different directory and it works.
<xranby_ac1001> check the mount options inside the directory you untar it into
<xranby_ac1001> a simple cross check that you do not have noexec bit set on the filesystem
<xranby_ac1001> you can also run ldd on the binary to check that it got all shared librarys in place on the target system
<gandhijee_> ok
<xranby_ac1001> what kind of error do you see when you try to run the file onem?
#ubuntu-arm 2012-02-21
<gandhijee_> xranby, no errors, the deb file just has the wrong things in it.
<pnphi> excese me ! !
<ppisati> anyone from arm's IS?
<dmart> ppisati: no, but what's your question?
<ppisati> dmart: someone told me you had panda's with same die id (and thus same mac address) and you couldn't change it at boot time
<dmart> can you remember who you were talking to?  I haven't experienced that.
<ppisati> dmart: Tobin told me that and the bug is real (i've a fix for that)
<ppisati> fix sent
<GrueMaster> ppisati: Thanks.  And it was Canonical IS, not Arm.  Lamont specifically.
<ppisati> GrueMaster: ah ok
<GrueMaster> ppisati: So, did it make it into the SRU kernel that is coming?  If so, I'll test it as soon as I can.
<ppisati> GrueMaster: nope, not pulled yet
<GrueMaster> Ok.
<Epsilonorion_> What is the default runlevel of Ubuntu 12.04?  I checked in rc-sysinit.conf and it says level 2, however my system seems to be running in level 1 (no level 2 scripts started at boot).  Is there a command line way to check and make sure of the current configuration?
<smplman> can someone help me merge the nvidia tegra kernel changes into my source? I have ubuntu 11.10 booted on my Xoom but wifi, bluetooth, and graphics acceleration aren't working.
<xranby_ac100> smplman: whick kernel version are you using?
<xranby_ac100> which
<smplman> xranby_ac100: 2.6
<xranby_ac100> 2.6.*?
<smplman> 2.6.36 i believe
<xranby_ac100> smplman: have you tested to use the latest ubuntu kernel sourcetree?
<smplman> my device is at home atm
<smplman> no, i can try to update and rebuild when i get home
<xranby_ac100> hmm i have to check if the xoom was based on the nvidia-harmony dev board
<xranby_ac100> if so then most work applied to the ac100 kernel should be usable for your setup
<smplman> ventana
<smplman> i found the nvidia source http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
<smplman> here is the source that i used to build my kernel https://github.com/LIV2/LIV2-Xoom-GNU
<xranby_ac100> ok hmm then your xoom are similar to the trimslice
<xranby_ac100> you can try the trimslice forum
<smplman> yea i saw a lot of docs about video acceleration, but only the binary comes with the trimslice
<smplman> no source
<xranby_ac100> there is no source
<xranby_ac100> video acceleration on the tegra2 currently only exist as a binary driver from nvidia
<xranby_ac100> the same situation apply for all other arm gpu cores currently
<smplman> ahh i see. Im more interested with wifi atm
<xranby_ac100> but you can get the video acceleration for ventana here: http://developer.nvidia.com/content/linux-tegra-l4t-beta-release
<smplman> xranby_ac100: will give it a shot when i get home from work. WIll be back later
<smplman> thanks for the help
<xranby_ac100> smplman: the ac100 team have managed to get these drivers working on the 3.0 kernels and later
<xranby_ac100> the trimslice still use the android kernel tree
<smplman> so a kernel upgrade may be in order
<xranby_ac100> you can try the #ac100 for tegra2 kernel guidance
<smplman> xranby_ac100: muchos gracias
<xranby_ac100> youre welcome
<Epsilonorion_> Does using update.rc somehow change the runlevel?
<Epsilonorion_> Anyone have any info they can share on how to setup a startup script for a user within ubuntu server?  I setup a autologin for a user.  I then created a startup script that I setup with update-rc.d.  The script seems to run, but not within the user account.  The user account also does not seem to auto login anymore.  Finally, I seem to have issues killing the autoscript when desired.  I can go through ps aux, but that is the only
<Epsilonorion_> way.
<GrueMaster> Epsilonorion_: Have the script change uuid during startup.  A simple way would to have the init script call sudo <user> <script>.
<infinity> Epsilonorion_: For system-provided (ie: packaged) stuff running as another user, you want "su" in your init scrpit.
<infinity> Epsilonorion_: For user-provided, @reboot cronjobs are the way to run things at boot as users.
<Epsilonorion_> is it suggested to run as a user.  I don't specifically need to.  I can just run it as a background service if that is best?
<Epsilonorion_> I had just assumed that using sudo would ask for a password, and I don't want that
<infinity> Epsilonorion_: su, not sudo.  Init scripts run as root anyway, no need for fancy wrappers.
<smplman> xranby_ac100: my wifi/bluetooth chipset is the bcm4329
<Epsilonorion_> infinity: so then on the line where I call the function to run, I use "su username function".  How should I handle the shutdown?  Just use ps aux, or create a stop procedure within the script?
<infinity> Epsilonorion_: If stopping actually matters (ie: if just killing the process won't do), then yes, you need a stop function.
<infinity> Epsilonorion_: And your start would look something like: su -c "/path/to/binary -option -option" - username
<infinity> Epsilonorion_: A third option is learning how to use start-stop-daemon (check the manpage), which lets you feed --user and --group.
<Epsilonorion_> infinity: killing the process will do, however I want an easy way for a user to kill it instead of ps aux and looking for the script.  Thanks for the correct su line.  Is there a correct way to stop the program in this case?
<victorp> ping
<infinity> victorp: Should the channel pong? ;)
<victorp> infinity, not even sure how that got there
<victorp> ooops
<victorp> :)
<infinity> Epsilonorion_: If you want it easily killable (and there isn't a /path/to/binary -shutdown option), then you want to start it with start-stop-daemon.
<GrueMaster> Epsilonorion_: Your init script can just call kill <PID> if it isn't doing anything important.
<infinity> Epsilonorion_: start-stop-daemon can be asked to write a pidfile.
<infinity> Epsilonorion_: Than your stop target can kill that same pid.
<infinity> GrueMaster: Just randomly scanning for PIDs is disastrous, if people may be running more than one copy of the same binary.
<infinity> (user copies, chroots, etc)
<GrueMaster> infinity: I didn't imply random scanning.  I was actually going to suggest storing the PID in /var/run/<app>.
 * GrueMaster is in multiple realities this morning.
<infinity> GrueMaster: Sure, which, if his app doesn't do it, is best done with start-stop-daemon, so I guess we're on a similar page. ;)
<GrueMaster> yes.  I was actually going to look for an example init script that I wrote many moons ago that does this.
<Epsilonorion_> I follow what you guys are saying, and have seen examples of how to store the PID to some extent, however I am new to creating a script in this manner.  Is there a good resource/example of how to do this
<GrueMaster> http://tldp.org/LDP/abs/html/index.html
<GrueMaster> That's what I use for bash scripting.
<infinity> Epsilonorion_: grep start-stop-daemon /etc/init.d/*
<infinity> Epsilonorion_: The ssh init script looks like a good one to steal from.
<infinity> Epsilonorion_: Ooo, kerneloops is even better, since it has the --chuid bit you want too. ;)
<infinity> kerneloops:	start-stop-daemon --start --quiet --oknodo --chuid kernoops:adm --pidfile $pidfile --exec $exec
<infinity> kerneloops:	start-stop-daemon --stop --quiet --oknodo --pidfile $pidfile
<infinity> ^-- Both start and stop invocations.
<infinity> "$exec" in that case would be "/path/to/binary --with --options"
<Epsilonorion_> I found both the site and kerneloops
<infinity> And $pidfile should be /run/mydaemon.pid
<infinity> And --chuid is self-evident, I assume, just change it to user:group that you wanted.
<Epsilonorion_> so doing this method, should I kill the autologin procedure.  It would seem that following this method is closer to creating a service for all users.
<GrueMaster> Epsilonorion_: Unless you are doing multi-user and each user will need a sparate instance of this app, I would make it an init daemon.
<GrueMaster> Far less overhead.
<Epsilonorion_> I just keep wondering if I am making this too complicated.  I started out simply wanting to create a script that would allow a single program to startup when the user auto logged in.  This way I could easily type ps -all, find the user (or the program) and end it.
<infinity> Epsilonorion_: You want an init script if it should be running even if the user isn't logged in.
<GrueMaster> If you want something to run when a user logs in, just add it to the ~/.bashrc (or /etc/bash.bashrc to be global).
<infinity> Epsilonorion_: If the goal is to have it run only when the user is logged in, you want it in their session.
<infinity> Epsilonorion_: As Gruemaster says, .bashrc for a CLI login, or for GUI logins, there's session preferences/editing in the various GUI control panels.
<steev> i have a question regarding the ubuntu udev package.  recent versions of udev seem to have a kernel version check for > 2.6.32, but since I'm using an older kernel with the portions that udev expects backported, i like to remove that check from the udev script, however I can't seem to find where it resides on Ubuntu, anyone know where it is?
<Epsilonorion_> I technically do not need it to run when the user logs in.  The system is a stand alone system.  Users log in to debug code or get logs, however the application should run as soon as it is fully powered up.  I have only been familiar with creating startup scripts for when users log in
<infinity> steev: rgrep 2.6.32 through the udev sources?
<Epsilonorion_> I don't mind letting it be a daemon that runs without a user, as long as when a user logs in they can easily end it
<infinity> Epsilonorion_: Right, if you want it running regardless of people being logged in, the init script you were writing is the right way to go.
<GrueMaster> With it being an init script, a user can end it with "sudo service <appname> stop".
<steev> infinity: well it normally resides in /etc/init.d/udev but that doesn't exactly exist in ubuntu.
<Epsilonorion_> that was what I thought on both accounts.  Then I will stick with the init script.  I assume that I do not need to worry abou tying it into a specific user in this case then
<GrueMaster> Epsilonorion_: No, but for security it is recommended that the process have a non-root user that it runs as (i.e. mysql, apache, etc).
<scientes> will ubuntu support this? http://www.wholesaletabletspcs.com/wholesale-Ainol-Novo7-Elf-7-Inch-Android-4-0-Tablet-PC-Capatitive-Multitouch-screen-Allwinner-many-core-A10-1GB-DDR3-camera-3G-WIFI-2160P-decoding-HDMI.html
<GrueMaster> Not required, but recommended.
<scientes> I want a cheap tablet with dual-core
<scientes> and HDMI+3G+Wifi+nice: GPS
<infinity> steev: We have /etc/init/udev.conf, but I see no kernel checks, there.
<Epsilonorion_> understood.  Thanks GrueMaster, infinity.  Hopefully I won't break anything
<infinity> steev: Are you sure it's not in the C source?
<scientes> also, anybody having success with multi-seat?
<steev> infinity: i'm 100% positive it's not in the C source
<GrueMaster> steev: It could also be in the initrd stuff.
<infinity> Nope, I see no version checks in the udev initramfs hooks either.
<infinity> steev: I honestly see no checks anywhere.  Are you sure something's checking, or just assuming that it must?
<steev> infinity: it does on debian, and gentoo, i just wanted to pre-empt it on ubuntu (doing a clean install)
<infinity> Oh, wait.
<infinity> MINKVER="2.6.24"
<steev> where do you find that?
<infinity> Oddly, it only checks when building the initrd.
<infinity> Actually, I suppose that makes some sense.
<infinity>  /usr/share/initramfs-tools/hooks/udev
<GrueMaster> scientes: Unknown if that will support Ubuntu or not.  Is it armv7?  I can't find any relevant specs on the cpu.
<steev> interesting, and good to know
<infinity> GrueMaster: Looks like the "Allwinner A10" is an A8.
<infinity> (Cuase that's not confusing)
<steev> infinity: it is an A8, i have one, it's quite nice
<infinity> 1.5G A8 and Mali400.
<steev> one of only 2 tablets i have that don't make me want to throw it out the window
<GrueMaster> I read "Allwinner A10 is just under the architecture of ARM Cortex-A8".  http://androidling.wordpress.com/2011/09/12/allwinner-technology-a10-tablet-solution-2160p/
<scientes> guerby, yes it is armv7---cortexA10 to be exact
<scientes> oh wait A* i guess
<infinity> scientes: It's an A8, not an "A10".  Confusing product name.
<scientes> yeah agreed
<infinity> scientes: Anyhow, what did you mean by "will Ubuntu support it"?
<infinity> scientes: Ubuntu's userspace will run on it.
<scientes> gotcha
<infinity> scientes: We don't have a kernel for it, but other kernels would work, if you built your own, or used the Android one.
<scientes> anyone gotten multiseat to work on these tablets?
<scientes> "A10 is just under the architecture of ARM Cortex-A8."
<scientes> damn that is misleading
<scientes> IE use the HDMI w/ usb keyboard+mouse as a seperate computer
<scientes> with a differn't user of course
<GrueMaster> scientes: We're just getting to the point of running alongside Android on tablets.  Not sure if multiseat would work in this instance.  Likely not, as the systems are really underpowered for something like that.
<scientes> well I wanted to do a very targeted thing on the tablet, and desktop-like on the hdmi
<scientes> with a dual-core one
<GrueMaster> You need a lot of memory to have two running desktop instances that are usable.
<scientes> and use one of the 1GB ones
<scientes> but you need multiseat support (two xorgs, seperate input handling) to use both at the same time
<scientes> like I wanted opencpn (navigation) on the tablet, and desktop like stuff on the hdmi
<GrueMaster> All I can say is that it is untested.
<scientes> supposedly systemd is working to bring back multiseat support in linux
<scientes> but i havn't gotten it to work
<scientes> the main thing is to be able to run two Xorg servers at the same time
<scientes> I also want this on x86
<scientes> anyone managed to upgrade the kernel on the sharp netwalker?
<Epsilonorion_> GrueMaster, infinity: I have finished the init script and tested it.  The script seems to be working fine, however, I need a feature I am unure of how to get.  When I made a simple script that ran the program, if I typed "service script" I would get the output of the function started by the script, however, I do not get that feature now.  Is there a way to do this?
<GrueMaster> I'm not sure I understand, but I think the init scripts usually trap output to /var/log/syslog.  You can also have your script create and append to it's own log.
<Epsilonorion_> GrueMaster: Can I do that by adding a pipe at the end of the start-stop-daemon command?  If so, is there a way to make the log file more dynamic (datestamped)
<GrueMaster> I really don't know the full answers to this.  I'd recommend googling at this point.  There are a ton of documents online for this.  Look for init script development.
<Epsilonorion_> GrueMaster: And to better explain what I am doing, the program will have multiple debugging printfs that are useful to check for errors when directly connected to the system.  I currently do not know how to get these printfs to show up if the daemon starts up on boot up.  I killed the --quiet and --background flags and it shows up now though
<Epsilonorion_> GrueMaster: Understood thanks again and sorry for taking your time
<GrueMaster> No problem, I'm glad to help where I can.
<scientes> https://lwn.net/Articles/482760/ OOOOO, can i do this with vhashify from vserver to consolidate ram and disk usage?
<scientes> http://www.ubuntu.com/devices/android/features-and-specs
<scientes> 512MB ram
<scientes> really?
<GrueMaster> scientes: Most of the cell phones out there have 512M.  Some have 1G.
<infinity> Certainly most of the dual core ones, which is also a listed "requirement".
<scientes> well you have 1GB requirement for desktops
<scientes> seems like you had to bend it
<scientes> cause its not like you are changing the stack that much
<GrueMaster> We do?  Hrm, better tellthat to the AC100 and beagleXM users.
<scientes> nono i don't say 512 to too little
<scientes> its just that you are saying you need 1GB to x86 people
<GrueMaster> Well, remember that x86 binaries are much larger too.  Especially for x86-64.
<scientes> true true
<scientes> so is chromium signif faster on arm?
<GrueMaster> Couldn't tell you.  I'm too busy testing stuff to do comparative benchmarking.
<scientes> just wondering why chomium is default over firefox
<scientes> BTW, i was trying to debug opencpn in a precise chroot (arm)
<scientes> and i couldn't get gdb to load the debug symbols
<GrueMaster> Erm, I have Firefox as default on my daily Panda image.
<scientes> you have to use target remote cause qemu doesn't implament ptrace
#ubuntu-arm 2012-02-22
<scientes> GrueMaster, here: http://www.ubuntu.com/devices/android/features-and-specs
<scientes> says chromium=default
<GrueMaster> I really couldn't tell you.  There is a whole different team working on that stuff.
<scientes> http://www.arm.linux.org.uk/docs/faqs/signedchar.php
<scientes> so x86 uses signed char?
<GrueMaster> But it is possibly due to chromium being already there for android.
<scientes> ahh, yes they said synced bookmarks and history
<scientes> so yes that is it
<GrueMaster> As to the char issue, again I couldn't tell you.  I do know that the K&R C book (considered the C reference bible) does say that it could be either/or.  Proper coding standards recommend specifying the variable when creating it.
<GrueMaster> I do remember this being an issue a long time ago between gcc and icc differences in behavior.
<GrueMaster> The key to remember is that if you want your code to work across multiple platforms, never assume a default behavior to be the same.
<infinity> Yeah, the signedness of char is very platform-specific (as in, arch + headers + moon phase)
<infinity> Depending on it being either signed or unsigned is always a Very Bad Thing.
<infinity> (And, really, treating chars as ints is deep voodoo and/or ignorance anyway, despite the underlying implementation of them as such)
<GrueMaster> iirc, that was one of the first things covered in my C programming class.  And that was at a crap school.
<infinity> janimo`: Bad news, libreoffice failed on armel and armhf.  (The armel failure doesn't look arch-specific; same thing happened on powerpc, but the armhf failure is testsuite-related, and only armhf)
<steev> trying to build a kernel here, and i'm getting arm-linux-gnueabihf-ld command not found, and i can't seem to find the package that actually installs it (binutils *is* installed)
<steev> this is on precise alpha2
<steev> what i don't understand is that this is the armhf tarball, but it pretends like it's cross compiling
<infinity> Maybe you need to sort out why it thinks it's cross-compiling, then.
<GrueMaster> steev: What platform is this?  What image?
<steev> GrueMaster:  precise-core-armhf.tar.gz (from alpha2)
<GrueMaster> Ok.  On an arm system I would assume?
<steev> it's on an i.mx51 machine, (i AM chrooted via a m
<steev> mmm... whatever the M release was
<steev> maverick
<GrueMaster> ok.  Should work.  I can try to reproduce it here if you can give me some quick steps (not something like Build LibreOffice).
<steev> GrueMaster: <partitiion sd card, tar -xpf precise-core-armhf, apt-get update, apt-get install ubuntu minimal (watch it fail because of resolvconf), apt-get install git-core, git clone git://github.com/genesi/linux-legacy.git, <edit sources.list, add universe> apt-get update again, apt-get install kernel-package build-essential <setup locales>, cd linux-legacy, mv .git .dotgit (this may be un-neces
<steev> sary, but on some versions of ubuntu it would add a + which would screw things up because of the .git dir), cp arch/arm/configs/mx51_efikamx_defconfig .config, make-kpkg --uc --us --initrd --subarch efikamx --rootcmd=fakeroot --revision 2012.02 binary
<twb> What does "ubuntu for android" actually mean?  Presumably it's just the GUI fluff, and not important stuff e.g. busybox, initramfs-tools, dpkg, apt ?
<GrueMaster> twb: Essentially it means that with this package, when you plug your android phone into a dock with keyboard/mouse/monitor, it will launch an ubuntu chroot environment and display it on the monitor.
<GrueMaster> Similar (but far more integrated) to the Motorola Atrix.
<twb> Ah, OK, so it's a chroot.  And you can install it via the android market?
<GrueMaster> twb: If you read the info on ubuntu.com, then you know as much as I do at this point.  :D
<steev> GrueMaster: oh i left off the chroot part, but i guess you'd know that much :)
<twb> I read LWN's repost :P
<twb> I was gonna read the whole subscriber-only article but I've lost my LWN pasword and ICBF digging it out
<scientes> twb, yeah looks pretty cool doesn't it
<scientes> saw it in ln too
<scientes> *lwn
<twb> scientes: not really
<scientes> well, then why are you asking about it?
<scientes> its pretty simple
<twb> I have zero respect for android; this addition seems notably only in that you get a chroot without having to jailbreak.
<twb> scientes: I'm asking to confirm that it's not actually any sexier than I guessed
<scientes> they did a little cool stuff like sync bookmarks and history
<GrueMaster> I'm really not sure about this new product, but I would guess it is for integration in new devices and not generally publicly available.
<GrueMaster> I.e, you have to buy a phone with this preloaded, or available in the market for that phone.
<twb> GrueMaster: ah, so the idea is that Mr. Motorola or whoever goes "ubuntu is cool, this will add value to my upcoming WhizzBang 9000 device for little investment"
<twb> Gotcha
<GrueMaster> But the basic concept is not new.
<steev> wth?
<steev> debian/ruleset/arches doesn't have armhf in it
<lilstevie> twb, from what I see it is just the same as webtop is on the motorola atrix
<twb> lilstevie: I'm not familiar with that, but GrueMaster et al explained it to me a bit.
<lilstevie> not quite a chroot
<lilstevie> and it gets given /dev/fb1 (the hdmi port)
<twb> It's interesting but I think I'd still prefer to just fuck off android completely, or at most dual-boot
<steev> GrueMaster: i worked around it by adding in armhf by copying/editing the armel.mk (and making related entries into the other .mk files), no need to test
<GrueMaster> steev: Excellent!  My wife had drug me off to dinner, I just got back (sorry).
<steev> no worries
<steev> i was playing WoW anyway
<lilstevie> :/
<lilstevie> I am having shutdown problems, screen goes blank, nothing happens, logs don't reveal anything :/
<janimo`> infinity, checking. I should have started a package build myself right after it was uploaded so I have a FTBFS locally when needed. Oh well
<janimo`> infinity, there is hope for libo armhf. According to the Debian maintainer the workaround of not building Base needs to be instated for armhf as it is for armel
<steev> is there a way to force resolvconf to... configure?  since i'm in a chroot, it can't exactly start, and because of that it keeps throwing up errors
<ogra_> steev, just copy /etc/resolv.conf from the host
<steev> ogra_: i have that, i'm trying to install the package resolvconf
<ogra_> do you have /proc mounted etc ?
<steev> and since it can't start in the chroot it doesn't install successfully (it's a dependency for ubuntu-minimal)
<infinity> Does 'initctl reload-configuration' help?
<steev> ogra_: yes
<infinity> Well, 'initctl reload-configuration && dpkg --configure -a'
<infinity> (Really, chroots should have a policy-rc.d that just denies starting services, though)
<steev> ill try when these packages finish installing, sdcards be slow
<steev> infinity: start: Unknown job: resolvconf\ninvoke-rc.d initscript resolvconf, action start failed.\ndpkg: error processing resolvconf (--configure)
<steev> ogra_: infinity: any other suggestions?
<steev> infinity: ah, someone explained the policy-rc.d to me, okay, have it installed, now i just need to get it booting, thanks for the pointer
#ubuntu-arm 2012-02-23
<GrueMaster> TheMuso: Ping.  Have you seen this issue with alsa 1.0.25? http://paste.ubuntu.com/853433/ Lines 2-4.
<GrueMaster> Not sure if it is a pulse issue or an alsa issue.
<GrueMaster> definitely new to alsa-lib 1.0.25.  I just reverted to libasound2_1.0.24.1-4ubuntu1 and I don't get that error.
<Neko> maybe it's old or corrupted? :D
<GrueMaster> Neko: New image.  Probably just need to kick pulse to work with some change in upstream alsa.
<GrueMaster> Guess I'll need to see if I can reproduce this on x86, since it is pulse-alsa.conf.
<GrueMaster> Yea, I can reproduce it on an x86 VM instance with "sudo alsactl restore".
<GrueMaster> Well, I have a solution to the pandaes audio issue.  Not perfect, but works within the current confines of alsaucm.
<GrueMaster> Will upload tomorrow, when my eyes are no longer crossed.
<TheMuso> GrueMaster: I just fixed some of those alsa-lib errors you showed me the other day, seems 1.0.25 changed some syntax for its conf files.
<NCommander> aramadxp images now building momentary
<ppisati> ogra_: why is it called the FINAL arm meeting? do you plan to commit mass suicide after it (e.g. Lemmings)? :)
<janimo`> ppisati, the ARM team within Canonical is being dissolved and its memebers assigned to other teams in the company
<rbasak> NCommander: around? Daviey asked me about http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html - are you aware of the "linux-armadaxp-tools-3.0.0-1500 has no installation candidate" in there, or is that resolved now?
<NCommander> !@#$#!@!
<NCommander> we shouldn't be building linux-tools
<NCommander> ^- cooloney
<cooloney> linux-tools built failed under armhf
<cooloney> so i disable it in out linux-armadaxp package due to urgent upload request
<cooloney> it can be built under armel, i think
<NCommander> cooloney: I don't think we even need it
<cooloney> NCommander: perf is very useful tool even for arm, we use it a lot for ti-omap4
<cooloney> NCommander: and I saw some new tools was added from Marvell LSP
<NCommander> cooloney: what would it take to fix it ?
<cooloney> NCommander: i guess it's related to compiler, but don't have much time to take a look
<infinity> cooloney: Oh, can you merge my latest armadaxp upload into git?
<infinity> (I really should request zinc access)
<infinity> cooloney: Oh, I see in another channel that you're already on top of it.  Nevermind. :)
<GrueMaster> ogra_: Did you get my email on the pandaES audio situation?
<ogra_> GrueMaster, yes, looks ok, lets upload it after someone (i.e. infinity) also eyeballed it quickly
<ogra_> that udev rule is our hack anyway, adding another few lines for PandaES wont do any harm
<infinity> ogra_: I'm sure you and Tobin are enough of a review.  And I'm happy to not take the blame on Panda audio this cycle. ;)
<ogra_> haha, ok, then i'll just upload after the call
<ogra_> WHEEE!
<ogra_> so chromium 17 seems to work just fine on armel
<ogra_> looks shiny, but takes twice as long as FF to start
<infinity> ogra_: Yeah, no big shock there.  It's just as bloated, just differently. :P
<ogra_> yep, but its great to have it after we had to live with 14 for ages
<GrueMaster> Not seeing chromium for armhf (at least not on my mirror yet).
<ogra_> GrueMaster, thats what we taljked about in the meeting :)
<ogra_> only armel yet
<ogra_> but it builds there for the first time in years
<GrueMaster> ah, ok.
<mahmoh> NCommander: armadaxp netinstall uImage resets, bug 939645
<mahmoh> (which doesn't exist yet)
<NCommander> mahmoh: the image fails to boot?
<NCommander> greaaaaaaaaaaaat
<mahmoh> right
<NCommander> GrueMaster: ^, can you take a look?
<mahmoh> ubot2`: ?
<GrueMaster> NCommander: Can I nuke the armada here or do you have data that you want to keep?
<mahmoh> for me at least, I'm using the 1500.3 uImage and the net installer uInitrd now
<NCommander> GrueMaster: nuke and path.
<NCommander> *pave
<GrueMaster> ok
<GrueMaster> I'm in a meeting now, but will be soon.
<NCommander> mahmoh: so it doesn't boot at all? You got the bootargs right?
<mahmoh> NCommander: it loads and tries to boot but resets immediately
<NCommander> mahmoh: ugh, might be an issue with the mkimage commands
<infinity> mahmoh: Gets into userspace, or dies in kernel init?
<mahmoh> disclaimer: I did tftpboot it though but the checksum was fine so ...
<mahmoh> infinity: dies before kernel init, right after load - you should be able to get to the bug
<infinity> Oh, shiny.
<infinity> (And no, I can't get the bug, I don't have the hardware)
<mahmoh> infinity: I meant see the bug (maybe) to see the details of where it fails exactly
<mahmoh> Starting kernel ...  interrupt request pc : [<0000803c>]          lr : [<006505cc>] sp : 005ffde0  ip : fffeffff     fp : 006d6ce8 r10: 005fff98  r9 : 00000bdc     r8 : 005fffcc r7 : 00000018  r6 : 005ffdec     r5 : 00000000  r4 : 005ffef7 r3 : 00008010  r2 : 000000f8     r1 : 00000bdc  r0 : 0040ff14 Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32 Resetting CPU ...
<mahmoh> NCommander: the good news is the uInitrd looks like it's fine so far ...
<NCommander> mahmoh: god thats special
<NCommander> mahmoh: try it with a differentuImage
<GrueMaster> Yea, I see the same thing.  Will look at the kernel a little.
<GrueMaster> Did the linux-armadaxp meta get bumped?  It seems to be pulling linux-image-3.0.0-1500-armadaxp 3.0.0-1500.2 instead of 3.0.0-1500.3
<GrueMaster> apt-get dist-upgrade is pulling the kernel in, but usually I should be able to just do apt-get update && apt-get install linux-armadaxp to update the kernel.
<GrueMaster> grrr.  resolvconf install error.
<infinity> GrueMaster: That trick only works in the case of ABI bumps.
<GrueMaster> ok.
<infinity> GrueMaster: No ABI bump means no new linux-meta, means you need to upgrade the kernel image itself, not count on linux-meta to do it.
<infinity> (But, as you note, apt-get upgrade gets it right)
<GrueMaster> Guess I'm just used to more that a minor change with new kernels.
<GrueMaster> Ok, the kernel in ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu113/images/armadaxp/ is busted.  Not even sure of it's origins.
<micahg> infinity: sorry, I started to look at it, but lost my session (forgot to run in screen)
<micahg> infinity: for chromium on armhf, if someone else has time to look, feel free
<infinity> micahg: Oops.
<infinity> I'm pretty craptacularly busy today, but remind me tomorrow to kick off a build, so I can look at it Monday. :P
<infinity> GrueMaster: Yeah, I think the SRU 2-week cadence with an ABI bump almost every time has conditioned people to assume that new kernel == new ABI.
<micahg> infinity: that's about the same timeframe I have :)
<GrueMaster> ppisati: The mmap patch seems to have fallen out of the 2.6.35 omap4 kernel.
<ppisati> GrueMaster: uh? it was there
<ppisati> GrueMaster: wait
<ppisati> GrueMaster: gitweb on kernel.u.com is sloooooooowwww...
<ogra_> use bzr !
<ogra_> :P
<ppisati> ogra_: i'll send a pull req to convert from git to bzr :)
<ppisati> GrueMaster: patches are still there
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=2956dd26b949343aca5581356bff6c1cf18a22c2
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=ddc72fa76d3965ca3576cfbc7a1de6e1e4b4a681
<ppisati> M/omap4
<GrueMaster> Maybe in the tree, but the tests are failing.
<GrueMaster> sudo ./mmap-test
<GrueMaster> Couldn't allocate the heap: 1902Mb
<ppisati> doh!
<ppisati> SRU kernel?
<GrueMaster> These are the tests included from the earlier bug (can't remember the bug number.
<GrueMaster> Yes, latest SRU kernel.
<ppisati> ok, i'll check it out
<GrueMaster> 2.6.35-903-omap4 #31-Ubuntu
<ppisati> remind me where the test are located
<ppisati> *these tests
<GrueMaster> I'm trying to find the original bug.  It was fix released a while ago.
<GrueMaster> (and of course the bug isn't in the test source.
<GrueMaster> https://bugs.launchpad.net/bugs/861296
<ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed]
<xranby_ac100> GrueMaster: the original bug was that eclipse failed to compile on arm
<xranby_ac100> since the eclipse build passed some herejava please use insane amounts of memory plx
<xranby_ac100> and this made x86 builds pass while arm where failing due to this bug
<GrueMaster> xranby_ac100: I think it was renamed or a new bug with specific info was created (see above).
<xranby_ac100> im not sure there exist an original bug.. try ask doko
<xranby_ac100> since it was clear mmap did not behave identical on x86 and arm i filed the above bug
<GrueMaster> xranby_ac100: I already posted the link (see backscroll).
 * xranby_ac100 scrolls back
<xranby_ac100> GrueMaster: before i rejoined?
<GrueMaster> bug 861296 is what I was referring to.
<ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
<GrueMaster> It has the mmap-test source.
<infinity> xranby_ac100: haskell-src-exts and qtwebkit-source are still FTBFS with OOMing issues.
<xranby_ac100> (07:26:30 PM) GrueMaster: Couldn't allocate the heap: 1902Mb  <---- how much swap are in use on your test system?
<infinity> I'm not convinced that it's this particular issue, though.  I can get the mmap test to pass on some kernels where the builds will still fail. :/
<GrueMaster> SwapTotal:      33554428 kB
<xranby_ac100> ok
<infinity> I think I probably need to spend some solid time revisiting that next week and hunt down the root cause before we get too close to release.
<GrueMaster> xranby_ac100: I run the same SRU test suite on all platforms and kernels.  This passed on the previous kernel for this platform.  Every image is installed from netboot & preseed.
<xranby_ac100> GrueMaster: i am convinced
<xranby_ac100> btw, thank you for running those tests
<GrueMaster> I added them to my SRU regression testing specifically for this reason.
<infinity> micahg: Kicking off a chromium testbuild locally now, but yeah, my timeframe for looking at it is probably still Monday. ;)
<infinity> micahg: Kicking off a chromium testbuild locally now, but yeah, my timeframe for looking at it is probably still Monday. ;)
 * ppisati -> EOD
<GrueMaster> ppisati: Also, still missing headers from the dove headers package.
<GrueMaster> linux-headers-2.6.32-423 is virtually empty.
<GrueMaster> (changelog & copyright info only).
<infinity> GrueMaster: Yeah, didn't we agree that we just didn't deeply care anyway? :)
<GrueMaster> infinity: really should be a kernel team call on that, but in general yes.
<GrueMaster> (and I had thought he was going to look at it).
<infinity> GrueMaster: well, yes.  If they care, they can fix it.  But I'm betting they don't if we don't.
<infinity> And I'd be shocked if we had any dove users.
<ogra_> we do !
<ogra_> GrueMaster !
<infinity> ogra_: I said users, not QA testers. :P
<ogra_> heh
<GrueMaster> I think there are commercial users, but maybe not for this specific kernel.
<infinity> ogra_: If GrueMaster's desk is representative of our average user, we're doing a pretty poor job of targetting, well, normal people.
<ogra_> surely not on dove devboards
<GrueMaster> I know HP has a little desktop system (I've seen one at a friends house).
<ogra_> did they ever sell that armada ebox they showed in brussels ?
<infinity> Ubuntu: Linux for Crazy People?
<ogra_> isnt it that ?
<GrueMaster> And it has our kernel patches at least.
<ogra_> from crazy people for crazy people
<infinity> I'm pretty sure I have a t-shirt that says something about Human Beings.
 * GrueMaster is having issues with LP.
<infinity> QA people don't qualify.
<GrueMaster> That's why my blog is titled "Terminal Insanity".
<infinity> ;)
<ogra_> GrueMaster, about time you gain membership
<ogra_> so it shows up on planet
<GrueMaster> Yea, I looked into that a while ago.  Lot of hassle.
<ogra_> heh
<ogra_> not really
<GrueMaster> And I just haven't had the spare cycles to jump through the hoops.
<ogra_> one wikipage that lists your contributions
<ogra_> and one evening to attend the rmb meeting
<mahmoh> NCommander: GrueMaster: otherwise, the net-installer works fine as far as I can tell, need to preseed it now to enable nightly install verification testing
<NCommander> mahmoh: I'll takea hammer to it
<ogra_> you surely got enough bugs under your belt to qualify easily
<GrueMaster> mahmoh: I'll pass you my preseed.
<mahmoh> thx
<GrueMaster> Guhhh.  What is going on with our web servers?  paste.ubuntu.com is slow, lp is almost non-existant.
<GrueMaster> and email is also having issues.
<infinity> GrueMaster: No issues here, perhaps you're suffering routing issues to the DC?
<GrueMaster> Must be.
<GrueMaster> ping seems fine.
<GrueMaster> mahmoh: http://paste.ubuntu.com/854454/
<GrueMaster> That's the preseed I am currently working with.
<mahmoh> GrueMaster: thx!
<slangasek> janimo`: for this apr upload in the freeze queue, what's the definition of "recent enough" for the kernels?
<ogra_> slangasek, hey, thanks for the welcome mail ! :)
<slangasek> :-)
#ubuntu-arm 2012-02-24
<GrueMaster> TheMuso: I'm going through some old bugs and found lp:631362.  Any interest in this or should I close as "won't fix"?
<TheMuso> GrueMaster: Yeah won't fix is fine for for that bug, I see you have done it already, thanks.
<scientes> where can i buy one of those new quad-core boards?
<twb> scientes: tegra3?
<lilstevie> transformer prime?
<scientes> http://www.engadget.com/2011/06/22/i-mx-6-quad-core-reference-board-flexes-processing-muscle-at-fre/
<scientes> i.MX 6
<lilstevie> heh
<scientes> this crazy guy mentioned it
<scientes> http://video.linux.com/videos/binary-blobs-attack
<scientes> which is quite amusing
<scientes> lilstevie, what do you mean by "heh"?
<lilstevie> just that I was suggesting the prime as a quad although it isn't
<scientes> haha
<lilstevie> 4plus1
<lilstevie> :p
<scientes> also, when will big.LITTLE be available?
<scientes> iow, is it availble?
<lilstevie> no idea
<scientes> but i am more interested in desktop-powered arm systems
<lilstevie> kinda like the trimslice
<scientes> I want something that works on a boat, so super-low-power-consumption
<lilstevie> heh
<scientes> a high-powered big.LITTLE could be pretty cool for this....
<lilstevie> trimslice is 6W
<scientes> my buddy on this, feels it is pragmatic to go with x86
<twb> Man that's only like half what atom uses
<scientes> and i only have armv5 hardware at this point
<scientes> so i cant really test stuff to proove arm over x86
<scientes> BTW< how the hell do i get gdb debug symbols to work in qemu?
<scientes> i tried qemu-arm-static with -g but i don't get the debug symbols i've installed
<scientes> how much does trimslice cost lilstevie ?
<lilstevie> $319
<lilstevie> +shipping
<lilstevie> if you enrol in the developer program you can get it cheaper though
<scientes> and with no display?
<steev> it has dvi-d and hdmi out
<steev> reminds me, i need to ship both mine back so they can fix my pmics... early adoption sucks sometimes
<lilstevie> steev, heh yeah I got mine later, and is fine
<steev> lilstevie: nice, yeah mine won't power off and such on their own... i forgot about that once... left it running for 3 days when it should have been turned off... that was, fun
<lilstevie> haha
<lilstevie> mine gets a little hot, but thats about the most that happens
<steev> well mine was sitting on a cardboard box
<lilstevie> that could start a fire
<lilstevie> :p
<Laplace> hello there.. I am trying to compile a program with -pg flag on the arm-elf-compiler... but I canÂ´t find the profilling starter file gcrt0.o
<twb> Laplace: FYI, you seem to be using a legacy non-UTF-8 encoding.
<Laplace> what?
<twb> 18:10 <Laplace> hello there.. I am trying to compile a program with -pg flag on the arm-elf-compiler... but I can\264t find the profilling starter file gcrt0.o
<Laplace> can not
<twb> My point is you're sending 0x01 0x08 instead of 0xE2 0x80 0x99
<Laplace> year I dont know how to change that in xchat
<twb> Probably by setting your locale to en_AU.UTF-8 or similar
<twb> It's not a big deal
<Laplace> but can you help me with the gprof compiling
<twb> Unless you're in #nihongo or something
<twb> Laplace: nope, sorry
<ayaka> how to use fastboot to boot a linux kernel with initrd and root in /dev/block/mmcblk1p2 (sd card second partation)?
<lilstevie> ayaka, what device
<ayaka> lilstevie, htc evo 3d x515m, a mobile
<ayaka> lilstevie: any idea?
<lilstevie> ayaka, ./fastboot boot zimage initrd -c $DEFAULT_CMDLINE root=/dev/mmcblk1p2
<ayaka> lilstevie: thank you I will try later, thank you
<ayaka> lilstevie: but where shall I select vmlinux and initrd file?
<ayaka> lilstevie: it default select the link in the root file?
<lilstevie> if you need to ask, this is probably a bit beyond you
<ayaka> lilstevie: ok, I will try tommorrow, thank you again
<infinity> janimo`, slangasek: I'm unconvinced that this apr upload was a good idea. :P
<infinity> janimo`: Did you test build it on natty? (that's what the buildds run)
<slangasek> infinity: hey, I wasn't the one who accepted it
<infinity> slangasek: Neither was I.  Perhaps you should have rejected it when you questioned it, though. ;)
<slangasek> heh
<infinity> I still think we need a saner policy of "if in doubt, reject; we can always rescue it later" for archive admins.
<infinity> But, I guess that generates scary mails that people don't like.
<janimo`> infinity, I only tested it on my host - I thought th only way to see if it works is to try on the hosts, now they have a new kernel
<janimo`> infinity, I think last time it was the kernel that held it up not eglibc
<infinity> janimo`: They don't have new kernels, though...
<infinity> janimo`: They've been natty since we installed them.
<infinity> janimo`: I mean, they've had some SRUs, but nothing that would have magically changed threading.
<janimo`> infinity, I think newer than 2.6.31 or what the babbages had
<infinity> janimo`: We've tried it on Pandas before. ;)
<infinity> janimo`: (In fact, armhf was bootstrapped almost entirely on Pandas...)
<janimo`> oh well. The worst that can happen is we revert the change, only arm is affected:)
<infinity> janimo`: So, yeah.  I suspect that build is probably hung, and we'll have to revert.
<janimo`> infinity, I did not know what the timing of armhf bringup was and whethee the debian workaround was already in place to avoid such ftbfs
<infinity> (sure looks hung)
<janimo`> infinity, ah ok. I thought only the babbages had otoo ld versions, sigh
<infinity> The Debian workaround was specifically for the armhf bootstrap. ;)
<janimo`> but on Debian machines no?
<infinity> No, note the uploader.
<janimo`> I could not get info on what kernel harris ran
<infinity> doko did it in Debian and synced to Ubuntu, but it was for both of us.
<infinity> Anyhow, no harm done.  Just a minor annoyance.
<janimo`> ok, my bad then, we can wait another year or so to get this enabled. So the fix exists just not in natty then?
<infinity> Well, if you say it works for you locally, I guess it's fixed?
<ogra_> just sneak the binary into the archive :)
<infinity> ogra_: *glare*
<ogra_> *g*
<janimo`> infinity, well it worked for me locally when I did the last try-revert dance a few months ago (only ubuntu changelog has the details and LP I guess)
<janimo`> I just had the impression the babbage kernels (and only those) were too old so they ftbfs on buildd only
<janimo`> just like there's a squashfs-tools workaround to build with -marm which is also only to have it work on the live-builder machines
<infinity> Well, there's a theory that we might have some Pandas upgraded to Precise before release.  If I can make that happen, we can revisit some of these workaround.s.
<janimo`> that would be good
<janimo`> infinity, btw I looked at uploaders in apr before adding the change and it was noone I know (Hector Oron) . Had it been you or doko I might have figured it out it is still an issue for us and let it be
<infinity> janimo`: Oh, maybe doko just pushed the change and synced, or something.  I don't recall.
<infinity> janimo`: Anyhow, oh well. :P
<infinity> janimo`: I'm curious that, in the bug, you claim it worked on natty, though?
<infinity> janimo`: It obviously doesn't now.
<janimo`> infinity, no, it did not work in natty, I only tested in oneiric last time
<janimo`> I may have just had the wrong impression natty was new enough
<janimo`> as at one point the builders had lucid or maverick which was clearly too old
<janimo`> I think only the kernel matters since glibc fixes are part of the build chroot
<infinity> Yeahp.
<infinity> So, if/when the buildds go to 3.2, we can revisit.
<janimo`> infinity, https://bugs.launchpad.net/ubuntu/+source/apr/+bug/604753 so at least some tried on natty and it worked a while ago
<ubot2`> Launchpad bug 604753 in linaro-toolchain-misc "[eglibc] process shared mutex's fail on armel v7 (thumb)" [High,Fix released]
<rOxx> hello, i want to build a new kernel for my pandaboard es. can someone help my ? i got errors on build with the official repo of oneiric
<rOxx> at build i get this error: II: Checking ABI for omap4...     Reading symbols/modules to ignore...read 0 symbols/modules.     Reading new symbols (1207)...read 8761 symbols.     Reading old symbols (1207)...read 8760 symbols. II: Checking for missing symbols in new ABI...     MISS : omap_cfg_reg     found 1 missing symbols EE: Symbols gone missing (what did you do!?!) II: Checking for new symbols in new ABI...     NEW : scsi_verify_
<ayaka> ./fastboot boot zimage initrd -c $DEFAULT_CMDLINE root=/dev/block/mmcblk1p2, but my kernel is CONFIG_KERNEL_GZIP=y, does it works?
<infinity> rOxx: That means you broke ABI with your changes, but didn't bump the ABI version in the package.
<rOxx> infinity: what can i do to fix it ?
<rOxx> i have read to add this skipabi=true skipmodule=true at  dpkg-buildpackage command-line. but i dont know how to do this
<rOxx> i build with "dpkg-buildpackage -B -uc -us"
<infinity> rOxx: "skipabi=true skipmodule=true dpkg-buildpackage -B -uc -us" then.
<rOxx> ok thx
<ogra_> bah, after all my non working BT headset is all janis fault !
<ogra_> janimo`, for BT headsets to work we apparently need CONFIG_USB_EHCI_TT_NEWSCHED set in the kernel config
<ogra_> could you enable that in the next upload please
<ogra_> (that is ... if you use an USB BT dongle with a headset the driver freaks out about lacking interrupts if thats not set)
<ogra_> (on ac100 indeed)
<janimo`> ogra_, sure
<janimo`> ogra_, did it work before? Is this a new config option?
<ogra_> [ 1381.300007] usbcore: registered new interface driver snd-usb-audio
<ogra_> [ 1382.117188] cannot submit datapipe for urb 0, error -28: not enough bandwidth
<ogra_> bahm not even with the usb soundblaster i can make input work
<ogra_> janimo`, no, old option, but i didnt bother to try getting sound input to work since sound was shaky all the time
<ogra_> so it didnt actually show up as a prob
<diwic> ogra_, is "2.6.36.4 armv7l" a normal kernel to use on ubuntu 12.04 ?
<janimo`> ah ok
<ogra_> diwic, not really, what platform ?
<diwic> ogra_, bug 932096
<ubot2`> Launchpad bug 932096 in pulseaudio "[armel] Pulseaudio crashes other program using sound: Assertion 'pthread_mutex_unlock(&m->mutex) == 0'" [Critical,Confirmed] https://launchpad.net/bugs/932096
<diwic> ogra_, maybe you can tell me what platform this is?
<ogra_> diwic, oh, transformer....
<ogra_> talk to the HWE/OEM guys, thats special
<diwic> ogra_, aha, the HWE guys...hey wait, that's me...
<ogra_> diwic, see my ping in the other chan
<janimo`> ppisati, do you know what is the best way to get some Ubuntu SAUCE for the ac100 kernel tree? It is 3.0.19 based
<janimo`> ppisati, are there some Ubuntu trees which make the best cherry-pick targets?
<ogra_> janimo`, would you be able to quickly cross build a test kernel with that option enabled ? i would like to see if it fixes it, but if i set up a tree that takes me longer than you
<janimo`> ogra_, I can try, sure
<ogra_> thanks !
 * janimo` really needs to document how to build your own ac100 tree. it is easy in fact
<ogra_> i know how to do it, its just that i dont even have a source package or the tree here
<ogra_> (nor do i have an x86 machine running in my house atm)
<janimo`> ogra_, armell or armhf?
<ogra_> el please
<janimo`> ogra_, I know you do, but for the general ac100 user who may not want to wait for 'official' debs
<ogra_> yep
<infinity> janimo`: Rebasing it against the oneiric tree (ti-omap4) would probably be the sanest.
<infinity> janimo`: Also, when you rev out of 3.0.x, can you change the versioning scheme to use the same one we do for other distro kernels? (ie: 3.2.0, regardless of upstream patchlevel).
<janimo`> infinity, you mean rebase the whole current packaging (originally linaro template) over the ti-omap4 tree? Hmm, may be worth it in the long run
<janimo`> and version number 3.0-xxx , so drop the .19 ?
<infinity> janimo`: Well, probably not worth it for the 3.0 packages, but when you switch to 3.2, definitely worth it.
<janimo`> or 3.0.0
<infinity> janimo`: 3.0.0
<janimo`> ok
<infinity> janimo`: But since you can't go back in time in versions...
<infinity> janimo`: That will have to wait until you're on 3.2.x :)
<janimo`> indeed
<janimo`> so what is the 3rd digit there if not upstreams version from the Makefile?
<janimo`> or is this only a 3.0 peculiarity?
<infinity> Well.
<infinity> See.
<infinity> 3.0.19 is 2.6.41.19
<infinity> We never advertised patchlevel.
<infinity> And we still don't.
<infinity> The reason we keep it three numbers, though, is because of all the tools that explode if kvers=AA.BB with no .CC
<ppisati> janimo`: Oneiric is the closest one
<janimo`> ppisati, ok
<janimo`> ok, did not know we never exposed patchlevel
<infinity> (Or is it 2.6.40.19.. Whatever, you get the idea)
<infinity> janimo`: Yeah, well, if you check any pre-3.0 system, our kernels all show 2.6.XX, with no fourth level.
<infinity> janimo`: But they all, of course, are rebased agaisnt the latest upstream PL.
<janimo`> ogra_, http://startx.ro/~jani/linux-image-3.0.19-1-ac100_3.0.19-1.2_armel.deb see if this works
 * ogra_ hugs janimo` 
<janimo`> I'd wait till you get sound out of the headset :)
<ogra_> heh
<diwic> ogra_, I can confirm the BT headset profile switching problem here
<diwic> ogra_, filing bug for it now
<diwic> ogra_, filed bug 940282
<ubot2`> Launchpad bug 940282 in gnome-control-center "Cannot switch profile on Bluetooth headset" [Undecided,New] https://launchpad.net/bugs/940282
<ogra_> janimo`, yay, thanks so much ... lets make sure that goes into the next upload, i'm for the first time able to use mumble on my ac100 !
<janimo`> ogra_, \o/
<janimo`> ok, that will go in the next upload then
<janimo`> I hope others will answer on the list, as there may be other config options to enable
<janimo`> syncing with ubuntu sauce would be the correctest thing to do
<ogra_> sadly, the soundblaster i have gives me choppy output in duplex mode
<ogra_> so i have the earphone connected to the internal soundcard and the mic on the SB USb card ... but that works impressingly well
<janimo`> maybe one of the 30+ ac100 alsa controls  has the solution for that too
<ogra_> it has
<ogra_> but that gets me feedbacks of all kinds and delays in my voice etc
<ogra_> i guess the sound driver still needs to mature a bit for full duplex
<janimo`> infinity, no leads on the qtwebkit-source mem-exhaustion issue?
<ogra_> i think i saw a discussion on debian-arm ML about that
<ogra_> iirc zumbi was involved in that
<infinity> No, the Debian issue was a GCC ICE, I believe.
<infinity> But I'm going to try to make time to look at it with more vigor.
 * ogra_ dances around mumble .... ooh its so awesome i can finally use it on arm
<infinity> Heh.
<Daviey> ogra_: just in time for it to be deprecated \o/
<ogra_> Daviey, well, g* isnt any option on arm
<ogra_> G+
<ogra_> and i dont run any non arm machines anymore around here
<ogra_> why would it be obsolete ? is IS tearing the server down ?
<Daviey> ogra_: no idea, but i know the frequency of use has shrunk for me.
<ogra_> ah
 * infinity wishes people would remember that Canonical runs a rather nice asterisk VoIP setup.
<ogra_> yeah, i wouldnmt mind to use that either
<ogra_> my new manager uses mumble a lot though :)
<infinity> But hey, reinventing wheels with things that require binary blob browser plugins, yay!
<rsalveti> mumble is still works fine for me :-)
<rsalveti> and I also prefer mumble
<rsalveti> just easier
<ogra_> if it works :P
<ogra_> but i agree
<zumbi> ogra_ / infinity : re qtwebkit/armhf, in debian we are waiting for doko to apply compiler patch, there an ICE (#641849). I think markos remind him not so long ago.
<ogra_> yeah, so infinity was right then
<ogra_> i dont think our issue was an ICE
<ogra_> GrueMaster, argh ! ... forgot to mention your name in the changelog for the alsa-lib patch (as well as the bug number) sorry, sorry, sorry ! ... but the fix is uploaded now
<GrueMaster> ok
<ayaka> ./fastboot boot zimage initrd -c $DEFAULT_CMDLINE root=/dev/block/mmcblk1p2, zimage and initrd means file name of vmlinux and initrd in /dev/block/mmcblk1p2 or just type those
<ayaka> ï¼
<ogra_> GrueMaster, bah, got rejected anyway, so i can add your name, do you rememebr the bug # from the top of your head ?
<GrueMaster> It was in the email.  Let me look.
<ogra_> oh, dont then
 * ogra_ checks the mail
<ogra_> no, it only has the alsa-utils bug
<ogra_> bug 880929
<ubot2`> Launchpad bug 880929 in alsa-utils "alsa ucm udev rules not working on SDP4430" [Medium,Confirmed] https://launchpad.net/bugs/880929
<GrueMaster> yea, I'm looking through LP now.
<ogra_> havent gotten to that part yet
<GrueMaster> Gah, there are so many bugs to choose from.
<ogra_> haha
<ogra_> i havent seen it on the ubuntu-arm list ... i looked there due to my mailer being temprarily broken wrt bugs
<GrueMaster> Yea, I haven't had time to go through and triage in the last few weeks.
<ogra_> well, will work without bug # i guess
<doko> zumbi, no, I won't. please get it upstream first
<GrueMaster> The odd thing is that I had it working without these ucm files, but there was an entire week between test kernel+tweaks to having an actual image with fixes.  And the new image had new versions of everything.
<GrueMaster> And I haven't been able to spot any diffs in the alsa git trees that would have affected this.
<GrueMaster> (we went from 1.0.24 to 1.0.25).
<ogra_> well, the fix is committed to the ubuntu alsa-lib tree already, i will just re-upload with a fixed patch file (was missing two lines in the header) ...
<ogra_> and then care for alsa-utils
<ogra_> if there is no bug thats fine, i'll just remove that header line from the patch file
<GrueMaster> Ok.  That's the new ucm configs, right?
<ogra_> right
 * GrueMaster is still recovering from sleep, one cup of coffee at a time.
<ogra_> take your time :)
<GrueMaster> WTF?!?  Chewing through email, I came across this bug:  lp:932096
<GrueMaster> come on bug bot.  bug 932096
<ubot2`> Launchpad bug 932096 in pulseaudio "[armel] Pulseaudio crashes other program using sound: Assertion 'pthread_mutex_unlock(&m->mutex) == 0'" [Medium,Incomplete] https://launchpad.net/bugs/932096
<GrueMaster> thank you.
<ogra_> yeah, diwic talked about it today
<ogra_> transformer ...
<ogra_> likely a kernel issue
<GrueMaster> It says Distro: 12.04  Kernel: 2.6.36
<ogra_> right
<GrueMaster> What platform?
<ogra_> android kernel
<zumbi> doko: I am not sure on the details, I thought it was already upstream, we'll check and let you know
<ogra_> transformer ...
<GrueMaster> ah
<ogra_> leave it to the HWE guys :)
<ogra_> just ignore
<GrueMaster> ok.  Added to .ignore
<ogra_> heh
<GrueMaster> I've also been churning through that archaeological list of bugs you posted a while back.  Closed a few, marked some as won't fix (mainly old targets).  fixed a few.
<ogra_> yeah, i just looked at it again, there is still a ton of stuff we could just close
<zumbi> doko: < markos> it's fixed upstream iin FSF and also in Linaro/Ubuntu gcc (PR50946)
<ogra_> i'll go through it next week
<ogra_> and shoot the obvious ones
<GrueMaster> Speaking of which, ppisati, can you pull in the patch from bug 707003 to the next maverick SRU so we can close this?  Or should I mark it as "Won't fix".  Looks like low hanging fruit.
<ubot2`> Launchpad bug 707003 in linux-ti-omap4 "Kernel panic when trying to offline CPU1" [Medium,In progress] https://launchpad.net/bugs/707003
<GrueMaster> Sometimes I wish bug 820034 would get fixed, but it is not on our plate.
<ubot2`> Launchpad bug 820034 in ubuntu-font-family-sources "Expansion: Miscellaneous Symbols and Pictographs U+1F4A9" [Wishlist,Confirmed] https://launchpad.net/bugs/820034
<ogra_> poke sladen about it :)
<GrueMaster> Did you see the text of the bug? (not just the title).
<ogra_> nope, following the release meeting while we chat here :)
<GrueMaster> ah, forgot it was that time.  ok.
<ppisati> bug 927860
<ubot2`> Launchpad bug 927860 in linux-ti-omap4 "Missing musb-hdrc module required by Pandaboard OTG port" [Medium,Confirmed] https://launchpad.net/bugs/927860
<ppisati> any reason i can't make all of them =m?
<ppisati> last comment says "Rebuilding the kernel with module built-in..."
<GrueMaster> None that I know of.  If you want to spit me a test kernel, I can run it and check.
<GrueMaster> ppisati: Did you see my earlier ping?
<ppisati> GrueMaster: nope
<GrueMaster> Bug 707003.
<ubot2`> Launchpad bug 707003 in linux-ti-omap4 "Kernel panic when trying to offline CPU1" [Medium,In progress] https://launchpad.net/bugs/707003
<ppisati> ah ok
<ppisati> got it
<GrueMaster> I was just curious if you wanted to add it to the next SRU cadence or if we should mark it as "Won't fix".
<GrueMaster> I'm cleaning up old bugs.
<ppisati> GrueMaster: i updated lp927860 with a test kernel
<GrueMaster> Fetching it now, thanks.
<GrueMaster> Uh.  I'll have to reimage, unless you can whip up an armhf kernel fairly quickly.  armel is slowly drifting away and all my systems are armhf.
<sveinse> Hi. I'm looking for gdb-arm-linux-gnueabi debs for i386 and amd64, Natty, which works against armel Natty gdbserver (Ubuntu/Linaro 7.2-1ubuntu11). I remember finding this on a Linaro PPA sometime, but google turns up empty. Anyone knows where I could find them?
<sveinse> hrw perhaps?
<GrueMaster> You might ask in #linaro.  This is something they maintain I believe.
<GrueMaster> ppisati: I think something got missed in that kernel re: bug 927860.
<ubot2`> Launchpad bug 927860 in linux-ti-omap4 "Missing musb-hdrc module required by Pandaboard OTG port" [Medium,Confirmed] https://launchpad.net/bugs/927860
<GrueMaster> # CONFIG_USB_GADGET_MUSB_HDRC is not set
<GrueMaster> cat /proc/version_signature
<GrueMaster> Ubuntu 3.2.0-1406.9~lp927860-omap4 3.2.6
<GrueMaster> Oh, it is listed twice in the config.  Odd.
<GrueMaster> Still doesn't work.  It might need to be built in, or it needs some other bits in the kernel.
<ppisati> GrueMaster: i'll try again
<GrueMaster> Ok.  I'll wait to hear back.
<pbuckley> as of yesterday my board has stopped crashing every 8ish hours..
<pbuckley>  10:08:25 up 22:09,  5 users,  load average: 0.26, 0.47, 0.44
<pbuckley> almost a full 24 hours
<pbuckley> woo!
<GrueMaster> Cool.  (of course I am not seeing this here, but...)
<GrueMaster> This is your ES, right?
<pbuckley> yeh my desktop es.. my dev board is still crashing every couple hours
<pbuckley> but thats probably more my fault then anything
<GrueMaster> I can live with that.  :P
<pbuckley> are there any known bugs around ssh-agent not correctly caching passwords?
<pbuckley> (12.04)
<pbuckley> pbuckley@panda:~$ ps -ef | grep agent
<pbuckley> pbuckley  1577  1539  0 Feb23 ?        00:00:04 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session --session=ubuntu-2d
<pbuckley> appears to be running but im not getting the gui dialog for a password like i used to
<pbuckley> also ii  puppet         2.7.10-1ubuntu Centralized configuration management - agent
<pbuckley> needs to get updated to 2.7.11
<pbuckley> 2.7.10 has some nasty security cve
<infinity> We know.
<pbuckley> k
<infinity> 2.7.10 is a regression nightmare in general
<infinity> But, hey, welcome to an unreleased distro. ;)
<pbuckley> heh
<pbuckley> its where all the fun happens
<pbuckley> and there is no way im going back from 12.04 even in its current state its night and day from 11.10
<GrueMaster> So many levels of confusion surrounding bug 747229.  Peeling this onion is leaving me in tears.
<ubot2`> Launchpad bug 747229 in ubiquity "weird color change during oem-config debconf package removal step in serial installs" [Medium,Confirmed] https://launchpad.net/bugs/747229
<GrueMaster> Shell wrappers for python wrappers for perl wrappers for...
<pbuckley> :(
<pbuckley> ruby wrappers?
<GrueMaster> Go away, you.  :P
<pbuckley> hehe
<GrueMaster> Ok, so it isn't whiptail that is causing the weird screen colors.  Next to check is debconf package.
 * GrueMaster switches to perl mode.
<pbuckley> almost time to switch to beer mode
#ubuntu-arm 2012-02-25
<pbuckley>  16:53:35 up 1 day,  4:55,  6 users,  load average: 0.74, 0.39, 0.39
<pbuckley> woo!
<pbuckley> now lets see if it makes it thru the weekend
 * GrueMaster breaks out the champagne.  
<ayaka> i want to use fastboot boot a kernel and initrd whose root is /dev/block/mmcblk1p2 in my mobile
<ayaka> someone tell me ./fastboot boot zimage initrd -c $DEFAULT_CMDLINE root=/dev/block/mmcblk1p2 but fastboot can't recognize it argument
<cybot> i'm running ubuntu for arm on my motorola atrix 4g, everytime i hit the button on keyboar between s an f (i can't type i) it minimizes the current programm. any i ea how to fix this?
<int_ua> cybot: looks like Ctrl is down
<int_ua> Ctrl+D = minimize all windows
<int_ua> Maybe some hardware issue?
<cybot> thanks
<cybot> maybe
<cybot> i have .o physical buttons, only osk
<cybot> no*
<cybot> i just loked into the shortcuts. it wasnt ctrl d, it was only do
<cybot> changed it
<cybot> thanks for your help!
<cybot> damn, its hard to type, sorry for my bad english
<int_ua> cybot: You're welcome :)
<int_ua> cybot: maybe you should look for/file a bug report about this?
<ayaka> how to use fastboot boot a kernel
<iglo> hi
<iglo> I have problems to install Ubuntu 11.10 Server on a Beagleboard C4; I copied the image to the SD Card, but its shows this while booting:   *** Warning - bad CRC, using default environment
<iglo> the checksum of the download is ok
<iglo> any ideas to solve this?
#ubuntu-arm 2012-02-26
<ayaka> anyone know how to use abootimg, i want to know how to write it config
<kvarley> Is the Ubuntu-Core armel release capable of running on ARM11?
<lilstevie> kvarley, no
#ubuntu-arm 2013-02-18
<redtape-renegade> k1l .. chromebooks ARE Arm !
<k1l> redtape-renegade: nope
<k1l> there is one chromebook. the rest is intel stuff
<redtape-renegade> k1l: Are you on #ubuntu-offtopic
<k1l> Dual-core IntelÂ® CeleronÂ® Processor
<redtape-renegade> oh ok .. what ubuntu #channel does that belong to ?
<k1l> for support try #ubuntu . for talking about ebay auctions its the offtopic one :)
<redtape-renegade> Crumbs .. how generic is that Ans.  ?? It's not an auction-topic .. It's about Chrubuntu ..
<k1l> hmm chrubuntu is not a official derivate of ubuntu :/
<infinity> There's no such thing as an official derivative.
<infinity> Derivatives, by their very nature, can't be "official", as we have no control over them.
<isaias> I was able to install ubuntu on my nexus7. onboard up during instalaion but not when I try and put in my password
<isaias> and it says I have 5% battery, but I know its full
<isaias> or it should be full
<darkfaded> isaias: i found that it doesn't update the display at all times
<darkfaded> although i'm on 12.10 and it worked most of the time
<darkfaded> it's a bit odd
<isaias> so reinstalling might fix it, right?
<isaias> im on 12.10
<guard> do I have to have Nexus connected to Ubuntu when installing it to my device?
<guard> i dont think so, but its acting weird
<guard> omg, it worked!
<raster> moo
<guard> how do I add the terminal icon to my dash?
<nils_> good morning
<nils_> I haven't visited this channel for a few days. Today I read this interesting article: http://www.canonical.com/content/touch-developer-preview-ubuntu-be-published-21-february-2013. Any implication to N7 so far?
<dholbach> good morning
<isaias> good morning
<isaias> I have to keep my nexus pluged in to be able to use it with ubuntu. is it my install that went weird? or does this happen with everyone?
<raster> isaias: i cassh in just fine
<raster> plugged in or not
<isaias> ok. I'll reinstall when I get home
<isaias> raster: Thank you
<smartboyhw> ogra_, ping..... You said that we should talk about the Nexus7 testcases in ISO QA Tracker today:P
<ogra_> sure, the QA people were on the hool to develop some, you should probably talk to gema and plars where they are at with that, adding them to the isotracker is only the last step
<ogra_> s/hool/hook/
<smartboyhw> ogra_, OK
<Darkwing> ogra_: are teh N7 daily images broken?
<ogra_> Darkwing, yes, you can use http://cdimage.ubuntu.com/daily-preinstalled/last-good-image/ with the manual method ... it has some bugs though
<ogra_> i recommend using a keyboard with it
<Darkwing> ogra_: Okay.
<ogra_> we're actively working on a fix though
<Darkwing> ogra_: I'm going to fiddling with Plasma Active with it so, I'm expectingbroken.
<wookey> what backend does plymouth use to draw on arm?
<wookey> does it need X, fbdev,, something else? I see mention of 'drm' which seems to be kernel mode access to GPU
<wookey> but libdrm only seems to be enabled for x86 in packaging
<wookey> I'm trying to work out what the smallest set of packages I have to build to make it work enough to boot on a no-graphics model is.
<wookey> but have no cleu how any of it works.
<ix_>  I'd like to install ubuntu on my ARM chromebook
<ix_> just delete chromeos
<wookey> or maybe it _won't_ boot on a console-only machine? (what does ubuntu server do about this?)
<plars> ogra_: I talked to balloons about setting up some tests on the iso tracker and opening it up to the community as well for weekly testing.  He wanted me to confirm that the team handling nexus7 images was ok with with that.
<plars> ogra_:  Regardless of whether the iso tracker exists or not, I'll try to drag some people into doing a weekly test this wednesday.  Do you think the install issue will be fixed by then?
<ogra_> we are ok with any kind of testing
<ogra_> plars, we nailed it down to whoopsie
<ogra_> even though it isnt clear why it happens yet
<ogra_> but it makes dbus and consolekit misbehave
<plars> ogra_: ok, balloons and I are both in US holiday today, but I'll talk to him more tomorrow
<ogra_> yeah, no hurry
<TheMuso> c
<ogra-nx7> yay
 * ogra-nx7 waves to xnox
<xnox> ogra-nx7: hola =)
<Laney> that's with the override?
<ogra_> that was with the override, yeah
<ogra_> just had installed the usual minimal bits i need to actually use the nx7 ...
<Laney> so the commits I reverted give me an X
<ogra_> like the grab-n-drag extension for firefox which is unusable without it
<ogra_> an X ?
<Laney> X starts
<ogra_> you mean a crosshair cursor ?
<Laney> i.e. it works
<ogra_> ah
<ogra_> yeah
<Laney> the ones about libnm-glib
<ogra_> awesome
<ogra_> i really wonder why it doesnt hit us on the normal install
<ogra_> i.e. post install everything seems fine
<Laney> 525 522 549 543
<ogra_> the measurements of your perfect girlfriend ?
<ogra_> (or are they the commit numbers ?)
<Laney> those would be interesting measurements ;-)
<Laney> yeah, the latter
<xnox> ogra_: do we have a nexus7 bug number for this as I want to open a whopsie bug mentioning it.
<Laney> 522 is the interesting one
<ogra_> one sec
<xnox> I also hope whoopsie (do not start) will also help with bug bzr branch lp:~xnox/androidos/patform-system-core
<xnox> bug 1123798
<ubot2> Launchpad bug 1123798 in ubiquity (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed] https://launchpad.net/bugs/1123798
<ogra_> Bug #1127051
<ubot2> Launchpad bug 1127051 in ubuntu-nexus7 "Broken dbus/consolekit setup causes black screen instead of running oem-config" [Critical,Confirmed] https://launchpad.net/bugs/1127051
<ogra_> merge them
<xnox> ok.
<ogra_> since thats not nx7 specific
<Laney> the previous code path a check for failure to get the system bus and warn
<Laney> s/path/path had/
<ogra_> ah, instead of looping forever
<xnox> Laney: which commits? in whoopsie?
<Laney> yeah
<Laney> that's not an exhaustive list, and there were some conflicts
<Laney> http://paste.ubuntu.com/1677775/ is what I used to test
<ogra_> hmm is that the whole valgrind stuff ?
<xnox> yeah.
<xnox> and switch from using dbus to using a g-i binding-library that uses dbus underneath (autogenerated dbus library)
<xnox> and while firefox is building we will get nothing...
 * xnox off to have a very late lunch.
<ogra_> oh
<ogra_> yeah
 * ogra_ goes for a *very* late breakfast :P
<Laney> hmm
<Laney> http://ostree.gnome.org/work/src/NetworkManager/examples/C/glib/get-ap-info-libnm-glib.c
<Snark> http://www.ubuntu.com/  <-- nice countdown, but I assume that says when it's becoming public, not when it's available ;-)
<Tassadar> whoa Oo
<Tassadar> Canonical sure likes countdowns)
<drizzy> i already has ubuntu on my tablet
<drizzy> must be a stable release
<drizzy> d=)
<Tassadar> yeah, that's my guess too
<drizzy> i hate unity desktop
<drizzy> i super hate it
<wookey> heh, whole stack of stuff just unbunged. check->libxau->libxcb->libx11->freetype->fontconfig, which fell over on build-deps
<wookey> the  direct B-D on binutils issue
<jacaru> hey alla
<jacaru> anybody in the know, chromium for armhf has not been compiling from some time. Latest version available for 386 is 24 for a while now, but armhf is still 22
<infinity> It's known.
<jacaru> It's just pending some king of work time or is there stopper?
<jacaru> kind*
<jacaru> I mean if I were to download sources and do myself, would it be possible barring my own stupidity? :P
<infinity> It's pending someone fiding the time to fix it.
<jacaru> okie, thnx. also thinking on just downloading the debian package and see how that would work out
<jacaru> another q. Any reading material for enabling opengl-es compiz/unity in raring? Or not possible yet?
<infinity> It's entirely up to if your platform has working 3D drivers.
<jacaru> it does and they work with glmark2-es2. But I can only bring up gnome classic. So I am missing something if it should be automatic.
<wookey> fontconfig built. libxrender and libxext should get me to cairo
<isaias> ogra_: it works. took me like 5 different installs and several reboots. lol.im on it right now
<ogra_> well, we have fixed the issue, i'm just testing the latest daily
<ogra_> yay, and it works
<isaias> cool.
 * ogra_ will copy over to the last-good-image dir
<ogra_> xnox, the crashing of compiz seems to be caused by onboard
<isaias> its a little slow and choppy, is it normally like this? i dont mind it, i know its still in  development
<ogra_> hmm, it shouldnt be slow or choppy no
<xnox> ogra_: interesting.
 * ogra_ reboots
<ogra_> xnox, hmm, no, red herring, it crashes reliably when i focus the wifi key input field
<ogra_> even if onboard is already up
<ogra_> i guess what we want is something like a respawn function though
<ogra_> xnox, aha, and the wallpaper misbehavior only happens if compiz is gone
<wookey> hmm, and libxt and pixman and lzo2.
<wookey> bloody hell, uploading cairo.
#ubuntu-arm 2013-02-19
<xnox> I saw a df: cannot read partition table warning from the installer.
<ogra_> are you sure it said partition table ?
<ogra_> else it woould be update-initramfs
<xnox> hmm.. will have camera ready next time.
<xnox> yeap it was after update-initramfs
<xnox> ogra_: ctrl+alt+t gives one a gnome-terminal as root in oem-config =)
<ogra_> right, thats fine
<xnox> cute, ain't it =)
<xnox> regression of bug 594233
<ubot2> Launchpad bug 594233 in ubiquity (Ubuntu) "Pressing ctrl-alt-T gets you a root terminal in oem-config" [Undecided,Fix released] https://launchpad.net/bugs/594233
<ogra_> update initramfs tris to compare the output of df with fstab
<ogra_> which we dont have at that time
<ogra_> i guess it should shuffle something
<ogra_> hmm, i though we had fixed that terminal thing a few releases ago
<ogra_> probably just for the only-ubiquity mode
<xnox> yes, and then metacity transitioned from gconf to gsettings and we didn't get the memo
<ogra_> heh, yeah
<xnox> and continued to set gconf key that doesn't exist any more =)
<infinity> I was going to suggest it was because you switched to compiz.
<ogra_> hmm, when did metacity transition ?
<infinity> But yes, same explanation, really.
<xnox> thankfully (or maybe not?!) gnome-settings-daemon handles media keys shortcuts these days.
<ogra_> i still see a metacity gconf key here
<ogra_> oh
<ogra_> not associated to a schema
<ogra_> now i wonder how it got there
 * xnox sees no metacity gconf on my normal desktop....
<ogra_> metacity/general/compsitor_effects
<ogra_> in apps/
<ogra_> weird
<xnox> well ubiquity used to set that key.....
 * xnox ponders gconf-service now provides a gconf api over dbus as a service going to the same store?
<xnox> ogra_: cause in d-conf editor you will find org.gnome.metacity with more properties.
<xnox> (some are under wm now)
<ogra_> well, ubiquity never ran on my chromebook ... i might have set it manually once
<xnox> hmmmm....
<ogra_> clicking "set to default" and restarting gconf-editor makes it vanish completely
<xnox> did you migrate your home directory?
<xnox> as gconf xml is written into home-dir.
<ogra_> so i guess it was a local leftover
<ogra_> yeah
<ogra_> infinity, do you know if nusakan -> cdimage sync happens automatically or if it needs a cdimage piblisher run
<infinity> ogra_: It happens when images are published, or when someone syncs manually, why?
<ogra_> i manually copied http://cdimage.ubuntu.com/daily-preinstalled/last-good-image/ in place and was waiting for the new content to show up
<infinity> Yeah, that would need a sync.  Doing so no.
<infinity> w
<ogra_> thx
<ogra_> wasnt urgent, i just want to keep a known working image around
<infinity> Doing awful things to break the world?
<ogra_> well, we had three broken images and the desktop sprint started today
<ogra_> nobody noticed they were broken
<ogra_> the kernel team pinged me friday evening about the image booting to a black screen after plymouth ... fun place to debug
<infinity> ogra_: Should be synced now.
<ogra_> yep, looks fine
<ogra_> infinity, hmm, no, its not fine, i missed .htaccess
<ogra_> copied now
<ogra_> oh, its just calling sync-mirrors as cdimage user ?
<ogra_> i can do that myself
<ogra_> yeah
<ogra_> now it looks fine
<xnox> also i have been studying mkfs.ext4 and one can reduce number of superblocks and allocate them lazily
 * xnox ponders if it will bring down the size of the fs.
<xnox> but it's for my todo someday analysis =)
<xnox> ogra_: do we mount recovery partition? is there space for any additional files in the abootimg? can I instruct to reboot into fastboot mode from user-space (booted into ubuntu)?
<ogra_> geez, a book of questions in one line
<ogra_> no, we dont mount recovery
 * xnox ponders to preseed wifi password in kernel command line option & if there is a way to reboot into fastboot mode - then we have a full automation for nexus7.
<ogra_> abootimg only manages kernel and initrd, if you want to add something use the initrd
<xnox> if I include a preseed file in the initrd or ubuntu-nexus7-defaults package....
<ogra_> and i dont thinnk you can reboot into fastboot easily with our "reboot"
<xnox> hmm...
<ogra_> androids is patched for "reboot bootloader" afaik
<xnox> but how does android does it?
<ogra_> which also needs special kernel options
<ogra_> (which we should have though)
<xnox> surely it's a kernel/firmware interface or like nvram option
<xnox> or something =))))
<ogra_> well, kernel/bootloader i think
<xnox> can I change kernel params after I flashed ?
 * xnox changed /etc/defaults/flash-kernel and then did update-initramfs -u and nothing changed.
<ogra_> yeah, not implemented for abootimg yet
<ogra_> you can just use abootimg
<ogra_> directly on /dev/mmcblk0p2
<xnox> awesome =)
<ogra_> make sure to not pull from /proc/cmdline ... the bootloader prefixes the cmdline with a ton of options
<ogra_> always use abotimg -i output as your base
<ogra_> in case you script anything or so
<xnox> now the poluted cmdline makes sense
<xnox> (ubiquity parses the cmdline and I was at first confused as usually it's much shorter)
<ogra_> its quite ugly :(
<ogra_> especially console=none
<ogra_> https://plus.google.com/107109423598372241322/posts/ehYKNcMP25u
<ogra_> heh, google knows everything
<xnox> yeah, I giggled over that one as well =)
<isaias> can i install flash on this?
<isaias> if its possible, lol
<xnox> isaias: yes - the free once, will they work - not really. adobe used to ship flash in play store but doesn't any more. there are some flash available e.g. for tegra 3 but only as preview for OEM builders with an NDA against nvidia.
<isaias> xnox: what about youtube?
<scientes> xnox, there is alto the TI flash
<scientes> for arm
<scientes> isaias, you can play youtube without flash using --enable-gstreamer to firefox
<scientes> which ubuntu _should_ be doing, but is not
<infinity> You can play youtube without flash regardless.
<scientes> infinity, not true, not all youtube is available in vp8
<scientes> some is h264 only
<xnox> if there are ads, you must have flash.
<scientes> that as well
<scientes> but only certain ads
<xnox> e.g. the music videos that are currently enjoying their 15minutes of fame all need flash.
<infinity> Unless you go to the mobile site and spoof an iOS user agent...
<xnox> \0/
<xnox> i should so do that.
<scientes> and then some videos are "not available for mobile"
<isaias> no way to get flash games, right? lol
<infinity> Yeah, though that's happening less and less, with mobile becoming the more common consumption device.
<infinity> isaias: Flash games are a lost cause.
<isaias> i know :P html5 is taking over flash, right?
<isaias> or something lake that
<wookey> less than half of youtube works without flash
<wookey> and currently gnash doesn;t work there anymore either
<wookey> or maybe lightspark. Either way it's broke unles syou use youtube-dl (clive is bust too)
<wookey> what's aprticularly annoying is there there is no way to tell without trying each vid, nor a way to tell YT to only show me the HTMl5 stuff
<wookey> vimeo seems to be broken this month too. OTOH the beeb started working.
 * xnox likes radio
<wookey> that does work a whole pile better :-)
<wookey> althouh the beeb still manage to F it up with their iplayer nonsense. I just use get-iplayer for everything beeby
<wookey> I do resent being forced to use someone else's broken player when I have piles of my own good players that actually work
<ptl> so...
<LisaNori> Can I get the ubuntu phone interface and use that on the nexus7?  It just seems as though anything appropriate for a phone would work well on the nexus7 screen instead of the standard desktop ubuntu gui.
<nils_> Good Morning.
<nils_> Any ideas what this is: "Tick, tock, tablet time!" http://www.ubuntu.com/
<nils_> Oh, and btw. htc has a similar countdown. http://www.htc.com/www/ Same event?
<Guest87254> hi
<dholbach> good morning
<hrw> hello
<nils_> 4 Hours left: http://www.ubuntu.com/
<ogra_> true ... http://www.htc.com/us/
<ogra_> (dont ask me, i have no clue if they are related ... not even internal canonical rumours about that ... :) )
<hrw> I can say that they are related
<hrw> both are for today and the time is same
<ogra_> heh
<ogra_> true
<nils_> ogra_ you can check the htc page with firebug and you will see that their event is probably related to their new M7
<hrw> that's when it comes to relations
<nils_> htc is showing it's new hardware flagship, german page: http://live.techstage.de/Event/Live-Event_HTC_OneM7. no offense! But I cannot seriously imagine that htc would link their event to ubuntu. I would love to see that - but they will want to keep control on their own.
<ogra_> you mean like not using foreign OSes
<ogra_> like android .... :P
<xnox> the chatter here is that htc is stealing thunder.
<xnox> and is not related.
 * ogra_ guesses we'll see in ~2h
<nils_> ogra_ you have a point. But I still do believe it's just a coincidence.
<nils_> anyways M7 is not a tablet. Ubuntu.com announces a tablet.
<ogra_> https://plus.google.com/communities/107299007624972266094
<ogra_> there is a tablet on the table among a huge set of phones
<ogra_> oh, and thats originally from http://www.androidauthority.com/htc-to-possibly-unveil-a-tablet-at-its-big-event-tomorrow-will-it-run-the-ubuntu-os-157131/
<ogra_> in any case it adds up popularity for both, HTC and ubuntu
<thebishop> tablet time! ... ubuntu touch UI coming to nexus7 or something else entirely?
<ogra_> you will see in 45min
<ogra_> or 40 or so
<diwic> I think it's just IS trying to reproduce the bug that caused the lack of responsiveness at the last launch.
<thebishop> :)
 * diwic runs away and hides ;-)
<ogra_> haha
<lool> ogra_: w00t
<lool> ogra_: I missed the status meeting for N7 last friday
<lool> ogra_: how are things in general?
<lool> ogra_: I wonder whether we have updated our kernel for 4.2.2
<lool> there might be good fixes in there
<ogra_> lool, quite ok, the kernel team didnt update yet
<ogra_> we had massive breakage over the weekend so on monday we didnt have a single working image
<Tassadar> there are 3 new commits in 4.2.2 kernel, don't get too exicited)
<ogra_> since we dont do milestones anymore
<ogra_> Tassadar, there is new BT firmware ... thats likely intresting for us
<Tassadar> that's not part of kernel, but I agree, that is interesting Oo
<ogra_> lool, beyond that we still have the input bug that makes the device unusable ... without that fixed we wont really be able to move towards something funtional
<ogra_> but beyond tjaalton poking in the dark, there is nobody working on it
<ogra_> lool, oh, and the rotation stuff now moved properly into gnome-settings-daemon
<ogra_> lool, ram usage didnt see much impact the last week ... we're all waiting for upstart user session support for the next big hit on that
<lool> ogra_: thanks for the updates
<lool> ogra_: who's usually handling the N7 kernels in ubuntu kenrel team?
<ogra_> (and the rewrite of the lenses in vala)
<ogra_> lool, i dealt with apw and rtg for them
<lool> ok, will poke them!
<ogra_> i poked rtg already but there was no released source at that point
<ogra_> (a while ago when the first announcement came out from google)
<xnox> ogra_: do i need a "special" android xz?
<xnox> input was encoded with settings that are not supported by this XZ decored
<xnox> s/decored/decoder/
<ogra_> where exactly do you use it in the stack ?
<xnox> initrd. I guess I should have used xz --check=crc32 --lzma2=dict=512KiB instead of just xz.
<xnox> ogra_: where is the code that generated nexus7 initrd and bootimg?
<ogra_> the device doesnt care about initrd
<ogra_> only the kernel does
<ogra_> so its our own (well, the kernels) xz
<xnox> well, I'm repacking. And the kernel docs say that only lzma2 and bcj filters are supported with small dictionary and it asks to prefferably add crc checking
<xnox> boots now \o/
 * xnox waits for tarball to unpack and automatic-oem-config to finish
<xnox> and it so totally self-provision =)
 * xnox rocks.
 * ogra_ applauds 
<ogra_> do you get completely through to the desktop ?
<xnox> yes.
<ogra_> wow !
<ogra_> you rock !
<xnox> it asks me for a password, but i can't remember it.... so where is that preseed file...
<ogra_> i guess plars will have a party now
<ogra_> uh, autologin should be preseeded
<xnox> it logged in fine, my password was !ubuntu123 and i couldn't login into pkexec.
<xnox> autologin is default, so no need to preseed it.
<ogra_> well, thats what i meant above :)
<ogra_> it should be set by default, sorry, wrong term
<xnox> just need to copy name, login, ssh pub id, network manager wifi and add it to usb-creator as "gift vs use my data"
<Laney> gah
<ogra_> we could do wifi from the tarball-installer btw ...
<ogra_> so you could wget that stuff before running oem-config
<TheMuso> ogra_: That has accessibility implications... :)
<TheMuso> Although on the nexus7 it doesn't really matter.
<xnox> wouldn't early command that drop it into oem hooks dir be sufficiently early enough?
<ogra_> (rigth before the ac100-tarball-installer package gets removed we are chrooted and could set up the nework, use wget and pull a preseed file)
<xnox> TheMuso: these settings are copied from already configured ubuntu desktop for auto-preseeding.
<xnox> which is accesible (lets pretend usb-creator is fully accessible)
<ogra_> TheMuso, nothing interactive that would need a11y here
<TheMuso> xnox: Point, usb-creator is accessible at least in quantal.
<ogra_> geez, ubuntu.com is slow right now
<ptl> yeah
<Tassadar> woot, tablet-optimized unity)
<thebishop> damn tablet folks
<thebishop> this does look pretty hot
<thebishop> obviously similar to the phone, but i think it's more compelling on the tablet
 * Tassadar saw "sidestage" somewhere before :)
<thebishop> so... do i need to buy a nexus10 to use this?
<Tassadar> it's probably just "showcase dummy device"
<Tassadar> although he didn't say anything about actual devices
<thebishop> Tassadar, yeah, but that's what was said about the Nexus phone, and it is actually the reference device
<thebishop> even if it won't be the flagship device in stores (obviously)
<Tassadar> well, it's developement phone, not something users should have
<thebishop> right, but it's a good phone, and it's the primary target.  if the same is true of the nexus10 (which is a sexy tablet imo), it's tempting
<Tassadar> well, sexy and expensive
<thebishop> truthfully i'd probably rather have the nexus10 than any other non-apple tablet
<Tassadar> well, theres nexus 7
<thebishop> yeah i have one of those
<thebishop> if the new ubuntu tablet software runs on there, i'll definitely try that before i do anything else
 * Tassadar just realized he begun three sentences in a row with "well,"
<thebishop> :)
<thebishop> there's a hell of a lot to like about this.  i'm not sure if it can actually compete with Android, but suddenly the tablet (with flexible UI switching) makes total sense to me.  whlie the phone just looked nice but ultimately doomed to fail
<thebishop> having flexible language support could prove very important
<Tassadar> yeah, it looks good
<thebishop> i wouldn't be surprised to see google copy some of that
<infinity> thebishop: I think further polish and convergence between phone and tablet will make the phone make more sense.
<thebishop> not sure if they can actually get Android to convert to Chrome OS, but Android touch to Android TV is probably doable
<Tassadar> current tablet UI is just "normal UI" streched out to fill the screen -.-
<infinity> thebishop: Much like Android 2.x was great for phones, 3.x was great for tablets, but it wasn't until 4.x that there was a decent convergence story.
<thebishop> infinity, exactly.  that's the thing that impressed me.  I already run Ubuntu on my laptop.  I'm basically sold on Ubuntu Tablet.  Integration with the phone makes it possible worth switching
<thebishop> the biggest hurdle to widespread usage will be the same as Ubuntu desktop: getting OEM support
<thebishop> but thanks to google's success and MS' blunders that may be more feasible now than ever
<thebishop> Tassadar, Ars says it's coming to Nexus7 http://arstechnica.com/gadgets/2013/02/ubuntu-for-tablets-arriving-on-nexus-7-nexus-10-this-week/
<Tassadar> I wonder where did they get such information
<Tassadar> ah, wonderful, daily nexus 7 image is working again, thank you :)
<thebishop> the sucky thing about Nexus7 is no sexy Ubuntu TV switching
<Tassadar> yeah, doesn't have hdmi
<thebishop> unless Ubuntu has a miracast-alike tech (which would be awesome BTW)
 * Tassadar angrily shakes his hand at Asus
<thebishop> haha
<Tassadar> the SoC has has hdmi pinout!
<Tassadar> kernel support is in there
<thebishop> yeah? should i break out some flux and solder?
<Tassadar> hell, the dev versions of n7 even has hdmi connector
<thebishop> yep
<thebishop> i blame google, actually
<thebishop> i think it was a combination of cost-savings and google maybe not actually wanting you to use nexus7 that way
<Tassadar> meh, probably some expensive license or something like that is needed for hdmi output
<thebishop> similar to the no-MicroSD headscratcher
<thebishop> Google seemed to have a narrow idea of how nexus7 would/should be used
<Tassadar> yeah, they want user to buy content from google play
<thebishop> exactly
<Tassadar> shame that it is not available in here)
<thebishop> nexus7 was a very strategically-minded product
<Tassadar> much like kindle fire
<Tassadar> except with real android
<thebishop> yep
<thebishop> but on the streaming possibilities... are there any? i read that miracast needs dualband radio, but iOS achieves a similar feat without it.
<Tassadar> http://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDIQFjAA&url=http%3A%2F%2Fesrlabs.com%2Fandroid-transporter-for-the-nexus-7-and-the-raspberry-pi%2F&ei=6qkjUbLTIITk4QSrw4CACQ&usg=AFQjCNFPcDgHVZuN9P5P1OxW0I2CN4Avgg&sig2=qNA1mY5WT-th8widcw3PMg&bvm=bv.42553238,d.bGE
<Tassadar> ah, sorry, google link, but anyway
<Tassadar> Android transporter
<thebishop> and anyway, my understanding on the dualband limitation was that it needed one band for streaming to output, and another to stay online.  what if you don't need to be online?
<Tassadar> not sure, but streaming needs quite fast connection
<thebishop> it's not wifi-direct?
<Tassadar> yes, it is
<Tassadar> but even then
<xnox> ogra_: so to push WiFi settings we just need to copy one file across into /etc/ although that requires root =(
<ogra_> so you could do it from the tarball installer
<ogra_> but you need to pull it somewhere ... hmm, catch 22
<xnox> ogra_: that's fine, since i'm rebuilding initramfs anyway....
<xnox> so same as preseed =)
<ogra_> well, yeah, then its easy
<ogra_> just add some cp before the removal of the ac100-tarball-installer package
<ogra_> or even earlier if you want
<isaias> how do i enable html5 on firefox? i cant watch videos on youtube
<Tassadar> have you enabled it here http://www.youtube.com/html5 ?
<Darkwing> I have a quick question... Once the "new" mobile and tablet software hit on thursday... will the current images of unity on the Nexus be replaced with that?
<TheMuso> Darkwing: No I don't think so.
<Darkwing> Okay. just wondering how that was going to work.
<xnox> ogra_: hmm.. so it ran out of battery but it's just flashed. it died at unpacking tarball.
<xnox> it's on ac charge now, but the screen flickers from time to time when (i guess) it's still trying to boot.
<ogra_> charge it a bit first
<xnox> any tips on recovering from that?
<ogra_> hmm, nope
<xnox> but i can't seem to force to be off and stop trying to poweron on power.
<ogra_> the device is built in a way that it will always reboot if you HW reset it with the power button
<Tassadar> have you tried to force it to bootloader?
<ogra_> if it has enough power yet
<ogra_> but yeah, that would at least stop the loop
<Tassadar> or into that useless nvflash mode (pwr+volup)
<ogra_> dunno, was there a shutdown option in the menu \?
<Tassadar> yes, it is there
<mainerror> Is it possible that this list isn't up to date? https://wiki.ubuntu.com/ARM/TabletList
<ogra_> yeah, then it will definitely help
<ogra_> mainerror, heh, i didnt even know it existed :)
<mainerror> :D
<mainerror> I'll start by adding a Tegra 3 section and at least the Nexus 7 since it is the reference device for Ubuntu.
<ogra_> yeah, good idea
<xnox> meh
 * xnox off to volleyball. will leave the tablet charging over night.
<infinity> xnox: If it's stuck on a flickering screen, it's not charging.  You need to boot into recovery, arrow down to "power off", then turn it back on and you'll get the friendly battery meter.
<infinity> xnox: If it shuts off hard, it never gets itself into the right state to recharge.
<infinity> xnox: (I had this problem just a week ago)
 * ogra_ just listens to his battery applet 
<ogra_> and if i work in console its usually plugged in ...
<mainerror> Done. https://wiki.ubuntu.com/ARM/TabletList
<mainerror> Now we have a Tegra 3 section and the Nexus 7.
<ogra_> thanks a lot !
<mainerror> The section needs a description (or maybe not, I don't know).
<ogra_> xnox, bug 1093050 btw
<ubot2> Launchpad bug 1093050 in ubuntu-nexus7 "compiz dies during oem-config and steals the focus so that input fields are unusable" [High,Confirmed] https://launchpad.net/bugs/1093050
<angs> does arm-linux-gnueabi- toolchain support cpu arm926ej-s?
<infinity> angs: Sort of.
<infinity> angs: You can target it with GCC (it's an armv5te), but our entire distro is built for armv7, including the libc and gcc stubs, so you'd need to probably start with crossing a new toolchain that's armv5-clean.
<angs> thank you infinity
<angs> do you know any prebuild arm-none-eabi toolchain that works on ubuntu 12.10?
<angs> I saw somewhere to type "sudo add-apt-repository ppa:germia/archive3 " the apt-get update, but it outputs such errors Ign http://us.archive.ubuntu.com quantal-backports/universe Translation-en_US
<angs> Fetched 4,240 B in 11s (375 B/s)
<angs> W: Failed to fetch http://ppa.launchpad.net/germia/archive3/ubuntu/dists/quantal/main/source/Sources  404  Not Found
#ubuntu-arm 2013-02-20
<xnox> infinity: ogra_ thanks. I came home and plugged it into the duracell battery pack and it managed to boot and install while i was making tea =)
<xnox> I wonder if we actually want an adb bridge running on ubuntu and allow to execute those commands (some of)
<SailorMoon> You guys aware of the Horrible english on the Nexus 7 install instruction page?
<SailorMoon> "You will be connect the device to your WiFi network "
<sfeole> oye, theres a lot of new information in there since I was last maintaining it.
<SailorMoon> Which really there isnt any point in installing, Correct?
<SailorMoon> Doesnt Ubuntu for Tablets launch Thursday?
<SailorMoon> making These desktop-style builds obsolete?
<sfeole> Meh, Completely up to you if you want to install or not.
<sfeole> I do believe that the Ubuntu for Tablets launch is soon! Not sure about the exact ETA.
<SailorMoon> It's Thursday
<sfeole> regardless, I fixed that first paragraph.
<SailorMoon> According to 4 different news sources, Ubuntu Phone and ubuntu tablet launch Thursday
<SailorMoon> Can you share a bit of information about it with me? assuming you know about it? lol
<RDash-BNC> is there any bugs for Nexus 7 wifi saying device not ready?
<SailorMoon> i just installed Ubuntu for Nexus 7, No wifi problems here
<sfeole> RDash-BNC: during install?
<RDash-BNC> after installed
<SailorMoon> only problem so far is screen rotation and OTG Device support seems to have disappeared
<RDash-BNC> dmesg says CFG8011-ERROR) wl_cfg80211_hang : In : chip crash eventing
<RDash-BNC> and dhd_preinit_ioctls: can't get MAC address , error=-5
<sfeole> RDash-BNC: dahh, i'm not really sure. I've been out of rotation for at least 3 months with the N7 doing other things. Your best bet is to check the existing bugs @ https://bugs.launchpad.net/ubuntu-nexus7 .. If you don't see anything, file one
<SailorMoon> Also, not really a bug, more of a missing feature, the Ubuntu Software Center seems to have no search bar
<RDash-BNC> does build-essential override anything important for wifi?
<sfeole> i just happened to be "strolling by" #ubuntu-arm and saw Sailormoons initial blurb about the wiki
<SailorMoon> I have to say, you guys are very quick with development
<SailorMoon> wasnt just two months ago the Nexus 7 builds were garbage
<SailorMoon> Now i could actually see myself using this
<RDash-BNC> true
<RDash-BNC> other than the random framebuffer problems when rebooting
<SailorMoon> Ubuntu for Tablets launching Thursday
<RDash-BNC> it is?
<SailorMoon> Supposidly, yes
<SailorMoon> http://www.itpro.co.uk/tablets/19236/ubuntu-tablet-os-will-make-its-debut-nexus-7-21-february
<RDash-BNC> heh
<RDash-BNC> I wonder if they hammered out the very major bugs
<SailorMoon> I wonder as well
<SailorMoon> screen rotation has me in fear of todays build
<RDash-BNC> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994 and https://bugs.launchpad.net/ubuntu-nexus7/+bug/1070283 are very annoying
<ubot2> Ubuntu bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed]
<ubot2> Ubuntu bug 1070283 in ubuntu-nexus7 "after reboot, framebuffer of previous boot appears on screen" [High,Confirmed]
<RDash-BNC> I know they are still patching it but still annoying
<SailorMoon> well, it wont be a stable build lol
<sfeole> is the button1 problem still around?
 * sfeole looks at the bug
<SailorMoon> "button1"?
<RDash-BNC> left mouse button
<RDash-BNC> or a single finger tap
<sfeole> SailorMoon: the first bug listed above
<SailorMoon> ohhh
<SailorMoon> darn lol
<SailorMoon> that will make it unusable
<RDash-BNC> and is there a way to install a compiler w/o bricking the wifi drivers?
<sfeole> yeap
<sfeole> RDash-BNC: i thought there was a convo about that RDash-BNC a few months / weeks ago here
<sfeole> let me check scrollback
<RDash-BNC> going to reflash since it's all bricked
<RDash-BNC> maybe dropbear or build-essential did it
<SailorMoon> Will Ubuntu Mobile make use of /system? or is my old android install just going to sleep there lol
<SailorMoon> No way to mount ubuntu over USB? =/
<RDash-BNC> and I just screwed up my initrd
<RDash-BNC> I think that explains why my wifi broke
<SailorMoon> My ubuntu just did the button1 thing =/
<RDash-BNC> just tap slowly
<Anonymous905> Hey, can someone help be get started on Installing Ubuntu for my Nexus 4?
<RDash-BNC> Anonymous905: did you mean Nexus 7?
<Anonymous905> Well actually I have a Nexus 10, but I'm curious how I can go about installing Ubuntu on platforms other than PC
<RDash-BNC> Right now, I think Nexus 7 is the only tablet running a kinda working Ubuntu
<RDash-BNC> what does my display manager log have other than my hostname?
<Anonymous905> In that case, how do I get a Nexus 7 to run Ubuntu?
<RDash-BNC> The wiki has the instructions for it. https://wiki.ubuntu.com/Nexus7/Installation
<RDash-BNC> Just remeber it's just the desktop and it's quite buggy
<ashes> hello
<ashes> have any of you got ubuntu for android working as a desktop?
<ashes> it looks like i need an mhl adapter with the cradle, and a bluetooth keyboard. is that right?
<RDash-BNC> ashes: you can use your finger for all the input
<ashes> doesn't ubuntu run from a chroot?
<ashes> uh
<ashes> i'm not talking about running ubuntu in the android display. i'm talking about having it displayed to an hdmi monitor. i would prefer a keyboard for that
<dholbach> good morning
<ogra_> xnox, what would adb gauin us over the serial console, usbnet and an optional sshd  that we already ship ?
 * ogra_ realy isnt fond of including any android stuff 
<xnox> true.
<xnox> i'll just rip apart adbd to gain reboot bootloader.
<ogra_> especialy if it just duplicates standard linux tools we have already
<ogra_> oh, ok
<ynezz> why not, it's so trendy :)
<ogra_> well, we can surely mimic the userspace bit of reboot bootloader ... but will also need the kernel support
<angs> I have ubuntu 12.10 on my host machine. Is it possible to install arm-none-eabi- tool chain by apt-get install ... ?
<ogra_> what would arm-none-eabi be ? that sounds ancient
<angs> I have a arm926ej-s cpu, I guess arm-linux-gnueabi- does not support it
<ogra_> that should support v5
<angs> do I need to download arm-linux-gnueabi- then compile it for arch=armv5te ?
<angs> or do I need to have arm-none-eabi-
<xnox> ogra_: well the linux patches were supposedly upstreamed. https://lwn.net/Articles/504721/
<xnox> unless that's intel only and not android.
<ogra_> well, then we would be able to just ship a hacked reboot binary
<ogra_> angs, it should default to that, shouldne need arch=
<ogra_> *shouldnt
<xnox> hehe, i guess linus had hard time remembering children's birthdays hence using them as magic numbers for reboot syscall made sure he can look them up on any machine ;-)
<ogra_> heh
<xnox> so the reboot syscall in ubuntu-nexus7 kernel does copy across the restart command... i'm stopping to dig further into arch specific implementations. but it's no different from the android kernel.
<hrw> prpplague: hi, early bird
<ogra_> xnox, well, it is the android kernel, just a different config
<ogra_> which reminds me ...
 * ogra_ upgrades his n7 to yesterdays kernel
<xnox> ogra_: right but stock android doesn't have much of an init system hence their reboot utility remounts the rootfs ro before doing reboot into firmware.
<ogra_> hmm, we could do that in a "startr on stopping filesystem" job or so
<xnox> ogra_: and our reboot is naturally is handled by upstart which has it's own shutdown utility. I can see how I can force `reboot -f bootloader` but i'm not sure how to correctly hook into the whole sysvinit mechanics.
<xnox> otherwise the next boot will not be clean.
<ogra_> we could ship our own reboot-bootloader binary
<xnox> ogra_: no, one cannot use upstart job to accomplish that, since upstart is killed by sendsigs and then later the filesystem is unmounted and finally we reboot with sysvinit I believe.
<ogra_> that gets called instead of upstarts reboot in the case where you call it with the bootloader arg
<xnox> ogra_: i'll do / try a quick dirty force one and then will work with jodh on the proper one which does it correctly.
<ogra_> k
<xnox> we will needed for UEFI fastboot anyway, since we will need an option to "reboot into firmware" and we have designs from mpt for the reboot dialog as well on the desktop.
<ogra_> ugh, we want to expose that to the user ?
<xnox> ogra_: for UEFI fastboot we must. As UEFI fastboot means there is no physical way to interrupt the boot process.
<xnox> (no usb, no keyboard, no networking, straight from poweron to boot the default configured OS as fast as it can)
<ogra_> well, i would consider that an admin task, not an enduser task ... and keep it as cmdline option
<xnox> and to get back to e.g. grub or like recovery-mode one needs to be able to get there somehow.
<ogra_> hmm
<xnox> well we will need a cmdline option to begin with =) to be able to actually do it ;-)
<ogra_> yeah
<quin> ~gibber 6
<quin> ~gibberish 6
<quin> oh sorry, please excuse me, wrong channel
<xnox> ogra_: I totally made upstart's: reboot -f bootloader
<xnox> boot back into fastboot mode ;-)
<ogra_> lol
<ogra_> how evil :)
<TheMuso> Now all you need to do is extend the system indicator to offer that option on the nexus 7. :p
<ogra_> hahaha
<SailorMoon> Hey, can i ask question about Ubuntu Mobile? Something is said in an official video
<SailorMoon> This image pretty much sums up my question http://i.imgur.com/AaRFzN7.png
<SailorMoon> He mentions running Windows apps, showing a tablet.
<SailorMoon> Is this an x86 example?
<Tassadar> http://en.wikipedia.org/wiki/Thin_client
<Tassadar> it is not running on the tablet
<davmor2> SailorMoon: if you listen to the video it is via thin client
<SailorMoon> Well i didnt know what a thin client was
<SailorMoon> I think we use those at work to process Orders
<SailorMoon> lol
<SailorMoon> Thanks for the info
<davmor2> SailorMoon: it runs on a windows machine elsewhere and you just access it via the thin client
<SailorMoon> Lol gotcha, useless feature
<Tassadar> it may have been unfortunate to show that in the video, I've seen many people just assuming it runs windows apps :/
<SailorMoon> i didnt think it did
<SailorMoon> was wondering how that was done lol
<SailorMoon> We get flashable builds tomorrow, right?
<SailorMoon> May i ask the stupidest question ever?
<SailorMoon> Java Runtime Environment?
<SailorMoon> Also, The builds of Ubuntu 13.04 for the Nexus 7 no longer support OTG Keyboards, will this mobile version?
<Tassadar> openjdk should be available as usual, and I don't think Ubunut doesn't support OTG on nexus 7 Oo
<SailorMoon> The old 12 builds supported Mouse and Keyboard over OTG
<SailorMoon> But the new Dailies don't
<Tassadar> I'm gonna try that
<SailorMoon> thanks~
<SailorMoon> id also like to recommend You guys create a channel for Ubuntu Mobile
<SailorMoon> Because this feels more like a Dev channel than a social/support channel
<SailorMoon> Unless i'm wrong
<Tassadar> it works okay
<SailorMoon> Last nights build didnt
<SailorMoon> i installed it last night and used my OTG cable and it didnt work
<SailorMoon> Unless my spare keyboard kicked the bucket (it IS cracked in half, but still worked as of a few days ago), ill test it on my desktop
<SailorMoon> yeah it works fine
<SailorMoon> didnt work on yesterdays 13.04 daily for the Nexus 7
<Tassadar> kernel was updated, maybe they changed something, gimme a while to update
<SailorMoon> Thanks again. my OTG cable and keyboard are working fine on Android
<SailorMoon> So it isnt my hardware
<SailorMoon> I hope this doesnt delay the launch
<SailorMoon> i guess it wont :P
<SailorMoon> I'm excited to replace android with something useful, is all
<ogra_> SailorMoon, that demos the rdp client if you use the tablet in thin client mode
<ogra_> ah, davmor2 already answered
 * ogra_ should read the full becklog before answering :)
<SailorMoon> lol
<SailorMoon> Thanks anyway, ogra_
<SailorMoon> So, are the ARM guys ready to get popular?
<davmor2> ogra_: pleasure :)
<SailorMoon> lol
<SailorMoon> how well does everything work on Ubuntu Mobile in comparison to the Dailies we're getting for the Nexus 7?
<SailorMoon> Screen rotation issues, "sleep" issues, and button1 issues plague it
<ogra_> SailorMoon, i am already popular :P
<ogra_> ask my GF
<SailorMoon> what was Ubuntu ARM doing before this?
<davmor2> ogra_: I asked her the air went blue, what have you done to that poor woman ;)
<ogra_> haha
<ogra_> SailorMoon, building the archive, making images for developer boards (and occasionally for an enduser devcie like the ac100 or now the nexus7)
<ogra_> the arm port is around since 2009
<Tassadar> SailorMoon: OTG works okay
<SailorMoon> Why didnt it work for me last night then Tassadar =/
<Tassadar> you have to connect keyboard to OTG reduction and then the OTG cable to tablet
<SailorMoon> i did that
<Tassadar> well, it works for me
<SailorMoon> Ill take your word for it, then :P
<Tassadar> maybe not in the installation dialog but even then, it should work as expected
<SailorMoon> it didnt owrk then and it didnt work when i was trying to type Terminal into the app search thingy on Unity
<SailorMoon> But to be fair, durring my attempt to search for apps in unity, i couldnt get the virtual keyboard to pop up either
<SailorMoon> and got several system errors
<SailorMoon> :P
<SailorMoon> Will the Ubuntu for Tablets be just a sexier titanic?
<Tassadar> will the aliens arrive tomorrow?
<Tassadar> we'll see
<davmor2> Tassadar: we are here now but shhhh don't tell everyone ;)
<Tassadar> i _knew_ it!
<SailorMoon> Okay now for the stupidest question
<SailorMoon> Nexus 7 wont run Minecraft right?
<SailorMoon> For 3D Acceleration reasons, not to mention the slow ARM processor?
<SailorMoon> also on Ubuntu Mobile, what happens if install LXDE, or KDE, Etc? (Hey, someone has to ask the dumb questions)
<ogra_> SailorMoon, get an old toshiba ac100 netbook ... we provide lubuntu images for it :)
<ogra_> everything works, KDE, lxde ... xfce ...
<SailorMoon> Thats totally diferent
<SailorMoon> I know it would work on the Dailies for Nexus 7
<ogra_> right
<SailorMoon> i mean the actual Mobile ubuntu, with the side swipe, etc
<ogra_> well, no idea, i havent seen the code yet (and if i had i wouldnt talk about it before it is publically released)
<SailorMoon> What kind of Memory usage am i going to see just from the system with nothing installed?
<SailorMoon> ahh
<SailorMoon> it releases tomorrow though, i've been told by magical unicorn sources
<ogra_> should be similar or lower than the current nexus7 image
<ogra_> where we are right below 400M for an idling desktop
<SailorMoon> So more then Android
<SailorMoon> To be expected, i guess
<SailorMoon> The difference between a real OS ;P
<ogra_> nope, to be cut down :)
<ogra_> if we are done with the cut down work (which is still going on) i would put my bets on 256M for the idling desktop
<ogra_> and note that i'm talking about the actual desktop here
<ogra_> the tablet studff might then even eat less
<ogra_> (once we have it fully integrated)
<ogra_> the current work we do in ubuntu arm brings benefits for all desktops no matter what arch is below ... raring x86 desktop should already be a *lot* smaller and faster than 12.10 was
<SailorMoon> huh
<SailorMoon> Android wit honly a few things running is using 418MB of ram on my Nexus 7
<SailorMoon> Difference being Android kills off Processes when memory gets tight, ubuntu can't do that, right?
<SailorMoon> ubuntu should use /system as swap
<ogra_> ubuntu can do that as well indeed
<ogra_> it just doesnt
<SailorMoon> if ubuntu used /system as swap, it wouldnt need to
<ogra_> we use compressed swap in ram
<ogra_> to not wear out the MMC
<SailorMoon> but what are you guys doing with /system ?
<ogra_> nothing atm (in the nexus7 image, cant talk about the tablet one yet)
<SailorMoon> My recommendation: Put a recovery image in there
<ogra_> (not because i'm not allowed, i was simply to busy to take a look yet)
<SailorMoon> in case people break their ubuntu, they could recover it with no struggle
<SailorMoon> the /system partition is like 700MB or something on the Nexus 7
<SailorMoon> would also be good for OTA updates to store the update to make writing to /userdata safer
<SailorMoon> Anyway, ill shutup now lol
<ogra_> we dont touch /system in the current ubuntu image
<SailorMoon> i know
<ogra_> ubuntu lives in userdata
<SailorMoon> you should take advantage of everything your offered
<ogra_> if i would the image would wipe the device and use one big partition
<SailorMoon> lol
<SailorMoon> that would like, ruin Android
<ogra_> who cares
<SailorMoon> no going back lol
<Tassadar> I care)
<ogra_> sure going back is always possible
<SailorMoon> i honestly wouldnt mind it if there was a no-fail way of undoing it
<SailorMoon> There's going to be people who install it and say "well, this isnt for me"
<ogra_> and ?
<ogra_> they can jusr reÃflash android then
<SailorMoon> i know :P
<SailorMoon> but if you destroyed the partitions, that might be a bit harder
<SailorMoon> lol
<ogra_> its not like we trash the device
<ogra_> nah, you can always flash from fastboot and restore it
<ogra_> the tablet image will likely completely take over everything
<SailorMoon> I just realized what should be done with /system
<Tassadar> repartitioning is not an option on nexus 7 anyway because of the bootloader, isn't it?
<Tassadar> *is it?
<SailorMoon> Bootloader can be unlocked just by typing "unlock"
<ogra_> Tassadar, depends, if nvflash works now, you can even replace the bootloader with it
<Tassadar> no, it doesn't
<ogra_> it didnt work back when we started with the n7, else i would have picked that route
<ogra_> you can on every other tegra
<Tassadar> n7's bootloader is encrypted
<Tassadar> and device-specific encrypted
<ogra_> right, you need the key
<SailorMoon> you guys need an android-style .zip package that installs like a rom, containing a Mini installer, with just wifi drivers, etc. To download the /userdata
<ogra_> SailorMoon, i think thats what the tablet image does
<SailorMoon> You'll get more users that way instead of the complex way its done with the Dailies
<ogra_> using zips and replacing all of android with the ubuntu image
<ogra_> SailorMoon, huh ?
<SailorMoon> its currently done with fastboot, wich 90% of android users have no idea how to use
<ogra_> whats complex there ? its a one click UI installer
<SailorMoon> For ubuntu users*
<ogra_> oh, well, i wouldnt ask my mom to use fastboot if there is a one click installer that runs fully automatic
<ogra_> (which we offer since day one)
<SailorMoon> Unless your mom was on Windows
<SailorMoon> or  Mac
<SailorMoon> or A non-ubuntu distro
<ogra_> well, *my* mom wouldnt be on either :)
<ogra_> but i see what you mean, yeah
<SailorMoon> Point is
<ogra_> well, the tablet image works this way
<SailorMoon> androidusers are experienced with .zip packages that can be installed via Recovery
<ogra_> the nexus7 image never was for users
<ogra_> yeah, a horrid way
<SailorMoon> Horrid but familiar.
<ogra_> still nothing a normal unexperienced user would do
<SailorMoon> a normal unexperienced user doesnt even know what Linux is
<SailorMoon> So
<SailorMoon> :P
<ogra_> right
<Tassadar> we need to define "normal" here)
<SailorMoon> ive been flashing Roms for a long time, but this was the first time i Really used Fastboot other than to unlock
<ogra_> but he would use the ubuntu tablet installer for windows ... with a one click UI :)
<ogra_> Tassadar, your mom
<SailorMoon> its a scary experience
<ogra_> or worse (since wimen are usually better at tech stuff) your dad
<SailorMoon> scary experience for first-timers*
<Tassadar> dude, I'm afraid to let that man to use computer
<ogra_> SailorMoon, and using a zip wasnt when you did it the first time ?
<SailorMoon> I guess your right
<ogra_> Tassadar, then he is the perfect target user :)
<SailorMoon> But like i said
<SailorMoon> Every tech android user has flashed zip roms
 * ogra_ usues his mom as tester if he writes apps
<SailorMoon> very few have done it with fastboot
<ogra_> SailorMoon, it wont be "flashing" at all
<ogra_> it will be "use the ubuntu installer for your OS"
<Tassadar> but if you take that as target user group, then they will wait for real ubuntu tablets - like preinstalled new models from OEMs, and they won't give a damn about hows it called
<ogra_> yeah, indeed
<SailorMoon> So there will be a Windows installer, then?
<ogra_> i'm talking more about the early adopters
<ogra_> SailorMoon, i woudl hope so
<ogra_> else it wouldnt be ubuntu ;)
<Tassadar> the issue with windows are usually the drivers :/
<SailorMoon> yeah you'll need fastboot drivers
<ogra_> well, i would assume people attaching their adnroid device to win already have a driver for it
<SailorMoon> Windows doesnt install those itself
<ogra_> which they used to put i.e. music on the device
<SailorMoon> like i said earlier, not many have used fastboot, and thus not many will have the Fastboot driver
<Tassadar> adb/fastboot drivers are often not the same thing as "normal" drivers
<SailorMoon> that driver is different, Ogra
<ogra_> anyway, no need to speculate ... we'll see where we are by 14.04
<SailorMoon> infact on windows 8, i couldnt even install my fastboot driver
<ogra_> which is the actual target date
<ogra_> before "normal" users wont really use it anyway
<SailorMoon> lol
<SailorMoon> We totally will. it's too exciting to pass up ;P
<ogra_> you arent a normal user
<SailorMoon> Then why do i feel so Nooby.
<ogra_> you are in an IRC developer channel dude !
<SailorMoon> lol
<ogra_> normal users dont do that
<SailorMoon> last night i did something stupid
<SailorMoon> did a Clockwork backup of my Android and its data but instead of moving it to my PC i moved it to internal memory
<SailorMoon> then i installed Ubuntu
<SailorMoon> and was like "Q~Q"
<Tassadar> I managed to do something like that in a day or two after I got n7, wasn't really used to not having sdcard)
<hrw> oops
<ogra_> pfft
<hrw> that's why titaniumbackup + backup on dropbox roxx
<SailorMoon> Is there anything like Wine, but Android?
<ogra_> do ayou know how our binfmt handler for qemu-user-statinc works ?
<ogra_> it enables you to exec arm binaries on an x86 pc
<SailorMoon> I play some Android Games id rather not give up
<SailorMoon> I had QEmu on my Nexus 7
<hrw> I wonder will ubuntuone ever get popular in android apps
<SailorMoon> was running x86 linux on my Nexus 7
<SailorMoon> very poorly <3
<ogra_> i once wrongly unpacked a tarball with arm root filesystem while being in a custome phoe conf
<SailorMoon> Ubuntu one is fail (NOT THE FACE D;)
<ogra_> sadly i missed that i unpacked it to /
<ogra_> and i didnt notice it at all, since my PC happily execudes arm binaries
<ogra_> until the next reboot ...
<ogra_> *customer phone conf
<SailorMoon> i dont use Ubuntu on my desktop/laptop because of driver issues, hardware bugs, etc. But Ubuntu mobile, since its device specific, wont have any of these issues, right? Thats why im excited, anyway
<SailorMoon> I would totally use Ubuntu if the learning curve was smaller
<ogra_> lol
<ogra_> thats a brave assumption
<SailorMoon> i mean, i know it will be buggy but
<SailorMoon> it will be focused
<ogra_> does win8 have less bugs on phones than on the desktop ?
<SailorMoon> lol i wouldnt know
<SailorMoon> i dont even cal lthat shameful peice of trash Windows 8
<SailorMoon> Windows RT
<SailorMoon> Runs only binaries signed by Microsoft
<ogra_> well, be sure ubuntu on phones and tablets will have bugs as well
<SailorMoon> i know
<ogra_> as all software has them
<SailorMoon> i didnt mean it like that
<ogra_> and there could even be owrse ones than on the desktop
<ogra_> *worse
<SailorMoon> i mean any bugs ive had on my desktop due to my hardware wont occure the same way on the tablet because the same hardware was developed on
<ogra_> usually bugs on such devices are way more fatal
<ogra_> simply because you only have one single way of input
<ogra_> i just spenbt a weekend trying to fix the installer ... having to do that from an initramfs prompt on y touch device is no fun
<SailorMoon> Ubuntu Mobile will be less Likely to throw a Terminal in your face, is what i mean
<Tassadar> that X bug with touch input must be real pain in the ass too :/
<ogra_> sure, it will just get stuck instead
<SailorMoon> yeah
<SailorMoon> it happened to me twice last night, Tassadar
<SailorMoon> made me switch back to Android
<ogra_> Tassadar, it is, but not my area of expertise, so i'm wainitng for a fix to appear
<ogra_> sadly not even upstream seems to have a clue
<SailorMoon> The ubuntu desktop appears whe nyou connect a mouse and keyboard, the video revealed that, right?
<SailorMoon> Will that occure when you connect just a mouse? just a keyboard?
<SailorMoon> or requires both?
<SailorMoon> or will there be some magical switch somewhere?
<ogra_> i doubt thats in the demo yet
<ogra_> but the theory is that at some point when its implemented, the device will detect a monitor and switch modes
<ogra_> or a tablet dock for the phone ... or whatever
<ogra_> all this is stuff that will be implemented on the road to 14.04, dont expect to much from the demo
<SailorMoon> lol
<SailorMoon> Okay not to be "That guy"
<SailorMoon> But
<SailorMoon> You guys are calling it a Q1 2014 release date
<SailorMoon> isnt 14.04 Q2?
<ogra_> do we ?
<SailorMoon> Yes?
<ogra_> where ?
<SailorMoon> idk, 50 different news sites
<SailorMoon> It's Q2 then, right?
<SailorMoon> lol
<ogra_> its april 2014
<SailorMoon> "Shuttleworth expects new Ubuntu-powered smartphones to start arriving in Q1 2014"
<ogra_> whatever news sites say :)
<SailorMoon> can i ask you something completely off topic?
<SailorMoon_> Stupid xbox
<SailorMoon_> Whenever i turn it on my wireless disconnects lol
<SailorMoon_> Anyway, what is "PowerPC"?
<Tassadar> processor architecture
<Tassadar> like x86 or ARM
<SailorMoon_> I know, but i would like to know about its performance and such compared to the others
<SailorMoon_> and why isnt it used very often
<SailorMoon_> I believe the Xbox 360 uses it, and some Macs use it, but thats all ive ever seen of it
<calculus> I need help getting my display resolution working properly... I have a pandaboard es, with ubuntu 12.04 and the ti-omap ppa installed... my monitor can do 1600x1200, but it defaults to 1024x768 and 1280x1024 is the only larger option in xrandr
<calculus> monitor is plugged in the hdmi port
<calculus> the strange thing is /var/log/Xorg.0.log mentions modelines for 1600x1200
<calculus> maybe related, the screen flickers when I move the mouse
<TheMuso> calculus: Do you have a specific reason to use the Ti OMAP PPA? There is a display driver in Ubuntu 12.04 proper, pvr-omap4 I think is the package, and it works with Stock Ubuntu OMAP 4 kernels.
<calculus> TheMuso: I was hoping for opengl and video acceleration/libdce things
<ogra_> TheMuso, calculus, while we ship the latest driver in the distro, TI always produced the codecs packages post release so they are only in the PPA ... what we have in the distro is only for GLES but not for accelerated video playback
<TheMuso> Oh right.
<ogra_> calculus, if its a PPA probalem, try #pandaboard (though i'm not sure who is still working on it after TI killed OMAP)
<ogra_> most of the devs that worked on panda stuff were laid off
<calculus> ogra_: I think it is dss related because /sys/devices/platform/omapdss/overlay0/output_size is 1280,1024 and I can't seem to write new values to it (even with sudo)
<ogra_> well, upstream for that stuff is in #pandaboard
<ogra_> we only package and integrate it
<TheMuso> yay for being burnt by proprietary software once the vendor stops supporting the hardware.
<ogra_> yeah, its not clear if we can go on building the desktop images once new Xorg hits the archive
<davmor2> ogra_: quick question, does the current n7 image port over to the touch interface or are they completely separate projects?
<ogra_> davmor2, currently they are completely separate ... over time they will merge
<calculus> what about stopping the flickering, would that be related to hwcursor?
<davmor2> good now I know not to be disappointed when the caterpillar desktop doesn't turn into a bufferfly version :)
<ogra_> davmor2, if you want the butterfly, use the tablet image :)
<davmor2> ogra_: I don't mind either way, although I have to say the tablet version does look gorgeous :)
<ogra_> yeah, if it just had some apps now :)
<ogra_> hurry devs, write some !
<hrw> davmor2: and for "entry level" requires 2GB of ram and cortex-a15?
<Tassadar> ogra_: you had some problems regarding ext4 filesystem, right? It got corrupted because of ...fsck it was?
<Tassadar> on n7
<Tassadar> meh, he's probably gone for the day
#ubuntu-arm 2013-02-21
<cheng> hi, is it ok when cross compile i am using glibc from compiler version and during runtime using glibc from ubuntu-core?
<cheng> the program is able to  run with ubuntu-core dynamic libraries.
<rampage73> I followed the info here https://wiki.ubuntu.com/Nexus7/Installation everything seems to go smoothly until ubuntu splash screen then it goes dark and nothing have waited around 24 minutes now, any ideas?
<nexus7user> does anyoneone know when i may expect to see an image of ubuntu for tablets, for my nexus 7?
<nexus7user> some on the web say as early as tomorrow?
<quin> afaik there are testing images you can install now
<nexus7user> how may i get an image, and a little how to?
<quin> officially it really isn't until later this year
<lilstevie> nexus7user, technically today :p it is the 21st in the UK
<rampage73> nexus7user, according to the link I found https://wiki.ubuntu.com/Nexus7/Installation you can install it now however I have tried it twice now and it seems to be not working
<nexus7user> i know!
<quin> i can't really tell you more than that, i don't have an n7
 * lilstevie is waiting super impatiently for ubuntu for phone images to appear
<rampage73> I second lilstevie
<nexus7user> i have been to that site.. i know that an earlier port of the desktop client came out moths ago, i am afraid that this is an outdated tutorial
<rampage73> anyone here have experience with the nexus 7 installer for ubuntu? I am stuck
<rampage73> it was last updated today (according to the site)
<nexus7user> rampage, are you trying to install the official ubuntu for tablets?
<lilstevie> rampage73, I would wait tbh
<lilstevie> rampage73, the nexus 7 installer installs ubuntu-arm, ubuntu for tablets will be much better :p
<rampage73> I know lilstevie I am just impatient figured this would get me by until then! ;)
<nexus7user> lilstevie, do you know when an image will be available?
<lilstevie> sometime today
<nexus7user> do you know what to expect?
<nexus7user> graphical installer?
<lilstevie> I am no more in the loop than you :p
<nexus7user> do you have an n7?
<lilstevie> nope
<lilstevie> I plan on hacking the image up until it works on my device :)
<nexus7user> oh cool
<nexus7user> what do you have?
<lilstevie> I have a TF201
<lilstevie> and an Xperia T
<rampage73> lilstevie, am I understanding you correctly, ubuntu is releasing tablet edition today?
<nexus7user> i wonder if i should stay up all night...
<lilstevie> rampage73, and phone
<nexus7user> thats what they say
<rampage73> well then I guess I can wait that long! is it on their site?
<nexus7user> how do we talk to someone who is in the loop?
<rampage73> sorry I mean will it be on their site
<lilstevie> they are releasing images for GNex,Nex4/7/10
<lilstevie> first 2 being ubuntu for phones and the latter for tablets
<rampage73> sweet I can try it on my phone too!
<lilstevie> rampage73, from what I hear it will be -> https://wiki.ubuntu.com/TouchInstallProcess
<rampage73> lilstevie, you are more in the loop than I! and thank you!
<lilstevie> rampage73, heh, just what news sites post :p
<nexus7user> i wish they would post what time too lol
<rampage73> lilstevie, I know my tired eyes somehow missed that, thanks and goodnight!
<nexus7user> ill give you my number, and text me when they post it
<LisaNori> So, for those of us using the multirom dual boot, is there a way to load the new image for nex7 and then fix it up to work correctly with multirom, or do we need to get a specific multirom capable image?
<nexus7user> i think we are looking at a whole new bag of chips here
<nexus7user> now hopefully i can put ubuntu on my iphone
<nexus7user> tough crowd
<dholbach> good morning
<hrw> dholbach: hi Daniel
<hrw> dholbach: nexus4 got into hands of new owner ;)
<ogra_> you gave it away ?
<ogra_> sad
<dholbach> hrw, :-)
<hrw> ogra_: I still have mine
<ogra_> ah, another one
<ogra_> great, spread them !
<ogra_> google HW is the best .... if you install ubuntu on it :)
<hrw> ogra_: s/ubuntu/cyanogenmod/ and I will agree with you
<ogra_> pfft
<ogra_> silly android stuff
<hrw> ogra_: I will test that ubuntu phone image one day but beware complaints on my blog
<XorA> someone needs to make Dalvik run under proper gnu/linux base and have best of both worlds :-D
<suihkulokki> if android is so silly, why do coattail on the android hw adaption layer ;)
<ogra_> hrw, well, its not an enduser image so dont be to harsh
<ogra_> suihkulokki, ask the vendors
<hrw> ogra_: ;)
<hrw> ogra_: can I atleast make a call with it? will both sides hear each other and be able to understand? text messages? taking and sharing pictures on google+?
<XorA> hrw: sacrilege no open phone should make phonecalls ;-)
<hrw> XorA: who called nexus4 an open phone?
<ogra_> i think you can make calls ... and i think there is a working browser so G+ should register as html5 app
<ogra_> but not sure, i havent tested it myself at all
 * vibhav sometimes winders why arm had so many build failures 
<vibhav> Wonders*
<vibhav> s/had/has/
<ogra_> because of hardcoded assumptions from programmers
<vibhav> Like?
<ogra_> like that the world only consists of x86 PCs
<ogra_> the build failure situation isnt much worse than for powerpc or other non x86 arches
<ogra_> in fact in ubuntu arm nowadays does better than ppc i think
<TheMuso> Well of course, there are few people caring about powerpc these days.
<vibhav> ogra_: AFAIK, the assumptions you are talking about are stuff datatype sizes, right?
<vibhav> I have heard of ugly code which assumes byte order (shrieks)
<vibhav> stuff like*
<TheMuso> Going from x86 to arm doesn't require endianness changes, at least I don't think so.
<TheMuso> I've never adjusted anything that close to the metal for arm so far.
<nilsB> people are waiting for Touch Developer Preview. https://wiki.ubuntu.com/TouchInstallProcess?action=info&hitcounts=1
<ogra_> great, isnt it :)
<xnox> well armhw doesn't have unalligned memory access, one can trigger it but it hinders performance.
<nilsB> ogra_, yeah great. the wiki home page has an daily average of 3100 page hits. now we have about 53800 after half a day.
<nilsB> on the page TouchInstallProcess
<nilsB> unfortunately on the page hits are moving at the moment...
<SailorMoon> No Ubuntu Mobile release today?
<SailorMoon> I feel betrayed by the Media
<Tassadar> It's still today)
<SailorMoon> Can someone make it right now?
<SailorMoon> I have to work tonight
<SailorMoon> lol <3
<Tassadar> ogra_: you here?
<SailorMoon> Assuming i like it (Totally will?) ill probably become a regular here.
<ogra_> Tassadar, well, with half a toe only, #ubunti-phone keeps me busy today
<ogra_> *#ubuntu-phone
<SailorMoon> which ubuntu is so open, if theres something i dont like i can just change it, right?
<Tassadar> okay, hopefuly short one: you had some problems regarding ext4 filesystem on n7, right? It got corrupted because of ...fsck it was?
<Tassadar> ooh, no, it was because of resizing the filesystem to fit the partition
<SailorMoon> Does Ubuntu Phone/Tablet do anything when connected to PC?
<ogra_> Tassadar, exactly
<SailorMoon> because the Daily "desktop" builds didnt, just curious
<ogra_> SailorMoon, the nexus7 desktop image  definitely does
<Tassadar> did you found out why? is it the bootloader?
<ogra_> Tassadar, nope, didnt
<Tassadar> k, thanks
<SailorMoon> it didnt for me, it seemed to once (Windows notification sound) bu ti unplugged it and it never did it again
<ogra_> oh, on windows
<ogra_> well, you can use putty (if you have the right driver i guess) to log in via usb
<ogra_> or you can set up an usbnet connection (assuming win needs a special driver for this too)
<ogra_> both works OOTB on an ubuntu machine
<SailorMoon> lol
<SailorMoon> Will it always be like that?
<SailorMoon> Surely not?
<SailorMoon> Ubuntu for Phone/Tablet is meant to be "Extremely" user friendly, right?
<ogra_> right, but the nexus7 image isnt ubuntu phone
<SailorMoon> Your going to get a lot of people in here "How do i put music on my blahblah?"
<ogra_> its ubuntu desktop on a tablet device :)
<SailorMoon> I know, i mean
<SailorMoon> is the Ubuntu for Tablets
<SailorMoon> going to do it better?
<Tassadar> I would guess it would do MTP mode like android later on, it wasn't priority for n7's image
<SailorMoon> i can alwyas set up an FTP server i guess
<SailorMoon> have you used it?
<SailorMoon> Ive seen Skype in the side stand thingy, but i can't imagine that not having a huge impact on performance?
<Tassadar> used what?
<SailorMoon> Ubuntu for Tablets
<SailorMoon> on the N7
<ogra_> its not out yet
<SailorMoon> I know, but surely some people have used it
<Tassadar> I'm not "from Ubuntu" :)
<ogra_> see all the buzz in #ubuntu-phone
<SailorMoon> ive seen one or two media sites with screenshots ive never seen before claiming to have used it
<Tassadar> there's video on engadget where they show it on n10
<SailorMoon> found this link on a german site https://wiki.ubuntu.com/TouchInstallProcess
<ogra_> yeah, that will update once it is released
<SailorMoon> "To finish installing updates, Windows must restart" ._. brb guys <3 lol
<SailorMoon> i applaud you, ogra_.
<ogra_> heh
<SailorMoon> First linux user i've met that didnt insta-hate me for being a Windows user on Desktop
<ogra_> :)
<SailorMoon> Truthfully i hate Windows, i just can't use Linux/Ubuntu. i'm too lazy to learn lol
<ogra_> hmm, then we are not good enough yet
<SailorMoon> Smeday Microsoft will make the bold move of Limiting what we're allowed to run, theyre heading that way now
<SailorMoon> And thats when i will switch
<SailorMoon> hey ogra_: Will you answer a question for me thats completely irelevant to Ubuntu or ARM lol
<ogra_> we'll never know if you dont ask it
<vibhav> SailorMoon: never ask to ask
<SailorMoon> lol i only asked to ask becuase its completely off topic lol
<SailorMoon> I have an ASUS Board with a Power mode, which clocks my CPU From 3.6Ghz to 4.3Ghz
<SailorMoon> But my PC would freeze at random, usually after like 20 minutes
<SailorMoon> the temps were fine, and it didnt matter if the PC was idle, or doing some intense gaming
<SailorMoon> So why was it freezing?
<SailorMoon> My guess is the board was trying to clock the ram in a way that wasnt supported?
<ogra_> well, i would suggest running the memtest that ubuntu installs into your bootmenu ... if you woudl run ubuntu
<SailorMoon> I could make a bootable usb
<SailorMoon> it comes with a memtest
<SailorMoon> infact my Bios might even have one
<SailorMoon> i think Windows has one now, too. not sure
<ogra_> well, if your fans run fine i would blame the ram rather than the cpu
<SailorMoon> thats what i was thinking
<SailorMoon> if it was CPU, it would be more likely to freeze when clocked up
<SailorMoon> then sitting idle
<SailorMoon> is it possible to clock CPU without clocking memory? (Im an OC noob.)
<SailorMoon> "dram" is my Ram clock settings right?
<SailorMoon> i think i could try switching it from Automatic to Manual in my bios?
<ogra_> dunno, i'm an arm guy
<ogra_> my only PC doesnt run overclocked
<SailorMoon> so you wouldnt know anything about this GPU Boost switch on my board?
<SailorMoon> lol
<SailorMoon> im scared of it, too
<Tassadar> It is possible the CPU/memory just can't handle frequency soo high
<SailorMoon> yeah the CPU said 3.6Ghz (3.9Ghz Turbo) whatever turbo means
<SailorMoon> and i had it at 4.3
<SailorMoon> But it ran fine and kept a decent temp
<SailorMoon> How many more hours
<SailorMoon> one? six?
<SailorMoon> lol meant to type that in #ubuntu-phone
<SailorMoon> But oh well
 * Tassadar flips a coin
<SailorMoon> Tabs, Tabs everywhere
 * Tassadar flips a tablet?
<sveinse> Is there a way I can run tar & gzip in initramfs? I've installed a custom initramfs script and uses tar gz. I fail to include /bin/gzip as busybox provides this, but tar is unable to use the version provided by busybox
<ogra_> sveinse, take a look at ac100-tarball-installer source
<ogra_> specifically at the initramfs scripts and hooks
<sveinse> thanks, I'll do that
<sveinse> heh. You divert the bulk of the stock initramfs scripts. :)
<ogra_> i thought you took that diversion stuff a while ago already
<sveinse> Yes. I'm using diversion for other things. It was just a comment. The interesting thing is that the purpose of your package is not too far away from what I'm working on.
<sveinse> Mgmt does not like that our product uses 40minutes to upgrade from natty->precise, so we're working on replacing the entire filesystem with rm and tar
<sveinse> zcat did it. Thanks ogra_
<SailorMoon> hey ogra_, the wiki is down for me
<ogra_> works fine for me
<SailorMoon> Internal Server Error  The server encountered an internal error or misconfiguration and was unable to complete your request.  Please contact the server administrator, webmaster@ubuntu.com
<SailorMoon> Can you help me get the download? T~T
<SailorMoon> ohh, its working now
<SailorMoon> must be stress on the server
<SailorMoon> And ofc, no windows install Method
<SailorMoon> Why didnt you tell me i couldnt it install it in windows
<SailorMoon> ive waited two days for nothing
<ogra_> SailorMoon, i think you can, using fastboot and adb
<ogra_> ask in the phone channel the devs are around
<Tassadar> I believe there's flashable ZIP on the download page
<Tassadar> and the whole thing is based on cyanogenmod Oo
<SailorMoon> nope
<SailorMoon> They dont have the images linked
<SailorMoon> and nobody is answering me
<SailorMoon> im so close to just spamming the channel =/
<Tassadar> http://cdimage.ubuntu.com/ubuntu-touch-preview/quantal/mwc-demo/
<rsalveti> SailorMoon: you can install at any os that has adb on it
<rsalveti> and fastboot
<SailorMoon> I know
<rsalveti> if you have clockworkmod at your phone, just grab our zip images
<SailorMoon> Thanks to Tassadar, i finally have the images
<SailorMoon> However
<SailorMoon> this is different then what im used to
<SailorMoon> do i just install this with clockworrk
<rsalveti> you can :-)
<rsalveti> that's what the phablet tools will do in the end
<SailorMoon> Why the small file size
<rsalveti> http://cdimage.ubuntu.com/ubuntu-touch-preview/quantal/mwc-demo/quantal-preinstalled-armel+mako.zip + http://cdimage.ubuntu.com/ubuntu-touch-preview/quantal/mwc-demo/quantal-preinstalled-phablet-armhf.zip
<rsalveti> for example
<rsalveti> install the first one first, and then the second
<rsalveti> like any normal zip via clockwork
<rsalveti> reboot and be happy
<SailorMoon> So wait..
<SailorMoon> you just confused me
<SailorMoon> what do i do with quantal-preinstalled-armel+grouper.zip
<SailorMoon> ohhh
<SailorMoon> i gotcha
<SailorMoon> i get it now
<SailorMoon> damn, for all these people downloading the images, you guys have a lot of bandwidth lol
<SailorMoon> So install device specific zip first, then armhf 2nd
<SailorMoon> and then party?
<Tassadar> ooh, it's split up into two
<ogra_> you could party *while* flashing
<Tassadar> no wonder it's not booting)
<SailorMoon> lol
<rsalveti> SailorMoon: yeah
<SailorMoon> See my idea to prevent having to zip files was to have the device rom download the rest
<SailorMoon> but this works too lol
<SailorMoon> having to download two zip files*
<SailorMoon> i re-overclocked, ogra_.
<SailorMoon> here's hoping i finish the download before i freeze
<Tassadar> I wonder why is there recovery image
<SailorMoon> Okay so question
<SailorMoon> if the zip goes in /userdata
<SailorMoon> how does that work exactly
<SailorMoon> when /userdata is formated
<SailorMoon> loads into memory or something?
<Tassadar> what?
<SailorMoon> the large zip formats your internal memory
<SailorMoon> which is where the .zip is stored
<Tassadar> no, it doesn't
<SailorMoon> yes, it does. lol
<Tassadar> you have to wipe it in recovery
<rsalveti> Tassadar: we have a recovery so we can auto-flash with our tools
<Tassadar> oh, right, that would be it
<SailorMoon> im confused T~T
<rsalveti> but it's basically the clockworkmod one
<SailorMoon> do i use sideload then?
<SailorMoon> or what?
<Tassadar> have you ever flashed any Android ROM?
<SailorMoon> Yes
<SailorMoon> but they write to /system
<SailorMoon> not /data
<Tassadar> then you know you have to wipe /data
<SailorMoon> not always
<Tassadar> well, no, but this is completely different thing, so you have to
<SailorMoon> Copying, Lalala
<SailorMoon> rebooting into recovery, lala
<SailorMoon> wipining system and data, lala
<SailorMoon> installing zips
<SailorMoon> still installing zips (lol)
<Tassadar> it's a big file and does a lot of extracting, probably will take much longer than usual
<SailorMoon> it just finished
<SailorMoon> i think theres some dev info left on these roms
<SailorMoon> Considering i have 14 tweets recieved
<ogra_> heh
<SailorMoon> many contacts, phone numbers, accounts
<SailorMoon> still on these roms
<ogra_> its a demo
<ogra_> it has demo data on it
<SailorMoon> :P
<SailorMoon> Lies <3
<ogra_> on purpose
<SailorMoon> lol okay
<SailorMoon> so your saying icant really call Chris wayne?
<ogra_> you could just wait until he drops into the channel here :)
<SailorMoon> lol
<SailorMoon> im going to call him whenever i need help now
<SailorMoon> (totally kidding)
<ogra_> he is cwayne in here if he is around :)
<SailorMoon> Wifi isnt working
<SailorMoon> Nvm, just got it
<SailorMoon> no "app store"?
<SailorMoon> i have to be honest, its hard to find anything on this
<SailorMoon> seems to be no settings page
<ogra_> well, there isnt much to find yet
<ogra_> pull down the top panel ...
<ogra_> it has the settings
<SailorMoon> thats it, though?
<SailorMoon> Search button appears to only work once
<SailorMoon> or no, its page specific?
<SailorMoon> im a bit disapointed
<SailorMoon> i know its not complete, but i still expected a TON more even in a dev build
<SailorMoon> this is practically feature-less
<ogra_> its a develloper *preview* ... a framework for devs to work in
<ogra_> not for endusers
<SailorMoon> I know
<SailorMoon> My PC hasnt frozen yet
<Tassadar> yaaay, dual-booted)
<Tassadar> hah, gmail thinks it's iphone)
<wookey> OK, so in upstart-world where do I set ttyAMA0 to have a getty run on it in init?
<xnox> wookey: add your own job =) https://help.ubuntu.com/community/SerialConsoleHowto
<wookey> I have no inittab to poke
<wookey> cheers
<wookey> and if a boot with upstart --verbose stops at mountall.sh does that probably mean it worked, I just have no getty?
<wookey> yeee-ha! a prompt
<wookey> what's the root password of a deboostrapped raring?
<ogra_> root is locked
<wookey> hmm. so I need to do an init=/bin/sh boot and set a password?
<ogra_> yeah, i usually do that when bootstrapping ... but indeed you need to know it in advance
<wookey> I was so excited, for just a moment....
<wookey> trying again....
<wookey> cjwatson: xnox doko: arm64 deboostrapped image booted in simulator :-) good job all round
 * ogra_ applauds
<wookey> fix nspr->nss->curl->gnupg->apt and cloog-ppl->gcc and we could start native building (very slowly)
<wookey> (doko already told me what the cloog issue is - should be an easy fix)
<wookey> I seem to have a few commands that are still using libc2.16. rebuilding
<Tassadar> whoa, that ubuntu tablet preview looks like it is cyanogenmod with chroot and the UI stuff running in it
<Tassadar> I suppose that is just because the ubuntu core isn't ready yet...?
<rsalveti> Tassadar: that's because we're using the android binaries
<rsalveti> and some other minor services
<Tassadar> so, will it stay like that?
<davmor2> ogra_: you about still?
<ogra_> davmor2, well, with half an eye, so much going on in the phone channel
<davmor2> ogra_: on the tab, open dash, goto the apps lens, and right click on an uninstalled app.  then check the memory on software-center-dbus  I just want to check if it is as high on the tab as it is on the desktop
<rsalveti> Tassadar: for now yes, but we can get rid of that once we have working driver running at the ubuntu side
<Tassadar> okay, thanks, I guessed it would be something like that
<baggers> hi all, I have a nexus 7 with ubuntu desktop version installed. Do I have to restore android before I flahs the ubuntu tablet image? Or is there a way to get adb running under ubuntu desktop?
<ogra_> baggers, no, but the desktop install doesnt toouch the recovery partition
<ogra_> if you boot into recovery from the bootloader screen you have adb
<ogra_> baggers, try this guide http://sergiusens.github.com/posts/installing-ubuntu-touch-preview-on-the-nexus-7-with-ubuntu-on-it.html
<ogra_> (and tell me if it worked ... if it doesnt you can still go back to android)
<baggers> sweet, I'll try that now, cheers!
<xnox> wookey: uploaded fixed nspr
<baggers> ogra_: The steps all seemed to work but I get a back screen when I boot :(
<baggers> I'll have another go!
<sergiusens> baggers: hey, before sideloading can you go to the mounts menu and wipe/format userdata>
<sergiusens> baggers: sdcard to just in case
<baggers> sergiusens: Turns out I just hadn't waited long enough before running adb reboot. I will flash again soon and format userdata just to see if there is any difference, thanks again!
#ubuntu-arm 2013-02-22
<xnox> oh well nspr is "over cross-compiled"
<RDash-BNC> is https://wiki.ubuntu.com/Touch same as the Nexus7?
<sanmn19> I have installed ubuntu on my nexus 7. I need the root password. I saw the help page where 'ubuntu' was given as the root password but that did not work.
<sanmn19> Can anyone help me out with my problem?
<SoulShadow> hey folks
<SoulShadow> anyone got ubuntu on a chromebook?
<angs> I compiled kernel 3.7.1, what directory does kernel headers should be located in?
<angs>   /arch/arm/xx ?
<vanhoof> Tassadar: finally got around to playing with multirom, completely bad ass :)
<wookey> xnox: aha cool. Chhers muchly
<sveinse> I read somewhere that I can configure dpkg to omit certain dirs from ever installing (like /usr/share/man), but I cant find it. Does anyone here know?
<wookey> xnox: OK. added arm64 support and uploaded.
<paultrafalgar> is this the best place for chromebook users?
<paultrafalgar> i searched the freenode list for chromebook and nothing came up
<Tassadar> paultrafalgar: that depens, does your chromebook have ARM platform?
<Tassadar> *depends
<paultrafalgar> yes series 3
<Tassadar> then this is probably the place
<paultrafalgar> i have 12.04 running nicely from sd card. must I stay  in dev mode for ever?
<paultrafalgar> first attempt to install was to internal ssd - after leaving dev mode i could never get back in (:-)
<paultrafalgar> i'd like to clone my sd card as a backup but uuid is a pain - could i dual boot with different sd cards?
<paultrafalgar> should i upgrade to 13.04? I find Marcin's instructions a  little daunting (too cryptic)
<vanhoof> Tassadar: my auto-complete failed me last night and thought you were online
<vanhoof> Tassadar: but anyways, got a chance to finally play with multirom
<Tassadar> okay
<vanhoof> Tassadar: its friggin awesome :)
<Tassadar> thanks :)
 * Tassadar just sent kexec-hardboot patches to Ubuntu Touch kernel
<Tassadar> hope they'll get accepted as smoothly as they did to ubuntu desktop port
<SoulShadow> should i be scared to try ubuntu on my chromebook
<ogra_> well, it works fine for me
<infinity> (So, yes)
 * ogra_ just recognized after two days standing in the storm of #ubuntu-phone that the old channels are still here :) 
<Zero_Chaos> I'm trying to find some kind of recovery mod that lets me backup all of rootrs on a nexus7 so I can clone my device. any thoughts?
<Tassadar> Zero_Chaos: TWRP should be able to make backup of whole /data
<Tassadar> hm, no, it skips /data/media
<Tassadar> (it is the "fake sdcard" for Android)
<Zero_Chaos> yeah that is close enough, the problem I'm having is when I copy the backup files from /data/media/TWRP it won't show up to restore on another device
<Tassadar> if the device has /data/media/0/ folder, you have to put it in there
<Tassadar> plus, you have to change the serial number
<Zero_Chaos> oh, that's a serial number?
<Tassadar> that weird number in BACKUPS folder in TWRP? yeah
<Zero_Chaos> nice
<Zero_Chaos> Tassadar: thanks dude, that solves that
<Tassadar> should be visible in bootloader
<Zero_Chaos> Tassadar: now, is there any easy way to get that number of do I just have to make a backup first and then read it?
<Zero_Chaos> hmm
<Zero_Chaos> testing
<Tassadar> (or, /proc/cmdline)
<Tassadar> yeah
<Tassadar> cmdline contains androidboot.serialno= parameter
<Zero_Chaos> nice
<Zero_Chaos> yeah that should work
<Zero_Chaos> Tassadar: fantastic, thanks for your help.
<Tassadar> you're....
<Tassadar> welcome!
 * Tassadar had to google if it has one or two l characters -.-
<Zero_Chaos> now silly question, if I'm backing up and restoring android stuff would I want to backup the cache at all?
<Zero_Chaos> heh
<Tassadar> nah, not really
<Tassadar> there isn't much in there, nothing happens if you just wipe it
<Zero_Chaos> Tassadar: english not your first language or you just go to public school? :-)
<Tassadar> no, it is not my native language, I'm from Czech Republic
<Zero_Chaos> that's fair then ;-)
<Zero_Chaos> teasing Americans with bad english is kind of a hobby
<Zero_Chaos> Tassadar: any idea if these "teamwin" guys hang out on irc? I wanted to beg for a feature
<Tassadar> join #twrp
<Tassadar> or create issue on github
<Tassadar> the main guy is Dees_Troy
<Zero_Chaos> heh, took me 1 minute longer to find on their website ;-)
#ubuntu-arm 2013-02-23
<isaias> hello
<isaias> is the current .img working?
<RDashh-BNC> Ubuntu Touch or core for my nexus 7?
<isaias> is the current .img working?
<wookey> xnox: sadly nss doesn't cross either.
<wookey> nor does chromium-os have patches
<wookey> I found a very old peter pearse patch but not had timeto work out if it's suitable.
<isaias> is the current .img working?
<isaias> is the current .img working?
<isaias> anyone?
<ogra_> isaias, i havent heard any reports that it wouldnt, but eveyone is testing ubuntu touch atm, so the desktop image might not get many testers
<vibhav> Do ARM builds use -Wformat-security?
<vibhav> ogra_: Any idea ^?
<ogra_> arm builds dont differ in the general compiler defaults from x86
<vibhav> ogra_: Apparently, thoggen fails due to - Wformat-security
<vibhav> ogra_: iImean fails to build
<vibhav> I mean*
<mosasaur> Is it possible for a device to support NEON but not thumb? And is vpadd a thumb instruction?
<TheMuso> c
<wookey> is insserv supposed to be executable on ubuntu? the package just seems to have /usr/lib/insserv/insserv
<wookey> whereas debian package has /sbin/insserv which makes more sense
<wookey> but /usr/sbin/update-rc.d runs system("insserv", ) so expect to find it on path. How shold this work?
<wookey> (it's not in my arm64 chroot)
<wookey> aha. sysv-rc preinst touches legacy-bootordering. that seems to sort things
#ubuntu-arm 2013-02-24
<tripelb> is just a list. wow  I got disconnected. anyway I found the *-netowrk item for ethernet. but I dont now what it would say if anthing is connected to it.
<tripelb> I dont know...
<tripelb> phone wifi source is truely spotty.
<tripelb> and if I were on gnome.
<tripelb> OK new question: how do I get GNOME 2?  I know how to use it much much better.
<tripelb> I see nothing anyone esle is typing.
<highvoltage> you can install the gnome-fallback session to get the older interface
<highvoltage> gnome 2 isn't in the archives anymore
<divx118> Hi, I am using sudo rootstock  --fqdn Archos  --login ubuntu  --password ubuntu  --imagesize 3G  --seed lubuntu-desktop,openssh-server --dist oneiric to build a lubuntu image for my archos 101IT.
<divx118> However I need to force reinstall "libgdk-pixbuf2.0-0" after starting the image on my device else it won't show the background and icons are missing.
<divx118> Anyone know why?
<ogra_> rootstock was put to death about 2 years ago, if you find issues you are prettyy much on your own to fix them
<divx118> Ok, what is now used to build an arm image?
<ogra_> well, there is no actual replacement for endusers, images for ubuntu are all built using live-build
<divx118> Thanks for the info.
<ogra_> there is also the ubuntu-core that gives you a minimal unconfigured chroot to work with ...
<divx118> ogra_: yes, I know. However I was looking for a way to build a ready image without making too many adjustments so it would be easy to reproduce.
#ubuntu-arm 2014-02-18
<wookey> infinity: is there a patch in ubuntu glibc to avoid "FATAL:kernel too old" messages using qemu-aarch64-static on wheezy?
<wookey> (a version build on saucy works. A version built on unstable doesn't)
<infinity> wookey: No glibc patch, but there's a qemu patch.
<ogra_> well, you still get messages for the missing syscall
<ogra_> 247 or so ...
<infinity> That's not his issue.
<ogra_> (which is "old kernel" in syscalls.h)
<infinity> His issue is qemu claiming to be a version it's not.
<infinity> We carry a patch for that.
<ogra_> right the fatal bit is gone
<ogra_> but we still get the noise fallout in logs etc
 * ogra_ gets questions about that since he revived rootstock :) 
<ogra_> (read: since last week)
<infinity> wookey: debian/patches/ubuntu/arm64/force-aarch64-uname-to-3.7.0-to-appease-glibc
<infinity> wookey: http://paste.ubuntu.com/6954659/
<wookey> aha. cheers
<wookey> Is it right to nobble qemu, rather than tell glibc not to be so picky?
<wookey> I guess the point is that officially the 3.2 kernel didn;t know about arm64 so on a real box it is normally wrong?
<wookey> (/me forgets when arm64 did hit kernel-land)
<suihkulokki> there is a qemu configure and command line and enviroment options to set up what uname is reported there...
<wookey> yes, but I'm not sure how you use that with binfmt entries
<suihkulokki> export QEMU_UNAME ..
<wookey> you mean the line for the binary that gets run is actually interpreted by a shell?
<infinity> wookey: I'm not going to tell glibc to be less picky, no.
<suihkulokki> wookey: why do you think the binary running with qemu linux-user wouldn't see the env ?
<infinity> wookey: Telling glibc to lower its baseline causes a lot more fallout than you'd think.  Bunch of compat code gets pulled in, slower paths taken, you really don't want that on a new port that literally CAN'T run on older kernels anyway.
<wookey> I'm sure it would see the env. The point is that normally it's run by binfmt-support entries. Those need to set all the necessary environement
<wookey> infinity: OK. fair enough.
<infinity> suihkulokki: The configure option is --enable-uname-release ... Which we (Ubuntu and Debian) set to 2.6.32 on all arches.  Which then blows up on arm64, hence my quick patch to just ignore it there.
<infinity> I meant to upstream a patch that actually did a saner thing and obeyed your configure option if it was >> the version glibc supports on that arch, but that sounds like real work.  This works for now. :P
<infinity> Well, it also means maintaining a table, which is a pain.
<wookey> OK. setting QEMU_UNAME=3.7.0 does indeed make it work. I'll do some more tests with that. Then work out a patch for the debian package
<infinity> Oh, and the table would be "when glibc got support for the arch" not "what your distro set baseline to", so still a lie.
<suihkulokki> certainly maintaining a distro-spefic hack is much better :P
<wookey> suihkulokki: I've done a debian qemu package from the current 1.7.50 git
<infinity> suihkulokki: In this case, the distro hack is much simpler, to be fair.
<wookey> am I right in thinking that the stuff taken out for +dfsg is just in pc-bios dir, or is there more?
<infinity> wookey: Just take my patch I pasted.  It's the path of least resistance here, unless you really want to introduce that table that's a lie anyway.
<wookey> OK. unless the qemu people complain that's fine by me.
<wookey> (riku and vagrant in this case i think)
<wookey> infinity: are you up early or late?
<infinity> wookey: Late.  Very late.
<wookey> :-)
<wookey> handy for me
<infinity> wookey: Pretty sure the qemu people are more likely to complain about you asking for a git snapshot. :P
<infinity> wookey: (hallyn's already backported the arm64 stuff to 1.7.0 in Ubuntu and, AFAIK, it works)
<wookey> the suse arm64 stuff or the linaro aarch64 (spit) stuff?
<infinity> wookey: The upstream stuff.
<wookey> That was announced yesterday?
<wookey> I could have saved myself some effort if so
<infinity> wookey: It got pulled in as soon as it landed in git, not when it was announced.  There may be a few fixes to pull in on top of our current stuff, but I doubt there's much.
<infinity> (Literally as soon as... dannf had a script running that kept doing a git pull, compile test, and runtime tests to see if it worked yet :P)
<infinity> He was a bit impatient.
<wookey> OK. any chance of some upstreaming to debian?
<dannf> wookey: the changes are in a branch of the debian package on alioth (http://anonscm.debian.org/gitweb/?p=pkg-qemu/qemu.git;a=shortlog;h=refs/heads/ubuntu-trusty)
<dannf> wookey: assuming the qem team is cool with taking in such changes, should be a relatively simple cherry pick
<wookey> dannf: OK. cheers. Adding adam's patch seems to have broken my build for some mysterious reason:-(
<wookey> how uptodate are you with the 1.7 master branch?
<dannf> infinity: : oh, is this the control file arch cleanup you were talking about?
<dannf> wookey: i'm not sure, i just handed hallyn debdiffs. but, i suspect the aarch64 stuff will apply cleanly patchwise - assuming debian takes the kvm stuff as well (basically ubuntu's whole aarch64 patch set)
<dannf> wookey: i can prep a github branch if you like
<infinity> dannf: I was just talking about a 2-line patch to fix the minimum uname version.
<infinity> But yes, we should look at getting all the aarch64 stuff pulled into Debian sanely.
<dannf> oh, right
<infinity> And update our patchset if there's new stuff we care about.
<dannf> i see nothing new target-arm wise
<wookey> yesterday seemed to be the point that ajb thought it was 'ready'
<wookey> http://lists.linaro.org/pipermail/linaro-dev/2014-February/016980.html
 * dannf wonders when qemu will cut a new upstream - upstream qemu git is difficult to track for cherry picks - or i need some better git fu
<wookey> I didn't want to do backporting to 1.7.0 from 1.7.50 as I know nothing.
<wookey> arm64 was targetted for 1.8 in 'spring'
<wookey> so if we test this and find it basiically works then I hope a new release is imminent
<wookey> which is why I was interested to package and test it
 * dannf suspects ubuntu virtualized ppas will be a good testbed
<infinity> dannf: Yeah, though it would be worth checking if the branches referenced in that email contain more fixes on top of what you pulled in for hallyn.
<dannf> infinity: well, it looks like he's saying master shoudl be enough (and i'm in sync there)
<wookey> bummer that they did s/arm64/aarch64/ but you can;t have everything in life
<infinity> * Additional NEON/SIMD instructions
<infinity> * sendmsg syscall
<dannf> infinity: he has some other patches - but i've no way of saying how likely they'd be needed
<infinity> Those are the bits in his tree but not master.
<infinity> Emulating more syscalls can't ever be bad.
<infinity> And more insns.
<wookey> right. I hit quite a lot of missing insns with the older suse code
<dannf> yeah, i was getting a lot w/ upstream until the merge last week w/ the neon/simd instructions fixed
<dannf> but my test case has just been "debootstrap"
<infinity> Try to build qt4-x11 and get back to me. :)
<wookey> gah. after adding the uname patch my build just stops with make: *** [build-stamp] Error 2 but no actual error.
<wookey> and I haven't run out of disk space...
<infinity> That's... Odd.
<wookey> grumble.
<infinity> And seemingly impossible.
<infinity> Did you debdiff old and new sources to make sure that's really all you changed? :P
<wookey> sigh.
<wookey> not yet. I shall go get coffee and gird loins.
<wookey> computers are fucking painful. You just want totest something and on no, random wierdness sens you off for extra faffage
<infinity> wookey: Time for a career shift?
<ogra_> go into management !
<wookey> ha ha people are worse than computers :-)
<ogra_> :)
<wookey> I have always fancied doing some rope access work by way of variety. Pays well too.
<wookey> OK. a non-parallel build gets me an actual whinge
#ubuntu-arm 2014-02-19
<suihkulokki> wookey, actually, aarch64 uname version should be just fine if you use the upstream release
<suihkulokki> s/release/head/
<suihkulokki> infinity: I just checked what it would require to do the hack properly, and as far as I see it already has been done :P
<wookey> suihkulokki: I was using the 'master' branch that ajb pointed me at. that is upstream isn;t it?
<wookey> unless that fix has been added in last couple of days
<suihkulokki> wookey: it's been there for a while - I guess you used debian packaging?
<suihkulokki> wookey: if so.. just remove the --enable-uname-release since that will override the default in the code
<wookey> suihkulokki: I put upstream source into debian packaging
<wookey> I'll rebuild without the patch and that config option.
<wookey> But there is something else wrong anyway. (it works outside a chroot but not inside - tying to track down the issue)
<infinity> suihkulokki: Really?  As of when?
<suihkulokki> infinity, as of when aarch64s support was merged
<suihkulokki> infinity: but you are breaking it with the configure override
<infinity> suihkulokki: Right, my hack is specifically to override the override. :P
<infinity> suihkulokki: Since we build all flavours at once, and we want most at 2.6.32.
<suihkulokki> infinity: no you don't want
<infinity> As a matter of fact, I do.
<suihkulokki> trust me, you don't :)
<infinity> qemu-user has this braindead notion that without that configure flag, it should just bubble up the underlying uname, which is actually a completely useless lie.
<infinity> Given that qemu-user is a syscall *emulator*, not a syscall *passthrough*, the underlying kernel isn't what's important at all, it's what interfaces qemu-user provides that are important.
<infinity> I consider it a fundamental flaw that it doesn't actually just define itself what interfaces it claims to support and give you that for uname, but it doesn't.  And falling back to telling me my qemu-use-arm (for instance) is "2.6.24" just cause my host system seems to be that isn't helpful in the least.
<infinity> Hence why we use the configure override, which is also a lie, but at least one that's easier to live with, since glibc won't *run* on a kernel that claims to be older than that.
<suihkulokki> yep, and with that flag, you are telling guest binaries never to use any syscall that is newer than 2.6.24
<infinity> 2.6.32, you mean.
<suihkulokki> whatever you are passing
<infinity> And yes, that's intentional.  Just as we pass the same thing to glibc builds.
<suihkulokki> now, if you actually look at what we did for qemu
<infinity> The idea being that it all should run fine on chroots on lucid/squeeze/rhel6.
<suihkulokki> i know
<suihkulokki> but you are not listening to me
<infinity> Anyhow, let me put this another way.  We *need* that configure override on Ubuntu virt PPAs.  If Debian doesn't need or require it, that's fine, but the Ubuntu usage of it can't go away.
<suihkulokki> the new qemu has it done properly
<infinity> Because letting qemu tell my userspace that it's 2.6.24 because it's running on a hardy Xen kernel is *wrong*.
<suihkulokki> you used to need the configure flag previously
<infinity> If the new qemu actually does what I said should be done (tells me what it *supports*, not what it's running on), that would solve my issue, for sure.
<infinity> But by "new qemu", I assume you mean git mainline, not 1.7.0.
<infinity> That's really the only sane way to do it, so I'm happy to hope they have. :P
<infinity> Cause the inverse problem is equally wrong.  Running on a 3.13 kernel shouldn't tell me that I'm using 3.13, if qemu-user-$arch has only implemented syscalls up to 3.6, for instance.
#ubuntu-arm 2014-02-20
<wookey> suihkulokki: I can confirm you are right that missing out the --enable-uname-release in configure makes the patch for upping the reported uname version aarch64 unnecessary
<wookey> so. If I have a saucy (arm64) system that appears to boot OK but never shows me a login prompt, what do I poke? If it was sysvinit/debian I'd look in inittab and /dev and etc/securetty
<wookey> but upstart is highly myseterious to me
<wookey> there is an /etc/init/tty1.conf that looks like what used to be in inittab
<wookey> (I can boot with /bin/sh OK, or /sbin/init --verbose and watch lots of stuff go by)
<wookey> there is no initramfs, because klibc was not ready in saucy) That may be part of the problem?
<xnox> wookey: where do you expect the login prompt to appear and did you pass the right console= on the kernel cmdline?
<wookey> xnox: I get console output from upstart during boot
<wookey> (console is set to AMA0 IIRC)
<xnox> wookey: so. it doesn't mean that that's where tty1 will be spawned.
<wookey> ttyAMA0
<wookey> and since putting the right earlyprintk rune in I get kernel output:
<wookey> earlyprintk=pl011,0x1c090000
<wookey> so I just tried running "exec /sbin/getty -8 38400 tty1" manually and I see nothing
<wookey> so I guess tty1 is going to the wrong place
<wookey> what decides where tty1 ends up?
<wookey> should I just change /etc/init/tty1.conf to specify ttyAMA0?
<xnox> wookey: is ttyAMA0 a serial console?
<xnox> wookey: https://help.ubuntu.com/community/SerialConsoleHowto
<wookey> yes (but in a model)
<xnox> wookey: yeah, then you need to add a job to spawn getty there.
<xnox> wookey: or try passing console=/dev/ttyAMA0 on kernel cmdline.
<wookey> aha. that's what I needed to know. This even seems horribly familiar frmo about a year ago....
<wookey> :-)
 * wookey feels a bit dense
<wookey> xnox: wahey. I have console. does a debootstrapped saucy have a default login?
<wookey> root:root and ubuntu:ubuntu didn;t get me in
<xnox> wookey: nope, no logins on default debootstrapps.
<infinity> wookey: FWIW, apw's ubuntu-core-to-foundation model conversion script will (a) do the job for you, or (b) be some nice hints about things you'd want to do if you were doing it yourself.
<infinity> wookey: http://people.canonical.com/~apw/arm64/arm64-prepare-image
<infinity> wookey: (Linked from https://wiki.ubuntu.com/ARM64/FoundationModel ... I don't just memorize weird paths on people.c.c)
<wookey> ah yes that looks like all the stuff I did to make it work
#ubuntu-arm 2014-02-22
<return0> What's the cheapest laptop/tablet that can run Ubuntu? I pretty much just want something for typing and reading.
#ubuntu-arm 2014-02-23
<thinkstu> I'm trying to have ubuntu to beaglboard, every time I have the image in the SD card and reboot - the Beaglboard-Black got all leds on and hanged
<thinkstu> any idea ?
<wookey> so /win 25
#ubuntu-arm 2015-02-18
<ogra_> suihkulokki, do you happen to know if http://git.qemu.org/?p=qemu.git;a=commitdiff;h=480eda2eda7c464e252f17ac87ec61bccc14f285 made it into any debian/ubuntu package yet ?
<suihkulokki> ogra_: I think that should be in 2.1 already
<ogra_> ok, trying
<ogra_> /tmp/npm.1417/package/lib/config/defaults.js:328
<ogra_>   Object.keys(os.networkInterfaces()).map(function (nic) {
<ogra_>                  ^
<ogra_> Error: EAFNOSUPPORT, address family not supported
<ogra_> *sniff*
<ogra_> doesnt look like it helps
<ogra_> ogra@anubis:~/datengrab/webrtc/builder$ qemu-arm-static -version
<ogra_> qemu-arm version 2.2.0 (Debian 1:2.2+dfsg-5expubuntu5), Copyright (c) 2003-2008 Fabrice Bellard
#ubuntu-arm 2015-02-19
<HazeAI> Hello folks, I've been using Ubuntu 14.04 on a bunch of beagle bone blacks at my workplace and I've been having a problem with them that I'm wondering if anyone here might be able to help me with
<HazeAI> I keep the software that I wrote to run on them in a git repository, each beagle has a clone on it, and a cron pulls them every 5 minutes to keep them up to date
<HazeAI> When I pull power without shutting them down first, they have about a 50-70% chance of corrupting the contents of the git repository so I have to remote in and re-clone it and patch things up
<HazeAI> Everything else seems fine, but the contents of my git repo are all 0 byte files
<HazeAI> I understand that powering down correctly would be best practice, but it seems odd that such a specific set of files are so likely to be corrupted when I pull power
<HazeAI> Has anyone else experienced anything similar?
<rbasak> Not experienced that, but I'm curious. What filesystem are you using?
<rbasak> Also, have you tried a different SD card manufacturer? AIUI, much hardware lies about when they've really committed data.
<infinity> HazeAI: A quick hack might be to throw a "sync && sync" at the end of your git pull cron job.
<rbasak> And what SD card manufacturer are you using right now?
<HazeAI> I have Ubuntu flashed to the eMMC - No SD card in use
<ogra_> well, forcing the sync is your best option then
<HazeAI> Thanks for the suggestion infinity - I'll test out adding "sync && sync" to my git pull cron
<rcn-ee> HazeAI, do you also have it mounted as "noatime" ?
<HazeAI> Apologies rcn-ee, I'm not sure what you mean. It's mounted to /dev/mmcblk0p2, is there a command I could run to check what you are looking for?
<HazeAI> And for adding sync && sync to my cron, do you mean: sync && git -C /usr/local/bin/marshal pull && sync
<HazeAI> or : git -C /usr/local/bin/marshal pull && sync && sync
<ogra_> mount|grep noatime
<HazeAI> looks like yes: '/dev/mmcblk0p2 on / type ext4 (rw,noatime,errors=remount-ro)'
<rcn-ee> any chance can you change your procedure from yanking power to pushing the "power button"?
<infinity> HazeAI: The latter.
<infinity> HazeAI: Not that a forced sync will help you if you pull the plug during the sync or during the git pull, but it minimizes the window for data being in flight.
<infinity> (It'll also grind the machine to a halt while it's doing it, if there's a lot to sync)
<HazeAI> Great! Yeah, I am definitely training users to actually press the power button but I can't control folks 100% of the time, so I'm just trying to get the rate of occurrence down to something manageable
<HazeAI> I initially told people the risk of pulling power would be negligible (ugh, my own fault), and I've been trying to find the cause of these random corruptions for a good month now
<HazeAI> Didn't realize what it was until I flashed a fresh batch, then went back to test them, and most of their git repos were corrupted
<HazeAI> Fantastic, that seemed to do the trick. I've pulled the plug 5 times in a row now with no corruption. Thanks for your help infinity, ogra, and rcn-ee!
<ogra_> mostly infinity ... :)
<ogra_> since he doesnt have anything to do today :)
<infinity> *cough*
#ubuntu-arm 2016-02-24
<tinyhippo> if I want to recompile and repackage an existing .deb for ARM, whats the best way of going about it?
#ubuntu-arm 2016-02-25
<flexiondotorg_> Are the arm64 binaries in the Ubuntu archive aarch64?
<rbasak> Yes, they're the same. The Debian architecture name for aarch64 is arm64.
<flexiondotorg_> I'm guessing they are ARMv8-A architecture?
<rbasak> Excluding other toolchain differences of course.
<flexiondotorg_> rbasak, Thanks.
#ubuntu-arm 2016-02-26
<_Sponge> Morning. How do I run Unity 8 on an arm device ?
<ogra_> you need a properly working EGL setup
<ogra_> (to run Mir)
#ubuntu-arm 2017-02-21
<linggao> Hi all,  has anyone tried to using the on-board wifi with Ubuntu 16.04 on a RPi3 device?
#ubuntu-arm 2017-02-22
<pvl1> is there a standard for like, repo structure
<pvl1> the pcduino repo isnt functioning for me
#ubuntu-arm 2017-02-23
<nameee> Anyone here ?
#ubuntu-arm 2018-02-19
<Seshu_> I have one ARM v8 board. Any advice on how to bring up the board with ubuntu?
<BenG83> what SoC?
<Seshu_> RealTek.
#ubuntu-arm 2018-02-23
<USFGXHcelie> _  _     _  _   _ _
<USFGXHcelie> _| || |_ _| || |_| | |
<USFGXHcelie> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
<USFGXHcelie> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
<USFGXHcelie> |_  __  _|_  __  _| | | (_| | | | | | | (_| \__ \
<USFGXHcelie> |_||_|   |_||_| |_|_|\__,_|_| |_| |_|\__,_|___/
<USFGXHcelie> el recommends ##llamas over ##feminism
<USFGXHcelie> k1l AceLan ikepanhc pekkari niska ubot9 BenG83 Freejack wgrant rsalveti dragan-s lool zzarr Guest54607 nslu2-log ptl_ zumbi rexxster ubuntulog ColdKeyboard yofel chihchun funnel PaulePanter ogra_ micahg nashpa chrisccoulson flexiondotorg ChunkzZ Gerghih steev awafaa guerby dannf popey lvrp16 alai manjo rbasak mariogrip robher tlbr_ NCommander mrutland doko y0sh Jack87 fabo moon127 Alesk13
#ubuntu-arm 2018-02-24
<CocoaGeek> hello, I'm trying to cross-compile a project to armhf, but I need libssl-dev (I'm on x64), but while I can see the package on launchpad, I can't get apt-get (on the host) to find it. Any suggestion?
<k1l> what ubuntu is that?
<CocoaGeek> k1l: 16.04
<k1l> apt policy libssl-dev
<k1l> doesnt show it?
<CocoaGeek> it does, but only amd64
<CocoaGeek> I was able to install the i386 version of the package
<k1l> so what you need now?
<CocoaGeek> the armhf one
<k1l> why you need the armhf one?
<CocoaGeek> to cross-compile for armhf
<CocoaGeek> i guess i'll just cross-compile libssl
