[00:35] <the_eye__> I am running ARM Ubuntu on a HTC Diamond how can I upgrade to latest
[00:36]  * persia checks specs, as this is often *not* a good idea
[00:38] <persia> the_eye__: According to http://www.qctconnect.com/products/msm_7201.html upgading to the latest Ubuntu will likely result in illegal instruction errors.
[00:38] <persia> You want to run Ubuntu 9.04 on that hardware, and *not* upgrade to any later release of Ubuntu.
[00:40] <the_eye__> ok
[00:41] <the_eye__> How to upgrade to 9.04 then
[00:47] <the_eye__> ?
[00:50] <persia> WHich version are you running?
[00:51] <persia> Because ARM support wasn't added to Ubuntu until 9.04.
[00:51] <persia> (but the mojo project did have some builds)
[00:51] <rcn-ee> oh, i wouldn't touch those, too bit rotten.. ;)
[00:52] <the_eye__> 8.04
[00:52] <persia> rcn-ee: I'm presuming that it's an old install, and looking for recovery to sanity.
[00:53] <persia> the_eye__: That's indeed likely to be a mojo build.  That's not directly upgradable, because of a change to the architecture name ("arm" to "armel").  You'd have to reinstall.
[00:53] <rcn-ee> good point.. yeah that was hasty, it actually worked on a htc phone?
[00:54] <the_eye__> I understand so I had to install the new one all the way
[00:55] <the_eye__> rcn-ee: yes it works
[00:55] <persia> the_eye__: Unfortunately, yes.  Sorry about that.
[00:55] <rcn-ee> the_eye__, cool.. i remember helping the mojo guys out, with first getting to run on the beagle....
[00:55] <persia> the_eye__: And only install 9.04.  9.10 and newer require newer processors than that device contains.
[00:56] <rcn-ee> did you do a chroot install or just a debian-install?
[00:56] <the_eye__> no bad feelings :)
[00:57] <the_eye__> I try 9.04 then
[00:58] <persia> Good luck with it.
[00:58] <the_eye__> rcn-ee: I installed an image from here http://forum.xda-developers.com/showthread.php?t=640785&page=77
[00:58] <persia> the_eye__: You may want to try to get a working 2.6.28 kernel first, as this is what 9.04 will expect.
[00:59] <rcn-ee> okay i see, they provided an image to dump in the sd card..
[01:01] <the_eye__> yes, and I loaded with haret, without changing my rom
[01:21] <DanaG> what is the "el" in armel?
[01:23] <persia> I've always thought it stood for endian-little
[01:23] <persia> But I could be wrong.
[01:24] <persia> An alternate interpretation is "EABI little-endian", which makes more sense, as compared to "endian-big" as a proper opposite.
[01:25] <rcn-ee> that's correct... i had to refresh my debian naming... at the time of the armel creation they left open the possibility of a 'armeb' for big-endian..
[01:32] <persia> rcn-ee: armeb predates armel in Debian.
[01:34] <rcn-ee> yeap, that was the old abi variant..
[01:35] <rcn-ee> i'm so close with rootstock, ogra's last change gets me a little farther, but it's kinda random past that...
[01:36] <persia> debootstrap seems to be working again for lucid.  What's the blocker?
[01:38] <rcn-ee> right now its: http://pastebin.com/twaXDppk  so far for about 8/10 runs.. but i'm also playing with the cache settings as mentioned in 532733
[01:40] <rcn-ee> one of the runs about an hour ago, segfaulted after closly finishing "uboot-netbook"
[01:41] <persia> Ugh.  That does end up being 90 random things.
[02:47] <DanaG> http://www.ifixit.com/Misc/iphone_processor_crossection.jpg
[02:47] <DanaG> nice
[02:47] <DanaG> that's a good way to describe package-on-package.
[03:09] <DanaG> "add bootloader = flash-kernel"...
[03:09] <DanaG> hmmm
[04:22] <DanaG> [   26.829498] HS USB OTG: no transceiver configured
[04:22] <DanaG> [   26.834442] musb_hdrc musb_hdrc: musb_init_controller failed with status -19
[04:28] <DanaG> great.... my asix is broken again.
[04:28] <DanaG> And my musb also is broken.
[04:29] <DanaG> http://pastebin.com/THwXNMEE
[04:29] <DanaG> wow, that's a nice "word".
[04:29] <DanaG> thwxnmee!
[04:35] <DanaG> ah, adding twl4030-usb to initramfs ahead of musb_hdrc fixed it.
[04:36] <styol> is there a way to retrieve/store/copy the contents of a flash drive prior to formatting it?
[04:37] <styol> basically ive got this awesome $90 netbook that comes with windows CE and an ARM processor but im essentially looking to backup the current OS and replace with something else like ubuntu arm, angstrom, or some other streamlined linux OS.. any general recommendations?
[04:40] <DanaG> You may be able to copy the contents of the MTD stuff using dd.
[04:41] <DanaG> What netbook is this?
[04:42] <styol> this is an EPC-702
[04:42] <styol> im not familiar with MTD or dd sorry im a supreme newbie to ARM and this sort of stuff :( im technically savvy just not with this (yet)
[04:43] <DanaG> MTD is "memory technology device"
[04:43] <DanaG> such as NAND flash.
[04:43] <styol> gotcha yeah this is a 2gb nand flash utilizing XIP
[04:45] <styol> so far i've got "F1 to update the system" at boot, asks for password, its ztk, then it gives me the options to format nand disk, format xip disk, format flash2 disk, update xip, update eboot
[04:57] <DanaG> hmm... any option to boot from an sd card?
[04:57] <DanaG> Or to check what's in the disk?
[04:58] <DanaG> hmm, there's both nand and flash2?
[04:58] <DanaG> xip is the kernel, most likely.
[04:58] <DanaG> eboot... not sure.
[05:01] <DanaG> sounds like the winCE boot loader.
[05:02] <NCommander> styol: its likely someone has to port the linux kernel to that board or device before you'll have any luck running on it
[05:03] <DanaG> http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_25366423.html -- is this you?
[05:03] <NCommander> persia: armeb is dead in Debian and was never an official port. If we need an EABI big endian port, it will be armeb
[05:03] <styol> thats not me but thats where i got the password from hehe
[05:03] <styol> my friend has an ad blocker and apparently it makes the answers appear, nothing particularly helpful
[05:04] <styol> DanaG yeah it has SD reader.. not sure why theres both nand and flash2
[05:06] <DanaG> hmm, unfortunately, there seems to be very little info on that EPC-701 thingy.
[05:06] <styol> how can i find out more information about this board? this is about all i have to go off of CPU: AK7802 and this at boot - http://img.vishun.com/IMG_0759.JPG
[05:06] <DanaG> Not even a spec of what ARM it is.
[05:06] <styol> 702 not sure if it makes a difference
[05:06] <styol> a friend claims that its the same processor that the motorola razr v3m uses
[05:06] <DanaG> http://en.wikipedia.org/wiki/ARM_architecture
[05:07] <DanaG> arm926ej-s
[05:07] <DanaG> search for that.
[05:07] <DanaG> hmm, is that "versatile"?
[05:08] <styol> not sure.. im a bit confused ;)
[05:11] <DanaG> somebody more knowledgeable about ARM stuff would have to answer that.
[05:11] <DanaG> interesting... my Cowon S9 has a Telechips 7901 in it.
[05:11] <styol> thanks very much for your help DanaG, its much appreciated
[05:12] <DanaG> hmm, you could also ask in #hardware, perhaps.
[05:13] <styol> ill give it a whirl for sure
[05:15] <NCommander> styol: its unlikely you'll be able to run Linux on that device. Unlike most other architectures, ARM doesn't have a standized mechanism of bringup, so the early system components through to the kernel must be tailored for each device
[05:17] <styol> NCommander ah ok.. hrm yeah it does seem to be something that might be a bit of a stretch.. curious, how do devices that run ubuntu arm normally get ubutu arm installed?
[05:18] <styol> found one thing thats promising.. http://www.arm.com/community/software-enablement/linux.php
[05:20] <NCommander> styol: on paper, there are two ways
[05:21] <NCommander> 1. A vendor works with Canonical and Canonical adds the support to Ubuntu
[05:21] <NCommander> 2. Community members take Ubuntu/ARM and port it themselves (i.e., beagle community). Due to optimizations used in ubuntu, only a small subset of devices can run Ubuntu/ARM sadly
[05:22] <styol> yeah that makes sense
[05:23] <NCommander> styol: looking at your device, Ubuntu's specs are too high (your chip only implemented ARMv5 it seems. Ubuntu on AMR needs Ubuntu ARMv7+Thumb2)
[05:23] <NCommander> s/AMR/ARM
[05:24] <styol> ARMv5TEJ yeah?
[05:24] <styol> how about something like Angstrom, or ttylinux
[05:24] <styol> http://www.angstrom-distribution.org/ http://www.minimalinux.org/ttylinux/downloadARM.html
[05:25] <NCommander> styol: well you still need kernel support before that's going to work unfortunately.
[05:26] <styol> kernel support by one of those systems?
[05:26] <styol> how about http://www.arm.linux.org.uk/
[05:26] <NCommander> styol: the Linux kernel is a special type of application that sits inbetween the raw hardware, and the userland (aka, the set of applications that the user interacts with it)
[05:28] <styol> how can i determine what this has presently?
[05:28] <styol> the first arm.com has an image you can download that says the kernel is supported for
[05:28] <NCommander> styol: if its running Windows CE, then its running the Windows CE client :-)
[05:29] <styol> ARM926EJ-S (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0184-)
[05:29] <NCommander> styol: its not that simple. Even if the SoC (or processor) is supported, the board as a whole must also be supported
[05:31] <DanaG> ARGH -- stupid asix.
[05:31] <DanaG> It's giving me ZERO packets.
[05:31] <DanaG> wow, and now it randomly came up.
[05:32] <DanaG> nope, it's just seeing its own outgoing arp.
[05:33] <DanaG> I see this looping on usbmon1:
[05:33] <DanaG>   7.039795          4.1 -> host         USB URB_INTERRUPT
[05:33] <DanaG>   7.039825         host -> 4.1          USB URB_INTERRUPT
[05:36] <DanaG> It loops, and never goes anywahere.
[05:36] <DanaG> Even does it with no ethernet cable plugged in.
[05:37] <DanaG> Upon plugging in a different usb-ethernet thingy, I see usb URB_CONTROL
[05:42] <DanaG> I suppose I should ask on the mailing-list about that.
[09:47] <nosse1> Do you know how to control the screen (tty / fb) blanking interval? After a given time the LCD goes blank
[10:06] <amitk> nosse1: setterm -blank 0 -powerdown 0 ?
[10:28] <nosse1> amitk: thanks
[12:49] <asac> hmmm ... so ffox debug build from trunk doesnt have frame/scrollbar issue for me
[14:02] <dmart> NCommander: hi there
[14:03] <hrw> hi
[14:05] <ogra> rcn-ee, meh, your initramfs patch uses bashisms ...
[14:13] <ogra> asac, can you put bug 563618 on the release meeting agenda ? it hits us hard on beagle
[14:13] <ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[14:17] <hrw> hi blotr
[14:19] <TheWhiteGhost> hey hrw
[14:58] <asac> ogra: seems the initramfs approach looks quite ok
[14:58] <asac> is that tested?
[14:58] <ogra> not yet
[14:58] <ogra> i'm still in rootstock tests that eats all my resources
[15:00] <ogra> asac, also that not all of it, there needs to be a hook to get all the binaries into the initramfs
[15:00] <ogra> i'll try to improve and test it today
[15:03] <dmart> A couple of comments...
[15:04] <dmart> You assume that the argument to root= is a UUID.  For systems set up by Ubiquity that's probably not a problem, but embedded devs will often use the device name instead when tweaking the boot config by hand
[15:04] <ogra> embedded devs will probably not even use an initramfs
[15:04] <dmart> Does that work these days?  I remember it being very unreliable in karmic days
[15:05] <ogra> but yes, i see your point ... the fix i work on is rather for the current official omap image though
[15:05] <ogra> it got a lot better
[15:05] <persia> no-initramfs works fine, but requires a bit of tweaking to boot (and is less safe as a generic model)
[15:05] <ogra> and i think the approach is that you *can* run your system without initramfs if youwant in certain cases
[15:05] <ogra> right
[15:05] <ogra> it will always stay for the std distro
[15:06] <dmart> Also, the hwclock backend often doesn't work during kernel porting I remember having a lot of trouble with this earlier during iMX51 support
[15:06] <ogra> but if people have a selected set of packages and cant install harmful stuff its pretty safe to go without one
[15:06] <ogra> i'm not sure if fsck even looks at the hwclock
[15:06] <ogra> it might suffice to use date --set
[15:07] <dmart> No, but hwclock --hctosys is used to set the soft clock
[15:07] <dmart> Maybe do both?
[15:07] <ogra> yeah, i'll discover such stuff when i test :)
[15:07] <persia> It's not feasilble to have both online-updates and can't-install-harmful-stuff
[15:08] <ogra> persia, it is if you use your own archive
[15:08] <persia> We can only do hard-to-install-harmful-stuff
[15:08] <persia> ogra: No it isn't, because of DNS spoofing.
[15:08] <dmart> ogra, anyway, looks like a reasonable workaround
[15:08] <ogra> and restrict to it indeed
[15:08]  * dmart still thinks e2fsck is wrong, but that's another discussion...
[15:09] <ogra> dmart, i agree though i also agree with Keybuk who says it needs to be solved on the actual filesystem layer
[15:09] <ogra> i guess we need to fix both
[15:09] <dmart> sure, it needs more thinking about
[15:09] <persia> Gets harder for ext3/ext4 than ext2, but yeah.
[15:10] <dmart> But if we rely on the reliability of the RTC _at all_ for preserving low-level fs consistency, that sounds really scary, especially for dual boot configs where something else may interfere with the clock sometimes
[15:10] <ogra> lool, writeback hangs too (just reached iso-codes in rootstock this second)
[15:12] <persia> dmart: Without reliance on the RTC, how can we know the time?
[15:13] <dmart> If you need to know the time, you are at risk.  I need to understand more about the way the fs works though, in order to understand whether knowledge if the time is actually needed to ensure consistency
[15:14] <dmart> It's worth considering that the journal has already been replayed before we get into userspace, so if the RTC really mattered, the fs has already been corrupted.
[15:14] <persia> I don't know the deep details, but my limited understanding is that the journalling is timestamped.
[15:15] <persia> Well, except in the initramfs case, in which case we're in userspace without actually using the filesystems.
[15:15] <persia> (or rather, without using on-secondary-storage filesystems)
[15:15] <dmart> fair point
[15:15] <dmart> afaict, serial numbers (not timestamps) are used in the on-disk structures in jbd{,2}.h, but I confess I don't really understand how it all works yet...
[15:15] <persia> heh, yeah.
[15:16] <persia> Would probably benefit from a discussion with the fs devs at some conference.
[15:16] <ogra> i dont think the journal has been touched until you get to mountall ... and it wont be touched until mountall remounts in RW mode (note that we specify ro on the cmdline by default)
[15:17] <persia> ogra: The journal has to have been replayed to be able to mount RO.
[15:17] <persia> Otherwise you have an inconsistent filesystem state.
[15:17] <dmart> Mouting a dirty journalled filesystem ro does replay the journal
[15:17] <ogra> persia, replayed but not changed
[15:17] <persia> right.
[15:17] <ogra> there wont be changes on disk yet
[15:17] <persia> But the issue we have is at fsck time, not at mount time.
[15:18] <persia> Well, except for refuse-to-mount-because-of-fs-age
[15:18] <dmart> Not sure about that -- the kernel prints out "temporarily mounting fs read-write to recover the journal" (or something like that(
[15:18] <persia> (but that's just a sanity check)
[15:18] <ogra> dmart, aww, evil
[15:18] <persia> dmart: Ooh, that makes lots of sense, and completely changes the semantics :)
[15:18] <dmart> maybe that just happens when mounting the root fs... ?  dunno
[15:19] <dmart> easy to test
[15:20] <dmart> I guess you need to replay or unwind the journal to mount, because the metadata might be inconsistent garbage until you do that
[15:20] <ogra> ah, yeah
[15:20] <persia> That makes sense.  So we need to be sure we're somewhere sane.
[15:20] <dmart> Unless you're using ext2 (it's still garbage, but you just hope the system doesn't explode ;) )
[15:21] <persia> No, if we happen to have a reliable, working, RTC, I expect that having a date in the future is a good indication of likely corruption.
[15:21] <persia> s/No/Now/
[15:21] <dmart> I think 90% of the times I've triggered that problem it's been the RTC, not the fs, which is corrupt.  But it depends on what you're trying to do.  "Normal" users shouldn't hit that so much.
[15:22] <ogra> wow, neither hwclock, nor date nor dumpe2fs are in the initramfs
[15:23] <dmart> argh
[15:23] <ogra> i would have expected the latter to be missing
[15:23] <dmart> settimeofday?
[15:23] <ogra> but surely not the first two
[15:23] <persia> RIght.  The tricky bit is to come up with something that works for both end-users and bring-up-developers
[15:23] <ogra> nah, no issue, i'll write a hook that copies them
[15:24] <ogra> i just didnt expect date to miss ...
[15:24] <ogra> nor hwclock
[15:24] <dmart> Is the "last mount time" recorded in the fs the time the filesystem was last mounted, or the time it was unmounted?
[15:24] <ogra> both i think
[15:24] <dmart> Really we would want to set the clock to the last unmount time (except where there was a crash the the fs wasn't unmounted)
[15:24] <ogra> last mount action
[15:24] <dmart> hm
[15:25] <persia> How is "mount action" defined?  Is that mount+unmount?
[15:25] <ogra> i guess so
[15:25] <ogra> (i was also guessing above)
[15:25] <ogra> there is only that value in dumpe2fs
[15:25] <persia> That sounds like desired behaviour.  Now I wonder if that's how it's implemented.
[15:25] <dmart> The ext3 superblock has "mount time" and "write time".  Dunno their behaviour though
[15:26] <ogra> yeah, i see the same in dumpe2fs
[15:26] <dmart> Does anyone know a filesystem expert?
[15:26] <ogra> i guess the stamp is updated by mount/umount
[15:26] <ogra> Keybuk is probably closest
[15:34] <dmart> It could still be worth discussing it at UDS
[15:35] <asac> ogra: session name?  booting clockless systems with journaling FSes?
[15:36] <asac> BootingWithTimeZero ;)
[15:36] <ogra> asac, RTCless
[15:36] <ogra> but yes
[15:36] <ogra> or batteryless :)
[15:36] <asac> ok i will add that
[15:36] <amitk> asac: not clockless please, use non-rtc or something
[15:36] <asac> amitk: Booting With Time Zero ;)
[15:36] <ogra> our prob is that we *have a clock*
[15:36] <asac> whatever causes this condition is probably irrelevant ;)
[15:36] <persia> dmart: Keybuk suggested a discussion at UDS would be fruitless unless we had the fs developers there (and it may be late for them to make travel plans)
[15:37] <ogra> persia, i disagree
[15:37] <persia> Fair.  Just sharing.
[15:37] <zumbi> hi! about gcc-4.4 in karmic, which is current? 4.4.1 (--with-arch=armv6) or 4.4.3 (--with-arch=armv7-a)?
[15:37] <ogra> while i agree for the superduper proper fix that might be needed it isnt for finding the cleanest solution that doesnt involve filesystems
[15:38] <ogra> since the filesystem fix might take years
[15:38] <persia> zumbi: According to https://launchpad.net/ubuntu/+source/gcc-4.4 4.4.1 and it ought be ARMv6, as the rest of karmic is supposed to be that.
[15:39] <zumbi> uhm.. ok thanks persia
[15:39] <persia> ogra: Oh, a session on workarounds could work, as long as everyone understands it's workaounds.
[15:39] <ogra> right
[15:39] <ogra> the filesystem fix will likely require a design change
[15:39] <zumbi> so Lucid is armv7-a :)
[15:39] <asac> ogra: dmart: let me know if you think you can lead a session on that booting zero time stuff
[15:40] <asac> otherwise i will note it down as a blueprint without session
[15:40] <ogra> asac, i'm happy to
[15:40] <persia> zumbi: Mostly.  Only ~7000 packages have been recompiled, so there's still bundles that may be ARMv6 or even ARMv5.
[15:40] <asac> ogra: but do you have all the details so we can achieve something?
[15:40] <ogra> asac, though i dont know how many sessions i have assigned at all
[15:40] <ogra> might be a lot or none ... nobody tells me
[15:40] <persia> zumbi: But I'd say that the majority of packages that generate ELF binaries are likely to have been recompiled.
[15:41] <asac> ogra: you had two ... iirc
[15:41] <ogra> asac, well, i know the problem and the possible areas for fixing
[15:41] <asac> i avent added them to the table/schedule yet. but will do
[15:41] <asac> if you want to drop one of the suggested ones let me know
[15:43] <ogra> nah, all fine
[15:43] <ogra> if its not 50 that i dont know about yet there is nothing to discuss :)
[15:50] <asac> bug 559295
[15:50] <ubot4`> Launchpad bug 559295 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel-installer needs to learn to handle omap (dup-of: 562888)" [High,New] https://launchpad.net/bugs/559295
[15:50] <ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu Lucid) (and 3 other projects) "omap installation failed with unrecoverable error (affects: 2) (dups: 2)" [Medium,Invalid] https://launchpad.net/bugs/562888
[15:50] <asac> bug 559297
[15:50] <ubot4`> Launchpad bug 559297 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel needs to learn to handle omap (dup-of: 562888)" [High,New] https://launchpad.net/bugs/559297
[15:50] <asac> bug 559301
[15:50] <ubot4`> Launchpad bug 559301 in partman-uboot (Ubuntu Lucid) (and 1 other project) "partman-uboot needs to handle omap installs (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/559301
[15:51] <asac> bug 563618
[15:51] <ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[15:51] <asac> ogra: what about partman? is that RC still?
[15:52] <ogra> asac, invalid
[15:52] <asac> can yo do that?
[15:52] <ogra> done
[15:52] <asac> ogra: both flash-kernel things too=
[15:52] <asac> ?
[15:52] <asac> e.g. see above
[15:52] <asac> bug 559144
[15:52] <ogra> they are duped to the ubiquity one
[15:52] <ubot4`> Launchpad bug 559144 in udisks (Ubuntu Lucid) (and 1 other project) "[armel] udisks-part-id crashed with signal 7 in memcpy() (dup-of: 561426)" [High,New] https://launchpad.net/bugs/559144
[15:52] <ubot4`> Launchpad bug 561426 in parted (Ubuntu Lucid) (and 1 other project) "partman dies when trying to detect disks due to kernel error (affects: 1) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/561426
[15:53] <asac> ogra: so all invalid for flash-kernel-* ?
[15:53] <asac> bug 541030
[15:53] <ubot4`> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1)" [High,Fix released] https://launchpad.net/bugs/541030
[15:53] <asac> ogra: so only omap issue is bug 563618 ?
[15:53] <ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[15:53] <ogra> asac, nope, the flash-kernel task on bug 562888 is fix released already ... ubiquity was just uploaded
[15:53] <ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu Lucid) (and 3 other projects) "omap installation failed with unrecoverable error (affects: 2) (dups: 2)" [Medium,Invalid] https://launchpad.net/bugs/562888
[15:53] <asac> bug 541399
[15:54] <ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) (and 1 other project) "netboot image fails to boot. (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/541399
[15:54] <asac> hmm
[15:54] <asac> so that was fix committed ... now its invalid
[15:54] <asac> well
[15:54] <ogra> asac, only *known* omap issue, i need to have images i can test now
[15:54] <asac> bug 514257
[15:54] <ubot4`> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 8)" [High,Won't fix] https://launchpad.net/bugs/514257
[15:54] <asac> bug 528524
[15:54] <ubot4`> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps through pulse on arm (affects: 3) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/528524
[15:54] <asac> ogra: we never had a working image?
[15:54] <ogra> bug 541399 is a mess
[15:55] <asac> bug 528524
[15:55] <ogra> asac, no, flash-kernel and ubiquity were missing, we never had one that finished the bootloader part
[15:55] <asac> yeah
[15:55] <asac> but thats not our release goal afaiui
[15:55] <asac> so its not RC
[15:55] <asac> oh
[15:55] <asac> hmm
[15:55] <asac> ogra: ok
[15:55] <asac> so bootloader missing?
[15:55] <ogra> asac, Bug #541399 is fix released for d-i (i did the change and upload)
[15:55] <ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) (and 1 other project) "netboot image fails to boot. (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/541399
[15:55] <ogra> the bot shows the wrong task
[15:55] <asac> ogra: ok. i dont list released bugs anymore
[15:55] <asac> ;)
[15:56] <asac> bug 532733
[15:56] <ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 4) (dups: 1) (heat: 32)" [High,Incomplete] https://launchpad.net/bugs/532733
[15:56] <asac> bug 528887
[15:56] <ubot4`> Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 3) (heat: 18)" [Medium,Triaged] https://launchpad.net/bugs/528887
[15:56] <asac> bug 555977
[15:56] <ubot4`> Launchpad bug 555977 in openoffice.org (Ubuntu Lucid) (and 1 other project) "openoffice.org FTBFS on armel (affects: 1)" [High,Fix released] https://launchpad.net/bugs/555977
[15:56] <asac> is ooo build now?
[15:57] <asac> ogra: please checkout https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[15:57] <asac> plars: ^^
[15:57] <asac> i am cros checking with the buglist now
[15:58] <ogra> looks fine
[15:58] <asac> hmm
[15:58] <asac> bug 559065
[15:58] <ubot4`> Launchpad bug 559065 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "ifconfig eth0 down will cause system hang after fec.c driver update (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/559065
[15:58] <asac> whats up with that?
[15:58] <asac> ogra: ?
[15:58] <ogra> mountall+fsck and qemu-kvm hang are my most serious ones
[15:58] <asac> wasnt that done?
[15:58] <ogra> i think the description is nonsense
[15:58] <ogra> plars, ?
[15:59] <ogra> well, or it should be fix released
[15:59] <plars> ogra: I didn't see that with the newest kernel
[15:59] <asac> is that RC? .... what does driver update mean? module reloaded?
[15:59] <ogra> since the described issue is gone
[15:59] <asac> usually we dont reload modules
[15:59] <plars> ogra: I think that bryan saw that, and thought it may be related to the suspend/resume issues
[16:00] <ogra> well, but you dont see the hang anymore
[16:00] <plars> but his kernels that I tested, that certainly did not have this bug in it, still would not suspend/resume
[16:00] <asac> bug 522858 is new?
[16:00] <ubot4`> Launchpad bug 522858 in maximus (Ubuntu Lucid) (and 2 other projects) "Sometimes app windows come up undecorated, unselectable, and not full screen (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/522858
[16:00] <plars> asac: the fec driver code was updated in the kernel
[16:00] <asac> plars: but how can that change something?
[16:01] <asac> without reloading the kernel/module?
[16:01] <plars> asac: because we have a new kernel with the new code in it
[16:01] <asac> bug 67544
[16:01] <asac> whats that?
[16:01] <ubot4`> asac: Bug 67544 on http://launchpad.net/bugs/67544 is private
[16:01] <plars> very old apparently...
[16:01] <asac> why is such an old bug targetted for us?
[16:01] <ogra> 67544 ?
[16:01] <asac> i will drop that
[16:01] <plars> are you missing a digit?
[16:02] <asac> no
[16:02] <asac> plars: no seems doko gave it to us
[16:02] <persia> Please don't drop it.
[16:02] <plars> looks like persia has commented on it before
[16:02] <persia> It's an old bug, but it's very valid.  That bug represents pascal support for armel.
[16:03] <ogra> asac, doko is also fixing it it seems
[16:03] <asac> yeah
[16:03]  * persia has been watching that bug since before armel was available in Ubuntu.
[16:03] <asac> persia: good. i will call you to give info during release meeting when questions come up ;)
[16:03] <asac> so be prepared (in 20 minutes i guess)
[16:03] <persia> If I'm still awake sure.  Ping me first (I'm getting really close to sleep).
[16:04] <persia> Basically, some of us can build it, and lamont can't, and nobody knows why.
[16:05] <persia> doko did a first-stage bootstrap that is hoped to ease the situation.
[16:05] <persia> Oh, I will be awake.  The release meeting seems to have moved with DST.
[16:07] <asac> persia: right. as i said: about 20 minutes till we are on :)
[16:14] <plars> asac: you said all done for porting to thumb2, but there are still a couple of needs porting to thumb2 bugs that are rc targeted
[16:14] <asac> plars: those are not armel tagged then
[16:14] <asac> i just looked at the list
[16:14] <plars> asac: yes they are
[16:14] <asac> https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscrib
[16:14] <plars> asac: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/514253
[16:15] <ubot4`> Launchpad bug 514253 in qt4-x11 (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 10)" [High,Won't fix]
[16:15] <plars> asac: https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/514257
[16:15] <asac> plars: thats wont fix
[16:15] <ubot4`> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 8)" [High,Won't fix]
[16:15] <asac> plars: wont fix too
[16:15] <plars> ah
[16:15] <plars> didn't look in the bug, just did a search
[16:15] <plars> must have at least one task that isn't won't fix
[16:15] <asac> plars: a search that includes won't fix? ;)
[16:15] <asac> plars: lucid task is wont fix
[16:15] <asac> i probably left the normal task open
[16:15] <plars> yeah
[16:15] <asac> so yeah
[16:15] <plars> asac: was that intentional? just won'tfix for lucid then?
[16:16] <plars> I will untarget them then
[16:16] <persia> It's a bug in LP that there's no good way to do that :(
[16:16] <asac> bug 528524
[16:16] <ubot4`> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps through pulse on arm (affects: 3) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/528524
[16:16] <plars> no sense in having them targetted if they are wontfix
[16:16] <asac> plars: wont fix is the way to untarget
[16:16] <plars> hmm, except they are still milestoned
[16:16] <asac> plars: thats the way you get a normal task back
[16:17] <asac> plars: but they are wont fix ... so they are hidden from all listss ;)
[16:17] <asac> unless you search for invalid+wontfix ;)
[16:17] <asac> feel free to change them to match your needs though
[16:17] <plars> asac: I just did search for tags including armel and milestoned for 10.04, and I did not include invalid or wontfix
[16:17] <asac> plars: right. you didnt search for "lucid"
[16:18] <asac> you have to go to bugs.launchpad.net/ubuntu/lucid
[16:18] <asac> nd then use advanced search there
[16:18] <asac> and
[16:18] <plars> yeah, I just started from ubuntu
[16:18] <asac> feel free to unmilestone ... but if the not targetted task is milestoned its not RC in the book of release team
[16:18] <asac> means: opportunity to fix for that milestone
[16:18] <asac> or for personal prioritization
[16:21] <plars> asac: there is https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551491 that ericm milestoned for 10.04, but it's not targeted to lucid, I doubt it will happen in time though
[16:21] <ubot4`> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress]
[16:21] <asac> plars: thats not rc ...
[16:21] <asac> SRUs etc.
[16:21] <asac> we can target and milestone for :later
[16:21] <asac> if we want to ensure that gets in
[16:22]  * plars would like to confirm ericm's plans with him first, but that's my assumption
[16:29] <ogra> ogra@ubuntu:~$ date
[16:29] <ogra> Sat Jan  1 01:01:14 CET 2000
[16:29] <ogra> ogra@ubuntu:~$
[16:29] <sn9> has anyone tried any flavor of ubuntu on one of these? http://delstar.net/multi-function-devices/ds700-netbook.html
[16:29] <ogra> wohoo !
[16:29] <ogra> works !
[16:31] <sn9> no one?
[16:41]  * asac out to run some errands
[16:43] <ogra> sn9, no kernel for that device and 128MB wont be fun
[16:43] <sn9> i was thinking MID edition or something
[16:45] <TheWhiteGhost> ogra what hardware you running on?
[16:45] <sn9> which generation arm is that, anyway?
[16:45] <ogra> TheWhiteGhost, frescale imx51, marvell dove and beagle
[16:45] <ogra> recent ubuntu requires ARMv7
[16:46] <persia> And doesn'T include MID anymore (it ended up being too hard to integrate the libgtk stuff).
[16:46] <sn9> i don't know whether samsung qualifies
[16:46] <sn9> persia: because of arm?
[16:47] <persia> sn9: Not at all.  It was about the nature of the hildon-gtk changes.
[16:47] <sn9> i mean, MID is gone from arm, or gone altogether?
[16:47] <persia> gone altogether.  flavours are independent of architectues.
[16:48] <sn9> anything replacing it?
[16:49] <persia> Not right now.  There's been a lot of work to get LXDE ready, but it didn't quite make it for lucid.  It will probably make it for maverick.
[16:49] <sn9> ko
[16:49] <sn9> *ok
[16:49] <persia> There's also been a lot of work on the Qt/Plasma front, which might hit maverick or might hit maverick+1, depending.
[16:50] <persia> The Mer folk did a tremendous job of integrating later releases of hildon, but we just couldn't merge all that back into Ubuntu because of the libgtk issues.
[16:50] <persia> And I don't know of anyone chasing that anywhere to make it work (hildon work seems unfashionable these days)
[16:51] <sn9> so, basically, for lucid, it's netbook edition or bust, but 128MB is too thin for that, right?
[16:51] <persia> Or roll-your-own works.
[16:51] <sn9> right
[16:51] <persia> LXDE should mostly just work, but the integration isn't 100% yet (and there aren't any images)
[16:52] <persia> The Qt/Plasma stuff isn't ready at all yet, although there's kubuntu netbook which has some of the same technologies (but has the same issues at 128MB)
[16:52] <sn9> which generation arm are the samsung cpu's?
[16:52] <persia> Depends which samsung cpu :)
[16:52] <persia> (but none of them have distro kernels)
[16:52] <sn9> unfortunately, that page did not say, as you saw
[16:54] <persia> Oh, that?  I heard that device was ARMv5.
[16:54] <persia> I may be mistaken though.
[16:56] <hrw> most of s3c are armv4t, some are armv5te. s3c6410 is armv6 iirc
[17:02] <sn9> google seems to suggest arm9
[17:03] <hrw> sn9: arm9 can be armv4t or armv5te
[17:03] <hrw> sn9: there are ARM core numbers and ARM ISA (instruction set arch) numbers
[17:04] <hrw> arm920t is armv4t, arm926ejs is armv5te
[17:04] <sn9> S3C2450
[17:06] <hrw> arm926ejs
[17:06] <sn9> so no ubuntu
[17:06] <sn9> past jaunty
[17:07] <hrw> yep
[17:07] <hrw> but Debian may work
[17:07] <hrw> but getting linux working in it is probably more expensive task then buying something linux supported
[17:07] <sn9> debian is armv6 and above, i thought
[17:08] <hrw> no, Debian is armv4t
[17:08] <sn9> i know for a fact debian does not support armv4
[17:09] <hrw> it is hard to find armv4 device today
[17:09] <sn9> 920 is not all gone yet
[17:10] <sn9> i think gentoo is the only thing that supports armv4
[17:10] <hrw> gcc 4.4 can generate EABI binaries for armv4....
[17:10] <hrw> sn9: OpenEmbedded distros also supports
[17:10] <hrw> I have to go
[17:10] <sn9> ok
[17:21] <persia> We tend to recommend folks with older HW run Debian though, just because 90% of bugs found in Debian also apply to Ubuntu (as well as the fixes), and using the same development technologies makes it easy to come back once one has newer hardware.
[17:24] <sn9> interesting how just-released hardware is "old"
[17:25] <persia> sn9: Older processors.  You can go buy a brand-new device that implements the i486 instruction set if you want, to show a parallel to ia32.
[17:25] <persia> That can't run Ubuntu either.
[17:26] <sn9> looks like there's a forum thread: http://ubuntuforums.org/printthread.php?t=1414364&pp=75
[17:26] <persia> So the age is about the time-since-processor-design, or even time-since-architecture-specification rather than about time-since-manufacture or time-since-purchase
[17:52] <dmart> ogra, you still there?
[17:53] <ogra> dmart, yep
[17:53] <ogra> seen -devel ?
[17:53] <dmart> Thanks for offering to lead the BootingWithTimeZero thing --- I was offline for a while (honest!)
[17:53] <ogra> heh
[17:54] <ogra> have a look at the backlog in -devel :)
[17:57] <dmart> ogra: Oh you mean the upstreamed proposal to ignore date issues in e2fsck with broken_system_clock
[17:57] <dmart> Hmmm, does that mean we don't need to bother?
[17:57] <ogra> well, probably not for maverick
[17:58] <ogra> but for lucid ...
[18:00] <dmart> right... I guess we need to pull together the proposed workarounds and choose one
[18:11] <ogra> hrm, it doesnt work and i dont get why
[19:08] <rcn-ee> ogra, just an odd ball idea, have you tried bypassing qemu's image files and just using a real disk?  i know it's not the best method in the end, but i just add 2nd sata drive to test... ;)
[20:02] <rcn-ee> laughs, it actually seemed to get farther, right before a kernel panic: [ 1306.403516] Kernel panic - not syncing: Attempted to kill init!  current patch (didn't implement the final save to file conversion) http://pastebin.com/FK3TaViG
[20:29] <andruk> rcn-ee: hey, did you ever get the spidev patch working?
[20:30] <rcn-ee> nope, sorry andruk, not yet, it's still on my list for this week..  I'm playing with a hacked up rootstock at to the moment..
[21:26] <prpplague> ~seen davidm
[21:26] <prpplague> hmm guess no bot in the channel
[21:28] <armin76> !seen davem
[21:28] <ubot4`> I have no seen command
[21:28] <armin76> :D
[21:28] <prpplague> ahh thanks different prefix
[21:28] <prpplague> ~seen davidm
[21:28] <prpplague> !seen davidm
[21:28] <ubot4`> I have no seen command
[21:29]  * prpplague checks the bot help
[21:30] <prpplague> bummer
[23:30] <styol> NCommander after a couple hours i was finally able to determine which cheap device i will need to try accomplish what im trying to do ;) ping me when you're around, id love to share