[00:35] 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] 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] You want to run Ubuntu 9.04 on that hardware, and *not* upgrade to any later release of Ubuntu. [00:40] ok [00:41] How to upgrade to 9.04 then [00:47] ? [00:50] WHich version are you running? [00:51] Because ARM support wasn't added to Ubuntu until 9.04. [00:51] (but the mojo project did have some builds) [00:51] oh, i wouldn't touch those, too bit rotten.. ;) [00:52] 8.04 [00:52] rcn-ee: I'm presuming that it's an old install, and looking for recovery to sanity. [00:53] 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] good point.. yeah that was hasty, it actually worked on a htc phone? [00:54] I understand so I had to install the new one all the way [00:55] rcn-ee: yes it works [00:55] the_eye__: Unfortunately, yes. Sorry about that. [00:55] the_eye__, cool.. i remember helping the mojo guys out, with first getting to run on the beagle.... [00:55] the_eye__: And only install 9.04. 9.10 and newer require newer processors than that device contains. [00:56] did you do a chroot install or just a debian-install? [00:56] no bad feelings :) [00:57] I try 9.04 then [00:58] Good luck with it. [00:58] rcn-ee: I installed an image from here http://forum.xda-developers.com/showthread.php?t=640785&page=77 [00:58] 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] okay i see, they provided an image to dump in the sd card.. [01:01] yes, and I loaded with haret, without changing my rom [01:21] what is the "el" in armel? [01:23] I've always thought it stood for endian-little [01:23] But I could be wrong. [01:24] An alternate interpretation is "EABI little-endian", which makes more sense, as compared to "endian-big" as a proper opposite. [01:25] 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] rcn-ee: armeb predates armel in Debian. [01:34] yeap, that was the old abi variant.. [01:35] i'm so close with rootstock, ogra's last change gets me a little farther, but it's kinda random past that... [01:36] debootstrap seems to be working again for lucid. What's the blocker? [01:38] 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] one of the runs about an hour ago, segfaulted after closly finishing "uboot-netbook" [01:41] Ugh. That does end up being 90 random things. [02:47] http://www.ifixit.com/Misc/iphone_processor_crossection.jpg [02:47] nice [02:47] that's a good way to describe package-on-package. [03:09] "add bootloader = flash-kernel"... [03:09] hmmm [04:22] [ 26.829498] HS USB OTG: no transceiver configured [04:22] [ 26.834442] musb_hdrc musb_hdrc: musb_init_controller failed with status -19 [04:28] great.... my asix is broken again. [04:28] And my musb also is broken. [04:29] http://pastebin.com/THwXNMEE [04:29] wow, that's a nice "word". [04:29] thwxnmee! [04:35] ah, adding twl4030-usb to initramfs ahead of musb_hdrc fixed it. [04:36] is there a way to retrieve/store/copy the contents of a flash drive prior to formatting it? [04:37] 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] You may be able to copy the contents of the MTD stuff using dd. [04:41] What netbook is this? [04:42] this is an EPC-702 [04:42] 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] MTD is "memory technology device" [04:43] such as NAND flash. [04:43] gotcha yeah this is a 2gb nand flash utilizing XIP [04:45] 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] hmm... any option to boot from an sd card? [04:57] Or to check what's in the disk? [04:58] hmm, there's both nand and flash2? [04:58] xip is the kernel, most likely. [04:58] eboot... not sure. [05:01] sounds like the winCE boot loader. [05:02] 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] http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_25366423.html -- is this you? [05:03] 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] thats not me but thats where i got the password from hehe [05:03] my friend has an ad blocker and apparently it makes the answers appear, nothing particularly helpful [05:04] DanaG yeah it has SD reader.. not sure why theres both nand and flash2 [05:06] hmm, unfortunately, there seems to be very little info on that EPC-701 thingy. [05:06] 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] Not even a spec of what ARM it is. [05:06] 702 not sure if it makes a difference [05:06] a friend claims that its the same processor that the motorola razr v3m uses [05:06] http://en.wikipedia.org/wiki/ARM_architecture [05:07] arm926ej-s [05:07] search for that. [05:07] hmm, is that "versatile"? [05:08] not sure.. im a bit confused ;) [05:11] somebody more knowledgeable about ARM stuff would have to answer that. [05:11] interesting... my Cowon S9 has a Telechips 7901 in it. [05:11] thanks very much for your help DanaG, its much appreciated [05:12] hmm, you could also ask in #hardware, perhaps. [05:13] ill give it a whirl for sure [05:15] 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] 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] found one thing thats promising.. http://www.arm.com/community/software-enablement/linux.php [05:20] styol: on paper, there are two ways [05:21] 1. A vendor works with Canonical and Canonical adds the support to Ubuntu [05:21] 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] yeah that makes sense [05:23] 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] s/AMR/ARM [05:24] ARMv5TEJ yeah? [05:24] how about something like Angstrom, or ttylinux [05:24] http://www.angstrom-distribution.org/ http://www.minimalinux.org/ttylinux/downloadARM.html [05:25] styol: well you still need kernel support before that's going to work unfortunately. [05:26] kernel support by one of those systems? [05:26] how about http://www.arm.linux.org.uk/ [05:26] 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] how can i determine what this has presently? [05:28] the first arm.com has an image you can download that says the kernel is supported for [05:28] styol: if its running Windows CE, then its running the Windows CE client :-) [05:29] ARM926EJ-S (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0184-) [05:29] styol: its not that simple. Even if the SoC (or processor) is supported, the board as a whole must also be supported [05:31] ARGH -- stupid asix. [05:31] It's giving me ZERO packets. [05:31] wow, and now it randomly came up. [05:32] nope, it's just seeing its own outgoing arp. [05:33] I see this looping on usbmon1: [05:33] 7.039795 4.1 -> host USB URB_INTERRUPT [05:33] 7.039825 host -> 4.1 USB URB_INTERRUPT [05:36] It loops, and never goes anywahere. [05:36] Even does it with no ethernet cable plugged in. [05:37] Upon plugging in a different usb-ethernet thingy, I see usb URB_CONTROL [05:42] I suppose I should ask on the mailing-list about that. [09:47] Do you know how to control the screen (tty / fb) blanking interval? After a given time the LCD goes blank [10:06] nosse1: setterm -blank 0 -powerdown 0 ? [10:28] amitk: thanks [12:49] hmmm ... so ffox debug build from trunk doesnt have frame/scrollbar issue for me [14:02] NCommander: hi there [14:03] hi [14:05] rcn-ee, meh, your initramfs patch uses bashisms ... [14:13] asac, can you put bug 563618 on the release meeting agenda ? it hits us hard on beagle [14:13] 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] hi blotr [14:19] hey hrw [14:58] ogra: seems the initramfs approach looks quite ok [14:58] is that tested? [14:58] not yet [14:58] i'm still in rootstock tests that eats all my resources [15:00] asac, also that not all of it, there needs to be a hook to get all the binaries into the initramfs [15:00] i'll try to improve and test it today [15:03] A couple of comments... [15:04] 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] embedded devs will probably not even use an initramfs [15:04] Does that work these days? I remember it being very unreliable in karmic days [15:05] but yes, i see your point ... the fix i work on is rather for the current official omap image though [15:05] it got a lot better [15:05] no-initramfs works fine, but requires a bit of tweaking to boot (and is less safe as a generic model) [15:05] and i think the approach is that you *can* run your system without initramfs if youwant in certain cases [15:05] right [15:05] it will always stay for the std distro [15:06] 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] but if people have a selected set of packages and cant install harmful stuff its pretty safe to go without one [15:06] i'm not sure if fsck even looks at the hwclock [15:06] it might suffice to use date --set [15:07] No, but hwclock --hctosys is used to set the soft clock [15:07] Maybe do both? [15:07] yeah, i'll discover such stuff when i test :) [15:07] It's not feasilble to have both online-updates and can't-install-harmful-stuff [15:08] persia, it is if you use your own archive [15:08] We can only do hard-to-install-harmful-stuff [15:08] ogra: No it isn't, because of DNS spoofing. [15:08] ogra, anyway, looks like a reasonable workaround [15:08] and restrict to it indeed [15:08] * dmart still thinks e2fsck is wrong, but that's another discussion... [15:09] dmart, i agree though i also agree with Keybuk who says it needs to be solved on the actual filesystem layer [15:09] i guess we need to fix both [15:09] sure, it needs more thinking about [15:09] Gets harder for ext3/ext4 than ext2, but yeah. [15:10] 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] lool, writeback hangs too (just reached iso-codes in rootstock this second) [15:12] dmart: Without reliance on the RTC, how can we know the time? [15:13] 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] 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] I don't know the deep details, but my limited understanding is that the journalling is timestamped. [15:15] Well, except in the initramfs case, in which case we're in userspace without actually using the filesystems. [15:15] (or rather, without using on-secondary-storage filesystems) [15:15] fair point [15:15] 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] heh, yeah. [15:16] Would probably benefit from a discussion with the fs devs at some conference. [15:16] 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] ogra: The journal has to have been replayed to be able to mount RO. [15:17] Otherwise you have an inconsistent filesystem state. [15:17] Mouting a dirty journalled filesystem ro does replay the journal [15:17] persia, replayed but not changed [15:17] right. [15:17] there wont be changes on disk yet [15:17] But the issue we have is at fsck time, not at mount time. [15:18] Well, except for refuse-to-mount-because-of-fs-age [15:18] Not sure about that -- the kernel prints out "temporarily mounting fs read-write to recover the journal" (or something like that( [15:18] (but that's just a sanity check) [15:18] dmart, aww, evil [15:18] dmart: Ooh, that makes lots of sense, and completely changes the semantics :) [15:18] maybe that just happens when mounting the root fs... ? dunno [15:19] easy to test [15:20] 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] ah, yeah [15:20] That makes sense. So we need to be sure we're somewhere sane. [15:20] Unless you're using ext2 (it's still garbage, but you just hope the system doesn't explode ;) ) [15:21] 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] s/No/Now/ [15:21] 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] wow, neither hwclock, nor date nor dumpe2fs are in the initramfs [15:23] argh [15:23] i would have expected the latter to be missing [15:23] settimeofday? [15:23] but surely not the first two [15:23] RIght. The tricky bit is to come up with something that works for both end-users and bring-up-developers [15:23] nah, no issue, i'll write a hook that copies them [15:24] i just didnt expect date to miss ... [15:24] nor hwclock [15:24] Is the "last mount time" recorded in the fs the time the filesystem was last mounted, or the time it was unmounted? [15:24] both i think [15:24] 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] last mount action [15:24] hm [15:25] How is "mount action" defined? Is that mount+unmount? [15:25] i guess so [15:25] (i was also guessing above) [15:25] there is only that value in dumpe2fs [15:25] That sounds like desired behaviour. Now I wonder if that's how it's implemented. [15:25] The ext3 superblock has "mount time" and "write time". Dunno their behaviour though [15:26] yeah, i see the same in dumpe2fs [15:26] Does anyone know a filesystem expert? [15:26] i guess the stamp is updated by mount/umount [15:26] Keybuk is probably closest [15:34] It could still be worth discussing it at UDS [15:35] ogra: session name? booting clockless systems with journaling FSes? [15:36] BootingWithTimeZero ;) [15:36] asac, RTCless [15:36] but yes [15:36] or batteryless :) [15:36] ok i will add that [15:36] asac: not clockless please, use non-rtc or something [15:36] amitk: Booting With Time Zero ;) [15:36] our prob is that we *have a clock* [15:36] whatever causes this condition is probably irrelevant ;) [15:36] 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] persia, i disagree [15:37] Fair. Just sharing. [15:37] 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] 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] since the filesystem fix might take years [15:38] 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] uhm.. ok thanks persia [15:39] ogra: Oh, a session on workarounds could work, as long as everyone understands it's workaounds. [15:39] right [15:39] the filesystem fix will likely require a design change [15:39] so Lucid is armv7-a :) [15:39] ogra: dmart: let me know if you think you can lead a session on that booting zero time stuff [15:40] otherwise i will note it down as a blueprint without session [15:40] asac, i'm happy to [15:40] zumbi: Mostly. Only ~7000 packages have been recompiled, so there's still bundles that may be ARMv6 or even ARMv5. [15:40] ogra: but do you have all the details so we can achieve something? [15:40] asac, though i dont know how many sessions i have assigned at all [15:40] might be a lot or none ... nobody tells me [15:40] zumbi: But I'd say that the majority of packages that generate ELF binaries are likely to have been recompiled. [15:41] ogra: you had two ... iirc [15:41] asac, well, i know the problem and the possible areas for fixing [15:41] i avent added them to the table/schedule yet. but will do [15:41] if you want to drop one of the suggested ones let me know [15:43] nah, all fine [15:43] if its not 50 that i dont know about yet there is nothing to discuss :) [15:50] bug 559295 [15:50] 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] 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] bug 559297 [15:50] 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] bug 559301 [15:50] 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] bug 563618 [15:51] 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] ogra: what about partman? is that RC still? [15:52] asac, invalid [15:52] can yo do that? [15:52] done [15:52] ogra: both flash-kernel things too= [15:52] ? [15:52] e.g. see above [15:52] bug 559144 [15:52] they are duped to the ubiquity one [15:52] 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] 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] ogra: so all invalid for flash-kernel-* ? [15:53] bug 541030 [15:53] 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] ogra: so only omap issue is bug 563618 ? [15:53] 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] asac, nope, the flash-kernel task on bug 562888 is fix released already ... ubiquity was just uploaded [15:53] 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] bug 541399 [15:54] 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] hmm [15:54] so that was fix committed ... now its invalid [15:54] well [15:54] asac, only *known* omap issue, i need to have images i can test now [15:54] bug 514257 [15:54] 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] bug 528524 [15:54] 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] ogra: we never had a working image? [15:54] bug 541399 is a mess [15:55] bug 528524 [15:55] asac, no, flash-kernel and ubiquity were missing, we never had one that finished the bootloader part [15:55] yeah [15:55] but thats not our release goal afaiui [15:55] so its not RC [15:55] oh [15:55] hmm [15:55] ogra: ok [15:55] so bootloader missing? [15:55] asac, Bug #541399 is fix released for d-i (i did the change and upload) [15:55] 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] the bot shows the wrong task [15:55] ogra: ok. i dont list released bugs anymore [15:55] ;) [15:56] bug 532733 [15:56] 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] bug 528887 [15:56] 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] bug 555977 [15:56] 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] is ooo build now? [15:57] ogra: please checkout https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid [15:57] plars: ^^ [15:57] i am cros checking with the buglist now [15:58] looks fine [15:58] hmm [15:58] bug 559065 [15:58] 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] whats up with that? [15:58] ogra: ? [15:58] mountall+fsck and qemu-kvm hang are my most serious ones [15:58] wasnt that done? [15:58] i think the description is nonsense [15:58] plars, ? [15:59] well, or it should be fix released [15:59] ogra: I didn't see that with the newest kernel [15:59] is that RC? .... what does driver update mean? module reloaded? [15:59] since the described issue is gone [15:59] usually we dont reload modules [15:59] ogra: I think that bryan saw that, and thought it may be related to the suspend/resume issues [16:00] well, but you dont see the hang anymore [16:00] but his kernels that I tested, that certainly did not have this bug in it, still would not suspend/resume [16:00] bug 522858 is new? [16:00] 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] asac: the fec driver code was updated in the kernel [16:00] plars: but how can that change something? [16:01] without reloading the kernel/module? [16:01] asac: because we have a new kernel with the new code in it [16:01] bug 67544 [16:01] whats that? [16:01] asac: Bug 67544 on http://launchpad.net/bugs/67544 is private [16:01] very old apparently... [16:01] why is such an old bug targetted for us? [16:01] 67544 ? [16:01] i will drop that [16:01] are you missing a digit? [16:02] no [16:02] plars: no seems doko gave it to us [16:02] Please don't drop it. [16:02] looks like persia has commented on it before [16:02] It's an old bug, but it's very valid. That bug represents pascal support for armel. [16:03] asac, doko is also fixing it it seems [16:03] yeah [16:03] * persia has been watching that bug since before armel was available in Ubuntu. [16:03] persia: good. i will call you to give info during release meeting when questions come up ;) [16:03] so be prepared (in 20 minutes i guess) [16:03] If I'm still awake sure. Ping me first (I'm getting really close to sleep). [16:04] Basically, some of us can build it, and lamont can't, and nobody knows why. [16:05] doko did a first-stage bootstrap that is hoped to ease the situation. [16:05] Oh, I will be awake. The release meeting seems to have moved with DST. [16:07] persia: right. as i said: about 20 minutes till we are on :) [16:14] 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] plars: those are not armel tagged then [16:14] i just looked at the list [16:14] asac: yes they are [16:14] 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] asac: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/514253 [16:15] 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] asac: https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/514257 [16:15] plars: thats wont fix [16:15] 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] plars: wont fix too [16:15] ah [16:15] didn't look in the bug, just did a search [16:15] must have at least one task that isn't won't fix [16:15] plars: a search that includes won't fix? ;) [16:15] plars: lucid task is wont fix [16:15] i probably left the normal task open [16:15] yeah [16:15] so yeah [16:15] asac: was that intentional? just won'tfix for lucid then? [16:16] I will untarget them then [16:16] It's a bug in LP that there's no good way to do that :( [16:16] bug 528524 [16:16] 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] no sense in having them targetted if they are wontfix [16:16] plars: wont fix is the way to untarget [16:16] hmm, except they are still milestoned [16:16] plars: thats the way you get a normal task back [16:17] plars: but they are wont fix ... so they are hidden from all listss ;) [16:17] unless you search for invalid+wontfix ;) [16:17] feel free to change them to match your needs though [16:17]