[00:45] <steev_> so, running into an... interesting issue with ubuntu-core, on an efika, i am installing, and really not doing much special, but, i'm doing it in a chroot, so i have the policy-rc.d file, but, upon reboot, once going through oem-config, when you login as the user created, it throws up 2 system errors, and it seems to be man-db and ubuntu-extras-keyring need to be re-installed.  is there a way to do
[00:45] <steev_>  that before oem-config is run?
[02:43] <infinity> steev_: I don't see how having a policy-rc.d in place would prevent man-db and ubuntu-extras-keyring from installing correctly.
[02:44] <infinity> steev_: What are the actual errors?
[02:45] <steev_> infinity: one sec, i'm about to reboot on a new install again
[02:50] <steev_> infinity: ugh, for some reason it only happens *after* oem-config is run.  and i'm trying to get all the different packages i want in order, before i set it to run oem-config.  i'll do more research, but i definitely remember it complaining about man-db and ubuntu-extras-keyring, but when i told it to report the issue, it complained about some log being empty.  Next time I will pay more attention
[02:50] <steev_> (i haven't slept since friday night)
[02:51] <infinity> Your man-db issue could just be that you need to manually run /etc/cron.daily/man-db (or wait for the cronjob to trigger later), but without seeing the error you're talking about, I don't know.
[02:52] <infinity> If you mean that either of them is complaining about actually not being installed correctly period, that's a packaging bug, and not something you should be working around in installers.
[02:52] <infinity> But, yeah.  Seeing the errors would be helpful.  Filing bugs, too.
[02:52] <steev_> like i said, i hit the button to report issue, it complained about some log file being empty, next time i see it, i'll take a screenshot just to be safe
[02:53] <steev_> for the moment though, i'm going to say this one is cooked, and prep it so i can mass install ;)
[07:31] <micahg> janimo`: I'll be uploading chromium in a couple hours, it would be nice to enable armhf properly :)
[08:18] <janimo`> micahg, well I do not have a proper patch, just handedited the files in question
[08:18] <micahg> janimo`: can you diff them for me against what's in precise?
[08:19] <janimo`> micahg, ok. I was not sure if a sed call in rules would be ok or a more elegant way that intriduces new variables in gyp
[08:19] <micahg> janimo`: we usually just patch the files ;)
[08:20] <janimo`> micahg, I am not sure if it was chromium (maybe thunderbird) that made me not want to work with it much. IIRC it did not work with edit-patch but some custom quilt paths and runes that were not documented
[08:21] <micahg> janimo`: yes, you need to be in build-tree/src for chromium
[08:22]  * micahg would love to switch to straight source format 3 and dh7, but that would require time :)
[08:25] <janimo`> micahg, that would be awesome. It would be time gained in the long run
[08:32] <janimo`> micahg, what rule does only the unpacking for chromium?
[08:32]  * janimo` tries to come up with a cleanish patch
[08:33] <micahg> janimo`: debian/rules patch I think
[08:35] <janimo`> Laney, around?
[08:35] <micahg> oh, did you fix ghc?
[08:36] <janimo`> micahg, yes
[08:36] <janimo`> but just like chromium. Fixed the build, have no idea what the 'proper' upstream patch should be
[08:36] <janimo`> could be a sed in debian/rules if armhf, of some haskell code + config stuff in another unusual build system
[08:37] <janimo`> s/of/or/
[08:37] <janimo`> I think it needs a normal patch though, upstream assumes softpf and has no config for armhf at all
[08:43] <Laney> janimo`: nice work! Can you show me the patch? I'll show the ghcarm people what was needed and they should be able to take it from there
[08:43] <janimo`> Laney, just filed a bug in ghc trac. A moment
[08:43] <Laney> oh ok, nice
[08:43] <janimo`> http://hackage.haskell.org/trac/ghc/ticket/5914
[08:44] <Laney> are you uploading to ubuntu?
[08:44]  * janimo` praises his habit of using a simple identical password almost everuwhere, so wehn visiting sites every couple years he does not have to scratch his head.
[08:44]  * janimo` oopses
[08:45] <janimo`> Laney, no, it is a hack, I;ll leave the proper patch to people who know how to integrate with the ghc build system and make it conditional
[08:46] <janimo`> Laney, I could not figure out from a few minutes of using the code whether all options need to be hardcoded in haskell or can be driven exclusively from some human readable file, like settings in the root dir
[08:46] <janimo`> as this option only needs passinf fo armhf
[08:46] <Laney> there is mk/build.mk but I am not sure exactly which options it takes
[08:47] <janimo`> Laney, another approach would be making llvm/llc default to hard float when invoked on a hard-float system, like gcc does .Not sure if that is ok with llvm people whough
[08:48] <janimo`> Laney, so if you could point this to arm/ghc people they may fix it properly
[08:48] <Laney> ok, thanks for the work!
[08:48] <janimo`> Laney, you're welcome
[08:57] <janimo`> micahg, can you help me with the patching of chromium. Finally untarred a sample package. cd build-tree/src
[08:57] <micahg> quilt push -a
[08:58] <janimo`> ok
[08:58] <micahg> quilt new fix-armhf-gyp.patch
[08:59] <janimo`> ok
[09:05] <janimo`> micahg, will attach the patch shortly
[09:05] <micahg> janimo`: thanks
[09:08] <janimo`> micahg, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/943281 fingers crossed. With restarted package builds and not knowing how and what exactly the build system regenenerates and which bits of config drive what this is a best effor tpatch :)
[09:08] <ubot2`> Launchpad bug 943281 in chromium-browser "armhf FTBFS in precise" [High,In progress]
[09:08] <micahg> janimo`: thanks
[09:09] <micahg> will look at it in a few minutes
[09:09] <janimo`> micahg, thanks
[09:09] <janimo`> at least the gyp bits i am fairly confident should work. The v8 one, may or may not
[09:10] <janimo`> I hope the TODO item - 'migrate to external v8 lib ' is not too unrealistic :)
[09:10] <micahg> we won't do that as chromium will move too fast in the stable release
[09:12] <janimo`> TODO: remove v8 entry from TODO file :)
[09:15] <micahg> janimo`: heh, anyways, patch looks sane and won't break armel builds, I'll upload shortly
[09:45] <micahg> janimo`: maybe that's why it works in Debian, they use the system v8
[09:48] <micahg> janimo`: well, we should find out in ~1hr if it worked or not, I'm about to upload
[10:23] <sveinse> Hi. I'm having some troubles with a custom natty armel installation (on custom HW). One particular device isn't booting properly, while others are. I'm debugging upstart and it seems it locks up in mountall, i.e. it doesn't emit the correct signals for upstart to continue into runlevel/rc-sysv modes.
[10:24] <sveinse> Mountall --verbose show that is indeed stops in mountall, but no errors on the console. How can I debug this? Any ideas?
[10:28] <ogra_> sounds like a kernel issue to me
[10:34] <micahg> janimo`: armhf seems happy, it's building
[10:48] <sveinse> ogra_: The device had an old HW clock setting. So from what I can see mountall (not fsck) halt if the HW clock is older than the superblock of the fs. If I set the hwclock to newer, it works. Is this expected or a bug?
[10:48] <ogra_> well, if you use an ubuntu initramfs you can easily work around this by using the ficrtc cmdline option
[10:49] <ogra_> it will force the RTC to the past mount time of the disk
[10:49] <sveinse> a kernel parameter?
[10:49] <janimo`> micahg, I still suspect it may fail later on when it tries to link v8 against it all. So in case it does not figure out what the eabi should be another bit in debian/rules may be in order
[10:50] <sveinse> fixrtc I suppose
[10:51] <ogra_> yeah
[10:51] <ogra_> (to both)
[10:53] <janimo`> micahg, amended the bug with a comment in case it fails because of V8 being built without HF
[10:53] <micahg> janimo`: well, the v8 parts compiled, we'll see if it links later
[10:54] <janimo`> ok.
[10:54] <sveinse> ogra_: It works. Thank you very much!
[10:55] <janimo`> ah qtwebkit-source keeps being ftbfs. But that looks nastier as if it was a kernel/glibc/toolchain issue
[11:51] <Laney> janimo`: "VFPv3D16" does not imply armhf?
[11:51] <janimo`> Laney, not necessarily afaik. We had that for armel as well
[11:51] <janimo`> it means use a certain set of VFP registers
[11:52] <janimo`> but even in softfp you could use those as long as they do not cross proc call boundaries
[11:52] <janimo`> so not part of the ABI
[11:52] <janimo`> so we only want to use registers D0-D15 and not D16-D31 as found on some chips.
[11:53] <janimo`> so generate code for that VFP config for both armel and amrhf. For armhf use said regs also for passing arguments and return values between calls
[11:55] <janimo`> Laney, we've been passing -mfpu=vfp3-d16 for a while in Ubuntu for armel
[11:56] <Laney> okey dokey, just thinking how ghc could tell if armhf or not
[11:57] <janimo`> Laney, if it has the equivalent of autogen, it may discover it by seeing gnueabihf in the triplet instead of plain gnueabi
[11:57] <janimo`> if not, it may be good enough to just pass a config option from debian/rules
[12:00] <janimo`> would be nice to be able to drive some options outside haskell code. I see settings.in but am not sure it has sections for passing options to LLVM, as it has for gcc
[12:01] <xranby> Laney:   you can use  #ifdef __ARM_PCS_VFP
[12:01] <xranby> to check for hard-float calling convention
[12:09] <janimo`> xranby, not in haskell code I assume
[12:10] <xranby> maybe.. depends on if you pass the haskell code through the gcc preprocessor or not
[12:10] <janimo`> xranby, there is a preproc step, not sure if it is gcc's
[12:14] <Laney> you can ask it to AFAIK
[12:14] <xranby> some parts of GHC are written in c.. if the arch version detection are done in c code then you can use it
[12:44] <micahg> janimo`: yep, you called it, linking with v8 broke :)
[12:46] <janimo`> micahg, ok, so the snippet I appended to the bug should help
[12:46] <janimo`> or maybe not , this build system is crazy. I know I got it working by setting that variable to 1 in the sconscript
[12:47] <janimo`> if you know that debian/rules can actually pass that v8_armeabi var reliably to SConscript it would be helpful
[12:47] <micahg> janimo`: that I don't know Scons is pretty greek to me
[12:48] <micahg> but, if there's a gyp flag, that's likely to work
[12:49] <janimo`> the script itself is legible, but wherever it is hooked in with gyp and the rest is a mistery to me
[12:50] <micahg> janimo`: so, I'll drop your scons change and use the gyp flag, how does that sound?
[12:50] <janimo`> sure
[12:51] <micahg> janimo`: is this worth doing now, or should I wait for the next stable update?
[12:51] <janimo`> although that SCons thing looks suspicious. Why there's no EABI setting like in the other cases simialr in that file - all come in threes soft/softpf/hard in 2 places, buit this one where only soft is specified
[12:51] <janimo`> micahg, next stable
[12:51] <micahg> ok, thanks
[12:51] <janimo`> progress has been made with this release too :)
[12:52] <micahg> yes, indeed :)
[12:52] <janimo`> is next stable in 6 weeks? Or do you have intermediate uploads too sometimes?
[12:52] <janimo`> either way, next upload, wherever it is
[12:52] <micahg> yeah, there are intermediate uploads whenever chromium feels like releasing it's cache of CVE fixes
[12:52] <janimo`> I'll actually do a test run these days, let it build to have a tested fix
[12:52] <micahg> s/it's/its
[12:52] <janimo`> soon, until I do not forget how to quilt patch the tree
[12:53]  * micahg will start using the word attempt with fixing armhf FTBFS :)
[12:53] <janimo`> exaclty - I have been cautious enough to use attempt in many changelogs and bug comments so far :)
[12:54] <janimo`> or the more optimistic - making the build progress
[14:18] <sveinse>  /etc/init/ttyS*.conf is set to start on stopped rc, which is rather late in the boot process, which can prevent login if booting fails. Would there be any problems starting getty very early, like on startup (upstart event)?
[14:19] <sveinse> I did this for debugging, and it seems ok. Of cource you are warned of ro rootfs, but that's fine as long as you get a login. Now I'm wondering if we should ship this config permanently
[14:26] <sveinse> Where does the logs from e2fsck run by mountall end up on a natty system?
[14:53] <int_ua> Is it possible to install deb package for armel that depends on other armel packages on armhf system?
[14:53] <int_ua> I tried dpkg -i --foreign-architecture armel but it still complains about missing package despite it's installed
[15:00] <Riddell> GrueMaster, ogra_: oneiric armel images boot fine on my panda board, precise armhf images do not
[15:00] <ogra_> oh ? intresting
[15:00] <ogra_> whats the error ?
[15:00] <Riddell> is that something in the pandaboard hardware that can't do armhf, or is it my low power I've giving the board?
[15:01] <Riddell> ogra_: green LED is the error
[15:01] <ogra_> i mean on your serial console :)
[15:01] <Riddell> I don't have a serial console
[15:02] <ogra_> for development it really helps to have one
[15:02] <Riddell> ogra_: what do I need to buy?
[15:03] <ogra_> an usb to serial adapter, try to get one you can attch directly to the pandas serial connector (female i think)
[15:15] <smplman> is their any way to CC entire deb packages then transfer the binaries to the host machine?
[15:19] <smplman> target, sry
[15:23] <infinity> smplman: Define "cc entire deb packages".
[15:24] <infinity> smplman: If you mean "attempt to reconstruct it based on what's currently on the filesystem", you want dpkg-repack.  But there's no guarantee that's going to give you a sane package.
[15:24] <infinity> smplman: Usually, you just want to install the same deb everywhere, and then customise your configs accordingly.
[15:25] <smplman> say i want to install the nano.dpkg on my arm system, but i want to cross compile if first on my x86 system so its faster
[15:25] <smplman> then transfer the binary over
[15:26] <smplman> i realize packages are usually platform independent, but i think its probably faster to cc my packages then transfer them over
[15:26] <smplman> if this is crazy talk just let me know
[15:26] <smplman> i know how to CC normal source, then transfer the binary
[15:27] <smplman> im more concerned with ubuntu packaged now
[15:27] <smplman> i meant *.deb earlier not *.dpkg
[15:29] <smplman> infinity: if that makes sense
[15:30] <infinity> smplman: I'm still lost by what you mean by "CC the package".
[15:30] <infinity> Unless you mean compile?
[15:30] <infinity> And packages are most certainly not platform independant.
[15:35] <smplman> cross compile the package on my x86 machine then transfer it to my arm machine
[15:35] <infinity> Yeah, it's sometimes doable.  But not often.  And we're still working on making it work better.
[15:36] <smplman> Anything documented yet?
[15:36] <infinity> You're really just better off building the package natively, unless you're ready to do a lot of reading on dpkg-cross and the like (and prepared to curse a lot when your use-case fails).
[15:36] <infinity> Well, all the dpkg-cross stuff is documented.  But also in the process of being deprecated for better and shinier methods.
[15:36] <smplman> its for personal dev so not that big a deal
[15:37] <infinity> I really do just recommend building natively for most people.
[15:37] <smplman> i have 11.10 running on both my xoom and beagleboard xm
[15:37] <infinity> The special case to that rule being people who build a lot of kernels, since that's all set up to "just work" with a cross-compiler installed.
[15:37] <smplman> yea im good with building kernels
[15:37] <smplman> it just takes forever to install packages on my xm
[15:38] <infinity> For most other packages, the odds of it working, and the odds of you wanting to throw things are high enough that building natively is just easier.
[15:38] <smplman> or just build from source vs using the .deb?
[15:39] <infinity> I don't see how that changes anything...
[15:39] <infinity> Wait.  Are you talking specifically about dpkg itself taking a long time?
[15:39] <infinity> There's zero ways around that.
[15:39] <infinity> I thought you meant building the deb on another system, then copying it over and installing it.
[15:40] <infinity> There's no sane way to avoid the part where you invoke dpkg.
[15:58] <int_ua> ogra_: You've mentioned ficrtc boot option earlier today. But I can't find docs about it. Was it some typo?
[16:01] <GrueMaster> int_ua: It is fixrtc, a simple shell script that is part of initramfs-tools.
[16:03] <int_ua> GrueMaster: Thanks
[16:19] <brendand> are the sudden switch offs i'm seeing on the pandaboard with this weekends daily expected?
[16:23] <tvoss> Hi all, is it possible to run the 12.04 omap4 image under qemu?
[16:23] <ogra_> no
[16:24] <tvoss> ogra_, is there any image that I can run under qemu?
[16:24] <ogra_> the omap3 image might run in the beagle emu
[16:24] <ogra_> qemu simply has no emu for omap4 at all
[16:27] <tvoss> thanks ... are imx images supposed to be running in qemu then?
[16:27] <ogra_> no
[16:27] <ogra_> there is no qemu emulation for any of the images we have apart from omap3
[16:27] <brendand> tvoss, qemu is not a platform as such
[16:28] <ogra_> you can roll something yourself based on the vexpress kernel and a self rolled rootfs (or ubuntu-core)
[16:29] <GrueMaster> ppisati: ping - not sure if you noticed, but I figured out why I didn't have sound & networking on the beaglexm.
[16:30] <ppisati> GrueMaster: network works here
[16:30] <ppisati> GrueMaster: dunno about audio
[16:30] <ppisati> GrueMaster: on the othert hand, while updating this morning i noticed latest kernel hangs before mounting root
[16:30] <ppisati> GrueMaster: did you try it?
[16:30] <ppisati> 3.2.0-18.28
[16:31] <GrueMaster> I have had spotty network at best.  I usually have to unplug, plug in the network cable several times to get it working.
[16:31] <ppisati> GrueMaster: works immediately here
[16:31] <ppisati> rev c and rev a
[16:31] <GrueMaster> I am just waking up.  Haven't even really started anything yet.
[16:31] <ppisati> k
[16:31] <ppisati> GrueMaster: when you are caffeinated enought, tell me which kerbnel version were you running
[16:31] <GrueMaster> I have a rev b beaglexm.  It has had these issues for 2 cycles now.
[16:32] <ppisati> 3.2?
[16:32] <GrueMaster> I documented everything in bug 925094 and bug 838200.
[16:32] <ubot2`> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
[16:32] <ubot2`> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
[16:32] <GrueMaster> 3.2.0.18 iirc.  I pulled from git.
[16:33] <ppisati> latest one is 3.2.0-18.28
[16:33] <ppisati> but it seems it's broken
[16:33] <ppisati> previous one -17.27 should be ok
[16:39] <GrueMaster> Well, it worked in my build of it.  Must be a patch since Friday?
[16:45] <ppisati> GrueMaster: i'm booting off the sd FWIW
[16:45] <GrueMaster> Same here.  I just added my kernel to the Beta 1 image.
[16:46] <smplman> GrueMaster: im running 3.2.9 from https://github.com/RobertCNelson/stable-kernel , good results
[16:46] <smplman> on my xm rev b ATM
[16:47] <GrueMaster> smplman: We are using the mainline kernel, not a hacked up version.  We really want to be as close to main as possible.  Eventually, the omap4 kernel will also be done this way.
[16:48] <ogra_> you wish :)
[16:48] <GrueMaster> I am well aware of other working kernels.  The test image that ships with the XM works perfectly, but not all of it is upstream.
[16:48] <GrueMaster> ogra_: well, I did say eventually.
[16:48] <smplman> GrueMaster: I understand, just trying to help
[16:48] <ogra_> yeah, it will take years until the DSS code goes upstream
[16:48] <hrw> janimo, ogra: can you endorse me on my motu application? https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplication-MOTU
[16:58] <Riddell> ogra_, GrueMaster: ok here is loading with oneiric successfully and with precise unsuccessfully http://starsky.19inch.net/~jr/tmp/arm/
[16:58] <Riddell> there's not much in the diff
[16:59] <Riddell> could it be just not showing on the monitor in precise?
[16:59] <Riddell> I have a full power supply now
[17:00] <ogra_> looks like the bootloader runs fine
[17:00] <smplman> Riddell: omapfb missing maby?
[17:00] <Riddell> smplman: I have no idea what that is
[17:01] <ogra_> smplman, thats compiled in
[17:01] <ogra_> Riddell, it would help to get the kernel bootmessages (which we supress by default)
[17:01] <Riddell> ogra_: how can I do that?
[17:02] <ogra_> Riddell, open the boot.scr from the first partition of the SD card in vi
[17:02] <ogra_> delete the garbage (u-boot header) in the beginning
[17:02] <ogra_> then edit the cmdline in that file and save it as boot.script
[17:02] <smplman> Riddell: what image are you using?
[17:03] <Riddell> smplman: ubuntu desktop precise beta 1
[17:03] <Riddell> omap4
[17:03] <GrueMaster> ppisati: I am uploading my kernel .deb to http://people.canonical.com:~tobin/linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb for you to try.  Should be available in ~12 minutes.
[17:03] <ogra_> Riddell, you will then need to install u-boot-tools to get the mkimage command
[17:04] <smplman> is omap4 backwards compatible with omap3?
[17:04] <GrueMaster> Actually, save it back as Env.txt and reboot.  Newer u-boot should be able to take it from there.
[17:04] <GrueMaster> ogra_: Riddell ^^^
[17:05] <ogra_> oh, i didnt know we got that bit from zupstream working nowadays
[17:05] <ogra_> smplman, no
[17:05] <ogra_> different arches
[17:05] <Riddell> ogra_: the whole of the first line is garbage?
[17:06] <smplman> i know the xm is omap3
[17:06] <ogra_> well, the stuff vim doesnt show properly :)
[17:06] <Riddell> GrueMaster: so don't save it as boot.scr but as Env.txt ?
[17:06] <ogra_> Riddell, right
[17:06] <ogra_> and put it on the first partiton of the SD
[17:07] <Riddell> ogra_: and what do I need to do with mkimage?
[17:07] <ogra_> not sure, you might need to remove boot.scr from that partition
[17:07] <ogra_> Riddell, if Env.txt works you dont need it at all
[17:07] <GrueMaster> Yes.  Strip the u-boot header (garbage at the beginning), then remove the quiet & splash lines on the bootargs and add "console=ttyO2,115200 console=tty0".
[17:07] <ogra_> else you would need it to add the header back to the file
[17:08] <Riddell> "[    5.272796] panic occurred, switching back to text console"  ouch
[17:08] <ogra_> hrw, done btw
[17:09] <Riddell> how can I get minicom to save to a file?
[17:09] <ogra_> ctrl-a+h
[17:09] <Riddell> ogra_: that saves it?
[17:09] <ogra_> that should give you the list of commands ... there is some way to use a logfile
[17:10] <Riddell> that hangs up
[17:10] <ogra_> i never used logging, i just scoll back in my terminal in screen and copy/paste that
[17:11] <Riddell> this is giving me a bit too much output to do that
[17:11] <GrueMaster> Riddell: Use "screen /dev/ttyUSB0 (or shat ever the serial port on your pc is), then use screen's logging capabilities.
[17:12] <ogra_> yeah
[17:12] <Riddell> aah
[17:18] <GrueMaster> ppisati: My kernel is up if you want to test it.
[17:19] <Riddell> GrueMaster, ogra_ http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-noquiet
[17:20] <Riddell> [    4.463867] EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)  ?
[17:20] <GrueMaster> odd indeed.
[17:21] <infinity> Did we misplace ext4 support somewhere? :P
[17:21] <infinity> I'm assuming 240 is an ext4 feature flag.
[17:21]  * infinity looks.
[17:21] <ogra_> it just loops over the ext filesystems usually
[17:21] <ogra_> thats a red herring
[17:21] <infinity> Yeah, 240 is an ext4 feature.
[17:22] <GrueMaster> Something doesn't sound right with his image.  I tested all (and I do mean ALL) images for beta 1 on multiple systems.
[17:22] <ogra_> it should be trying ext4 next ... not sure why it doesnt
[17:22] <infinity> Riddell: Is that a fresh precise install, or something hacked up and/or upgraded?
[17:23] <Riddell> infinity: installed like this  sudo sh -c 'zcat ./ubuntu-12.04-beta1-preinstalled-desktop-armhf+omap4.img.gz |dd bs=4M of=/dev/mmcblk0 ; sync'
[17:23] <Riddell> which works fine for oneiric
[17:23] <ogra_> did you let it finish the resize on first boot ?
[17:23] <Riddell> ogra_: I don't know, I had no output
[17:23] <ogra_> if it was interrupted it indeed might corrupt your fs
[17:23] <infinity> You have no monitor connected?
[17:24] <Riddell> infinity: I do have a monitor connected.  it does not show anything with precise
[17:24] <infinity> Wrong port?
[17:24] <infinity> Is it HDMI or DVI?
[17:24] <infinity> (Yes, people mess this up all the time)
[17:24] <infinity> The HDMI port is the one next to the ethernet.
[17:24] <GrueMaster> Do you have the monitor on the HDMI port (closest to the USB ports).
[17:24] <infinity> ie: Not the one on the outside of the board.
[17:24] <Riddell> I have a DVI monitor plugged into the DVI port which worked fine with oneiric
[17:25] <ogra_> might have changed with the new kernel version
[17:25] <ogra_> try HDMI :)
[17:25] <infinity> Ahh, kay.  Something may have broken DVI.  I only ever test with HDMI (cause it's all I have the cabling for)
[17:25] <Riddell> I have no HDMI monitor
[17:25] <infinity> HDMI TV?
[17:25] <ogra_> just plug the DVI into the HDMI port
[17:25] <Riddell> I have no TV
[17:25] <ogra_> should work fine
[17:25] <infinity> ogra_: That really shouldn't work.
[17:25] <infinity> ogra_: But I'd be curious to see if it does.
[17:26] <ogra_> or was it the orther way round ?
[17:26] <ogra_> it wont do any harm either way though
[17:26] <infinity> True.
[17:26] <GrueMaster> infinity: Yes, it should.  hdmi is the same signal as DVI-D.
[17:27] <infinity> Riddell: Also, despite all protests to the contrary, you can just zcat foo.img.gz > /dev/whatever
[17:27] <infinity> Riddell: The dd is entirely pointless.
[17:27] <ogra_> right, i thought so
[17:27] <infinity> GrueMaster: Yes, HDMI is a superset of DVI-D, but it also intentionally leaves out (in many implementations) lots of the possible resolutions.
[17:27] <ogra_> infinity, using a 4M blocksize speeds up the writing
[17:28] <infinity> GrueMaster: If that's the case on the omap4 kernel (or at the hardware level), I have no idea.
[17:28] <GrueMaster> I don't know if the dvi port on panda will work w/o the TI drivers (not in FB w/o kernel parameters).
[17:28] <ogra_> i know i used the HDMI port of my monitor with a HDMI cable plugged into the DVI port in the past ...
[17:29] <GrueMaster> But signal wise, an HDMI port can connect to a DVI monitor just fine.
[17:29] <ogra_> but i dont think i ever tried the other way round
[17:29] <infinity> The other way around really shouldn't work.
[17:29] <infinity> But HDMI->DVI will work, if it supports the resolutions you need.
[17:29] <GrueMaster> The only thing that will be missing is HDMI audio.
[17:29] <infinity> The audio channels just go off into la-la land.
[17:30] <GrueMaster> And DVI->HDMI works the same way.
[17:30] <infinity> Anyhow.
[17:30] <infinity> Riddell: Using the HDMI port may well make things happy.
[17:30] <Riddell> I gathered :)
[17:30] <Riddell> remaking the image on the SD card
[17:30] <infinity> Or, we could discuss it more. :P
[17:30] <GrueMaster> As long as it is all digital.  DVI also supports analog (but that is a different discussion and irrelevant to this discussion).
[17:31] <ogra_> infinity, awesome idea !
[17:36] <GrueMaster> Riddell: I relooked at your kernel output (above).  Why is "rootfstype=ext3" in the kernel cmdline?
[17:36] <GrueMaster> That isn't normal in our images.
[17:39] <damian0815> hey ubuntu-arm, ld is complaining that 'main.o uses VFP registers, a.out does not'
[17:40] <damian0815> i'm compiling main.cpp with -mfpu=vfp + other args. how can i convince ld that a.out should use VFP registers also?
[17:47] <Riddell> GrueMaster: I have no idea
[17:47] <Riddell> I just used a normal image with the edited boot command edited to remove quiet
[17:48] <GrueMaster> Well, since we use ext4 images, that line would have given you issues.
[18:02] <GrueMaster> Riddell: Was this the Ubuntu beta 1 or Kubuntu Beta 1?
[18:05] <Riddell> GrueMaster: Ubuntu Desktop Beta 1
[18:06] <GrueMaster> Ok.  Checking here, I see no indications of where "rootfstype=ext3" could have come from, unless it is in u-boot and you didn't use the boot.scr.
[18:06] <GrueMaster> Your console log above was started after u-boot had booted.
[18:07] <Riddell> GrueMaster: I didn't use the boot.scr after I saved it to Env.txt
[18:07] <GrueMaster> Did it load the Env.txt?
[18:08] <Riddell> dunno reformatting the SD card and trying again
[18:08] <GrueMaster> Oh, wait.  I think I see what is happening.  u-boot only looks for the uImage & uInitrd lines in Env.txt.  I was told it works the same as boot.scr.
[18:10] <GrueMaster> So nix the Env.txt idea.
[18:11] <GrueMaster> At any rate, you should have video on hdmi.
[18:16] <infinity> damian0815: That sounds like you're using -mfloat-abi=hard on an armel system.
[18:16] <infinity> damian0815: Which will only work if you link with gcc as well (or pass the right bits to ld), since ld won't magically do what you think it should.
[18:16] <infinity> damian0815: Alternately, run armhf if you want armhf. ;)
[18:17] <damian0815> infinity: thanks for the reply
[18:17] <damian0815> infinity: i am in fact linking by calling gcc
[18:17] <damian0815> infinity: i guess gcc isn't telling ld to do the right thing?
[18:17] <infinity> damian0815: On which release is this?
[18:17] <damian0815> infinity: 10.10
[18:17] <infinity> Oh, yeah.
[18:18] <infinity> That's almost certain to just plain not work.
[18:18] <damian0815> rightoh
[18:18] <steev_> what is this install RELEASE shortcut that's started showing up on my shortcut bar (and how do i get rid of it?)
[18:18] <steev_> clicking on it just gives me a crash in ubiquity
[18:18] <damian0815> i'm installing 11.10 as we speak. was avoiding before due to lack of omap-extras-graphics.
[18:18] <infinity> Besides, even if you compiled your application as hardfloat, if it links to anything else, it won't work.
[18:18] <steev_> (it's still rotating circle on collecting info)
[18:18] <infinity> damian0815: Install precise/armhf if you want hard-float.
[18:19] <infinity> damian0815: You'll like it better than oneiric anyway.
[18:19] <GrueMaster> Riddell: The ubuntu beta 1 image works for me on a non-hdmi DVI monitor here, so you "should" have no issues.  If you still do, we can figure it out.
[18:19] <Riddell> GrueMaster: http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-hdmi
[18:19] <Riddell> that's ubuntu beta 1 with a dvi monitor plugged into the HDMI port
[18:19] <Riddell> I'm awaiting instructions :)
[18:19] <damian0815> infinity: what's the status of SGX drivers in precise?
[18:20] <steev_> er, this is interesting.  so ubiquity is crashing with IOError in main() Errno 2, No such file or directory: '/proc/2058/oom_score_adj'
[18:20] <steev_> why would ubiquity crash because oom_score_adj doesn't exist?
[18:21] <GrueMaster> Riddell: This is normal so far.  You see nothing on screen?
[18:21] <Riddell> GrueMaster: nothing
[18:21] <infinity> damian0815: As I understand it, it's all working in the tiomap-dev/trunk PPA.
[18:21] <GrueMaster> (not serial console, but on the monitor).
[18:21] <GrueMaster> And you have a proper power supply now?
[18:21] <Riddell> GrueMaster: I do
[18:21] <infinity> damian0815: But depends on installing the 3.1 kernel from the oneiric PPA.
[18:21] <infinity> damian0815: (That will be resolved soon)
[18:22] <damian0815> infinity: super. i'll see how i go with oneiric. i'm trying to build a straightforward enduser experience for openFrameworks (C++ art+code toolkit)
[18:22] <GrueMaster> Monitor is using an HDMI->DVI cable and no other conversions?
[18:22] <infinity> damian0815: Sure.  oneiric should work fine.  But just stop trying to pass whacky float options to the compiler.  Stick with the defaults and your life won't be pain. ;)
[18:23] <infinity> damian0815: (But, like I said, precise/armhf will treat you better than oneiric/armel, except for the bit where it's not quite done yet)
[18:23] <damian0815> infinity: heh. thx.
[18:23] <GrueMaster> Riddell: Monitor is using an HDMI->DVI cable and no other conversions?
[18:24] <infinity> steev_: Is /proc mounted at all?
[18:24] <Riddell> GrueMaster: HDMI-DVI adaptor and DBI cable to monitor
[18:25] <GrueMaster> Ok.  Wanted to make sure there were no DVI->VGA adapters in the mix.
[18:25] <GrueMaster> Do you have another device with HDMI out that you know works?
[18:27] <GrueMaster> It is also possible that your cable only handles DVI-A (VGA), although those are rare.
[18:27] <Riddell> GrueMaster: I have no HDMI devices no
[18:27] <GrueMaster> No PS3 or XBox?
[18:27] <Riddell> no
[18:27] <Riddell> GrueMaster: this setup works fine for oneiric
[18:28] <GrueMaster> The oneiric image works?  Now that is odd.
[18:29] <Riddell> yes
[18:30] <GrueMaster> Out of curiosity, what rev board is this?
[18:32] <Riddell> GrueMaster: how do I find out?
[18:33] <GrueMaster> Sticker on the bottom?
[18:34] <Riddell> GrueMaster: Rev A1
[18:35] <GrueMaster> Panda or PandaES?
[18:36] <GrueMaster> I'll look at my stacks and see which is an A1 so I can try to reproduce it here.
[18:37] <Riddell> GrueMaster: Model: PandaBoard Rev A1
[18:38] <GrueMaster> Ok.  I have one (I have one of each and then some).  I'll try it here.  Works fine on PandaES and Panda A3 so far.
[18:38] <shadeslayer> infinity: ping
[18:39] <shadeslayer> infinity: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/945393 << Any ideas how to fix? (/usr/bin/ld: final link failed: Memory exhausted)
[18:39] <ubot2`> Launchpad bug 945393 in qtwebkit-source "qtwebkit-source version 2.2.1-1ubuntu2 failed to build on armhf" [High,Confirmed]
[18:44]  * micahg wonders if it's worth filing a toolchain bug for https://launchpadlibrarian.net/95446439/buildlog_ubuntu-oneiric-armel.chromium-browser_17.0.963.65~r124586-0ubuntu0.11.10.1_FAILEDTOBUILD.txt.gz
[18:48] <GrueMaster> Riddell: I can't seem to reproduce your issue here at all.  Give me a minute and I will send you a replacement boot.scr for debugging.
[18:49] <Riddell> GrueMaster: thanks
[18:51] <GrueMaster> Did it get through the first boot ok?  Easiest way to check is to look at the sd card in your desktop and see if the second partition fills the SD.
[18:52] <Riddell> GrueMaster: I think it did but I've since reformatted it ready for your new boot.scr
[18:53] <GrueMaster> Ok.  One sec then.
[18:55] <GrueMaster> I have to flash it fresh to an SD then modify it.  Takes the same time as uncompressing/loop mounting.
[19:00] <infinity> shadeslayer: It's on my TODO, but no, I don't have any immediate ideas right now.  I have a few things on the go.
[19:01] <infinity> micahg: I wouldn't bother, personally.
[19:02] <GrueMaster> Riddell: http://people.canonical.com:~tobin/boot.scr
[19:02] <GrueMaster> Download it and copy directly to partition 1 (fat partition) overwriting existing boot.scr.
[19:02] <micahg> infinity: ok, well, if there isn't a way to work around it then, Chromium on arm in the stable releases looks slim
[19:03] <GrueMaster> And make sure screen is set to log before powering on the panda.
[19:03] <GrueMaster> I need food, will return shortly.  Pastebin the console log (or save it somewhere).
[19:03] <infinity> micahg: I'm much more interested in the LTS anyway, but if we have a spare moment, we can look at the oneiric FTBFS.
[19:04] <micahg> well, we're 2 hours (build time) closer to havign armhf work, armel already works in precise
[19:04] <Riddell> GrueMaster: what changed?
[19:08] <Riddell> GrueMaster: when I run screen /dev/ttyUSB1 I just get junk output and it causes minicom to get junk output to
[19:11] <GrueMaster> Works fine here.
[19:12] <Riddell> ogra_: not at cebit are you?
[19:13] <ppisati> GrueMaster: which u-boot/x-loader version do you have with beaglexm? and which cmdline do you use?
[19:14] <ogra_> Riddell, nope, 150km south of it
[19:14] <Riddell> ogra_: you couldn't ship yourself and your office to hannover or Bielefeld for tue/wed/thu could you, just to help me? :)
[19:16] <ogra_> Riddell, hmm not really, what are you doing at CeBIT ?
[19:17] <Riddell> see cebit
[19:17] <Riddell> seeing cebit
[19:17] <Riddell> I've never seen it before
[19:17] <ogra_> ah
[19:17] <ogra_> i have been to each since i was 16
[19:18] <ogra_> but not since i work for canonical
[19:18] <ogra_> <- grew up in hannover
[19:18] <Riddell> too many travelling days for UDS et al? :)
[19:19] <ogra_> nah, just no interest, i moved south a few years before starting ubuntu stuff, havent been back often
[19:19] <ogra_> if i go, i just do it to visitn my parents, but thats not more than a few hours (though i love hannover, but all friends i had there moved to berlin or elsewhere)
[19:22]  * ogra_ is off for the evening 
[19:31] <Riddell> GrueMaster: http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-tobiins-boot.scr
[19:35] <Riddell> GrueMaster: now I'm getting a very jumbled login prompt http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-tobiins-boot.scr-login
[19:35] <Riddell> from the serial
[19:35] <Riddell> nothing on monitor
[19:36] <davidhayesbigtoe> hello
[19:37] <davidhayesbigtoe> can anyone direct me to any ubuntu ARM's that might be able to run on the new rasberrypi's?
[19:40] <rcn-ee> the rasberrypi is an arm11 "armv6" core, ubuntu's current minimal arch for supported dist is "armv7-a"....
[19:40] <Riddell> "use debian"
[19:41] <davidhayesbigtoe> rcn-ee damn..
[19:42] <davidhayesbigtoe> i guess i would've found that out had i read more on the man for the pi. i haven't bought one yet as they first B boards haven't even shipped yet.. but i heard about it 3 days ago and i'm excited and would like to get my hands on one. so i'm trying to plan my assault on the thing the moment it arrives..
[19:42] <davidhayesbigtoe> Riddell i was hoping for ubuntu or slax... but i digress...
[19:44] <davidhayesbigtoe> i know there is bt ARMS for android phones.. but obviously an HTC incredible is much more powerful than a pi and i think it uses v11? idk..
[19:46] <rcn-ee> the htc incredible is a QSD8650, armv7-a core..
[19:47] <davidhayesbigtoe> yea..
[19:47] <davidhayesbigtoe> ARM cortex-A15 cpu
[19:48] <davidhayesbigtoe> for my specific phone.. using the armv7 arch.. anyhow. i know my phone HAS the capability to handle 720p/1080p but is not enabled by default?
[19:48] <rcn-ee> ah, no.. currently no "cortex-A15" cores are shipping yet.. But shorty.. ;)
[19:48] <davidhayesbigtoe> i need to root and crack this baby open
[19:48] <rcn-ee> usually. 720p/1080p video is handled by a video coprocessor..
[19:49] <shadeslayer> davidhayesbigtoe: you can boot debian tho
[19:49] <rcn-ee> (the rasperby pi's core has the same feature, that's why they can show it doing video..)
[19:49] <davidhayesbigtoe> blah.. i'm dumb.. the successor to the current scorpion chip i have.. the S4 SoC has the cortex cores
[19:49] <shadeslayer> also, I'm waiting for my RasPi as well
[19:49] <davidhayesbigtoe> rcn-ee yea, i know that's why i want a pi
[19:49] <davidhayesbigtoe> lol
[19:49] <davidhayesbigtoe> but i also wanna fully crack open my dINC1 now that my contract is up and i'm do for a new phone
[19:50]  * shadeslayer has a voucher code, but no way to redeem the voucher
[19:50] <davidhayesbigtoe> i wanna integrate the pi and the droid together.. maybe use it for touch screen display on the pi
[19:50] <davidhayesbigtoe> hah
[19:52] <shadeslayer> http://lists.qt-project.org/pipermail/qtonpi/2012-March/000215.html ... :(
[19:54]  * davidhayesbigtoe :-(
[19:54] <davidhayesbigtoe> i didn't even order
[19:54] <davidhayesbigtoe> i put myself on the mailinglist and sent an inquiry
[20:07] <danboid> How do I install 12.04 (nightly or beta) on my pandaboard?
[20:08] <danboid> I've booted a recent nightly and modified it to show a serial console but I dunno how to log in to it- username/password?
[20:08] <danboid> I've tried ubuntu with no password or ubuntu as password too with no luck
[20:11] <danboid> There don't seem to be any headless OMAP4 builds of Precise yet, which is what I'd use if I could get some
[20:13] <infinity> danboid: s/headless/server/
[20:13] <infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
[20:15] <danboid> infinity, Aha! Thanks v much!
[21:24] <pbuckley> Kernel /boot/vmlinuz-3.2.1 does not match your subarchitecture
[21:24] <pbuckley> omap4, therefore not writing it to flash.
[21:24] <pbuckley> got this on this morning's apt-get dist-upgrade
[21:26] <infinity> pbuckley: And where did that kernel come from?
[21:26] <infinity> pbuckley: It's not a distro kernel.
[21:26] <pbuckley> hrmm it might have picked it up from ti's repo
[21:26] <pbuckley> ill let you know once it finishes
[21:27] <infinity> dpkg -S /boot/vmlinuz-3.2.1
[21:28] <infinity> And it wouldn't be from TI's PPA, they're building 3.1
[21:28] <pbuckley> nm.. i must have built it
[21:28] <pbuckley> its not showing up in dpkg
[21:29] <infinity> Yeah, I suspected as much.
[21:29] <infinity> If you want flash-kernel to play nicely with local kernel builds, just tack an -omap4 extraver on the end of them.
[21:29] <infinity> Cause we do machine type to subarch mapping to make sure Bad Things don't happen if someone installed a kernel package for another subarch.
[23:33] <CodeWar> https://wiki.ubuntu.com/ARM/RootfsFromScratch
[23:34] <CodeWar> What in God's name are you guys using to build that kernel,  if I replace it with my own kernel it says rootfs not found. Is there a driver MMC perhaps you guys bake in there?
[23:34] <CodeWar> :-)
[23:44] <pbuckley> i just use the ubuntu tools for building a kernel
[23:44] <pbuckley> let me get you a link
[23:44] <pbuckley> https://help.ubuntu.com/community/Kernel/Compile
[23:47] <CodeWar> pbuckley, thanks let me read that wiki, if there is a .config file you have somewhere that would be very useful too
[23:51] <GrueMaster> CodeWar: What platform are you building a kernel for?
[23:51] <CodeWar> GrueMaster, vexpress-a9 running on QEMU
[23:52] <CodeWar> I can build zImage and load run and have fun with NFS boot all I want but booting off qemu img never worked for me. It appears to work for you guys so diffing whats different :-)
[23:54] <GrueMaster> I know nothing about the vexpress build or running on qemu, but I believe we have a vexpress kernel in the pool.
[23:55] <CodeWar> can you point me to the .config file for whatever kernel works successfully on QEMU?
[23:55] <CodeWar> thats all I m looking for anyways :-)
[23:57] <GrueMaster> Not easily.  Either pull the deb package or use the kernel git tree from the link pbuckley pasted.  I think the omap kernel is what is used for qemu.
[23:59] <mythos> hmm... not versatile? :o