=== bjf is now known as bjf[afk] [00:53] Weird... trying to use a pl2303 usb-serial ON the beagleboard... and it's giving me garbage. [00:53] pl2303_process_read_urb - tty_flag = 0 [00:54] H�H�H [04:23] say, what's the practical difference between 2.6.35-17 (ubuntu) and 2.6.35-1002 (linaro) [04:30] not much for now, I'd say [04:30] but need to check the kernel tree [04:42] hmm, stupid pl2303 gives garbage on my beagleboard. [05:59] Say, if I'm using an aufs overlay, is there any advantage to having the underlying FS be ext4 instead of ext3? [06:11] yes [06:11] it would be faster [06:29] DanaG, Depends on what you're accessing. If you're accessing stuff on the base FS, you'll get the normal advantages of ext3 vs. ext4. If you're accessing stuff on the overlay, you won't see any difference between the two. For most uses of union filesystems, actual usage is a mix of both. [06:31] ah, I don't even remember now what the advantages of the base were. =/ [06:32] http://en.wikipedia.org/wiki/Ext4 has fairly extensive discussion [06:34] ah, checksum is a big one. [06:38] Note that it *only* provides benefits to files unmodified from the base: anything in the overlay will naturally be handled based on the backing-store mechanism used for the overlay (often RAM, but potentially other things) [06:41] I've also run into the blockage of hardlinks... http://patchwork.ozlabs.org/patch/52392/ [06:42] What is this blocking? I've played with all sorts of layed filesystems, and never ended up finding this painful. [06:46] It was blocking the "SingletonLock" Chromium links to wherever it links. [06:48] With packaged chromium? [06:48] Yeah. Though, there was a new update today... maybe that would've helped. [06:49] My recommendation would be to try to catch fta: there may be a way to get it to work more easily. [06:50] Anyway, it only happened when the lock was on the underlying fs. [06:50] Say, is there any easy way to make ttyS2 start only if console=ttyS2 is present? [06:50] You could write a custom upstart job... [06:50] I need to use that port for other things in 'normal' (read-only) mode -- using the "user" button to boot read-write for servicing. [06:51] yeah, though I have no idea of the syntax -- start-on? [06:51] * persia doesn't know modern upstart syntax, not having worked on upstart jobs since jaunty [06:52] My recommendation would be to review already installed jobs for clues, and ask in #upstart once you're sure you know the basics. [06:52] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586386 [06:52] Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 40)" [Medium,Fix released] [06:54] Perfect, it's already been done. === kmargar is now known as markos_ === hrw|gone is now known as hrw [09:17] hi === amitk is now known as amitk-afk [10:52] lag: morning, man [10:52] cooloney: They Bryan [10:52] i just pinged sebjan who is still working on the 2.6.35 patches. [10:52] Hey~* [10:53] No problem [10:53] it will be available soon. [10:53] he helped a lot to fix coding style and duplicated patches. i think [10:53] I'd rather them late and in good order than quickly and in a state [10:53] I don't mind that at all [10:53] Keep up the good work sebjan [10:53] after sebjan boots the new kernel on panda, he will send it out. [10:56] thanks lag :) [10:57] :) === amitk-afk is now known as amitk [12:41] ndec, a ti-team ML for the package maintainer field sounds fine to me [12:42] ogra: ok. so should I use tiomap-dev team on LP and create a ML with same name? [12:42] yeah, i think LP offers that [12:43] ogra: ok. I will do that. [12:44] ogra: Mailing list requested and queued for approval.... [12:44] perfect ! [13:42] ndec, was there ever a bug filed for your AAC issues ? [13:45] ogra: no. in fact we are looking at using ffmpeg instead of faac by default. so i don't have any information to open a bug for now. [13:45] ok [13:46] ogra: but do you confirm that packages cannot be compiled with neon optimizations by default? [13:46] ogra: do you really support v7 h/w that does not have neon? [13:46] if you do neon on a common package you should roll an additional binary with -neon in the name, yes [13:47] ndec, we support v6 HW that pretends to be v7 and has no NEON, yes :) [13:47] ndec, ask NCommander :) [13:48] he maintains the dove stuff [13:48] ogra: so how do we automatically install these -neon packages in case the hw supports it? [13:48] hmm, thats hard [13:49] i think asac had a different idea of using runtime switches [13:49] so the binary is the same but uses a different codepath if NEON is available [13:50] Can we reliably detect the ability to run neon on a given machine? If so, hwcap might work. [13:50] yes, i think asac's idea involved hwcap [13:50] but he can probably elaborate [13:51] I'd hope it involved something similar to what we did for pango vfp for jaunty, rather than actually patching every source to have multiple codepaths. [13:52] ndec: there was going to be some work i was going to suggest in Natty to work towards solving this issue [13:53] NCommander, the missing NEON on dove ? [13:53] ogra: no, having a mechanism in APT tohandle packages on a subarchitecture basis :-) [13:53] that wont happen i think [13:54] and it would have to be on dpkg level i think [13:54] iirc we discussed it before [13:58] And it doesn't help the neon bit anyway: we don't want that: we want opportunistic use of NEON, if available. [14:08] \o/ [14:08] * ogra dances [14:08] telepathy-glib builds ! [14:08] (when using -O0 :/ ) [14:09] Um, how did you test that? Everyone is reporting that it builds locally, and only fails on buildds. [14:09] everyone ? [14:09] * persia has yet to actually replicate the test failures. [14:09] everyone who told me about it. [14:09] who was that ? [14:09] it doesnt build with -O2 here or on the porter box [14:10] one test fails with "invalid utf-8" the other segfaults [14:10] Hrm. Right then. [14:11] * persia suspects irregular hardware and incorrect environments [14:19] morning [14:30] * ogra files bug 623979 and uploads a telepathy-glib workaround [14:30] Launchpad bug 623979 in telepathy-glib (Ubuntu) "telepathy-glib fails to build on armel due to two unsuccessfull selftests (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/623979 [14:33] \o/ [14:35] now that were 2 very productive hours to fix that :) [14:36] finally we can start to prepare for beta [14:37] mmm betas ... tasty :) [14:48] ogra, any news/updates wrt doing the arm work ? === zyga is now known as zyga-us-visa-stu [15:28] ogra: can we setup the PPA to send notification email to the team list for each upload and build success? [15:28] I think one only gets notification on build failures. [15:29] Or maybe I'm confused. [15:30] persia: hi! I did receive an email of build failure for something that was uploaded by someone else. so you might be right [15:30] persia: so there is no option to subscribe the team ML to get more notifications? [15:30] * persia is asking [15:31] (for reference, #launchpad is a good place to ask questions about LP) [15:35] ndec1, At least one other user reports they couldn't find any way to get richer notifications. If you want it, please file a bug against LP (and subscribe me, please). [15:35] persia: thx. will do. [15:43] persia: Bug #624038 entered. you and ogra are subscribed [15:43] Launchpad bug 624038 in launchpad "Team notifications of package upload and build success for PPA (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/624038 [15:44] persia: cool.. didn't know about the ubot notification ;-) [15:44] ndec1, Thanks. It may take a while to get implemented, but we now have a place to discuss it :) [15:45] yeah [15:45] thanks for that [15:46] lool: there is a rebased qemu branch in gitorious (omap3-rebase) with your and matts changes included [15:47] suihkulokki: Thanks [15:47] ogra: ndec1: could any of you add me at tiomap-dev? [15:48] I'm also interested on this, once we get the notifications [15:48] suihkulokki: I'm slowly moving this tree under a Linaro umbrella and we have asked one new Linaro starter to look at upstreaming these OMAP3 patches, amongst other things [15:49] rsalveti: done [15:50] ndec1: cool, thanks :-) === bjf[afk] is now known as bjf [16:05] rsalveti, did you research the "Bad Magic Number" issues on omap4 more ? [16:05] ogra: it is an issue with the old u-boot [16:05] seems that really bites us badly now i cant even fatls on the panda atm [16:06] ogra: updated u-boot from sakoman works with no issues [16:06] ogra: i created a small script to reload the boot partition [16:06] ogra: nops, not yet [16:06] prpplague, is there an updated 1.1.4 tree anywhere ? [16:07] ogra: http://paste.ubuntu.com/483487/ for reloading [16:07] we're way paste feature freeze and i'm not really eager to change to a different u-boot version [16:07] prpplague, thats not an option in release images [16:07] ogra: no, there isn't a fixed 1.1.4 since the fat driver was re-written [16:07] sigh [16:08] yep, our version is *very old* [16:08] at least the common u-boot part [16:08] ogra: the issue only seems to occur when writing to the boot partition frequently [16:08] that's why no one likes fixing that [16:08] well, it was the one version that i was told to use [16:09] ogra: probably because at the time sakoman's tree wasn't ready [16:09] prpplague, it happens on first reboot for me, after install (which writes the new initrd once to the fat) [16:09] rsalveti, right [16:09] ogra: ahh interesting [16:09] beta freeze is tomorrow and we have a ton of other issues to fix [16:09] gdm isnt starting either :( [16:10] :-( [16:10] GrueMaster, ^^^ do we have a bug for that ? [16:10] Looking. [16:10] i can run startx and get to a desktop session [16:10] well, i could before i tried to reboot [16:11] and do we have a bug for the bad magic number ? [16:11] * ogra digs [16:11] I'm missing something here. What am I looking for? [16:12] ogra: fwiw.. I think the issue updating the fat boot partition with new uImage is actually an issue with linux fat support... if I write the uImage to an MMC card from macosx I can do it 100's of times and I haven't seen bad magic # [16:12] GrueMaster, for a bug about gdm not starting on the panda [16:12] so I think the best option is to dd an entire raw boot partition, rather than relying on fatfs [16:12] I don't think so, but I might have. [16:12] robclark, why dont we have any issues on omap3 then ? [16:13] I had same issue on omap3 [16:13] at least on 3430.. I never tried 36xx [16:13] No, thats what I was working on last week. Haven't finished narrowing it down yet. [16:13] GrueMaster, we need bugs for the freeze execptions [16:14] Understood. [16:14] please file something generic for each issue you find first, we can do detailed research later [16:14] ogra: that is a good question, how are you mounting the boot partition? as vfat or just msdos? [16:14] prpplague, vfat [16:14] Ok [16:14] prpplague, well, we dont specify a fs actually we just mount it [16:15] ogra: you said we don't have this issue for blaze [16:15] that's more interesting [16:15] ogra: ahh, can you check to see what it is actually reporting after mounting? [16:15] echo "Using u-boot partition: ${UBOOT_PART}" >&2 [16:15] TMPMOUNT=$(mktemp -d) [16:15] mount $UBOOT_PART $TMPMOUNT [16:15] thats the code that mounts it [16:16] we rely on the kernel here to determine the fs [16:16] i would, if i could boot :P [16:17] /dev/mmcblk0p1 on /mnt type vfat (rw) [16:18] thats what i get on x86 [16:18] ogra: Bug #624059. I marked it as critical - incomplete to indicate that it is high priority but cause unknown. [16:19] thanks === zyga-us-visa-stu is now known as zyga [16:19] Launchpad bug 624059 in ubuntu "gdm fails to start on armel images updated from Alpha 3. (affects: 1) (heat: 8)" [Critical,Incomplete] https://launchpad.net/bugs/624059 [16:21] prpplague, same on panda ... "/dev/mmcblk0p1 on /mnt type vfat (rw)" [16:22] mkdosfs -n "SERVICEV001" -F 32 /dev/mmcblk0p1 is the way we use to create the filesystem btw [16:23] yep, creating it as a simple fat 32 partition is enough to get the problem [16:28] ogra: can you email me a list of items that are of concern for the panda support? [16:28] prpplague, you mean for u-boot ? [16:29] ogra: any issues that you have for 10.10 release [16:29] the trashed filesystem is the only one atm [16:29] the other ones are rather homemade [16:29] ahh ok [16:29] i.e. busybox reboot doesnt work and things like that ... all stuff i need to fix in the packages [16:30] I have discovered on this issue that I can reproduce it by just moving/renaming existing files and copying new ones over. [16:30] robclark and i have seem to nailed down the issues with the hdmi/dvi stuff so we should be getting those merged soon [16:30] GrueMaster, does the system dbus run if you try to start gdm ? [16:30] robclark has his stuff posted on gitorious [16:30] But if I copy them to a different area, reformat the partition, and recopy them back with the new files first followed by the old ones it works. [16:30] yeah, right thats another issue but we're waiting for the latest kernel [16:30] GrueMaster: yea that is what my script does [16:31] It appears to be an issue with seeking past a certain pont in the filesystem. [16:31] we cant reformat the whole thing on every initramfs update [16:31] * ogra will not release with such hacks [16:32] prpplague, how far is the new u-boot implementation feature wise ? shoudl it be on par with the 1.1.4 version ? [16:32] (we need hush shell and scripting support for our images) [16:33] ogra: feature wise, it is 10000000 times ahead of 1.1.4 [16:33] if it works as good as 1.1.4 we should probably update [16:33] but that would have to happen today [16:34] ogra: you'd need to get with sakoman to double check the complete status [16:34] his wikipage didnt look like it would be comeplete [16:34] http://omappedia.org/wiki/U-boot_Upstreaming_Project [16:34] ogra: as I described at the bug report, it works fine :-) [16:35] ogra: for panda it should be fine [16:35] ogra: even using the current u-boot default tree [16:35] ogra: i think that just means the upstream items [16:35] rsalveti, would you have time to package it ? [16:35] i think we need to switch for the es2.0 HW anyway [16:35] ogra: sure, if you think we're good to update it now [16:35] for sdp/blaze it is missing final ethernet/spi driver cleanup and emmc environment support [16:36] rsalveti, well, if it saves us from bad hacks like reformatting the fat every update [16:36] hush shell and scripting are there [16:36] sakoman, do you have an ETA for landing teh blaze features ? [16:36] ogra: should I update it now or wait for es2? [16:36] ogra: if you switch to the mainline u-boot to fixed the magic number issue, it will be a good reason to push for changing support on our end [16:36] rsalveti, well, with the current state we cant roll beta images [16:37] ogra: ok, will test the latest one and pack it [16:37] *try [16:37] ogra: probably a month or two since I've had OMAP3 stuff moved up on the priority list by the LInaro folks [16:37] prpplague, right, the thing is that we have time constraints and updating stuff gets harder every day, from tomorrow on each fix requires a ton of paperwork [16:38] ogra: ahh [16:38] sakoman, bah, thats bad, out omap3 u-boot works fine apparently [16:38] ogra: not for Beagle xM or C4 [16:38] * ogra hast seen any such issues on beagles [16:38] that support is not upstream [16:38] i only have a C4 to test (kernel issues on XM prevent me from testing there atm) [16:38] my task is to get all support upstream [16:39] sakoman, i dont use upstream, i use your branches ;) [16:39] ogra: my omap4-exp branch has functional ethernet [16:39] it is just not cleaned up for upstream [16:39] so we should use that one in the distro ? [16:40] rsalveti, would you update our u-boot-omap4 package from that one ? [16:40] that is my working branch and I do frequent rebases as I clean things up and submit upstrea [16:40] ogra: http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.35-17-omap_2.6.35-17.23rsalveti1_armel.deb should work for your xM, if you want to test it [16:40] ogra: sure [16:40] rsalveti, i will, but i'm currently focusing on panda [16:41] and have a long list of broken stuff still here [16:41] i know, I'm pointing the link just in case you want to test it :-) [16:41] yeah, i will [16:41] the omap4-exp branch should work with panda, blaze, beagle c4, beagle xm, and Overo (both 35xx and 37xx versions) [16:42] sweet [16:42] cool. One uboot to bind them. [16:42] the only caveat is that the omap4-exp branch is rebased fairly often as I prepare the patches, submit them upstream, and respong to feedback [16:42] as we're not seeing any issue with u-boot-omap3, I'd prefer updating just u-boot-omap4 with your current branch [16:42] ogra: what do you think? [16:43] I try to keep it working at all times though [16:43] sure, np [16:43] rsalveti, yeah, it will also be a lot easier to package [16:43] ok then [16:43] if you build multiple binaries you need multiple configure and build runs [16:44] i plan to switch to linaro u-boot in N anyway [16:44] that's not a problem as linaro's package is probably doing that already [16:44] but I'd say it's better to just update omap 4 now [16:44] yeah, linaro uboot is not uploaded yet i think [16:45] if we see any blocking issue for omap 3, then we merge both packages in one that's upstream based (or linaro) [16:45] i think slangasek said something like that in yesterdays call [16:45] hm, ok [16:45] ogra: I know jcrigby is testing my branch for the linaro u-boot builds [16:45] well, if the linaro u-boot would work on omap4 we could even switch now [16:45] but i think thats plain upstream [16:45] and i want all the additional sakoman love from the -exp branch ;) [16:46] hmm, what did I say? [16:46] ogra: just uploaded new version to ppa [16:46] slangasek, that u-boot isnt uploaded to the archive yet [16:46] the linaro one [16:46] correct - I need to work with jcrigby today to get it uploaded in a feature-freeze-compliant manner [16:47] slangasek, we have fat issues with the current omap4 version we use and i was wondering if it wouldnt make sense to switch to your version now instead of waiting for N [16:47] if it helps you, we're happy to support your use of it [16:47] since i want to do that switch anyway at some point [16:48] but you are building from plain upstream [16:48] which doesnt have everything i'd like to have :) [16:48] ah [16:48] (we need to support panda and blaze with the omap4 package) [16:48] well, we can discuss putting some sauce into the packaging [16:48] oh, that sounds less like sauce and more like a side dish :) [16:49] and as sakoman said above eMMC support for blaze is missing atm [16:49] and eMMC is the main disk on the blaze :) [16:49] ndec1, whats your suggestion from a blaze POV ? [16:52] ogra: jcrigby can confirm, but it seems current linaro's tree is using most of current sakoman's patches from omap4-exp [16:52] rsalveti, well, lets do it that way, i trust you on picking the right way and leave it in your hands ;) [16:53] ogra: haha, sure :-) [16:53] but I'd say at the moment that linaro's tree is enough for us [16:53] but still want to look for omap3 related patches [16:53] * ogra needs to reasearch busybox, gdm and update the netbook-settings package [16:54] as we could be missing patches [16:54] ok [16:54] the busybox breakage smells very much like toolchain :( [16:55] ogra: I'm continuing my Alpha 3 update-to-fail investigation right now. Should have something by EOD (since I can focus ,more on it & have faster network). [16:55] ogra:I have all of sakomans latest patches [16:55] on top of upstream [16:55] jcrigby: cool, will try your package later [16:55] GrueMaster, i still see no systm dbus on ym images, gdm will not start without that running [16:55] and check omap 3 support [16:56] if everything is well, than we can just use your package [16:56] and drop omap3 and omap4 ones [16:58] yeah [16:58] ogra: what do you mean by 'eMMC support is missing on blaze'? [16:58] that was my plan for N [16:58] ndec1, in u-boot [16:58] ogra: eMMC on blaze is working with TI version of uboot [16:58] ndec1, which u-boot would you suggest to use, apparently 1.1.4 has massive issues [16:59] since it seems unlikely that we can get the whole fat driver replaced now, we're discussing which other tree to use [16:59] rsalveti, I have tested it on the hw I have which is C4, xM and mx51 babbage [17:00] * jcrigby has no omap4 hw [17:00] jcrigby, yeah, we need omap4 panda :) [17:00] but we have the HW [17:00] jcrigby: nice, but our old omap 3 tree had some extra patches, I'd say [17:00] initial zippy support and other stuff [17:00] jcrigby: I'll test it on my panda [17:00] rsalveti, i think i only made config changes and used sakoman'S omap3 tree as is [17:01] rsalveti, I think sakomans next task is expansion board support for mainline [17:01] jcrigby: cool, good to know [17:01] ogra: yup, but these patches are not at his current branch [17:02] ah [17:02] ok, so downgrading busybox to the last version makes reboot -f work again [17:03] * ogra re-adds -marm to debian/rules [17:03] who could help testing it on blaze? ndec1, GrueMaster? [17:03] i have a blaze but a) not set up and b) we need a special eMMC setup we dont have yet [17:04] (in flash-kernel) [17:04] hm, ok [17:07] ogra: and davidm have the blazes (I don't get cool toys, only guts). [17:07] rsalveti: we can. I just not available atm to discuss since I am on another meeting. i want to understand more about this. perhaps we can discuss on Fri during our call. [17:07] ndec1, beta freeze is unfortunately tomorrow [17:08] it's simply, just to test if the latest u-boot boots at blaze [17:08] rsalveti, well, its more since the blaze should get a special setup later [17:08] yeah, but for now, I mean [17:09] it will boot from a raw partiton on the eMMC and the u-boot version we use needs to support that [17:09] or at least be enhancable in a way that we can easily get a freeze exception [17:11] I can send the blaze to GrueMaster if that helps, just got it back from NCommander [17:12] well, to someone who will actually work with it would be good :) [17:12] either GrueMaster or rsalveti i'D say [17:13] davidm: I think I forgot to send the power cord (i couldn't find it, but its a standard plug) [17:13] Probably faster/easier to send it to me, although rsalveti would be the better choice for long term development. [17:13] GrueMaster, I can't send it to him the duties would be insane [17:14] yep, expensive board [17:14] send it to GrueMaster, I can work with him on that [17:14] then send it to GrueMaster [17:14] at least it'd be good so he could test it when needed [17:14] GrueMaster: I can get it directly from you later, if needed [17:15] ok, busybox uploaded, automatic rebooting should work again [17:15] ogra: just reverting last commit is enough? [17:15] re-adding -marm [17:15] rsalveti, yeah, just building with -marm again [17:16] just a note, the power management is working on the ES2.0 8-layer panda boards [17:16] looks like the twl6030 silicon we had on the earlier es2.0 boards has an issue [17:16] hm [17:17] tricky === fta_ is now known as fta [17:17] i dont think we'll get the 8 layer yet [17:17] ogra: i'd be good if people could test or ask to test arm specific changes on packages [17:18] but don't know how hard was to find this bug [17:18] it was just a look at the changelog and some experience :) [17:18] the gdm issue seems to be rather tricky [17:19] what would be good would be to have enough HW to give it to ara so she could set up automated testing [17:19] i.e. not require the maintainer to test but just have automated tests that send regression alterts [17:20] *alerts [17:20] jcrigby: correct -- adding the expansion board stuff is on the agenda next [17:20] should be in by end of this week [17:20] Hopefully I can work with her on this post release. My systems are idle at night anyways. [17:21] sakoman: nice [17:22] GrueMaster, not your systems :) for N we should have huuuuge amounts of HW [17:22] GrueMaster, but its surely worth a spec for N [17:22] hey zul ! [17:23] you in -arm ? === hrw is now known as hrw|gone [17:23] hey ogra, yep just lurking [17:23] phew ... i was fearing server breakage :) [17:23] good to see you here :) [17:25] ogra: I've added a task to my list to write up a blueprint for test automation, however I'll need someone to proxy for me as I won't make UDS. [17:25] huh ? you wont ? [17:25] thats bad, but i can proxy for you [17:26] ogra: hehe [17:26] GrueMaster, or worst case i'll delegate to NCommander he has nothing to do anyway ... just that little dove thing :) [17:26] I had already booked a cruise that week. Booked it once we had the release date finalized at the last UDS. [17:26] heh [17:26] ah, year i remember now, you told me at the sprint [17:27] When I told the wife I should go to UDS, she gave me a look that would have given an exorcist pause. [17:27] * sakoman has no idea what this N thing is [17:27] * NCommander embeds a golf club in ogra's head [17:27] Next Release. [17:27] sakoman, next release after mmmmmaverick :) [17:27] sakoman: its a letter [17:27] :-) [17:27] :-) [17:28] * sakoman imagines Sesame Street music in the background [17:28] "this release brought to you by the letter N" [17:28] lol [17:29] it actually *is* like sesame street :) you learn a lot about adjectives and animals following ubuntu releases [17:30] maverick meerkat :) natty narwahl [17:31] * ogra takes a break [17:32] I thought it was narcissistic narwhal. [17:33] Guess I should read the web a little more. [18:54] has anyone been able to use the ftrace's "set_ftrace_filter" on OMAP3 ? [19:24] sebjan: ping [19:29] ogra: are you guys using the linux-fsl-imx51 kernel at all in maverick? It was inherited from lucid when the archive opened, hasn't been updated since, and if it's not needed / worked on, it's better to cull it from the archive than to let it drift [19:30] (it's already missing two security revisions from lucid) [19:31] slangasek: it's removed already [19:31] in maverick [19:31] lool: no, it isn't [19:31] slangasek, we dont support imx51 at all [19:32] in maverick [19:32] slangasek: Oh I don't see the source in rmadison output [19:32] lool: I'm looking straight at the archive; not sure why rmadison doesn't show it for you [19:32] ogra_cmpc: so you're ok with me nuking it? [19:32] slangasek: Uh yes I do, I'm just assuming it's sort alphabetically [19:32] slangasek: I'm just tired, sorry [19:32] slangasek, totally [19:33] slangasek: I do get security updates for lucid to test. And we do still support it on lucid. [19:33] GrueMaster: yes, we don't remove packages from released versions after the release [19:33] ok, just making sure. [19:34] GrueMaster, only maverick [19:34] Might also check with oem to see if they have any strange projects going on that require it. [19:35] oh, that might be, but for imx51 they will surely have their own kernel/bootloader [19:35] since ours definitely only supports babbage boards [19:36]