[00:03] <GrueMaster> The only problem is that it pulls only from ports.ubuntu.com (no mirrors).  You can get around it if you have a local mirror, but that takes a large amount of drive space.
[00:05] <brandini> maybe I'll stick with trying the headless daily
[00:06] <infinity> s/headless/server/
[00:06] <brandini> server?
[00:06] <brandini> I only see netbook and headless
[00:07] <infinity> Not for oneiric.
[00:07] <infinity> We're now more in line with the rest of the distro, with desktop and server.
[00:07] <infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/
[00:08] <GrueMaster> Oneiric changes the names.  Netbook>Desktop (daily-preinstalled).  headless>Server
[00:09] <GrueMaster> brandini: If you want the netboot installer, it is at a different location.  http://ports.ubuntu.com/dists/oneiric/main/installer-armel/current/images/omap4/netboot/
[00:13] <brandini> naw, I think I'll stick with server
[00:14] <brandini> how come cdimage is so slow?
[00:57] <GrueMaster> infinity: Does this certificate thing invalidate the current images that were just rebuilt?
[00:58] <GrueMaster> For armel?
[01:00] <infinity> GrueMaster: Almost certainly.
[01:00] <infinity> GrueMaster: I think we ship that package on pretty much every image.
[01:00] <infinity> Task: standard
[01:00] <infinity> Yeah.
[01:00] <infinity> Every image except core.
[01:01]  * GrueMaster mutters a few choice words that get stuck in the irc filters.
[01:02] <GrueMaster> Well, may as well fix jasper (yet again).  FS resize is failing.  Testing server images now.
[01:05] <infinity> It's failing on the server images?
[01:06] <GrueMaster> yes.  It runs way too quickly (1-2 seconds) on a 16G SD.
[01:06] <GrueMaster> Waiting for the rest of the install to see what it is doing (or not doing as the case may be).
[01:07] <GrueMaster> heh.  This is a definite indicator of fail:  /usr/sbin/oem-config-firstboot: line 98: cannot create temp file for here-document: No space left on device
[01:07] <GrueMaster> 16G SD.
[01:07] <infinity> Not promising...
[01:08] <GrueMaster> Considering installed we use ~1.9G max...
[01:09] <infinity> Not entirely sure how the changes would have made it fail.  A log would be nice.
[01:11] <GrueMaster> Working on it as fast as these turbo systems will go.
[01:13] <GrueMaster> What is the kernel cmdline to break in init during initrd?
[01:15] <GrueMaster> Hate to say "I told you so", but this is kind of why I was against ext4 switch this late in the game.
[01:24] <GrueMaster> infinity: What is the proper way to break in init prior to premount?  I can't see what is going on with jasper.
[01:26] <infinity> We can switch back to ext3 with almost no effort.  I can do it right now, if you think the failure is the filesystem.
[01:26] <infinity> But if it's not the filesystem, you get to blame all the mx5 changes, and not me. :P
[01:26] <infinity> And the init break would be something like "break=top"
[01:26] <infinity> Or similar.
[01:26] <infinity> Depending on which step you want to break into.
[01:26] <infinity> break=premount, I would assume.
[01:26] <infinity> Unless that happens after premount.
[01:26]  * infinity hasn't hacked initramfs-tools in a while.
[01:26] <twb`> You can just put "break" and it stops just before the pivot_root
[01:26] <infinity> twb`: That's too early.
[01:26] <infinity> Err, late.
[01:27] <infinity> Brain bleeding.
[01:27] <twb`> If you grep for maybe_break over /usr/share/initramfs-tools you can see all the break points
[01:27] <infinity> Yeah.  Just did. :P
[01:27] <twb`> infinity: I hack the shit out of casper to make it work on diskless thin clients -- I know all about initramfs :P
[01:27] <infinity> GrueMaster: You want break=premount
[01:28] <GrueMaster> got it.  Trying.
[01:33] <GrueMaster> export ROOTDEV=/dev/mmcblk0p
[01:33] <GrueMaster> Looks wrong
[01:35] <infinity> Nah, that's right, just unneeded now with jani's changes.
[01:35] <infinity> Since rootpart used to be rootdev+n
[01:36] <GrueMaster> I can't see where it is failing.
[01:36] <infinity> If ROOTPART is correct, then the only place it really could fail is just because resize2fs doesn't work on ext4 (which we know it does, but could be a bug or something)
[01:36] <infinity> Or just a grumpy SD.  My testing worked on one, and not another.
[01:37] <infinity> PS: I hate flash memory.
[01:37] <infinity> Let me grab a copy of this image and flash it.
[01:37] <GrueMaster> fails on both beagleXM and panda.  different cards (4 now).
[01:39] <infinity> I'm perfectly willing to believe there's a bug with resize2fs and ext4 on arm (or in general), just going to look here quickly as well and see if I can see how or why it fails.
[01:39] <infinity> Like I said, switching back is easy (one small diff on antimony), now that jasper itself doesn't hardcode fs types.
[01:41] <GrueMaster> I don't think that is the problem.
[01:42] <GrueMaster> resize works fine manually from init.
[01:42] <infinity> Running the script, or just typing resize2fs manually?
[01:43] <GrueMaster> running resize2fs manually.
[01:43] <infinity> Also, is there a sane way to do kernel command line editing on these things, or do I have to mangle the image?
[01:43] <infinity> Well, I guess, mangle boot.whatever on the card.
[01:44] <GrueMaster> That's what I do.  You could interrupt u-boot also and do it manually.
[01:45] <GrueMaster> The filesystem on /dev/mmcblk0p2 is now 15589376 blocks long.
[01:45] <GrueMaster> I call that a success.
[01:45] <infinity> And ext4?
[01:46] <infinity> In that case, I don't think you get to blame me. :P
[01:46] <infinity> But I'll see if I can figure out WTF *is* going wrong.
[01:47] <GrueMaster> exit
[01:47] <GrueMaster> grr.
[01:47] <GrueMaster> Ok, it seems to be booting through after manually massaging the partitions.
[01:47] <GrueMaster> jasper-growroot has issues.
[01:49]  * infinity goes to meet a woman, get married, and have a few kids, while he waits for this image to flash.
[01:51] <stgraber> infinity: didn't realize flashing images is taking that long now ;)
[01:51] <GrueMaster> Doh!.  Looks like jasper-growroot is mounting the filesystem before resizing.
[01:53] <GrueMaster> It would be nice if these derived variables were also in the log.  Not a single log entry has the variable output.
[01:54] <infinity> GrueMaster: It mounts and the umounts, doesn't it?
[01:55] <GrueMaster> Yes, but who knows if the umount actually happens before it tries to check the drive.
[01:55] <GrueMaster> flash-kernel has timing issues with this.
[02:01] <infinity> I wonder if this is begging for an icky sync solution and we're just racing...
[02:01] <GrueMaster> probably.
[02:02]  * GrueMaster is approaching the 12 hour mark w/o glasses.  Everything is getting real fuzzy.
[02:03] <infinity> Oh, ffs, that image doesn't fit on a 1G card.
[02:03]  * infinity tries his sketchy 16G card that fails half the time.
[02:04] <infinity> This script makes me sad...
[02:05] <infinity> How was $MYECHO deemed less typing than "echo "?
[02:05] <GrueMaster> MYECHO feeds plymouth
[02:05] <infinity> Oh, I missed the if plymouth bit.
[02:07] <GrueMaster> what is this frigging initrd format this week?  I have stripped the uboot crap off, but non of my unpack scripts work.
[02:08] <infinity> Same as it's been for the last several years...
[02:08] <infinity> A cpio archive, compressed with the compression flavour of the month. :P
[02:09] <infinity> gzip still, looks like.
[02:09] <GrueMaster> gzip: initrd.img: not in gzip format
[02:09] <GrueMaster> lzcat: Decoder error
[02:09] <GrueMaster> Those are the two I work with the most.
[02:13] <GrueMaster> xz?  (from mkinitramfs)
[02:13] <infinity> Really?  Mine claim to be gzipped.
[02:14] <GrueMaster> I'm talking about the one on the boot image.
[02:14] <GrueMaster> Stripped first 64 bytes, nothing.
[02:16] <infinity> Ahh, lzma.
[02:16] <infinity> Well, the ones from live-build are.
[02:17] <infinity> Of course, your lzcat still says no to that.
[02:17] <GrueMaster> ARRRGGGG
[02:17] <GrueMaster> file just comes back as data.
[02:19] <GrueMaster> I'm leaving the jasper debug to you.  My head really hurts.  No glasses doesn't help.
[02:27] <infinity> I hate flash media.  So.  Much.
[02:29] <infinity> Wait...
[02:30] <infinity> bad geometry: block count 897024 exceeds size of device (897008 blocks)
[02:30] <infinity> That seems like a bad thing.
[02:32] <infinity> How are we 16 off?
[02:33] <twb`> nand flash itself isn't that bad, it's just the dancing that you have to go through when there's no FTL
[02:34] <infinity> twb`: nand is pretty bad, I have a ton of dead and dying cards.
[02:34] <twb`> Shrug
[02:34] <twb`> I could say the same about HDD or optical media
[02:34] <infinity> Hard drives die a tad more slowly. :P
[02:35] <infinity> (Or, rather, after a lot more use)
[02:35] <infinity> As a write-once (or write-infrequently) medium, nand is great.
[02:37] <twb`> Meh.
[02:37] <twb`> That's partly just that HDDs are more mature technology
[02:38] <twb`> As long as I get 3-5 years of life out of a unit, I'm happy.
[02:43] <infinity> GrueMaster: I'm now wondering if this is a bug we've had for ages, and we only trigger it sometimes...
[02:43] <infinity> GrueMaster: I think we're occasionally creating an image that's one block short.
[02:44] <GrueMaster> What, sync?  I hit it quite often.  Just kept getting told it is only affecting me.
[02:44] <GrueMaster> That bug too.
[02:45] <infinity> The 1 block short thing causes the mount and umount to fail.
[02:45] <infinity> Cause it's a bad FS.
[02:45] <infinity> But resizing works.
[02:46] <GrueMaster> And reflashing over the same SD will occasionally work fine.
[02:47]  * GrueMaster sometimes wishes he could have a developer stand next to him and sucker-punch him for every bug that flies by.
[02:47] <twb`> That sounds like a job for an automaton, not a developer :P
[02:47] <infinity> You have a live-in one, don't you?
[02:48] <GrueMaster> Only when he's awake.
[02:48] <GrueMaster> And he rarely enters my office anymore.  guess he is learning.  :P
[03:11] <dash> howdy. I would like to install ubuntu on an ARM machine for hacking/server usage
[03:11] <twb`> dash: what kind of ARM machine
[03:11] <dash> but I don't know if a machine suitable for that exists :)
[03:12] <dash> twb`: that is my question! where can I find an ARM box that has, like, SATA connections
[03:12] <dash> and a non-tiny amount of RAM
[03:12] <infinity> "box", it's not, but the Freescale i.MX53 QuickStart has SATA.
[03:13] <twb`> Whatever Debian's armel porter boxes run (efikamx?) are probably good for that role
[03:14] <dash> yeah i was looking at the efika smarttop
[03:14] <twb`> Which is a motorol^W freescale underneath
[03:14] <infinity> The quickstart's definitely faster.
[03:14] <infinity> (And Debian's new buildds are those)
[03:14] <twb`> infinity: who do you buy one from?
[03:15] <infinity> I got mine from DigiKey.
[03:15] <twb`> I mean presumably they're BGA so you need to get a mobo+soc combination
[03:15] <infinity> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB
[03:16] <twb`> Huh, I never heard of them but they sound big
[03:17] <infinity> It's about 4 inches square...
[03:17] <twb`> I meant the company
[03:17] <twb`> "Digi-Key is the fourth largest electronic component distributor in North America"
[03:17] <infinity> Oh.  Yeah.
[03:18] <infinity> http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2621773&k=mx53
[03:18] <infinity> Assuming that works without my cookie... Their catalog can be annoying.
[03:18] <twb`> That gives me: (Download)Save file to: dksus.dll
[03:18] <infinity> Yeah, figured it might.  Useful.
[03:18] <twb`> This is why I avoid .com domains
[03:19] <infinity> Just searching for mx53 and clicking on General Embedded Dev Boards will bring it up.
[03:39] <infinity> GrueMaster: Grr.  Despite this fs size bug, everything still works fine on one of my cards. :/
[03:40] <dash> infinity: that looks nice.
[03:40] <dash> 1GB RAM and sata connector means you could use it for something real :)
[03:40] <dash> pity it's the A8 instead of the A9, but whatever
[03:41] <infinity> Yeah, A8 is its only failing, really.  Well, that and being a dev board. :P
[03:42] <dash> meh, i've got gaffer tape :)
[03:43] <dash> i'm just looking for a dinky home server that i can build some software on
[03:43] <dash> to replace my thinkpad t42 whose fan just died
[03:44] <infinity> dash: My MX53 is my Debian and Ubuntu mirror, among other things, when it's not busy rebooting for dev work.
[03:44] <infinity> dash: Works fairly solidly.
[03:45] <dash> nice
[03:45] <dash> well i could always turn my old athlon back on
[03:45] <dash> but that's loud and hot :)
[03:45] <infinity> Yeah, same reason most of my POWER systems aren't on. :/
[03:49] <dash> hmm, welp
[03:49] <dash> this is the first piece of kit i've wanted this year that fry's hasn't had :D
[03:49] <infinity> DigiKey is next day FedEx for 8 bucks (or maybe less in the US?), free for orders over 200.
[03:49] <infinity> So, not the end of the world.
[03:50] <infinity> At least, that's what they do for Canadians.  Maybe they're more cruel to locals. :P
[08:26] <twb> Note to self: next time doing a dist-upgrade within a chroot on a foreign architecture, do --download-only
[08:26]  * twb watches dpkg chug along from within a qemu userspace emulation
[10:40] <ogra_> janimo, no updated mx5 images ?
[10:40] <janimo> ogra_, apparently none with the newer jasper
[10:40] <janimo> still at .60
[10:41] <ogra_> why didnt infinity start a rebuild, do you know ?
[10:41] <ogra_> jasper should be long done
[10:46] <janimo> no idea, I was asleep
[10:47] <ogra_> ok, there were issues with ca-certificates and a mozilla update
[10:47] <ogra_> seems new builds were started around 6am UTC by pitti
[10:48] <ogra_> so we should have them this afternoon (about 6h for one build)
[10:52] <ogra_> janimo, within the next 2h we should have them
[10:53] <janimo> ok
[10:54] <ogra_> so let me find that silly wlan debug setting
[10:54] <huge> hello, I'd like to use ubuntu 10.10 without desktop ... the question is ... how disinstall gnome?
[10:54] <brandini> morning
[10:55] <ogra_> janimo, phy0 -> rt2800usb_txdone_entry_check: Warning - TX status report missed for queue 2 entry 47 ... thats the message in dmesg you get thanks to it ... one every few mins
[10:55] <huge> then i will want to start my own QT/QML ... based on Qt 4.7.4
[10:55] <janimo> ogra_, ah, so not _that _ spammy - I thought it was flooding dmesg
[10:55] <ogra_> janimo, CONFIG_RT2X00_DEBUG
[10:56] <janimo> it can actually be a good debugging clue
[10:56] <huge> is available a debian package for qt4.7.4 for arm with prebuilded libraries?
[10:56] <ogra_> well, spammy enough that you cant read the actual dmesg messages because of it at times
[10:56] <ogra_> its not as bad as one line per second, but still annoying and nothing for a release :)
[10:58] <janimo> huge, I know there are qt 4.7.4 libs in Ubuntu Oneiric, technically debian packages but not sure it's what you're after
[10:58] <ogra_> sigh, but 6h for one desktop image build run is pretty bad, we will need way more livefs builders next release
[10:58] <brandini> I put my usb SSD in and my CF And booted the daily server and things seem to have gone better
[10:58] <brandini> but right now it's stopped at "Waiting for network configuration"
[10:58] <janimo> ogra_, why does a debootstrap take that long?
[10:58] <janimo> what else is happening there?
[10:58] <ogra_> janimo, i think for Qt they package upstream and dont sync
[10:58] <ogra_> (i might be wrong, but i think i remember something like that)
[10:59] <ogra_> janimo, which debootstrap ?
[10:59] <janimo> ogra_, no idea, how do live images get built?
[10:59] <ogra_> you mean running it locally ?
[10:59] <ogra_> ah
[10:59] <janimo> not by debostrapping initially?
[10:59] <ogra_> well, there si debootstrap involved
[10:59] <ogra_> did you ever use rootstock ?
[10:59] <janimo> yes
[10:59] <ogra_> it functions pretty much the same
[11:00] <xranby> huge: debian currently have 4.6.5 in testing/unstable.         the quickest way to remove gnome are    apt-get remove  gdm       and then apt-get install kdm
[11:00] <janimo> but that did never take close to 6 hours here
[11:00] <janimo> an hour at most maybe
[11:00] <ogra_> debootstrap -> apt-get install ubuntu-desktop^
[11:00] <ogra_> then configure some stuff
[11:00] <janimo> ah they happen natively that's why it is slow?
[11:00] <ogra_> and roll the whole into a filesystem image of any kind
[11:00] <ogra_> they have to
[11:01] <ogra_> while we dont really require fast disks for normal buildds (usually CUP and RAM are more important there), livefs builds totally depend on disk speed
[11:02] <ogra_> and thats something we heavily miss (even with fast USB disks you are limited to the bus speed)
[11:02] <ogra_> we shoudl consider an mx5 cluster for livefs builders, so we can use SATA
[11:57] <huge> hello, i've problems with ubuntu-omap4-extras, after installation ubuntu (10.10) does not work fine any more
[11:57] <huge> graphics does not work properly
[11:58] <huge> how to fix this issues??
[12:06] <huge> some help?
[12:08] <xranby> huge: are xorg running?
[12:08] <xranby> huge: did graphics stop after you installed the package?
[12:09] <huge> yes ... after reboot ubuntu is starting in graphics mode but it is not usable
[12:10] <huge> xorg is running.
[12:10] <huge> my HW is pandaboard
[12:11] <xranby> huge: fist check that your pandaboard gets enough power..   how many A can your powersupply deliver?
[12:12] <xranby> huge: try reduce powerconsumption from the board by connecting keyboard and mouse to a self powered usb hub instead of directly connecting them to the board
[12:13] <huge> power supply is +5V
[12:13] <xranby> huge: how many A at 5V can your powersupply deliver   i want to know how many Watt   (A *V)
[12:13] <huge> ah ... sorry
[12:14] <huge> 2.4 A
[12:14] <xranby> huge: ok thats a bit on the low side
[12:15] <xranby> huge: do you have a watt meter?
[12:15] <huge> yes
[12:15] <huge> what to do?
[12:17] <xranby> huge: check that you do not use more than 12W or else you risk  a brownout when using the board
[12:17] <xranby> huge: since you powersupply can only deliver 12W
[12:17] <xranby> huge: a brownout will manifest itself like random crashes and segfaults
[12:18] <xranby> huge: since the board will not get enough power
[12:18] <ogra_> janimo, did you care for mx5 vto be on the iso tracker ?
[12:18] <xranby> huge: if you exceed 12W or are close to using 12W then buy a better powersupply
[12:18] <ogra_> pitti just asks in #ubuntu-release
[12:19] <xranby> huge: that can deliver say 4A 5V+
[12:21] <janimo> ogra_, no idea.  I know too little about the iso tracker and what the implications are for an image to be there
[12:21] <janimo> we want to have the image usable so probably yes i'd say
[12:21] <ogra_> can you tell pitti you want mx5 (and where on the tracker it should go)
[12:21] <huge> so i have need a 20W powersupply??
[12:22] <xranby> huge: remember that one usb device connected to the panda can consume up to 2.5w       so if you connect two usb devices you allready use   5W of the 12W
[12:22] <xranby> leaving only 7w left for the board itself
[12:22] <ogra_> you really only need the 4A if you drive a lot of USB devices on the pand
[12:22] <ogra_> a
[12:23] <ogra_> 2.5 to 3.0 should be fine for normal operations off an SD card
[12:23] <xranby> ogra_: huge's powersupply are 2.4A
[12:25] <ogra_> yes, i saw that
[12:25] <ogra_> for bare SD card installation that should still be ok
[12:27] <xranby> huge: still you have not mentioned why your graphics mode is not usable
[12:27] <xranby> huge: is it stalled ?
[12:29] <huge> no is it not stalled ... the mouse pointer is evil ... when i start application i see only green windows
[12:30] <huge> how can i'm sure that is not an sw problem?
[12:32] <huge> now i've downloaded SGX with Demo Package from http://neuvoo.org/neuvoo/distfiles/SGX-3.01.00.07-SDK.tar.gz ./OGLESEvilSkull Does not start
[12:32] <xranby> huge: can you paste any error message?
[12:33] <huge> libGLES_CM.so is missing
[12:34]  * ogra_ would recommend waiting for rsalveti or robclark 
[12:34] <ogra_> they maintain the sgx drivers (one for TI, one for linaro/ubuntu)
[12:34] <ogra_> they are both on US timezones and should show up soon
[12:35] <huge> maybe can be a reason ... becouse i donìt have libgles2-sgx-omap4-dev installed
[12:36] <rsalveti> huge: install -dev package
[12:36] <xranby> huge: try sudo apt-get install libegl1-sgx-omap4 libgles1-sgx-omap4 libgles2-sgx-omap4
[12:40] <huge> i've installed libgles2-sgx-omap4-dev ... but nothing changed
[12:46] <huge> now i've solved ... was missing a simbolic link for libGLES_CM.so ... but to start ./OGLESEvilSkull i need to have X up ... but in graphics mode ubuntu is not utilizable
[12:54] <huge> also on startx i've: startx (EE) AIGLX error: dlopen of /usr/lib/dri/pvr_dri.so failed (/usr/lib/dri/pvr_dri.so: cannot open shared object file: No such file or directory)
[13:04] <huge> xrandy tried with usb hub ... same problems
[13:07]  * ogra_ runs an ac100 test install ... brb
[13:08] <huge> xrandy what i don't understand ... is that X start, gnome start ... and seems fast ... then when i try to open a simple terminal (in graphic mode) i've white screen
[13:10] <xranby> huge: sounds like a gfx driver bug
[13:10] <xranby> huge: did you check your board powerusage witht he watt meter?
[13:10] <xranby> just to rule out that source of error
[13:10] <huge> i'm going to do ... i need to reboot
[13:11] <huge> just 5 minutes
[13:16] <huge> done
[13:17] <huge> it is max 5 W
[13:19] <huge> so we can exclude problems about powerusage
[13:19] <xranby> huge: great, hopefully robclark here and rsalveti know hot to debug the sgx drivers and can come up with an idea why you get a white screen when you launch the terminal
[13:22] <huge> thank you, robclark/rsalveti could you help me?
[13:25] <brandini> it looks as though the install runs into issues if you don't have your CF card zero'd out before you start your install
[13:28] <huge> hello hello
[13:30] <robclark> huge, umm, ok, what is the issue then?
[13:31] <huge> issues is that after omap4-extra installation, I can't use ubuntu in graphics mode
[13:31] <xranby> robclark: (15.09.06) huge: xrandy what i don't understand ... is that X start, gnome start ... and seems fast ... then when i try to open a simple terminal (in graphic mode) i've white screen
[13:32] <robclark> xterm?  Or gnome-terminal?
[13:32] <robclark> dmesg or /var/log/Xorg.0.log have anything interesting?
[13:33] <huge> gnome-terminal
[13:34] <robclark> is this compiz, or metacity?
[13:35] <huge> and
[13:35] <huge> sgxCopy PVR2DBlt3D with error code -7
[13:36] <huge> sgxComposite: failed  to do composition
[13:36] <robclark> k.. can you pastebin the xorg log?
[13:36] <robclark> (and also check dmesg.. maybe we crashed sgx somehow)
[13:37] <huge> ok, i will ...
[13:40] <huge> i need to install telnetd and to reboot
[13:41] <robclark> (or sshd)
[13:46] <huge> http://pastebin.com/JUd5dwwD
[13:46] <huge> var/log/Xorg
[13:47] <huge> dmesg seems ok
[13:47]  * robclark looks
[13:48] <robclark> error 0x00000003 is INVALID_PARAMS...
[13:49] <robclark> I'm guessing something is fubar in the package..
[13:49] <robclark> maybe some patch merged badly or something like that?
[13:49] <robclark> but sgxCopy shouldn't really fail like that.. it is a pretty basic operation
[13:50] <rsalveti> huge: are you using the sgx packages from stable or trunk ppa?
[13:51] <huge> http://pastebin.com/RMDXYdng
[13:53] <robclark> huge, yeah, kernel level stuff looks ok..
[13:53] <huge> yes yes
[13:55] <huge> i don't understand really ...
[13:57] <huge> i've used this: sudo add-apt-repository ppa:tiomap-dev/omap-trunk
[13:57] <huge> and followed this guide
[13:57] <huge> http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
[14:24] <ogra_> GrueMaster, respin in progress, enjoy your morning coffee and relax :)
[14:31] <GrueMaster> planned on it.
[14:31] <ogra_> seems pitti didnt think that üpreinstalled needs ubiquity at all
[14:31] <ogra_> so we have a broken oem-config still
[14:32] <ogra_> (crashing very badly if you do a non networked install)
[14:37] <GrueMaster> sigh
[15:21] <huge>  robclack ... some help ? :)
[15:51] <huge> rsalveti : do you suggest to use sudo add-apt-repository ppa:tiomap-dev/release ??
[15:51] <huge> instead of trunk?
[15:55] <rsalveti> huge: trunk in theory works
[15:55] <rsalveti> unless something else changed and broke the ppa
[15:56] <huge> so how to solve my isuess? :(
[15:57] <GrueMaster> ogra_: jasper is still broken.
[16:09] <ogra_> GrueMaster, on mx5 ?
[16:09] <ogra_> janimo, ^^^
[16:10] <GrueMaster> ogra_: nevermind.  Appears my mirror sync was not sync'd.  It gets confused when we start triggering builds manually.
[16:10] <ogra_> .oO( would really be helpful if that was discussed here and not in teh other channel )
[16:11] <ogra_> ;)
[16:11] <ogra_> GrueMaster, thanks for notifying here :)
[16:12] <GrueMaster> I tend to go where the people that can fix things pop their heads up.  Kind of like whack-a-dev.
[16:12] <GrueMaster> (since so few of you guys seem to use windowed IRC systems and only hover over one channel at a time).
[16:13] <ogra_> i dont :)
[16:14] <infinity> Ew?
[16:14] <infinity> Err, "Eh".
[16:14] <infinity> I get lovely annoyances when people correctly nick highlight me. :P
[16:14] <infinity> And I blissfully ignore even the window I'm "watching" when they don't.
[16:16] <GrueMaster> infinity: This is based on years of conditioning on this team.  Not everyone is the same, however I tend to follow best practices for all.
[16:17] <GrueMaster> And when I see a critical release-stopping issue, I go hunting for immediate assistance.  You should have seen the flack a few releases ago when I didn't.
[16:19] <ogra_> well, stop making up excuses we all fail in that regard (including me) and use the wrong channel to often
[16:23] <GrueMaster> infinity: I still don't see a 0.62 tag in jasper bzr.
[16:23] <ogra_> infinity, so there are people poking me about a partitioner in the ac100 installer ... which i refuse to write ... i'm wondering, since you wanted to move the jasper bits into d-i, we could probably also have a tarball installer udeb
[16:25] <GrueMaster> I do see your patch to fix partition detection.
[16:26] <infinity> GrueMaster: That would be because I didn't tag it. :P
[16:26] <infinity> GrueMaster: There.  Happy? ;)
[16:27] <GrueMaster> Like I said yesterday, I am just keeping everyone on their toes.
[16:27] <infinity> ogra_: Yeah, it should all be in d-i somehow or other.
[16:27]  * ogra_ whacks infinity 
[16:27] <ogra_> use debcommit !
[16:28] <ogra_> it auto tags if the changelog is right
[16:28] <infinity> Meh.
[16:29] <infinity> I'm actally completely opposed to people trying to switch source packages to bzr repositories, I might be avoiding tagging as a subconscious protest. :P
[16:30] <ogra_> oh, i fyou actuvely do it i will join in
[16:30]  * ogra_ prefers source debs too, but gave up on fighting for it 
[16:30] <ogra_> it doesnt look like it has much chance
[16:31] <infinity> I have no problems with package collaboration in a VCS, I have huge issues with building directly from that VCS.  Maemo did that, and it wasn't an improvement over the old skool Debian way in any way.  It just made people feel like they were more "cutting edge" or some crap.
[16:32] <ogra_> well, i still also prefer apt-get source ... edit, dpkg-buildpackage ... upload
[16:32] <ogra_> and theoretically UDD should DTRT with that and push it into the bzr branch
[16:33] <infinity> ogra_: And some day, it might.  I hope.
[16:33] <infinity> ogra_: I dislike the idea that one person's workflow needs to be imposed on another.  So, if that can all Just Work, cool.
[16:34] <ogra_> heh
[16:38] <brandini> so I just took the time to zero out both SD cards and flash the preinstalled server image
[16:38] <brandini> lets hope it works this time :(
[16:40] <infinity> GrueMaster: Phew.
[16:40] <infinity> GrueMaster: Resize works here. :P
[16:40] <infinity> GrueMaster: Your stale mirror has me scared. :)
[16:40] <infinity> s/has/had/
[16:40] <GrueMaster> ok.  Still pulling updated images here.
[16:41] <infinity> So, who's good at partition math?
[16:41]  * ogra_ hides
[16:41] <GrueMaster> It's as if zsync completely fell over for all the images I pull.  Each one is taking ~15 minutes to pull.
[16:42] <infinity> I suspect this is a bug we've had for months/years, but I think we're generating images that are a block short around 50% of the time.
[16:42] <GrueMaster> And my link light on my DSL router is blinking faster than my eyes can refresh.
[16:42] <infinity> Which means losing a bit of random data off the end of the ext* filesystem.
[16:42] <ogra_> you mean it woulod try to write there ?
[16:42] <infinity> I mean the partition is shorter than the filesystem.
[16:43] <brandini> infinity: on the dailies?
[16:43] <ogra_> hmpf
[16:43] <infinity> brandini: Mmhmm.
[16:43] <ogra_> after resize or at build time ?
[16:43] <infinity> EXT4-fs (sdb2): bad geometry: block count 897024 exceeds size of device (897008 blocks)
[16:43] <infinity> Build time.
[16:43] <ogra_> bah
[16:43] <infinity> After resize, it's "fine".
[16:43] <GrueMaster> I notice it more with 16G SD.  Not sure but could be layout related.
[16:43] <infinity> Because it re-fits it.
[16:43] <brandini> that's why all my daily attempts fail :(
[16:43] <infinity> But that still means it's missing a tiny bit of data, and we have no idea what. :)
[16:44] <brandini> me too, my 32GB SD works and my 16 doesnt :(
[16:44] <ogra_> infinity, given that we add 50M spare space ....
[16:44] <infinity> ogra_: Err, where?
[16:44] <ogra_> chances are good its just empty space
[16:44] <GrueMaster> brandini: If you are trying daily-preinstalled this week, it fails for a whole lot of reasons.  Next build "should" be better.
[16:44] <ogra_> infinity, in the TI contract :)
[16:44] <infinity> ogra_: Oh, you mean on the livefs itself.
[16:45] <ogra_> infinity, i originally added 50M to the post-boot scripts, if thats not there anymore, ask who removed it
[16:45] <infinity> ogra_: Still, the partition being short for the FS is broken. :P
[16:45] <ogra_> sure
[16:45] <infinity> ogra_: Wait.  No, I'm confused.  You're adding 50M padding to the partition, or to the filesystems?
[16:45] <ogra_> but if the overlap is for empty space and the partitioning is fine after install, thats not a biggie
[16:45] <infinity> ogra_: Cause I see no padding on the partitions.
[16:45] <ogra_> to the fs indeed
[16:45] <infinity> Which is sort of the problem..
[16:45] <brandini> GrueMaster: :(
[16:45] <ogra_> so TI can modify the panda images for blaze
[16:46] <ogra_> well, the 50M are added before the partitions are created
[16:46] <ogra_> iirc we are creating an img file with 50M more than the chroo occupies
[16:47] <infinity> ogra_: I must be missing where that happens.
[16:47] <ogra_> *chroot
[16:47] <infinity> ogra_: Or it doesn't anymore. :P
[16:47] <ogra_> should be in post-boot
[16:47] <infinity> I've been staring at post-boot for the last day.
[16:47] <ogra_> that might be, i havent touched the omap/omap4 script in a release
[16:47] <infinity> Though, mostly that one block of shell arithmetic.
[16:47] <GrueMaster> sounds like more craknschpiel.
[16:47] <infinity> That I think is off by a block.
[16:47] <ogra_> i think only NCommander did
[16:49] <ogra_> the 50M are essential though
[16:49] <brandini> so I should use the 11.04 release instead?
[16:50] <infinity> Current oneiric server images seem fine.
[16:50] <infinity> Keep in mind that some cards will just hate you, too. :P
[16:50] <brandini> :)
[16:50] <brandini> they all do!
[16:51] <ogra_> infinity, oh, might be that we did it in livefs.sh, not in post-processing code
[16:51]  * ogra_ chaks livecd-rootfs
[16:52] <infinity> ogra_: That would make more sense, if the goal is to have a bigger FS.
[16:52] <infinity> ogra_: Since a bigger partition doesn't actually give you a bigger filesystem. :)
[16:52] <ogra_> yes
[16:52] <brandini> I really wish I could boot off my usb drive
[16:53] <ogra_> livefs_ext2()
[16:53] <ogra_> {
[16:53] <ogra_>   # Add 1024MiB extra free space for first boot + ext3 journal + swapfile
[16:53] <ogra_>   size=$(($(du -ks ${ROOT} | cut -f1) + (1024000)))
[16:53] <ogra_> there it is
[16:53] <ogra_> no idea why thats not 50M anymore
[16:54] <ogra_> infinity, oh, btw, are we still properly creating the swapfile in live-build ? else beagle C4 wont work anymore
[16:54]  * ogra_ just noticed we moved that into livecd.sh
[16:56] <infinity> I doubt it.
[16:56] <ogra_> (C4 will OOM if you try to run desktop and have no swap)
[16:56] <infinity> But nothing there was turning it on either...
[16:56] <ogra_> jasper does
[16:57] <infinity> Then jasper can create it too?
[16:57] <ogra_> it also used to create the file
[16:57] <ogra_> but that adds 10.15 min to the jasper run
[16:57] <ogra_> 10-15
[16:57] <infinity> Eh?
[16:57] <infinity> It should be instant.
[16:57] <ogra_> no
[16:57] <ogra_> you have to dd 512MB
[16:57] <infinity> You can dd it sparse.
[16:57] <ogra_> sawpfiles cant have zeros
[16:57] <ogra_> or holes
[16:58] <ogra_> mkswap will refuse to use it, try it
[16:58] <ogra_> (ignore that i said zeros above :) )
[17:01] <infinity> root@vishnu:~# time dd if=/dev/zero of=test.swp bs=512 count=0 seek=1048576
[17:01] <infinity> 0+0 records in
[17:01] <infinity> 0+0 records out
[17:01] <infinity> 0 bytes (0 B) copied, 6.2626e-05 s, 0.0 kB/s
[17:01] <infinity> real	0m0.011s
[17:01] <infinity> user	0m0.000s
[17:01] <infinity> sys	0m0.000s
[17:01] <infinity> root@vishnu:~# time mkswap test.swp
[17:01] <infinity> mkswap: test.swp: warning: don't erase bootbits sectors on whole disk. Use -f to force.
[17:01] <infinity> Setting up swapspace version 1, size = 524284 KiB
[17:01] <infinity> no label, UUID=87833675-2023-43d1-83a8-63afbd948484
[17:02] <infinity> real	0m1.531s
[17:02] <infinity> user	0m0.000s
[17:02] <infinity> sys	0m0.010s
[17:02] <infinity> ogra_: ^--- Not seeing a problem.
[17:02] <ogra_> swapon ?
[17:02] <infinity> Oh. :P
[17:02] <infinity> You said mkswap would refuse to use it. ;)
[17:02]  * ogra_ would have been surprised :)
[17:02] <ogra_> sorry, its a year ago i had to do with it ...
[17:02] <ogra_> so it was swapon
[17:03] <ogra_> i just know it doesnt work
[17:03] <infinity> That's a bit silly, given that I can create files on a filesystem on a loopback device with holes.
[17:03] <infinity> In fact, I could create a swapfile on a filesystem on a loopback with holes, and it would work!
[17:03] <ogra_> well, swapon would refuse too in that case i bet
[17:04] <infinity> Nope.
[17:04] <infinity> (Hint: Our SD card image has "holes")
[17:04] <ogra_> sure
[17:04] <ogra_> the swapfile itself doesnt
[17:05] <ogra_> not sure how that gets handled on fs level if your fs has holes though
[17:05] <infinity> Well, holes are a temporary inconvenience.
[17:05] <infinity> The VFS layer masks around sparse files.
[17:06] <infinity> I can only assume that VMM is doing nasty things to VFS, and they should sit down for a timeout.
[17:06] <ogra_> might be ...
[17:07] <infinity> Anyhow.  That whole swap creation thing has been broken/nonexistant for months (ever since the live-build switch), and no one has complained. :P
[17:07] <ogra_> well, in any case we need to look into that for post beta
[17:08] <ogra_> likely because not even GrueMaster tests desktop on C4 anymore :)
[17:08] <infinity> That was sort of my point.
[17:08] <GrueMaster> I haven't tested desktop on much of anything in the last few weeks.
[17:08] <infinity> I suspect no one tests or uses it.
[17:09] <infinity> (On that hardware)
[17:09] <ogra_> well, but if we offer images for it, it has to work
[17:09] <ogra_> or we restrict what we support
[17:09] <ogra_> or drop the image
[17:09] <infinity> We offer images for "omap", we don't specify which boards...
[17:09]  * ogra_ wouldnt mind to drop C4 support
[17:09] <GrueMaster> Can't drop the image.  It still supports XM
[17:09] <infinity> That's like saying Ubuntu Desktop works on every x86 machine (it doesn't).
[17:10] <ogra_> infinity, we offer omap3 images for beagleboards
[17:10] <infinity> ogra_: Yes, there are lots of beagles that it works on.
[17:10] <ogra_> we need to make clear ^that we dont support C4 imho
[17:10] <GrueMaster> We can limit what we support, and leave other systems to user discression.
[17:10] <ogra_> especially since the C4 was our only supported TI board for a while
[17:10] <GrueMaster> XM in, C4 out for desktop.
[17:10] <ogra_> right
[17:11] <infinity> ogra_: Well, the other option is to have jasper take that 10 minutes to dd a swapfile if (and only if) you're on a C4.
[17:11] <ogra_> needs to go into the release notes
[17:11]  * ogra_ will happily see the swapfile crap die 
[17:11] <GrueMaster> infinity: Anything on C4 takes a lot longer than on other platforms.
[17:11] <ogra_> infinity, well, i didnt like that hack when i added it, i dont like it more today :)
[17:11] <infinity> Heh.
[17:12] <infinity> I will say I was pretty effin' shocked to discover a swapfile on my SD card when I first set up the Panda.
[17:12] <GrueMaster> As to my beagle, I honestly do not have any room for that atm.  I am out of desk space/network drops/power cords.
[17:12] <infinity> Cause swapping to nand flash is about as smart as shaving your scrotum with a cheese grater.
[17:12] <ogra_> that i'm the guy who writes most of the scary weired hacks doesnt mean that i particulary admire what i hack together :)
[17:13] <ogra_> *weird
[17:13] <GrueMaster> done that.
[17:13] <ogra_> infinity, as you mantioned above, swapfiles sit on top of the VFS layer ... they should be less harmful than a swap partiton
[17:13] <ogra_> i wonder where all these typos come from today
[17:14] <infinity> ogra_: It's pretty harmful.  But so it almost everything a modern system can do to flash.
[17:14] <infinity> (I've killed a card here just with /var/log)
[17:14] <infinity> s/so it/so is/
[17:14] <ogra_> well, you have a stack of FTL->VFS->swapfile
[17:14] <ogra_> at least on SD
[17:15] <infinity> But I wasn't just referring to the destruction of the flash, I was also just talking the speed.  I'd probably rather invoke the OOM killer than swap to monkeys with pencils.
[17:15]  * ogra_ hasnt killed a card in 4 years ... i had some dead USB keays from my classmate times
[17:15] <ogra_> OOM will tear your app down
[17:15] <infinity> Yup!
[17:15] <ogra_> swapping will come back after the IO is done
[17:15] <ogra_> so you can still save your document
[17:16] <infinity> From the C4 perspective (that couldn't run desktop at all), the swapfile made sense.
[17:16] <ogra_> even if it takes 1h
[17:16] <infinity> On my Panda, it made less sense. :P
[17:16] <infinity> S'all I'm saying.
[17:16] <ogra_> swapfile makes always sense on systems where you potentially can hit OOM imho
[17:16] <ogra_> just because of the above
[17:16] <infinity> That's every system in the world.
[17:16] <infinity> But you'll still OOM when you fill swap.
[17:16] <infinity> So.
[17:16] <ogra_> well, chances on my 4G intel are less than on my 512M XM
[17:17] <infinity> Eventually, you hit a point where you're saying "this is how much memory I have".
[17:17] <Neko> happy medium: use zram to cache swap pages in compressed memory, and reduce soujourns to disk until it's absolutely necessary?
[17:17] <infinity> (Unless you do the dynamic swap thing, then your wall is just disk space)
[17:17] <ogra_> Neko, yes, we used to use compcache in the past
[17:17] <ogra_> i was planning to have a spec on it for UDS
[17:18] <GrueMaster> What is going on with cdimage?  My zsync is extremely slow.  Been updaing one image now for almost an hour.
[17:18] <infinity> Honestly, I think we're hitting a point where we don't care anymore about that sort of thing.  Or shouldn't.
[17:18] <ogra_> GrueMaster, many people download ?
[17:18] <infinity> Modern ARM systems (at least the ones we target) have RAM, can have more, and can swap to storage that isn't flash.
[17:18]  * GrueMaster hates release week.
[17:18] <ogra_> infinity, well, zram/compcache can easily add another 50% of ram for no costs
[17:19] <ogra_> and its a good first level swap
[17:19] <infinity> ogra_: The cost is CPU time.  That never mattered on ARM, where memory I/O was shit, and CPU was free as a result, but that's changing.
[17:19] <ogra_> the cup time cost isnt really noticeable
[17:19] <infinity> ogra_: When we become cycle-bound instead of i/o bound, we need to watch our solutions.
[17:19] <Neko> big problem though, you have to make sure it is added first. When we ran the init scripts they came up far, far after disk swap was enabled, and without specifically bumping priority to 0 (since disk swap came in at -1) it wouldn't use it
[17:19] <ogra_> we did experiment with compcache in the past on the C4 and older
[17:20] <ogra_> and there wasnt a noticeable hit on CPU back then
[17:20] <Neko> then of course, if you use prelink, running firefox with a few tabs, leaving a system on for days and days, your compressed swap fills with discarded linker data
[17:20] <ogra_> ubuntu will never use prelink i think
[17:20] <infinity> ogra_: Yes, I know the CPU time wasn't noticeable (and, in fact, it probably made things faster), but like I said, all ARM systems until now have been I/O bound.
[17:20] <ogra_> sure
[17:20] <infinity> ogra_: When your CPU is idle half the time, waiting on RAM, compressing RAM is a huge win.
[17:20] <ogra_> and they will stay that way for more releases :)
[17:21] <Neko> efika isn't so i/o bound :)
[17:21] <infinity> Its memory bandwidth isn't that exciting.
[17:21] <ogra_> its CPU neither :)
[17:21] <Neko> it isn't on most ARM boxes
[17:21] <infinity> Thank you for restating my point?
[17:22] <ogra_> tegra has a pretty decent memory bandwith
[17:22] <ogra_> faster than panda
[17:22] <Neko> you can have all the memory bandwidth in the world but running off a USB disk or SD card is basically negating everything there
[17:22] <infinity> Eh?
[17:23] <infinity> Are you from the "I benchmark applications by cold-cache starting them?" camp?
[17:23] <infinity> How fast Firefox starts != how fast it runs.
[17:23] <Neko> well, let's put it this way; it took 4 hours to compile a kernel on pandaboard. I can do it in 70 minutes on an Efika with -j3.
[17:23] <infinity> And memory I/O is hugely important.
[17:24] <infinity> Neko: Odd, I have both here, and the Panda nearly always wins compile races.
[17:24] <ogra_> definitely
[17:24] <infinity> Neko: Was that when you were getting 5MB/s off a Panda's USB?
[17:24] <Neko> it's purely down to the SD card in use.. and it's a good SD card
[17:24] <ogra_> ac100 wins over both though :)
[17:24] <Neko> no I don't use USB on the Panda
[17:25] <infinity> Neko: Oh, if you're compiling on SD, that's a lost cause.  And a pointless comparison.
[17:25] <Neko> just a UHS SD card.. which isn't so ultra-high-speed since the bus seems limited to about 10MB/s
[17:25] <ogra_> thats bad
[17:26] <Neko> booting over USB on Panda helps but for some reason it doesn't help all that much.  it still loses the kernel compile race, even building on another disk.. there is some very strange stuff there, I think combined with the extremely poor SD and USB performance, even when that's fixed, SMP slows things down.. it builds faster on -j1 than it does on -j2
[17:26] <GrueMaster> Neko, what is the performance on the efika with the same SD card doing the same job?
[17:26] <Neko> I can't say I've attemped it in about 3 weeks though
[17:26] <Neko> GrueMaster, about the same, the point would be that no matter how good you think your SD card is, it's actually not.
[17:27] <GrueMaster> kernel patch fixed usb performance last week.  Retest, then talk about it.
[17:27] <Neko> and USB disks don't solve anything...
[17:27] <steev_> Neko: don't talk bad about the pandaboard
[17:27] <infinity> They do if they work. :P
[17:27] <Neko> I like my pandaboard
[17:28] <GrueMaster> The point is, when you spout performance benchmarks on two different systems, that you are actually reducing as many variables in the test setup.  Comparing Sd vs Sata is blindingly stupid and invalid.
[17:28] <Neko> btw USB disk in question was an A-Data MLC SSD.. the bus limits it's performance over USB (but it's topping out somewhere else).
[17:28] <Neko> nobody ships a SATA system except Quickstart
[17:29] <GrueMaster> Again, update kernel & retest.
[17:29] <infinity> Neko: About 7 times now, people have mentioned that your USB disk tests were getting about 5MB/s, and that's fixed.
[17:29] <dash> Neko: i just found out about trimslice
[17:29] <infinity> Neko: And yes, when your I/O is throttled that low, -jN will make it worse, since concurent reads just block hard.
[17:29] <Neko> trimslice is USB to SATA
[17:29] <dash> !
[17:29] <dash> well that's no good
[17:29] <dash> glad i bought an mx53 instead then
[17:30] <Neko> the only chip out there with a native sata controller is the mx53.. it's sad to say, it really is
[17:30] <dash> soon i will have my first web server with an accelerometer
[17:30] <ogra_> trimslisce has the fill PCIe bus available (unlige other tegra implementations) you can easily use a miniPCI SATA card
[17:30] <ogra_> s7fill/full/
[17:31] <Neko> infinity, I tried a bunch of things, there were questions about SMP causing it, which turned into that write buffer flush patch.. I disabled SMP a long while back and it gave me back my performance, but it still lost. Perhaps the CPU itself, or some power management was in the way, or just USB being the worst possible protocol with too much overhead and zero possibility for DMA
[17:56] <NCommander> infinity: the post-boot scripts for armel are made otu of cheap gum and duct tape
[18:04] <dash> oh, i take it back, that thinkpad had an accelerometer.
[18:30] <GrueMaster> infinity: The current respin, what was affected?  oem-config?
[19:37] <GrueMaster> Wow.  Lots more chatter from the kernel in dmesg.  Mostly audio and wifi.  There will be bug reports.
[19:39] <brandini> :)
[21:37]  * GrueMaster stares at the beaglexm screen and silently wonders why oem-config restarted a second time.
[21:55] <GrueMaster> So, we no longer are doing swap files on omap images?  System is real slow.
[21:55] <infinity> We haven't been for months.
[22:01] <GrueMaster> Why not?  This is very slow with only 512M.
[22:01] <GrueMaster> Had I been able to do daily image testing, I would have raised a flag a long time ago.
[22:02] <infinity> Because that code was in livecd-rootfs, and it never got moved to live-build, and no one noticed until today.
[22:02] <infinity> I swear we just had this conversation this morning.  That was the context of "dropping C4 support".
[22:03] <infinity> And not to question what you're seeing, but the speed issues could be elsewhere.  I refuse to believe that swapping to flash could make anything *faster*, just less prone to OOMing.
[22:03] <GrueMaster> Well, may as well drop all armel support without it.  Even the panda daily is very slow, with all of the cruft added by DX.
[22:04] <GrueMaster> crap.  panda hung.
[22:04] <GrueMaster> Hard hang while oem-config was configuring locales.
[22:07] <GrueMaster> As to swap, not sure what is going on, but my loadavg just dropped after creating a 1G swapfile and enabling it.
[22:17] <infinity> GrueMaster: I'm happy to hack swapfiles into live-build to resurrect the functionality.  It's just not happening for B2.
[22:18] <GrueMaster> Wasn't talking about B2 required.  But it would be nice to know about these changes before release.
[22:18] <infinity> They do drastically infalte the size of the image, though (not the zipped size, since the swap is empty, but the real size).
[22:18] <infinity> Yeah, no one seemed to be aware until, like I said, today. :P
[22:18] <infinity> But it's been like this since the switch.
[22:18] <GrueMaster> And yes, I am seeing a huge amount of swapper errors in dmesg on beaglexm.
[22:19] <infinity> Like..?
[22:19] <infinity> You can't reall have swap errors without swap.
[22:19] <infinity> s/reall/really/
[22:20] <GrueMaster> Can't?  Tell that to my system.
[22:20] <infinity> Oh, wait.  You mean a page allocation error?
[22:20] <infinity> If so, then yeah, that's just OOMing.
[22:21] <infinity> I find it a bit sick that we can't boot with 512M of RAM.  But whatever. :P
[22:21] <infinity> We'll fix it.
[22:24] <GrueMaster> Yea, I've heard that line a lot this cycle.  :P
[22:24] <GrueMaster> BTW:  Installer is still on the unity menu bar after login.
[22:24] <infinity> Lovely.
[22:27] <GrueMaster> Rebooted beaglexm with /SWAP.swp, desktop looks much different.
[22:27] <GrueMaster> I have a top indicator bar, for example.
[22:28] <infinity> Picky, picky. ;)
[22:29] <infinity> Yeah, fuck omap3 for now, then.  If it boots at all, ship it, realising that the underlying software is identical to omap4.  And light a fire under my ass post-B2 to get you swapfiles back.
[22:34] <GrueMaster> Bah.  ENONETWORK again on my beaglexm.
[22:57] <brandini> is there a new daily image that is worth downloading?
[23:00] <brandini> also, is there any way to make the serial console actually display useful output ?
[23:00] <infinity> Define useful?
[23:01] <brandini> well right now when I connect and the installer comes up it's so jumbled I can't even tell what it says
[23:01] <brandini> using the default terminal app in ubuntu, export TERM=vt220 minicom and no dice :(
[23:02] <infinity> brandini: Oh, minicom's just crap.
[23:02] <brandini> I also tried screen, cu and gtkterm
[23:02] <infinity> brandini: "screen /dev/ttyUSB0 115200" is your friend.
[23:02] <infinity> (Or whatever your serial device is)
[23:02] <infinity> At least, it always DTRT here.
[23:03] <brandini> I did try that... not looking good
[23:04] <infinity> Not sure what to suggest, then.  That always works for me.  It's not perfect, but it's certainly usable.
[23:04] <infinity> I think terminal emulation became a lost art when BBSes died.  I miss Telemate and Telix.
[23:05] <GrueMaster> brandini: Do you have a null modem cable attached?  If so, remove it.
[23:05] <GrueMaster> What image are you trying?
[23:05] <brandini> GrueMaster: I have a usb to serial adapter
[23:05] <GrueMaster> Ok, plug that straight into the panda.
[23:05] <brandini> oneiric-preinstalled-server
[23:06] <brandini> does the preinstalled from today have the partition/packaging issue fixed?
[23:06] <GrueMaster> Today's?  20110921 is the one you want.
[23:06] <brandini> ok
[23:06] <GrueMaster> Seems to.
[23:06] <brandini> this mirror is SO SLOW
[23:07] <brandini> an hour to grab 500mb?
[23:07] <brandini> I don't need the manifest or zsync right?
[23:07] <GrueMaster> Yea, having same issue here and I use zsync (which in theory only pulls binary differences).
[23:07] <infinity> No, but if you have the old image, you could just "zsync http://path/to/zsyncfile"
[23:07] <brandini> oh really...
[23:07]  * brandini tries
[23:07] <GrueMaster> Once you have the img.gz, you can update it with zsync.
[23:07] <infinity> The old image needs to be in your CWD.
[23:08] <brandini> I can handle that much:)
[23:08] <GrueMaster> not nessarily. Use "zsync -i <old image> http://cdimage....<new image>"
[23:09] <infinity> Well, yes.  But no need for -i if you just want to update it in place. :)
[23:09] <GrueMaster> The "old image" can even be a different name (or even subarch, which is kind of interesting).
[23:09] <brandini> 88% complete
[23:09] <brandini> nice!
[23:10] <brandini> I didn't know about zsync
[23:11] <brandini> this pandaboard seems like it will be absolutely great as a webserver
[23:12] <GrueMaster> I've tested it.  As long as you don't expect high (as in slashdot.org) traffic, it is pretty nice.
[23:12] <brandini> no, I don't
[23:12] <brandini> what are your apps written in?
[23:12] <GrueMaster> Part of my testing included the entire lamp stack.
[23:12] <brandini> or just static html
[23:13] <GrueMaster> More install and run some prepackaged website.
[23:13] <GrueMaster> Then nuke and run some other test.
[23:13] <brandini> I'm using go
[23:14] <GrueMaster> Let me know how it works out.
[23:17] <brandini> even on my atom proc it does thousands of reqs/sec
[23:18] <GrueMaster> I just hope to get an arm based server in the near future.  Testing the server stacks on what is essentially a cell phone is not pleasant.
[23:18] <GrueMaster> (although running 6 pandas in a filesystem cluster makes me giggle).
[23:19] <brandini> :)
[23:19] <brandini> I wouldn't mind a panda farm
[23:19] <dash> mmm, panda farm
[23:20] <dash> of course. how else would we get those delicious panda steaks
[23:20] <brandini> :)
[23:21] <brandini> GrueMaster: I did have go built on the arm on 10.10... decided I wanted 11.x and didn't build any of my apps on the pandaboard
[23:23] <GrueMaster> Do you have a link?
[23:23]  * GrueMaster is always interested in using new apps as test suites.
[23:24] <brandini> www.golang.org
[23:24] <brandini> it's the new python, ruby, java :)
[23:24] <GrueMaster> sigh.  yet another language for me to learn.
[23:25] <dash> eh
[23:25] <dash> go isn't all that.
[23:25] <dash> it's a bunch of old ideas thrown together, some of them good, some of them dumb
[23:27] <GrueMaster> I'm self taught in C, C++, JAVA, Perl, Atari-basic, x86 assembly, to name a few.  Adding to the stack heap is getting painful.
[23:27] <GrueMaster> No formal programming training.
[23:27] <infinity> GrueMaster: You didn't see Gustavo's Go presentation in Dublin?
[23:27]  * GrueMaster was teaching more than learning in the University of Phoenix course.
[23:28] <infinity> GrueMaster: And the company-wide challenge to go (re)write random crap in Go for kicks?
[23:28] <GrueMaster> infinity: I may have missed it.
[23:28] <GrueMaster> (and when have I had spare time to go programming for kicks?)
[23:28] <infinity> Apparently, there are prizes at stake.
[23:28] <GrueMaster> in any language.
[23:28] <infinity> This hasn't motivated me, mind you.
[23:29] <GrueMaster> hmm, prizes you say.
[23:29] <dash> heh
[23:29] <dash> go! it's so great, they have to bribe people to use it.
[23:29]  * GrueMaster wonders how many engineers and managers he could piss off by rewriting all of the qa tests in go?
[23:35] <brandini> if you rewrite a C program in Go you have to use Go conventions rather than your C conventions
[23:35] <brandini> or it's not worth the effort
[23:50] <brandini> even this new images says "If you created or changed a DOS partition, /dev/(1) to zero the first 512 bytes: dd if=/dev/zero...
[23:51] <brandini> oh, it says partition 2 does not end at a cylinder boundary
[23:52] <GrueMaster> Ignore it (unless it has actually failed).
[23:54] <brandini> still resizing
[23:54] <brandini> 95/100
[23:54] <GrueMaster> What size SD?
[23:55] <brandini> 32GB
[23:55] <GrueMaster> Whoa.  If you run into issues, please let me know.  I don't have anything that big.
[23:55] <brandini> ok
[23:55] <brandini> if that fails should I try a 16GB?
[23:56] <GrueMaster> I have a few 16G, and a lot of 8G.  Nothing bigger.
[23:56] <GrueMaster> Well, it hasn't been tested (by me) on 32G.
[23:57] <GrueMaster> I'm on a 16G right now.  No problems yet.
[23:57] <infinity> My Panda runs on a 32G, but I haven't tested that since early oneiric.
[23:57] <infinity> I see no reason why it would have stopped working, though.
[23:57] <brandini> it hit 100/100 and the lights are still blinken
[23:57] <infinity> I have a stupidly high miss rate for bad media in general though. :/
[23:57] <brandini> Kingston?
[23:58] <infinity> All over the map.
[23:58] <infinity> Kingston, Patrio, non-name junk, Lexar.
[23:58] <brandini> the one I'm using now has the rainbow on the front
[23:58] <GrueMaster> brandini: That is normal.  The counter is just a shell script routine.  resize does a litlle post-processing.
[23:58] <infinity> Actually, the Lexar cards are the only ones that have never acted up, but I doubt that's a quality thing, and suspect it's just random statistical luck.
[23:59] <brandini> woot, creating bootloade
[23:59] <brandini> just restarted