[00:00] <persia> Wow!  This is the most useless stacktrace I've seen in a while.
[00:00] <persia> No pointers to where the segfault is happening.
[00:01] <persia> And cyclical from frame #1, with gdb reporting a corrupt stack.
[00:01] <sgnb> hum...
[00:01] <sgnb> so probably in ocaml land
[00:02] <persia> I'm happy to be a robot, but I don't have any idea how to begin to debug this without instructions.
[00:05] <sgnb> well... you do have access to the surrounding assembly code, don't you? I would try to find the closest symbol or so
[00:06] <persia> I'll need guidance for that.  I'm good at reading stacktraces, but don't really use GDB as such, beyond as a stacktrace generator.
[00:06] <sgnb> I usually use the disassemble command
[00:07] <sgnb> I should probably do that myself... is there a quick guide to set up an Ubuntu armel box in qemu?
[00:07] <persia> Do you need full system emulation, or just userspace emulation?
[00:08] <sgnb> I don't know... sothing enough to reproduce the problem
[00:08] <persia> If the latter, `mk-sbuild --arch=armel --distro=ubuntu oneiric` should do it, from a Debian system
[00:08] <persia> If the former, you'll need more setup, and I'd have to hunt up a guide.
[00:16] <sgnb> W: Failure trying to run:  dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-9ubuntu2_armel.deb
[00:17] <persia> Oh, right.  debootstrap is broken (/run)
[00:17] <persia> `sudo rm -rf /var/lib/schroot/chroots/oneiric-armel`
[00:17] <persia> Then `mk-sbuild --arch=armel --distro=ubuntu natty`
[00:17] <persia> Then `sudo schroot -c natty-armel -uroot`
[00:18] <persia> Then edit sources.list, and dist-upgrade.
[00:18] <sgnb> avoiding libc6?
[00:18] <persia> It doesn't actually avoid libc6
[00:18] <persia> It just avoids the situation that makes libc6 fail to install with debootstrap for oneiric
[00:19] <persia> Alternately, if you want persistence, edit /var/lib/schroot/chroots/natty-amd64/etc/apt/sources.list, and then enter the natty-armel-source chroot.
[00:33] <sgnb> ok, I can reproduce the segfault
[00:34] <sgnb> actually, a mere "ocamlfind" segfaults
[00:34] <sgnb> but I get in gbd: qemu: Unsupported syscall: 26
[00:35] <persia> That's fine.
[00:36] <persia> We haven't been grilling qemu-user agressively recently, but I believe that support was added for all the syscalls need to build all the packages in the archive.
[00:36] <persia> Which would include anything necessary to run ocamlfind properly.
[00:36] <sgnb> 26 is ptrace
[00:36] <persia> Mind you, that isn't how we build stuff, but the work was done to enable just the sort of debugging you're doing now.
[00:37] <persia> Ah, hrm.  Maybe running gdb in that environment isn't so reliable :(
[00:38] <persia> Well, I suppose you could try https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
[00:39] <persia> I've been reminded that there's a buildd chroot available from https://launchpad.net/api/devel/ubuntu/oneiric/armel/chroot_url if you like.
[00:39] <persia> (or rather, from the URI given at that URL)
[00:45] <sgnb> persia: actually, an empty program segfaults
[00:45] <persia> Empty ocaml program?
[00:46] <persia> Then I'm confused.
[00:46] <sgnb> yes
[00:46] <persia> Because ocaml didn't change between when it was working and when it wasn't working.
[00:46] <sgnb> create an empty file "toto.ml"
[00:46] <sgnb> run "ocamlopt toto.ml", then ./a.out
[00:46] <sgnb> it segfaults
[00:47] <persia> File "toto.ml", line 1, characters 0-1:\nError: I/O error: /tmp/camlasm637f94.s: Invalid argument
[00:47] <sgnb> persia: with empty toto.ml?
[00:47] <sgnb> for me, it compiles
[00:47] <persia> That's the output from `touch toto.ml; ocamlopt toto.ml`
[00:48] <sgnb> so it means that you cannot even compile anything
[00:48] <persia> apparently.
[00:49] <persia> I got here by dist-upgrading my natty buildd chroot, and installing ocamlfind.
[00:49] <persia> Maybe I need to install something else?
[00:50] <sgnb> that's what I did
[00:51] <sgnb> something must have changed somewhere else
[00:51] <persia> Between when I did what I did and when you did what you did?  There was only a short window.
[00:52] <persia> And not much has been added to the archive, as folk are trying to fix the /run issue (publishing and buildds are expected to stop being manual any time now)
[00:52] <sgnb> no, I meant between 2011-05-20 and 2011-06-28
[00:52] <sgnb> (when ocaml stuff started segfaulting)
[00:53] <sgnb> it must be something very fundamental in the toolchain
[00:53] <persia> Well, we had a successful run on 2011-06-28 ( ocaml-data-notation ), and the failure on 2011-06-29 (oasis)
[00:53] <persia> There is no difference in the versions of everything in a buildd chroot there.
[00:53] <persia> Some differences in the build-depends, but nothing that I'd call "fundamental toolchain".
[00:54] <persia> (as that would be Priority: required or build-essential, or in the complete dependency/recommendation tree of those)
[00:55] <persia> It was just mpfr4, udev, and apt that differed in the base set.
[00:57] <sgnb> it's getting late here
[00:57]  * sgnb goes to bed
[00:57] <persia> Sleep well.
[00:57]  * persia updates the buildlog parsing scripts, and looks for differences in build-dependencies
[01:01] <persia> Hrm.  ocaml-findlib is the only package with a different version.
[01:02] <persia> Mind you, there are other packages that are present/absent in one or the other build based on differing build-dependencies, but those shouldn't matter for parallel runs of ocamlfind
[01:03] <sgnb> well, one should find an oneiric snapshot of 2011-06-28, and try to compile and run a program there
[01:03] <persia> Dunno if such a thing exists.
[01:05] <persia> Does anyone happen to have an un-updated chroot including ocaml stuff from June?
[01:58] <sgnb> persia: binutils is faulty
[01:59] <sgnb> with the version from natty, the empty program works
[01:59] <Martyn> hmm?
[01:59] <sgnb> persia: was binutils the same between the two builds above?
[02:01] <sgnb> Martyn: an empty .ml file compiled with ocamlopt segfaults on armel
[02:01] <sgnb> (since ~end of June)
[02:01] <persia> sgnb, Yes
[02:02] <persia> http://paste.ubuntu.com/643682/
[02:03] <sgnb> well, the upgrade from 2.21.0.20110327-2ubuntu2 to 2.21.52.20110707-1ubuntu1 did trigger the bug here
[02:03] <persia> Ah, maybe we have more than one bug.
[02:03] <persia> Both of those builds were running binutils 2.21.52.20110606-1ubuntu1
[02:04] <sgnb> maybe one of them doesn't run native program at all
[02:05] <sgnb> indeed, it seems that ocaml-data-notation doesn't run ocamlfind
[02:05] <sgnb> ah no, it does
[02:05] <sgnb> strange
[02:06] <persia> I think that pair of builds is likely the closest in time we'll find between working and not working.
[02:06] <persia> Everything from oasis on seems to have the same issue.
[02:06] <sgnb> well: take a natty chroot, install ocaml-nox, upgrade everything but binutils and gcc, it works, upgrade binutils, and it doesn't
[02:06] <persia> And this makes me suspect that findlib misbuilt
[02:07] <persia> Very odd.
[02:07] <sgnb> I don't think findlib is involved
[02:08] <persia> BTW, oneiric can debootstrap again
[02:08] <persia> What happens if you install https://launchpad.net/ubuntu/oneiric/+source/binutils/2.21.52.20110606-1ubuntu1 ?
[02:09]  * sgnb really goes to bed now
[02:10] <persia> heh
[02:30] <armelTest> anyone know of a tool to edit the size of a disk image without messing up the data inside?
[02:32] <persia> Doesn't exist, but there are tools that achieve most of the things that people want to do when they want to do that.
[02:32] <persia> So, what do you want to do?
[02:36] <armelTest> well i have the same img i was working with yesterday... the img size is only 2G i wanna make it 3
[02:37] <persia> OK.  If I remember correctly, that was a raw filesystem on an image, with no internal partitions or anything.
[02:37] <armelTest> right
[02:39]  * persia grumbles at dd not behaving quite as expected.
[02:40] <persia> Aha!
[02:41] <persia> OK, try `dd if=/dev/zero of=my.img bs=1G count=3 && mkfs.ext4 -f my.img && mount -o loop my.img /mnt/new`
[02:42] <armelTest> ok kewl imma try one more thing b4 i do that
[02:42] <armelTest> thanx again
[02:42] <persia> Heh, OK :)  Note that this creates a 3G image.
[02:42] <persia> Then you have to copy stuff.
[02:43] <persia> tar is probably easiest for that.
[04:55] <lintux> 04 or 11.10 work with the arm archictecture here's the link for the dreamplug: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx
[04:55] <lintux> oops
[04:56] <lintux> i just purchased  dreamplug while it has ubuntu downloads my question is will 11.04 or 11.10 work with the arm archictecture here's the link for the dreamplug: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx
[05:00] <lintux> my fault marvell kirkwood cpu
[05:05] <lintux> anybody here?
[05:38] <persia> lintux, Hey.  Ubuntu won't run on that device (although Marvell ships it with their own remix of Ubuntu)
[05:39] <persia> http://dreamplug.googlecode.com/files/Dreamplug%20-%20Change%20OS%20from%20%20Debian%20to%20Ubuntu-20110615.1.pdf has instructions
[05:39] <persia> Hrm.  Timing :(
[05:43] <lilstevie> persia: bad timing there
[05:44] <persia> Indeed.
[06:44] <siji> Hi
[06:47] <siji> Whether any netinstall option is avilable for ubuntu-arm
[06:48] <siji> I mean atleast for building RootFs
[06:53] <siji> janimo`, you there
[07:00] <janimo`> siji, yes
[07:00] <siji> hi
[07:01] <siji> I gone through your doc
[07:01] <siji> regd.devlopers meet
[07:01] <siji> janimo`, here am working with Beagleboard and ubuntu-arm
[07:02] <siji> And looking for a small ubuntu footprint version
[07:02] <siji> (with minimal things)
[07:03] <siji> So I think netinstall for arm will be good option
[07:04] <janimo`> siji, I have never used netinstall so cannot comment on this :)
[07:04] <siji> ok,now netinstall is not there for ARM
[07:05] <siji> So why cant you add it in the developers agenda ?
[07:27] <janimo`> siji, the session is about package build failures and aimed for those who want to help fix them. It is not about installing Ubuntu on ARM hw
[07:28] <siji> janimo`, ok
[07:29] <persia> siji, If you're looking for stable, small-footprint, check out the "headless" images.
[07:29] <siji> persia, ok
[07:30] <persia> http://cdimage.ubuntu.com/releases/natty/release/
[07:30] <persia> For the beagleboard, you want the "OMAP3" image.
[07:30] <siji> persia, i have tried those
[07:31] <persia> The headless one?  It wasn't small enough for you?
[07:33] <persia> Netinstall is only available for oneiric (in-development), at http://ports.ubuntu.com/dists/oneiric/main/installer-armel/current/images/omap/netboot/
[07:33] <persia> But it may or may not work, depending on the current state of the archive.
[07:35] <siji> persia, ok
[07:35] <siji> let me try that
[07:39] <persia> Thanks for helping test :)
[07:41] <siji> persia, actually am in the process of deciding OS for one of our Device
[07:43] <persia> siji, What sort of device?
[07:44] <siji> An ubuntu based tablet
[07:45] <siji> *without android :)
[07:45] <persia> Oh, cool!  That sounds kind of exciting.
[07:47] <siji> and i strongly prefer ubuntu
[07:47] <persia> Cool!
[10:51] <sgnb> persia: same pb, but it works with the one just before (2.21.51.20110421-6ubuntu1)
[11:17] <sgnb> persia: reported it at https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/810402
[11:17] <ubot2> Ubuntu bug 810402 in binutils "all native ocaml programs segfault on armel" [Undecided,New]
[14:28] <siji> persia, my protorype is running with 11.04 now
[14:29] <siji> Now try to enable touch screen
[14:29] <siji> 8trying
[14:29] <siji> *trying
[15:02] <LPhas> hello, installing ubuntu-omap4-extras from trunk on ubuntu10.10 i get this error Error! Bad return status for module build on kernel: 2.6.35-903-omap4 (armel)
[15:02] <LPhas> Consult the make.log in the build directory
[15:02] <LPhas> /var/lib/dkms/pvr-omap4-kernel/1.7~git0f0b25f/build/ for more information.
[15:02] <LPhas> Traceback (most recent call last):
[15:02] <LPhas>   File "/usr/share/apport/package-hooks/dkms.py", line 57, in <module>
[15:02] <LPhas>     report.write(open(apport.fileutils.make_report_path(report), 'w'))
[15:08] <rsalveti> mahmoh: GrueMaster: next u-boot upload should have the unique mac address fixed on panda
[15:08] <rsalveti> thanks to jcrigby
[15:08] <rsalveti> still building
[15:08] <GrueMaster> Yes, I saw the email.  Thanks.
[15:08] <mahmoh> awesome!
[15:09]  * mahmoh now has to convince jcrigby to make pxe a default (and /me needs to also investigate a boot failure by the likes of "test" with that setup)
[15:14] <damian0815> hey folks.. i just got wlan working on my pandaboard, got a quick q about wpa_supplicant binary vs functions.sh versions...
[15:14] <damian0815> basically /etc/wpa_supplicant/functions.sh includes a "-s" parameter when starting the wpa_supplicant daemon
[15:14] <damian0815> but this isn't supported by the wpa_supplicant that comes with ubuntu natty
[15:15] <damian0815> is this a bug? something wrong on my end?
[15:36] <ogra_> NCommander, oh, in case you didnt notice, persia provided a patch for netboot that now also publishes the MLO and u-boot.bin files ... so we have publically available unpacked binaries for both
[15:38] <ogra_> lool, so i'm just looking into adding the postinst/trigger bits to flash-kernel, whats the reason you focus on the ABI only in your original patch, shouldnt just the latest existing initrd suffice to get the version without splitting out the ABI
[15:38] <GrueMaster> Still need to post non-uImage versions of the kernel & initrd (or create an abootimg netboot.img) for usbboot.
[15:38] <ogra_> GrueMaster, meh, you should have said that when persia wrote the patch ... its just two more lines to the two he added :)
[15:39] <GrueMaster> I noted it back at the rally.
[15:39] <ogra_> bug ?
[15:39] <GrueMaster> NCommander was working on the d-i at the time.
[15:39] <ogra_> ah
[15:39] <GrueMaster> No one told me persia was working on it.
[15:40] <ogra_> he fixed the other issue a few days ago
[15:40] <ogra_> spontaneous as response to a user request
[15:41] <ogra_> but it was discussed largely in here, probably at a time where you were asleep though
[15:42] <ogra_> bug #808810
[15:42] <ubot2> Launchpad bug 808810 in debian-installer "Please publish MLO and u-boot.bin on download page for OMAP netinst" [Wishlist,Fix released] https://launchpad.net/bugs/808810
[15:42] <GrueMaster> I'm guessing that the u-boot that is there is already out of date, given the fix for die-id based mac in pxe.
[15:42] <ogra_> well, there was an upload today iirc
[15:43] <ogra_>     - Generated unique usbethaddr (LP: #809015)
[15:43] <ogra_> i guess thats the one
[15:45] <GrueMaster> yep
[15:45] <ogra_> so next d-i rebuild then
[16:03] <LPhas> GrueMaster, any hint about this? http://dpaste.com/568564/
[16:03]  * GrueMaster looks
[16:04] <GrueMaster> I haven't seen that before, but I haven't looked at maverick in quite a while.
[16:04] <LPhas> http://dpaste.com/568555/ this is the make.log
[16:06] <GrueMaster> It looks almost like the maverick ppa got clobbered by the natty ppa release.
[16:06] <LPhas> robclarck (from ti) sent me here saying
 hmm.. you might want to ask on #ubuntu-arm ...  I think there was some PM related API that changed in the kernel..  so when it upgrades the kernel, it tried to rebuild the old pvr kernel module, which failed..
 I don't remember how to get around that.. I think perhaps remove the sgx packages, then update, then re-install them
[16:06] <LPhas> but makes no sense to me
[16:06] <GrueMaster> I'll see if I can reproduce.  May take a while though.
[16:07] <LPhas> understandable
 Linux panda 2.6.35-903-omap4 #22-Ubuntu SMP PREEMPT Mon Mar 28 17:25:09 UTC 2011 armv7l GNU/Linux
[16:13] <robclark> that is not the trunk update..  which should be 2.6.35-980
[16:13] <ogra_> but the trunk driver ?
[16:13] <LPhas> mmmh
[16:14] <LPhas> so
[16:14] <LPhas> you are saying that i'm not using the up-to-date kernel
[16:14] <ogra_> you are using the release kernel
[16:14] <LPhas> that's strange
[16:14] <robclark> yeah.. so I guess you end up w/ release kernel, but trunk userspace syslink libs and trunk firmware
[16:14] <ogra_> but not the release PPA for pvr
[16:15] <LPhas> ok, in which package i have te kernel?
[16:15] <robclark> I seem to remember you need to uninstall pvr/sgx stuff to update.. otherwise the upgrade gets blocked by dkms compile error
[16:15] <ogra_> linx-omap4 should be the metapackage pulling in everything
[16:15] <ogra_> oh, that might be, could be that dkms is blocking
[16:15] <LPhas> uhm uhm
[16:16] <LPhas> dpkg drives me mad
[16:16] <robclark> it is a bit ugly, but if you uninstall sgx/pvr stuff first, then upgrade, then re-install
[16:16] <GrueMaster> It may not have updated the boot partition.  We have a bug filed about that.
[16:16] <LPhas> i've already tryied to uninstall sgx/pvr
[16:16] <robclark> It isn't really dpkg's fault..
[16:16] <LPhas> and upgrade
[16:16] <GrueMaster> Run "sudo flash-kernel" and it should update properly.
[16:16] <LPhas> as you said
[16:16] <ogra_> GrueMaster, indeed !
[16:16] <robclark> problem is kernel API that changed, so old pvr kernel module won't compile w/ new kernel headers and visa versa :-(
[16:16] <ogra_> why didnt i have that idea !
[16:16] <LPhas> but no newer package were pulled
[16:16] <LPhas> also, i tryied to run flash-kernel
[16:16]  * ogra_ is hacking on exactly that code atm  :)
[16:18] <LPhas> phas@panda:~$ aptitude show linux-omap4
[16:18] <LPhas> Package: linux-omap4
[16:18] <LPhas> ...
[16:18] <LPhas> Version: 2.6.35.903.6
[16:18] <ogra_> ugh, aptotude
[16:18] <LPhas> what's wrong with aptitude?
[16:18] <ogra_> thats just the meta
[16:18] <ogra_> check for the linux-image package
[16:19] <LPhas> Version: 2.6.35.903.6
[16:19] <LPhas> (aptitude show linux-image-omap4 ...0
[16:19] <GrueMaster> LPhas: Make sure you have maverick-updates in /etc/apt/sources.list
[16:20] <GrueMaster> iirc, that was also an issue with maverick.
[16:20] <LPhas> GrueMaster, yep, they seems to be there
[16:20] <ogra_> dpkg -l|grep linux-image
[16:20] <ogra_> try that
[16:20] <LPhas> phas@panda:~$ dpkg -l | grep linux-image
[16:20] <LPhas> ii  linux-image-2.6.35-903-omap4                  2.6.35-903.22                                     Linux kernel image for version 2.6.35 on TI OMAP4-based systems
[16:20] <LPhas> ii  linux-image-omap4                             2.6.35.903.6                                      Linux kernel image for the OMAP4 architecture.
[16:20] <ogra_> k, only 903
[16:21] <LPhas> http://dpaste.com/568569/ sources.list
[16:21] <ogra_> hmm, how did you add the PPA
[16:22] <ogra_> that looks like manually hacked in, usually ppas end up in sources.list.d
[16:22] <LPhas> yep, i put them in manually
[16:22] <ogra_> (if you use the right tools)
[16:22] <ogra_> well, better follow the instructions next time :)
[16:23] <ogra_> wont do harm though
[16:23] <ogra_> its intresting that you dont get the new kernel from the trunkl ppa
[16:24] <ogra_> robclark, did you not provide a linux-meta package too in there ?
[16:24] <LPhas> couldn't i simply download the deb file and dpkg -i into it?
[16:24] <ogra_> well, there is a bug we'd like to identify :)
[16:25] <LPhas> i get your point
[16:26] <ogra_> so there is no -meta package
[16:26] <ogra_> thats the issue
[16:27] <ogra_> sudo apt-get install linux-image-2.6.35-980-omap4  linux-headers-2.6.35-980
[16:27] <ogra_> try that one
[16:30] <LPhas> installing
[16:32] <robclark> ogra_, no idea..  I wasn't really too involved in the deb packaging stuff
[16:32] <ogra_> well, thats definitely the blocker
[16:33] <LPhas> so i won "i found a bug" t-shirt?
[16:33] <ogra_> though its possible that one of the ubuntu-omap4-*-* packages would pull it in
[16:42] <jayabharath> followup from #pandaboard....
[16:43] <jayabharath> LPhas: plz file a bug against the TI natty PPA
[16:43] <jayabharath> will ping the folks who maintain it to see if they can address it
[16:44] <LPhas> uhm
[16:44] <LPhas> this is maverick not natty
[16:45] <LPhas> and i'm not 100% aware of what happened, not sure at least.
[16:45] <LPhas> basically the meta package of linux-omap4 was not updated to include newest linux kernel?
[16:46] <ogra_> no
[16:46] <jayabharath> oops yeah maverick
[16:47] <ogra_> there was no metapackage created at all
[16:47] <LPhas> sob, now i've x not starting
[16:47] <ogra_> the existing one in the archive cant depend on a linux-image outside of the archive
[16:47] <ogra_> so someone would have had to create it inside the PPA with a higher version than the archive has
[16:48] <ogra_> which didnt happen
[16:48] <LPhas> FATAL: Module omap_gpu not found.
[16:48] <LPhas> that's strange
[16:48] <LPhas> oh, well, i probably got why
[17:11] <LPhas> mmh i keep getting omap_gpu not found on startx
[17:12] <LPhas> i removed and reinstalled ubuntu_omap4_extra thinking that previous installation compiled modules for the old kernel
[17:12] <LPhas> but nothing, it keeps not working
[17:20] <rsalveti> LPhas: which ppa are you trying to use at maverick?
[17:20] <rsalveti> release or trunk?
[17:20] <LPhas> trunk
[17:20] <LPhas> i have to use it
[17:20] <rsalveti> so you should be using the linux-kernel from trunk
[17:20] <LPhas> realease worked fine
[17:20] <LPhas> i'am
[17:20] <LPhas> if you look at the history
[17:21] <LPhas> we found a bug
[17:21] <LPhas> that prevent me to automatically get the latest version of the kernel from trunk
[17:21] <rsalveti> LetoThe2nd: 2.6.35-980.1release9?
[17:21] <rsalveti> LetoThe2nd: sorry
[17:21] <rsalveti> LPhas: 2.6.35-980.1release9?
[17:22] <rsalveti> oh, ok
[17:22] <LPhas> yep
[17:22] <rsalveti> sorry, huge backlog
[17:22] <LPhas> i noticed that linux-headers-2.7.35-980-omap4 was not installed
[17:22] <GrueMaster> Interesting.  Fresh install of maverick, I am getting dependency failures trying to install ubuntu-omap4-extras.
[17:23] <rsalveti> GrueMaster: ogra_: LPhas: http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
[17:23] <LPhas> GrueMaster, interesting
[17:23] <rsalveti> that's why meta wasn't included I believe
[17:23] <rsalveti> need to update x-loader/u-boot to make it work
[17:24] <LPhas> rsalveti, the "update the bootloader" part seems quite overcomplex
[17:24] <LPhas> shouldn't just sudo flash-kernel do the trick
[17:24] <LPhas> oh, it is intended
[17:24] <rsalveti> LPhas: not for maverick
[17:24] <LPhas> oh my
[17:26] <GrueMaster> Ah, forgot that multiverse & universe were not added by default.  yet another bug (and I now remember filing it back in the day).
[17:27] <LPhas> well, that is written on a lot of documents online
[17:48]  * GrueMaster signs his life away to the TI liscense agreements in Maverick for the sake of testing.
[18:08] <pmcgowan> jeremiah, ping
[18:12] <ogra_> GrueMaster, you read them before clicking, right ?? especially the part talking about your first born i hope :)
[18:13] <GrueMaster> Bah.  They can have him
[18:13]  * GrueMaster is more concerned with the anti-cloning on Titan 6 clause.
[18:14] <ogra_> i dont think it says they want him :)
[18:14] <ogra_> i might misremember, but i think there was something abotu life long vacancy *g*
[18:39] <persia> So, about exposing netboot stuff: I tossed in those lines as a whim.  The linked branch should make the process fairly obvious if anyone wants to include more files.
[18:39] <persia> I don't know what needs doing with abootimg to generate the right files for USB: if someone *really* wants to send me code to stick in the file, rather than writing a patch, that works.
[18:40] <persia> I'm also happy to review someone's patch adding abootimg code for syntax, integration, etc. if someone wants.
[18:40] <persia> (although I can't commit, so it would be a "looks sane" class of review)
[18:42] <persia> sgnb, Thanks for filing a bug about it.  Looks like useful progress is happening there.
[18:43] <persia> ogra_, regarding the image list: it's not *my* list (if anyone's it's skaet's), and it has mx5 images for Server starting today and for Xubuntu Desktop starting on Tuesday, so not everything is supposed to wait until 0801
[18:45]  * micahg notices a mention of xubuntu ARM images...
[18:46] <persia> micahg, Yeah.  When 0705 passed with no images in site, I bumped the date to 0719, because I figured two weeks was a nice round number, and someone else had set server/mx5 to 0715
[18:47] <persia> From my memory of our last conversation about it, you didn't really care about the specific date, as long as there was something to test sufficiently before alpha-3 that you had a chance to fix obvious problems.
[18:48] <micahg> persia: sounds good, now I just have to take care of my other stuff so I can actually play with this image :)
[18:49] <persia> sgnb, Apologies: I am having a bit of trouble following the discussion in bug #810402 : Does the 4.5 -> 4.6 change mean we need *another* ocaml transition for ABI shift?  Is there something else happening?
[18:49] <ubot2> Launchpad bug 810402 in ocaml "all native ocaml programs segfault on armel" [High,Confirmed] https://launchpad.net/bugs/810402
[18:50] <ogra_> note that there was an ocaml rebuild upload today
[18:50] <ogra_> which apparently ftbfs on all arches (i havent looked at the logs)
[18:51] <persia> Yeah, doko uploaded ocaml to build with a different GCC.
[18:51] <persia> It didn't work.
[18:52]  * persia grumbles at the institutionalilsation of *yet another* resolution: "qHD", with a vertical component less than 600 pixels (and also less than the 576 pixels we chased last time someone had this sort of brilliant idea)
[18:53] <ogra_> well, but you should at least get back horizontally what you lose vertically :)
[18:53] <persia> But the discussion in 810402 seems to be missing some bits, or at least it doesn't make sense to me as a conversation.
[18:53] <ogra_> why else would they add a q in front :P
[18:53] <persia> 'q' is for "Quarter".
[18:53] <ogra_> must be something special :)
[18:54] <ogra_> lol
[18:54] <persia> 19020x1080, except only 1/4 of it, so 540 vertical.
[18:54] <ogra_> so not for quality ?
[18:54] <persia> 960 horizontal is fine.
[18:54] <ogra_> sure
[18:54] <Neko> 960x540? better than iPhone4 resolution! :)
[18:54] <ogra_> well, thats close to PAL
[18:56] <persia> Still means that we either have to squash software or declare the resolution unsupported as a primary display
[18:58] <ogra_> i would go for the latter
[18:59] <ogra_> how many devices that fit a formfactor we target are there ?
[18:59] <ogra_> (with such resolution)
[19:03] <micahg> janimo: I know where to find you when I do have porting questions, thanks :)
[19:03] <janimo> micahg, ok ;)
[19:04]  * janimo crosses fingers it is not chromium :)
[19:05] <persia> ogra_, An increasing number, since the resolution has a special name, and glass is available, rather than being considered weird.
[19:38] <mahmoh> I'm trying to run pts/java-scimark2 and all the tests fail, exit non-zero, so it's not working for sure.  Should I try the same tests with JemVM? (if that's correct?)
[19:39] <GrueMaster> mahmoh: It would be interesting to look at the failure log to see why it fails.  I have openjdk-jre-headless running jenkins slave on panda.
[19:40] <mahmoh> oh, and a crash in netboot too: http://paste.ubuntu.com/644324/ ( cmagina )
[19:41] <mahmoh> GrueMaster: good point, let me try that
[19:49] <mahmoh> GrueMaster: it wasn't installed correctly b/c unzip wasn't installed!  Is that a package bug I would guess?
[19:50] <GrueMaster> dependency issue.  Should have resolved on it's own, but phoronix-test-suite relies on aptitude to install (which isn't part of the standard image).
[19:51] <mahmoh> it's not?  It's installed on my image (netboot w/ basic server), unzip was not
[19:51] <GrueMaster> I have seen a lot of dependency issues with phoronix.
[19:52] <GrueMaster> My netboot install with basic server & openssh-server didn't have aptitude.  Not sure what else was missing.  Had to install build-essential for the io tests as well.
[19:53] <GrueMaster> Possibly due to the debootstrap issues.
[19:53] <mahmoh> GrueMaster: hm, build-essential was installed for me by pts, aptitude's on there, wonder why our installs are different, itneresting
[19:53] <mahmoh> interesting
[19:54] <GrueMaster> I installed fresh Tuesday, right in the middle of the bootstrap issues.
[19:55] <mahmoh> ok, I'm installing now on another board so I'll check
[19:55] <mahmoh> actually, the install crashed (noted above)
[19:55] <mahmoh> bbib
[20:02] <mahmoh> and if anyone is nice enough to take a look at this and tell me why it's failing I'd appreciate it:  http://paste.ubuntu.com/644336/
[20:07] <GrueMaster> mahmoh: Install libaio-dev
[20:13] <mahmoh> GrueMaster: awesome, thx
[20:14] <mahmoh> oh, it's installed already
[20:34] <Johu> Hy. I did this : http://seabright.co.nz/2011/03/29/building-the-ubuntu-pandaboard-kernel/ but it didn't seem to do anything. Where should the uImage be?
[20:35] <phh> arch/arm/boot
[20:38] <Johu> it only compilse some object files but makes no linking... is this right?
[20:41] <Johu> It might  be I'm getting just to sleepy.  I'll continue tomorrow.
[20:41] <phh> no that's not right
[20:41] <phh> thsi page assumes you've got an arm crosscompiler
[20:42] <Johu> I was doing it on arm not on crosscompiler
[20:43] <Johu> Okey... thanks.
[20:43] <phh> ok so you don't have CROSS_COMPILE= line ?
[20:44] <Johu> in makefile?
[20:44] <phh> ...
[20:44] <phh> in the page you gave, it says to do export CROSS_COMPILE=blabla
[20:44] <Johu> no
[20:44] <Johu> i didn't need to..
[20:45] <Johu> i didn't crosscompile.
[20:45] <Johu> I was running it on panda.
[20:46] <phh> so you didn't do what this page states like you first said ...
[20:46] <Johu> eee... yes (angel).... i did allmost like it told
[20:47] <phh> anyway, what did the make say ?
[20:48] <Johu> It just made lot of .o and finaly one ld. It didn't link.
[20:48] <phh> ld isn't a link tool ?
[20:48] <phh> interesting
[20:49] <Johu> Only on ld.
[20:49] <Johu> I did something wrong. I'll go to sleep... won't anoy you any more.
[20:49] <Johu> Thnx.
[20:49] <phh> if you did something wrong there are errors in make log ...
[20:50] <Johu> I'll come back with log tomorrow... there was no errors.
[20:50] <Johu> Tnhx. Bb.
[23:43] <persia> Could anyone point me to nice documentation on boot.scr?  I can't seem to find anything :(
[23:52] <rcn-ee> persia, just something generic or?  (btw, if this is for the beagle, upstream has moved to uEnv.txt's instead, clear text..)
[23:52] <persia> Not for the beagle, and for a vendor uboot, so not even something where I can happily leverage upstream, sadly.
[23:53] <persia> But generic works.  I basically want to understand conditionals, how program flow works, and how variables are used.
[23:54] <rcn-ee> ah, variables get fun.. they end up being 'true' if they are not defined..
[23:54] <persia> In the end, I probably just want to setenv ramdisk/kernel/bootargs and bootm, but when digging through the pile of examples I have, it helps to have docs alongside to make sure I understand.
[23:54] <persia> Oh my :)
[23:54] <rcn-ee> kinda decent example here: https://github.com/RobertCNelson/flash-omap/blob/master/reset.cmd
[23:55] <rcn-ee> if i boot that on  a pandaboard, where "beaglerev" is not defiend it'll drop into every if..
[23:55] <persia> Wait, not only is the variable true if undefined, but the tests are automatically true if the variables are undefined?
[23:56] <rcn-ee> yeah, that's what i ran into, it was annoying..
[23:56] <rcn-ee> so you have to be pretty careful with the end target..
[23:56] <persia> In one of the examples I'm looking at, there's a construction that might work around that: "if test "_${foo}" = "_"; then:"
[23:57] <persia> (explicitly tests for null state, but presumably the same sort of thing could be extended to specifically testing a known state)
[23:57] <rcn-ee> actually, yeah that should work, didn't think of that..
[23:58] <persia> Heh, and that's why sharing is good :)
[23:58] <persia> Mind you, having documentation that mentioned the flaw in the implementation of test and the workaround would be even better :)