[03:02] <pdc> When I create an ext3 partition, the file system is "Unknown" and I can't mount the volume.  Any ideas?
[03:04] <persia> I seem to remember there being some issue with checksums and signed vs. unsigned interpretations of some C.
[03:04] <persia> My recommendations would be to try another filesystem *OR* to make sure the filesystem was created the same place it was checked.
[03:05] <persia> https://patchwork.kernel.org/patch/22568/ seems to be the relevant issue
[03:09] <persia> pdc, Just to make sure, where/how did you create the ext3 partition?
[03:21] <cooloney> persia: world changed, i got 200kBps on my pandaboard from ports.ubuntu.com
[03:22] <persia> cooloney, Heh.  Nice.
[03:24] <cooloney> persia: save my life, do you have any updates about the audio issue on pandaboard?
[03:25] <persia> My understanding is that just about everything was committed, but there was some uncertainty about the config file that needed to go in alsa-utils, because it worked on one platform and not another.
[03:25] <persia> I'd recommend enabling -proposed, getting the new kernel, alsa-lib, and alsa-utils from there, and testing.  Ought work.
[03:28] <cooloney> persia: great, i am upgrading to the latest kernel and alsa-lib and alsa-utils from -proposed
[03:35] <Neko> persia, that patchset you just ref'd has it been pushed to kernel yet?
[03:39] <persia> Neko, The place I found it suggested it had been applied in Ubuntu kernels.  I don't know more about it.
[03:39] <Neko> I somehow remember it being but
[03:39] <Neko> I would have thought it'd have hit mainline ages ago
[03:40] <persia> May well have done so.  Still the only thing I know that would make ext3 bail.
[03:41] <Neko> but only really if you are using an ext3 filesystem generated on some other platform and then drop it on ARM
[03:41] <Neko> doesn't ext4 handle it properly
[03:42] <Neko> (we use ext4 exclusively here... no point using ext3 it's slow as fuck)
[03:47] <persia> !ohmy | Neko
[03:47] <ubot2> Neko: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[03:48] <persia> But I think it is only ext3: I think ext4 has the workaround (I hesitate to call it "properly", as I agree that God and K&R intended char to be signed)
[03:51] <pdc> I discovered that I can create good ext3 partitions on a microSD when it's plugged into an SD adapter, but when it's plugged into a USB adapter, it creates an "Unknown" partition and lots of ugly error messages show up in dmesg.
[03:53] <persia> From the same host?
[03:54] <pdc> persia, I'm not sure what you mean.
[03:57] <persia> For the case where you created the ext3 partitions on MMC and USB to the same microSD, were you on the same machine?
[03:58] <pdc> Yes
[03:59] <persia> Interesting.  You may have found an exciting bug.  If you could create two small filesystems (say 10MB) using both methods, and attach zipped dd's of them to an LP bug, it may develop some interest.  If you are so willing, please file it with `ubuntu-bug linux`
[04:00] <persia> Obvious workaround is to use MMC to create a partition if you need ext3, but I suspect at least someone would be interesting in tracking down and fixing the real bug.
[04:04] <persia> Easier workaround is probably to use ext4.
[04:13] <pdc> persia, the problem is not specific to ext3.  I just tried ext4 and ext2 and got the same results as I got with ext3.
[04:27] <persia> pdc, That's unexpected.  Does the USB adaptor work properly on other hosts?
[04:44] <pdc> I tried it on another Ubuntu box, and it does work properly there!
[04:53] <persia> same architecture or different architecture?
[04:58] <pdc> They're quite different.
[04:59] <persia> Ah, good.  That makes it more likely to be an arch-specific kernel issue.
[08:33] <hrw> ehlo #
[08:39] <ukleinek> hrw: 501-# is an invalid hostname
[15:58] <GrueMaster> lrg: Do you have any more info on UCM?  I have been looking into it and was wondering what the timeline was for initial release to see if it could be worked in to Ubuntu Natty.
[16:26] <sveinse> Hi. I'm trying to decide if I should use Ubuntu or any other distro/build system (like OE or Ångström) for a new custom Cortex-A8 based product we're making
[16:27] <sveinse> From one POV Ubuntu is nice, since the packages comes neatly prepared and have a good way of handling upgrades and updates
[16:27] <ogra_ac> what are you expecting us to suggest in the ubuntu channel ?
[16:27] <ogra_ac> :)
[16:27] <GrueMaster> Depends on the memory being added.
[16:27] <ogra_ac> but yeah
[16:27] <ogra_ac> memory is key
[16:27] <sveinse> ogra_ac: LOL :)
[16:27] <sveinse> 256Mb is the number
[16:28] <hrw> sveinse: what will run on device?
[16:28] <sveinse> I have already been experiencing with Ubuntu ARM for a while, so I know its quirks
[16:28] <GrueMaster> Well, you can definately use some of the core stuff, but don't expect any performance from any of the main gui envirounments (gnome, kde).
[16:29] <sveinse> We will run Qt/e against FB/SGX
[16:29] <Neko> omap?
[16:29] <ogra_ac> qt embedded should be fine with 256M
[16:29] <sveinse> So doing a custom compile of Qt natively takes a long time on Ubuntu
[16:29] <sveinse> yes, omap
[16:29] <ogra_ac> as GrueMaster said though, a full desktop/netbook ubuntu UI will need 512M
[16:29] <ogra_ac> to run smoothly
[16:30] <ogra_ac> sveinse, for building packages natively get a pandaboard ;)
[16:30] <sveinse> So we're wishing very hard to have cross compilers that can target Ubuntu. I've experienced using CSL cross and inject the Qt and Qt app into the system. Now, it works, but for how long...
[16:30] <sveinse> ogra_ac: I'll check out the pandaboard, thanks
[16:30] <ogra_ac> sveinse, hrw is your man
[16:31] <ogra_ac> he maintains xdeb and friends
[16:31] <ogra_ac> for cross building
[16:31] <hrw> wookey maintains xdeb not me
[16:31] <ogra_ac> ah
[16:31] <sveinse> yes, linaro or something like that, isn't that a cross for ubuntu?
[16:31] <ogra_ac> well, you maintain what it uses
[16:31] <ogra_ac> linaro is a company
[16:31] <hrw> sveinse: apt-get install g++-arm-linux-gnueabi then ;D
[16:31] <ogra_ac> but yes, the stuff they do ends up in ubuntu
[16:32] <sveinse> what is xdeb? ....checking google...
[16:33] <sveinse> I also want to comment that the product will be entirely "embedded". The user will not install any apps/packages of own choosing. The device will start directly into our app and not a general UI
[16:34] <hrw> sveinse: not planning any kind of updates to be done once deployed?
[16:35] <sveinse> Yes, but controlled via our company. I.e we will branch out the relevant packages and put up our own repo
[16:35] <sveinse> We need that for support reasons (we will guarantee the product)
[16:36] <sveinse> Our GUI will shell out to dpkg/apt-get in the BG
[16:37] <sveinse> So... Building qt can be handled from g++-arm-linux-gnueabi and it will link against the correct target libs, right?
[16:39] <ogra_ac> it should
[16:40] <hrw> sveinse: looks like going for Ubuntu will work.
[16:40] <sveinse> Yeah, it sound like it
[16:40]  * hrw has OE/Ångström background
[16:40] <sveinse> The alternative is OE/Å
[16:40] <sveinse> But I know too little about it
[16:41] <sveinse> and my boss wants a decision by tomorrow :D
[16:42] <hrw> Ubuntu will give you less work probably
[16:43] <sveinse> One uncertainty with Ubuntu is that it relies on initrd and does heavy scripting during bootup. It is a string wish to minimize the startup time a much as possible. Down to 15 secs from linux unpacking to GUI app is a target
[16:44] <ogra_ac> thats not true anymore
[16:44] <ogra_ac> you dont need the initrd
[16:44] <sveinse> Nice.
[16:44] <ogra_ac> only if your users can freely install packages you should have it
[16:44] <ogra_ac> but that doesnt seem to be the case
[16:44] <sveinse> And then the big wait is probably the udev population
[16:44] <ogra_ac> no
[16:45] <ogra_ac> ubuntu doesnt use udev to populate the initial /dev, it relies on the kernel to have devtmpfs
[16:45] <ogra_ac> indeed, if you dont have that, udev scripts will run and everything will slow down
[16:45] <sveinse> well. in the bootlogs I've seen, that seems to be the case.
[16:46] <ogra_ac> if your kernel has devtmpfs that shouldnt take any time
[16:46] <sveinse> At least I'm beginning to be confident that we can strip things down to something lean and mean
[16:46] <ogra_ac> you surely can
[16:46] <sveinse> well, then it seems that ubuntu is it then (said in the #ubuntu-arm channel :) )
[16:47] <ogra_ac> hehe
[16:47] <ogra_ac> what release do you plan to base on ?
[16:47] <sveinse> proto by jan-11. release by 1Q12
[16:48] <ogra_ac> i meant ubuntu release ;)
[16:48] <sveinse> Ah. Currently maverick
[16:48] <sveinse> But it can change. We've just changed from lucid
[16:49] <ogra_ac> well, lucid would be cleverer regarding security support
[16:50] <sveinse> Yeah. So lucid (ARM) is included into the LTS program? I thought it wasn't
[16:50] <sveinse> In all cases, we as a mfg need to take the ultimate responsibility for the customer. So having LTS is more a convenience for us, not the customer
[16:51] <hrw> sveinse: packages are built for each arch
[16:51] <sveinse> Aha. So security updates are updated for all archs
[16:54] <sveinse> BTW: Are there any concerns basing a commercial product on Ubuntu (where the user cannot choose packages freely)? Given, of course, the obligations in GPL
[16:54] <sveinse> (And not considering the Tivoization issue for a moment)
[16:54] <ogra_ac> as long as you obey to the ubuntu trademark policy it should all be fine
[16:55] <ogra_ac> (i.e. if you will have ubuntu in your product name you need to get trademark approval)
[16:55] <sveinse> sure. And thanks, I'll check it out
[16:58] <sveinse> Slightly OT: Are there any open source scripts/tools for building packages and populating a custom apt repo?
[17:01] <hrw> dpkg-scanpackages you mean?
[17:01] <hrw> or apt-ftparchive (which does same but require apt)
[17:03] <sveinse> Sorry for repeating myself, what is xdeb? https://wiki.ubuntu.com/Specs/M/ARMXdebCrossCompilationEnvironment isn't too informative unfortunately
[17:05] <hrw> ok, me off
[17:05] <hrw> have a nice rest of day
[17:05] <sveinse> hrw: Thanks for your help & input
[17:05] <hrw|gone> sveinse: https://edge.launchpad.net/xdeb has code etc
[17:06] <sveinse> Thanks again
[17:29] <davidm> Woot PandaBoard can be purchased at USD $174 from DigiKey today!
[17:29] <davidm> Cheap Cortex AP hardware finally
[17:29] <davidm> make that Cheap Cortex A9 hardware finally
[17:32] <ogra_ac> heh :)
[17:33] <jayabharath> davidm: you can order it today.. yes.. expect about 4 week lead time to ship
[17:34] <jayabharath> so you can order it now and by the time you get home from UDS.. it should hopefully be at your home :)
[17:38] <davidm> jayabharath, it's really really nice to be able to say you can put in an order today.  It's been a long time coming
[17:38] <jayabharath> davidm: yup - I totally agree...
[17:49] <davidm> prpplague, quick question, with zippy2 attached to a panda can I achieve a clean network boot?
[17:50] <prpplague> davidm: yep, sakoman has full support for the 8851 in u-boot, you'd need to tweak some of the pinmux's and add a small amount of glue code, but  nothing major
[17:50] <ogra_ac> where would u-boot come from ?
[17:50] <ogra_ac> you still need the SD, no ?
[17:51] <prpplague> ogra_ac: yea you still need an SD for MLO and u-boot, but you can tftp the kernel and nfs the rootfs
[17:51] <ogra_ac> that desnt work without zippy ?
[17:51] <ogra_ac> *doesnt
[17:51]  * sakoman doesn't have a zippy2, but if he did he would add support to the panda u-boot ;-)
[17:52] <ogra_ac> i thought the interface would be up in u-boot (honestly i never checked)
[17:52] <jayabharath> ogra_ac: dosent -- no support for uboot to boot over network ..
[17:52] <prpplague> ogra_ac: the smsc LAN9514 is via the EHCI which means that you need to init the ehci and have a driver for the lan9514
[17:52] <davidm> ogra_ac,  so still need a monolithic kernel that can't write to the SD :-(
[17:52] <jayabharath> sakoman: perhaps prpplague can donate a zippy2 for you :)
[17:52] <ogra_ac> well, if i have to have the SD anyway, i can also put the kernel on it
[17:52] <prpplague> sakoman: i have you zippy2 on my desk, but i've been too busy to get it shipped
[17:52] <ogra_ac> davidm, right
[17:52] <prpplague> sakoman: i'll try to do that this week
[17:53] <ogra_ac> davidm, no such thing like PXE on arm
[17:53] <sakoman> u-boot ehci for OMAP3 and OMAP4 is on my list
[17:53] <davidm> ogra_ac, yea I know
[17:53] <sakoman> prpplague: no rush, my Panda doesn't really work anyway
[17:53] <sakoman> need to wait till I get the one from Digikey
[17:53] <ogra_ac> davidm, but i dont see that as a prob, monolithic kernel is safer anyway
[17:53] <ogra_ac> davidm, and no MMC support is a must
[17:53] <davidm> ogra_ac, yea but was hoping for an "easier" solution, no joy there
[17:54] <ogra_ac> nah
[17:54] <ogra_ac> we could solder some nand on ;)
[17:55] <davidm> I so miss the days of a real hardware lock on SCSI HD, throw the switch and nothing could change end of story
[17:55] <ogra_ac> yeah
[17:55] <ogra_ac> well, the wonderful times of SD cards
[17:55] <davidm> I really was under the impression that SD was the same, was really bummed out that it was a software lockout
[17:55] <ogra_ac> yup
[17:56] <ogra_ac> me too when i found out abou tit the first time
[17:58] <GrueMaster> I honestly don't remember a system having a hardware write-lock that couldn't be bypassed in software.
[17:59] <ogra_ac> floppies
[17:59] <ogra_ac> and old SCSI
[17:59] <GrueMaster> I could write to them with some of the hack software I had for the Atari.
[17:59] <GrueMaster> Unsure about old scsi.
[17:59] <GrueMaster> Have to check my books.
[18:01] <GrueMaster> But I do remember that there was a way to bypass the floppy by hacking the controller.
[18:11] <davidm> SCSI was a hardware lock, could not bypass in software, linux thought it could write and then would error out
[18:12] <davidm> Was a great alert system, set up your hardware, lock the drive and then watch logs for errors from someone trying to overwrite a file.  Was great
[18:13] <ogra_ac> haha
[18:17] <davidm> linux was unaware that the hardware write protect was on, worked really nicely,  Had the switch hooked up to the old turbo switch on AT cases
[18:33] <lag> Hi robclark
[18:33] <GrueMaster> Wouldn't it be cool if panda supported SDXC?  <2TB capacity, 832Mbit/s.
[18:33] <GrueMaster> Unfortunately, nothing exists yet.
[18:33] <ogra_ac> isnt that also heavily patented ?
[18:34] <lag> And heavily priced
[18:34] <robclark> hi lag
[18:34] <lag> Hey buddy
[18:34] <lag> How are you?
[18:34] <ogra_ac> ah, come on if you can get a panda for $174 you can spend $50 forr an SD
[18:34] <robclark> oh, keepin busy ;-)
[18:34] <lag> Are you making an appearance at UDS?
[18:35] <robclark> no.. I'll be at gstcon/elc that week..
[18:35] <robclark> bad timing this year
[18:35] <lag> Shame, it would be good to see you again
[18:35] <robclark> yeah
[18:35] <pcacjr> does u-boot support ext2 fs ?
[18:35] <lag> Well, there's always the Platform Sprint
[18:35] <lag> Can you take a look at something for me?
[18:36] <ogra_ac> pcacjr, yes and no
[18:36] <robclark> well, yeah, there will be more sprints and UDS's
[18:36] <lag> http://launchpadlibrarian.net/57732292/dmesg
[18:36]  * robclark looks
[18:36]  * pcacjr nods
[18:36] <ogra_ac> pcacjr, depends on the platform
[18:36] <lag> A user is complaining that his EDID appears 3 times
[18:36] <pcacjr> ogra_ac: ah, ok
[18:36] <robclark> EDID appears 3x, or the picture?
[18:36] <lag> robclark: bug 661761
[18:36] <ubot2> Launchpad bug 661761 in linux-ti-omap4 (Ubuntu) "3 copies of video with LG Flatron W22561VP (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/661761
[18:36] <robclark> I think it is https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/661761
[18:36] <ubot2> Launchpad bug 661761 in linux-ti-omap4 (Ubuntu) "3 copies of video with LG Flatron W22561VP (affects: 1) (heat: 12)" [Undecided,New]
[18:36] <robclark> yeah
[18:36] <lag> Yep
[18:37] <robclark> it is similar to what rsalveti sees
[18:37] <robclark> I was chatting w/ ricardo about that the other day..
[18:37] <lag> What was the outcome?
[18:37] <pcacjr> ogra_ac: maybe the FAT3 is a way to go, right ?
[18:37] <lag> Is it 3 pictures?
[18:37] <pcacjr> FAT32*
[18:37] <robclark> I suspect we might need some time threshold.. ie. if we get rapid connect/disconnect/connect, then don't try and re-read EDID
[18:37] <ogra_ac> pcacjr, yes
[18:37] <robclark> although will be a few weeks before I have a chance to give that a try
[18:38] <pcacjr> ogra_ac: thanks for the explanation
[18:38]  * robclark is on the road this week and next
[18:38] <ogra_ac> lag, talk to desrt in #pandaboard ...
[18:38] <lag> robclark: Awesome, so you're on this?
[18:38] <ogra_ac> (he is ryan)
[18:38] <lag> It's okay
[18:38] <lag> It sounds like Rob has it in hand
[18:38] <robclark> we'll  I'd like to try.. but it will be a few weeks.   Maybe rsalveti beats me too it?
[18:38] <robclark> at least he has a monitor which reproduces the same issue.. which I don't have
[18:39] <lag> Ah
[18:39] <lag> I guess that would help
[18:39] <lag> I'll keep an eye on it
[18:39] <robclark> yeah
[18:39] <lag> And chat to rsalveti at a later date
[18:39] <lag> Thanks Rob
[18:39] <robclark> but it is an issue we've seen w/ two different LG monitors.. so hopefully it is only w/ LG monitors and not others
[18:39] <robclark> np
[18:54] <GrueMaster> Wonder if these would work on panda?  It would take a long time to expand root, but would be cool.  http://www.flash-memory-store.com/sdxc-card.html
[19:54] <lrg> ogra: did the Panda audio config updates get released ?
[19:55] <ogra_ac> lrg, yes, but i made a mistake, fix is pending
[19:55] <lrg> ogra: ah, np - thanks
[19:55] <ogra_ac> (the omap4 file doesnt end up where it should be)
[22:00] <kgilmer> hi, when using the rootstock program, how do i know what are all the available seeds?  " --seed <>"
[23:45] <persia> kgilmer: you can look at the seeds available under http://code.launchpad.net/ubuntu-seeds (or add some)