| NTU | LOL @ ubuntu on ARM!! | 01:03 |
|---|---|---|
| infinity | ... | 01:04 |
| infinity | That was constructive. | 01:04 |
| === prpplague^2 is now known as prpplague | ||
| lilstevie | infinity: its the little things | 01:40 |
| === asac_ is now known as asac | ||
| persia | ericm|ubuntu, Good morning. Quintasan was trying to compile imx-libs against linux-headers-2.6.35-1001-linaro-lt-mx53_2.6.35-1001.1_armel.deb based on guidance from http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu and ended up withhttp://paste.kde.org/86929/. Do you happen to know of more modern (or working) instructions? | 02:22 |
| ericm|ubuntu | persia, paulliu knows the detail - btw, can you let Quntasan send email to us, me and pualliu, thanks | 05:05 |
| persia | I'll try to convince him. Thanks for the pointer. | 05:08 |
| === Lopi is now known as Lopi|idle | ||
| === fairuz_ is now known as fairuz | ||
| === apachelogger is now known as rohansgoogle | ||
| === rohansgoogle is now known as apachelogger | ||
| ogra | soo, seems we have images again | 10:49 |
| lilstevie | og? | 10:50 |
| lilstevie | tabcomp fail :p | 10:50 |
| ogra | and the oversizedness is caused by the fact that the images contain *all* langpacks | 10:50 |
| lilstevie | oh dear | 10:50 |
| lilstevie | so how does one go about getting a package in universe | 10:50 |
| lilstevie | say a kernel | 10:50 |
| ogra | you file a bug pointing to the package and then find a sponsor | 10:51 |
| lilstevie | ok, sounds easy enough | 10:51 |
| ogra | or you get it into debian ... | 10:51 |
| ogra | which is the preferred way | 10:51 |
| ogra | but might be hard in case of kernels | 10:51 |
| lilstevie | would be hard in the case of my tab kernel | 10:52 |
| ogra | in any case it would be better to have upload privileges | 10:52 |
| ogra | going through sponsoring with a kernel is painful | 10:52 |
| lilstevie | heh | 10:53 |
| ogra | at least for followup changes and fixes | 10:53 |
| lilstevie | yeah that is what I am not looking forward to, with the sponsor method that is | 10:53 |
| ogra | neither will your sponsor | 10:54 |
| ogra | uploading a 90M package for every change is annoying, finding sponsors for that will not be easy | 10:55 |
| ogra | long term i would suggest to earn upload privs | 10:55 |
| lilstevie | hm | 10:55 |
| ogra | or have someone with these privs in your team that maintains the arch | 10:56 |
| lilstevie | that sounds the hardest | 10:57 |
| kunguz | Hi all, I have installed Ubuntu arm 11.04 on my beagleboard C3. The thing is usb devices attached to it works in the early stages of booting of the system. But when the booting finishes the usb devices stop working. Any ideas? | 10:57 |
| lilstevie | I don't know anyone with upload privs | 10:58 |
| lilstevie | ogra: the good news is though I am killing the last bug that affects basic usability since switching up to the new kernel | 11:01 |
| ogra | what version are you on now ? | 11:02 |
| lilstevie | 2.6.35.7 | 11:02 |
| ogra | oh, still ancient | 11:02 |
| lilstevie | yeah | 11:03 |
| lilstevie | but newer | 11:03 |
| persia | Finding sponsors doesn't have to be that hard. I'm almost always willing to sponsor kernel uploads to universe, for example. | 11:04 |
| persia | kunguz, Maybe bug #784474? | 11:06 |
| ubot2 | Launchpad bug 784474 in linux-ti-omap "usb enumeration fail on beagleboard" [Undecided,New] https://launchpad.net/bugs/784474 | 11:06 |
| kunguz | ubot2: persia seems similar, thank you | 11:07 |
| ubot2 | kunguz: Error: I am only a bot, please don't think I'm intelligent :) | 11:07 |
| kunguz | ubot2: but you are clever one :D | 11:07 |
| ubot2 | kunguz: Error: I am only a bot, please don't think I'm intelligent :) | 11:07 |
| persia | kunguz, I'm not sure that's precisely the bug: it has a decent test scenario written up. If you can't replicate precisely that way, it's always safest to search a bit more for a bug you can precisely replicate, or file a new one. | 11:08 |
| * ogra ponders what to do with the images | 11:08 | |
| persia | What do you mean? | 11:08 |
| ogra | We should have enough space to include all langpacks on the 1 GB armel desktop | 11:09 |
| ogra | live images: | 11:09 |
| ogra | * /^language-pack-[^-]+$/ [armel] | 11:09 |
| ogra | * /^language-pack-gnome-[^-]+$/ [armel] | 11:09 |
| ogra | that ... | 11:09 |
| ogra | (paste from the live seed) | 11:09 |
| ogra | seems lool added that back when we still rolled live images | 11:09 |
| persia | Let them be oversized for a bit more. In #ubuntu-devel there was some talk about sorting the internationalisation bit next week. | 11:09 |
| ogra | well | 11:10 |
| ogra | for live, yes | 11:10 |
| persia | There's some reason to have *lots* of languages right now. | 11:10 |
| ogra | for preinstalled we likely need some extra code | 11:10 |
| ogra | and i dont really want 1G images | 11:10 |
| persia | I suppose. | 11:10 |
| persia | My suspicion is that the work on making sensible international images will end up reducing that substantially. | 11:11 |
| lilstevie | persia: even my galaxy tab 7" image? :) | 11:11 |
| persia | lilstevie, *especially* your galaxy tab image. I would really like Ubuntu to support as many retail devices as we can. | 11:11 |
| ogra | ++ | 11:11 |
| persia | But I'm not a kernel hacker, so all I can do is review other folks kernels, make sure they're packaged sanely, and help them get images from them. | 11:12 |
| lilstevie | :) | 11:12 |
| lilstevie | well I am within 24hours of a sane kernel | 11:12 |
| lilstevie | :) | 11:12 |
| persia | For packaging, I'd recommend starting from either jcrigby's scripts or linux-n900 (derived from those)., depending on which makes you more comfortable. | 11:12 |
| ogra | persia, note that the hack above is armel only, no other arch ships all langpacks | 11:13 |
| persia | I'm within 24 hours of my weekly "ignore IRC traffic for 20-30 hours" time, but I'd be happy to upload later in the weekend. | 11:13 |
| lilstevie | tbh I will need a bit of help with the packaging, the only debs I have ever packed have been for apt on arm-darwin | 11:13 |
| persia | ogra, So, we should undo that. I'm still not tempted to undo it until we understand the i10n plan. | 11:13 |
| ogra | well, i'm happy to go with the defaults all arches use | 11:14 |
| * ogra drops the lines from the seed | 11:14 | |
| persia | If you want to have a seed commit today, I'm 100% in favour of doing anything to make armel less special in the seeds. | 11:14 |
| persia | I just expect that we'll have to fiddle it again later. | 11:14 |
| ogra | why ? | 11:15 |
| ogra | we will inherit whatever desktop does | 11:15 |
| persia | lilstevie, I *may* have time on Sunday, depending on your timezone, etc. If not, I'll try to catch you as soon as I have time. | 11:15 |
| lilstevie | :) | 11:15 |
| persia | Because preinstall != live. | 11:15 |
| lilstevie | well it is 8:15pm friday here :p | 11:15 |
| persia | Ah, a *good* timezone :) | 11:15 |
| lilstevie | :) | 11:16 |
| ogra | persia, well, the only difference is casper vs jasper | 11:16 |
| ogra | we use the live seed on preinstalled | 11:16 |
| persia | So, yeah, there's a chance I'll have time Sunday evening then. | 11:16 |
| ogra | seed change pushed | 11:16 |
| ogra | lets see how much that saves | 11:16 |
| ogra | i guess we should come out below 800M now | 11:16 |
| persia | Given that there is a *new* method of doing internationalisation in the works, I'm expecting *both* jasper and casper to need adjustment, along with live-build configu. | 11:17 |
| persia | But yeah, for the weekend, we can have smaller images. | 11:17 |
| ogra | well, desktop will not go to bigger images for now | 11:18 |
| persia | lilstevie, Be aware that the release manager has all sorts of requirements for generating images. In practice, this typically means that if we get a kernel into the archive in one cycle, we can have proper images the *next* cycle. That said, if your kernel is good enough, and there are testers, etc.., we may be able to work around that. | 11:18 |
| ogra | so they will rather drop langs than add | 11:18 |
| persia | It's changing. | 11:18 |
| ogra | not yet | 11:18 |
| persia | Stuffing bundles of langs into a single image may not be how it is done in the future. | 11:18 |
| ogra | as i understood we still go for 700M in oneiric | 11:19 |
| persia | And there is no way to have any idea about this until next week. | 11:19 |
| lilstevie | persia: heh I don't think we will be working around that | 11:19 |
| persia | Yes, oneiric images will be 700M. Nonetheless, per-locale customisations are happening in a *completely* different way than in the past, and much more comprehensively, which likely has implications about how locale-specific code ends up in default images. | 11:20 |
| persia | lilstevie, Fine by me, as long as you don't mind it being a remix for 11.10. | 11:20 |
| ogra | i dont care about customizations :) | 11:20 |
| ogra | only about the default image | 11:20 |
| persia | If there are enough users, etc. then we can apply to have proper images for 12.04. | 11:20 |
| persia | Yes. Please read my last sentence again. | 11:20 |
| lilstevie | persia: that said I always tend to understate my stuff | 11:21 |
| lilstevie | persia: my problem is the lack of hardware support | 11:21 |
| persia | lilstevie, It's a geographical limitation. You're just following your peers. | 11:21 |
| lilstevie | heh | 11:21 |
| lilstevie | persia: well there already have been some testers just FYI | 11:24 |
| lilstevie | on the utouch team | 11:24 |
| persia | More folk always help, but we're going to need someone to commit to the milestone testing, which basically means being nearly continuously available (for respins) for ~3 days for each milestone release to ensure image quality. | 11:25 |
| persia | And that usually requires user numbers in the 100s, unless one happens to get lucky and catch a great tester early. | 11:26 |
| lilstevie | hm, well I don't know about 100s :/ | 11:26 |
| persia | Heh, yeah. That's part of why it's sensible to start slowly. | 11:27 |
| persia | If you make something great, and then you tell your users that someone has to volunteer to help test in order to continue, you'll either get a volunteer, or you'll have confirmation that there isn't enough interest. | 11:27 |
| lilstevie | heh | 11:27 |
| ogra | hmm | 11:37 |
| ogra | so how do i make preinstalled images use the oem user | 11:37 |
| ogra | should that be created at image build time or by jasper | 11:38 |
| persia | By jasper. | 11:41 |
| ogra | why ? | 11:41 |
| persia | To parallel casper, and keep live-build config more similar. | 11:41 |
| persia | (yes, there's messiness now, but I'd rather clean that up than add to it). | 11:41 |
| ogra | well, do you see a reason why preinstalled images shouldnt have an oem user and oem-config enabled by default | 11:42 |
| persia | Remastering. | 11:42 |
| ogra | i actually think that code should move into the build process | 11:42 |
| persia | For live also? | 11:43 |
| ogra | no | 11:43 |
| persia | OK. Why should live and preinstall be different? | 11:43 |
| ogra | well, for remastering its actually an advantage | 11:43 |
| ogra | because they are totally different things by design | 11:43 |
| ogra | preinstalled images will always have oem-config installed | 11:44 |
| ogra | so why not enable it by default (including the user) | 11:44 |
| ogra | wrt remastering ... if you dont use the jasper initrd, you are screwed today | 11:45 |
| persia | Why? | 11:45 |
| ogra | because jasper enables oem-config | 11:45 |
| persia | I know of people who have extracted the rootfs from a preinstall, generated a *different* initrd, and used it on devices. | 11:45 |
| ogra | i know of people trying to use our preinstalled rootfs as is but without initrd :) | 11:46 |
| persia | Heh. | 11:46 |
| ogra | if you only want the rootfs then you have to manually fiddle with it to get oem-config up | 11:46 |
| lilstevie | I had to manually touch /var/lib/oem-config/run | 11:47 |
| persia | So the basis of my argument is mostly "There should be no difference between live and preinstall". | 11:47 |
| ogra | i.e. you have to do all the bits jasper does to the rootfs | 11:47 |
| persia | But I can see the argument "There should be no difference between preinstall and the results of booting live and performing an orm install". | 11:47 |
| ogra | jasper should *only* care about partitioning and resizing | 11:47 |
| ogra | and the peripherial bits that includes like bootloader config and fstab creation etc | 11:48 |
| ogra | i want to get all unrealted hacks out of the code | 11:48 |
| persia | OK. I can accept that. | 11:48 |
| ogra | enabling oem-config is one | 11:48 |
| persia | And jasper might end up going away completely, replaced by spices, or similar. | 11:48 |
| ogra | and we dont even do it right atm | 11:48 |
| persia | (or be the instrument of spice implementation) | 11:48 |
| ogra | you will always need the resize on boot bit | 11:49 |
| persia | Right. You've convinced me. oem-config should be enabled by live-build. | 11:49 |
| ogra | which in turn means you will need to create fstab and bootloader config at the same time | 11:49 |
| ogra | that cant be handled by seeds only the package can be pulled in or be omitted by seeds | 11:50 |
| ogra | i dont expect jasper to go away as long as we have the resizing | 11:50 |
| persia | Ah, and if jasper is pluggable, fstab can be generated dynamically, and bootloader config can be done by spice insertion to some conf.d. | 11:50 |
| ogra | well, bootloader config is something that should better live in flash-kernel-installer ... but that will require more changes | 11:51 |
| ogra | since its only available in udeb form atm | 11:51 |
| persia | We could add it to oem-config. | 11:51 |
| persia | Or, no, you need it earlier, don't you. | 11:51 |
| ogra | no | 11:51 |
| ogra | well | 11:51 |
| ogra | yes | 11:51 |
| ogra | heh | 11:51 |
| ogra | tricky | 11:51 |
| ogra | i need a change of the cmdline earlier | 11:52 |
| ogra | not necessarily a full new setup of the bootloader | 11:52 |
| persia | We already did the work to have a ubiquity controller for flash-kernel-installer, so it would be handy if we didn't need it until oem-config runs, but because we need it early, jasper has to do it. | 11:52 |
| ogra | the actual setup could be done by oem-config | 11:52 |
| ogra | but that wouldnt get rid of bootloader code in jasper | 11:53 |
| persia | If we're going to have bootloader code in jasper, let's use flash-kernel. | 11:53 |
| ogra | thats what it does ... just not for the setup | 11:53 |
| ogra | i.e. the generation of config | 11:53 |
| persia | flash-kernel-installer won't generate the config? | 11:54 |
| ogra | flash-kernel-installer isnt existent in jasper | 11:54 |
| ogra | i would have to pull it into the initrd | 11:54 |
| persia | Not all of it. | 11:54 |
| ogra | with a big penalty (lots of different bootloader deps) | 11:54 |
| persia | So, the way ubiquity does it is to embed the flash-kernel source in the ubiquity source, and then copy flash-kernel-installer.postinst to somewhere useful when building the binary. | 11:55 |
| ogra | by current design, all of it | 11:55 |
| persia | It then calls that script to do the setup. | 11:55 |
| ogra | i know how ubiquity works | 11:55 |
| ogra | (i worked on that code too) | 11:55 |
| persia | Can't we do the same thing for jasper? | 11:55 |
| persia | And inject only the bootloader support demanded by the spice? | 11:55 |
| ogra | yes, but to keep it generic you would have to pull all bootloader tools into the initrd | 11:56 |
| ogra | that will get huge | 11:56 |
| persia | Yeah: just refreshing both our memories to make sure we're talking about the same thing :) | 11:56 |
| persia | We don't need generic at that point: this is what spices are supposed to do. | 11:56 |
| persia | That's the entire point of the two-stage image build process. | 11:56 |
| ogra | well, thats not how flash-kernel-installer is workigng currently | 11:57 |
| ogra | so that would need some massive redesign | 11:57 |
| persia | I thought that flash-kernel-installer simply assumed that everything was present, but then only called the bit it needed for the board it was using. | 11:57 |
| ogra | modularization ... and support for initrd | 11:57 |
| ogra | flash-kernel-installer *makes* everything present | 11:57 |
| ogra | thats part of its job | 11:57 |
| ogra | it chroots and installs the bits and pieces for the currently used arch | 11:58 |
| persia | Yes, but that's the dependencies. flash-kernel-installer.postinst doesn't do that on it's own, does it? | 11:58 |
| ogra | which means you need support for *all* arches in the ship seed | 11:59 |
| persia | And flash-kernel-installer.postinst is *designed* to run from an initrd (the d-i environment) | 11:59 |
| persia | Why? | 11:59 |
| ogra | flash-kernel-installer.postinst chroots and calls apt_install | 11:59 |
| ogra | flash-kernel-installer.postinst is not designed to be run from an initrd | 11:59 |
| ogra | it is designed to be run in d-i context | 12:00 |
| persia | The d-i context *is* an initrd, but we stray :) | 12:00 |
| ogra | it expects certain d-i copmponents to be there | 12:00 |
| persia | It calls apt_install for *everything*, rather than just the currently-detected platform? | 12:00 |
| ogra | no | 12:01 |
| persia | Right. | 12:01 |
| ogra | its doable but as i said in the beginning it takes a lot of changes | 12:01 |
| persia | Ah. because in the preinstall context, we don't have a chroot. Right. | 12:01 |
| ogra | and essentially a complete redesign of flash-kernel-installer | 12:01 |
| persia | Let's not do that. | 12:01 |
| ogra | we do have a chroot | 12:01 |
| ogra | from initrd | 12:01 |
| persia | So, why do we need to change anything? | 12:02 |
| persia | apt_install is a no-op if the package is already installed. | 12:02 |
| ogra | if we want to use it out of context we need to change it | 12:02 |
| ogra | apt_install doesnt *exist* in non d-i initrds | 12:02 |
| ogra | there are plenty of calls to d-i tools in the scripts | 12:03 |
| ogra | you cant just dump it into an initrd | 12:03 |
| ogra | it wouldnt run | 12:03 |
| persia | Ah, so we'd end up embedding all sorts of things, essentially duplicating ubiquity, and we'd get all sorts of annoyed trying to maintain it. | 12:03 |
| persia | Right. | 12:03 |
| ogra | yeah | 12:03 |
| ogra | so it would have to become more modular (so you only pull in the snippets you need at initrd generation time) and would need a layer that can switcfh between d-i tools and normal initrd binaires | 12:04 |
| persia | So, we have flash-kernel available in the chroot, right? And whatever bootloader support bits we need for the target? | 12:04 |
| ogra | and you would need arch specific hooks in initramfs tools so you can select which bootloader tools go into the initrd | 12:05 |
| persia | Oh, but that won't generate the initial configuration. | 12:05 |
| ogra | right | 12:05 |
| persia | No I don't. | 12:05 |
| persia | I can control that by which packages I happen to have installed at initrd generation time. | 12:05 |
| ogra | the first change of the cmdline is the bit | 12:05 |
| ogra | for the actual final initrd we can actually use flash-kenrle-installer | 12:05 |
| * persia wishes someone would port grub2 already, *again* | 12:05 | |
| ogra | *kernel | 12:06 |
| * ogra doesnt :P | 12:06 | |
| persia | flash-kernel-installer, or flash-kernel? | 12:06 |
| ogra | the former | 12:06 |
| ogra | from oem-config | 12:06 |
| persia | Oh, right. Because that gives us a d-i context. | 12:06 |
| ogra | right | 12:06 |
| persia | So, really, we just need to be able to boot *this one time*. | 12:06 |
| ogra | its only the jasper bits | 12:06 |
| ogra | where i parse the cmdline and adjust it after resizing | 12:06 |
| persia | So, I don't believe there's a generic way to change the commandline. | 12:07 |
| persia | We've different requirements for different bootloaders. | 12:07 |
| ogra | not generic, but pretty generic | 12:07 |
| ogra | we currently support what, two bootloader variants in ubuntu ? | 12:07 |
| ogra | u-boot and abootimg | 12:08 |
| ogra | redboot is gone from teh achrive and from flash-kernel since a few days | 12:08 |
| ogra | (and from d-i) | 12:08 |
| persia | Yeah. I have to add some of it back one of these days, if I ever get around to upgrading my netwalker (I kinda wish someone would come out with a satisfactory replacement I could just buy instead). | 12:09 |
| persia | But what I'd add back for redboot is *completely different* from what was there, so that's not strictly relevant. | 12:09 |
| Daviey | ogra: Do you know if PXE boot is likely going to be an option for next? | 12:09 |
| persia | And there's the messiness for the Nokia devices, but that's something else. | 12:09 |
| Daviey | (or anyone else) | 12:09 |
| persia | Daviey, "next"? | 12:09 |
| ogra | Daviey, the code is in our oneiric u-boot package | 12:10 |
| ogra | Daviey, we'll run some tests next week | 12:10 |
| persia | Daviey, You want to watch https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-pxe-support andhttps://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-initial-usb-tftp-support-panda | 12:10 |
| persia | Supposedly, as part of those implementations, we'll end up with docs that describe how to enable PXE for arbitrary u-boots (needs device driver porting) as part of that delivery. | 12:10 |
| ogra | persia, yeah, well, we largely dropped imx51 | 12:11 |
| ogra | and all bootloader code it had | 12:11 |
| ogra | or better lool dropped i just nodded :) | 12:11 |
| persia | Except for the netwalker, all the i.MX devices I have use u-boot. | 12:11 |
| ogra | yup | 12:11 |
| ogra | most future devices will use fastboot i suspect | 12:12 |
| persia | Dunno. u-boot has a lot of following, and Freescale supports it. | 12:12 |
| ogra | if we cover these two we should be largely generic ;) | 12:12 |
| persia | (plus, we *could* have grub2, and not have to worry about any of this mess) | 12:12 |
| ogra | pfft | 12:12 |
| ogra | unlikely that you get the vendors to support it | 12:13 |
| Daviey | Ah lovely! | 12:13 |
| ogra | took long enough to get most of them to u-boot | 12:13 |
| Daviey | ogra / persia: we might be pestering you next week. :) | 12:13 |
| ogra | we hope so ! | 12:13 |
| Daviey | Thanks! :) | 12:13 |
| persia | Anyway, for supporting two bootloaders, should that be pluggable? | 12:14 |
| persia | Have the bootloaders provide some file that, when jasper is installed, jasper uses to define *how* to change the cmdline? | 12:15 |
| persia | That's likely more compatible with spices than jamming everything in jasper and hoping the initrd doesn't overflow. | 12:15 |
| lool | I actually think we should consider grub as a third stage bootloader | 12:15 |
| ogra | lool, what would be second stage ? | 12:17 |
| persia | lool, I'd love to have a discussion about why we shouldn't use grub as *second* stage, but I really want to figure out the design for pre-oem-config booting first :) | 12:17 |
| lilstevie | I'd love to see grub2 for arm | 12:17 |
| persia | ogra, So, pluggable, or bundle-everything-in-the-initrd and hope we don't get too many bootloaders? | 12:17 |
| ogra | persia, well, on the ac100 i have exactly 4M for the initrd | 12:17 |
| persia | That's a good argument for pluggable :) | 12:18 |
| ogra | every byte above makes the system oops | 12:18 |
| persia | So we have /usr/share/jasper/bootloaders.d/*.conf, and we source that, and then call "fix_command_line()" ? | 12:19 |
| ogra | something like that | 12:19 |
| persia | Oh, right. initrd. Change the names :) | 12:19 |
| persia | And then we add the magic file to abootimg and u-boot. | 12:19 |
| ogra | right | 12:20 |
| persia | So, here's the worry. The magic file will end up in the initrd after jasper is purged. | 12:20 |
| persia | Do we care that much? They should be very small. | 12:20 |
| ogra | why would it ? | 12:20 |
| persia | Because it lives in the bootloader package. | 12:20 |
| ogra | oem-config runs update-initramfs after jasper is removed | 12:20 |
| persia | Right, but that won't remove the files from the bootloader packages. | 12:21 |
| ogra | but the hoooks that would install it to the initrd | 12:21 |
| ogra | s/it/them/ | 12:21 |
| ogra | the files live in the filesystem, but not in the initrd if no hook installs them | 12:22 |
| persia | Aha, so it *would* be somewhere like /usr/share/jasper/... and then jasper would provide the hooks for initramfs-tools, which would be purged on jasper-purge, which would result in the magic files not being in the initrd when update-initramfs is called? | 12:22 |
| ogra | well, in /usr/shar/initramfs-tools/hooks, but yeah | 12:22 |
| persia | Well, the hooks go there, but the bootloader implementation files? | 12:23 |
| ogra | the hooks define what ends up in the initrd | 12:23 |
| persia | Yes. | 12:23 |
| ogra | actually /usr/shar/initramfs-tools/hooks/jasper does | 12:23 |
| persia | But in order to end up in the initrd, stuff has to be in the filesystem. | 12:23 |
| ogra | /usr/shar/initramfs-tools/hooks/jasper is part of the jasper package | 12:23 |
| ogra | the bootloader config templates can come with the bootloader | 12:24 |
| persia | And the bootloader packages need to deliver the implementations to the filesystem to ensure we don't have multiple (assuming we didn't spice the image to have multiple). | 12:24 |
| ogra | right | 12:24 |
| persia | Right. I'm suggesting that the bootloader config templates should be installed to /usr/share/jasper/bootloaders/ or similar. | 12:24 |
| ogra | but they wont end up in the initrd ever if /usr/shar/initramfs-tools/hooks/jasper is gone | 12:24 |
| persia | Where jasper ships either an empty directory or a directory containing only .placeholder to support this. | 12:25 |
| persia | Right, which is the correct behaviour. | 12:25 |
| * ogra wishes he would find out why this 4M limit exists on the ac100 | 12:26 | |
| persia | Insufficiently hackable bootloader. | 12:27 |
| lilstevie | ogra: partition size? | 12:27 |
| persia | lool, So, why wouldn't we want grub as second stage? Wouldn't using it as third stage add ~8 seconds to boot time? | 12:27 |
| lool | persia: I'm not sure where the 8 seconds are from | 12:28 |
| lilstevie | ogra: is the ac100 fastboot? | 12:28 |
| persia | Random guess on my part to load grub, detect time, timeout, and load the kernel. | 12:28 |
| persia | lool, To put that another way, if we're loading grub2, why wouldn't we want that to be second-stage? | 12:29 |
| lool | it's a bit of a complex story; we could discuss it next week if you like; first, you often need a SPL which just loads the real bootloader into the initialized RAM | 12:29 |
| lool | then you need a bootloader which does good stuff, this could be grub; but we're already at the TPL | 12:29 |
| persia | TPL? | 12:30 |
| lool | invented that one just now for tertiary or third program loader ;-) | 12:30 |
| lool | SPL being secondary program loader | 12:30 |
| persia | Right. | 12:30 |
| lool | the second stage loader is hard for various reasons | 12:30 |
| lool | first, it's extrenely device specific; it's hard to make it generic | 12:31 |
| lool | second, it needs to be extremely small | 12:31 |
| persia | So, for example, on beagle, we do ROM -> FPL (xloader) -> SPL (uboot) -> TPL (linux), right? | 12:31 |
| lool | no, ROM is first stage | 12:31 |
| lool | xloader is a SPL | 12:32 |
| persia | Ah, OK. | 12:32 |
| persia | So you want ROM -> (something) -> grub2 -> linux ? | 12:32 |
| ogra | lilstevie, yeah | 12:33 |
| lilstevie | ogra: wonder if it is bootloader related, or if it is partition size | 12:33 |
| lilstevie | fastboot is a pita | 12:33 |
| ogra | i'm pretty sure its bootloader related | 12:33 |
| ogra | it seems to be related to the unpacked size | 12:34 |
| lool | persia: that's right; the something could perhaps be UEFI related :-) | 12:34 |
| lilstevie | ogra: oh | 12:34 |
| ogra | i.e. i can squeeze more into a bz2 or lzma initrd, but that will cause an oops | 12:34 |
| persia | lool, Right. We completely agree, but were previously using different nomenclature. | 12:35 |
| lilstevie | ogra: so maybe its memory hole isnt big enough | 12:35 |
| persia | I also want grub2 as TPL. | 12:35 |
| ogra | lilstevie, right | 12:35 |
| lool | persia: also, "something" might need to be in two pieces itself | 12:35 |
| ogra | in *some* pieces :) | 12:35 |
| lool | so grub 2 might be QPL or something :-) | 12:35 |
| * lool lunch | 12:36 | |
| lilstevie | ogra: FYI memory layout from bootloader is what was causing my issue too, turns out the drivers for 2.6.32 expected FB mem to be at 1 address and the new bootloader has the memory location offset a bit highre | 12:36 |
| lilstevie | higher* | 12:36 |
| persia | lool, I'd really prefer a less capable *something* than a split one. For example, u-boot is often no longer used as SPL beause it has too many features to fit in the small memory barriers, but realistically most of those features aren't needed if handing off to grub2. The same applies, only moreso, for UEFI. | 12:36 |
| ogra | often used as ? | 12:37 |
| ogra | u-boot *is* an SPL, no ? | 12:37 |
| persia | ogra, For panda, it's TPL. xloader is SPL. | 12:38 |
| ogra | well, yeah | 12:38 |
| ogra | for panda | 12:38 |
| persia | (according to the nomenclature lool and I are using for this discussion) | 12:38 |
| ogra | usually its SPL though | 12:38 |
| ogra | omap is special since it doesnt fit enough into its rom apparently :) | 12:39 |
| ogra | else x-loader would just live on the board | 12:39 |
| ogra | preinstalled in rom | 12:39 |
| persia | No. | 12:39 |
| persia | x-loader is just a trimmed u-boot because u-boot can't all fit in the environment started by the ROM. | 12:39 |
| ogra | thats what i said, just the other way round :) | 12:40 |
| persia | But nearly *every* ROM boot code ends up just jumping to somewhere to do setup, and isn't nealy as complex as e.g. x-loader. | 12:40 |
| ogra | in non omap boards that bit lives in rom | 12:40 |
| persia | No. | 12:40 |
| persia | So, ROM always just does a jump to somewhere after absolute minimum startup. | 12:40 |
| persia | But ROM is *never* complicated. | 12:40 |
| persia | (this is FPL). | 12:41 |
| persia | Depending on the capability of the ROM, it *may* have enough of an environment to use u-boot as SPL, but it may not. | 12:41 |
| ogra | rom inits ram, loads the BL and jumps to it | 12:41 |
| ogra | in case of omap the initialized ram is to small | 12:41 |
| persia | If one enables *all* the features in u-boot it's fairly easy to end up with needing something else as SPL. | 12:41 |
| persia | hence the comment above '"something" might need to be in two pieces itself' | 12:42 |
| ogra | i didnt debate that :) | 12:43 |
| ogra | i just said that generally u-boot is SPL by design | 12:43 |
| persia | My contention is that u-boot is an operating environment that neither knows nor cares where it's loaded. | 12:43 |
| ogra | that we deal with the special case of omap doesnt change that fact | 12:44 |
| persia | It could be PPL and be happy. | 12:44 |
| persia | (rom -> uefi -> grub -> linux -> u-boot, for example) | 12:44 |
| ogra | well | 12:44 |
| ogra | you could: rom -> linux | 12:44 |
| ogra | that doesnt make the kernel an SPL :) | 12:45 |
| persia | Sure. | 12:45 |
| persia | Yes it does. | 12:45 |
| ogra | for that particular case, yeah | 12:45 |
| ogra | but not generally | 12:45 |
| persia | I don't happen to think it's a particularly *good* SPL today. Needs *lots* of work. | 12:45 |
| persia | But some folk use it that way. | 12:45 |
| ogra | if you talk to linus you wont talk about his coll SPL | 12:45 |
| ogra | *cool even | 12:45 |
| persia | So, I agree that u-boot is often used as SPL. I'm just arguing that there isn't anything about u-boot design that makes it especially suited for that role. | 12:46 |
| ogra | apart from its design as SPL you mean ? | 12:46 |
| ogra | *g* | 12:46 |
| persia | I might, actually. I happened to be discussing boot loaders last time I was in the same room as Linus (although not with him) | 12:46 |
| ogra | thats something else | 12:47 |
| persia | So, what about the u-boot design allows it to even *tell* in which layer it's running? | 12:47 |
| ogra | you could discuss u-boot as rootfs with wolfgang | 12:47 |
| persia | I believe it can't. | 12:47 |
| ogra | wouldnt change its default purpose | 12:47 |
| persia | So, I just looked at the u-boot design documentation. It explicitly lists several different use cases, and completely fails to mention anywhere at which point it belongs in the boot process. | 12:50 |
| persia | But I also don't care enough to keep banging on the difference between "some" and "any" in specific application to bootloader purposes any longer. | 12:50 |
| persia | On the other hand, I completely fail to understand the point of x-loader: u-boot is claimed to support devices with 128K RAM. Does OMAP really not have that much on startup? | 12:51 |
| ogra | i think its half of it, not 100% sure | 12:53 |
| persia | 64K!!!!! | 12:54 |
| ogra | but even if you had 128 ... | 12:54 |
| ogra | you would have to rip out many important features from u-boot to make it fit | 12:54 |
| ogra | especially the hush shell support adds a lot | 12:54 |
| persia | If I'm using u-boot as an SPL and loading a real boot loader (e.g. grub), that's fine :) | 12:55 |
| ogra | without it we lose .scr support | 12:55 |
| persia | That's fine. | 12:55 |
| ogra | no, its not | 12:55 |
| ogra | you would have to recompile to change the cdmline | 12:55 |
| persia | Why not? .scr support is just a dirty hack we tossed together because we didn't have a good bootloader. | 12:55 |
| ogra | no | 12:55 |
| persia | No you wouldn't, because your TPL would set it dynamically. | 12:55 |
| ogra | its a design feature of u-boot | 12:55 |
| ogra | nothing we put together at all | 12:56 |
| ogra | we just use it | 12:56 |
| persia | You and I are using different definitions of "we" here. | 12:57 |
| ogra | we as people in this chatroom :) | 12:57 |
| ogra | (awake or not) | 12:57 |
| ogra | scr support comes from upstream | 12:58 |
| ogra | anyway, your u-öboot would be pretty limited if you would have to fit it in 128k | 12:58 |
| persia | I'm not willing to assert that nobody who occasionally follows #ubuntu-arm works on u-boot upstream, but we're off-point. | 12:58 |
| persia | Right, which is *fine* if I'm using it as SPL. | 12:58 |
| persia | As long as I have a capable TPL. | 12:59 |
| ogra | define capable :) | 12:59 |
| ogra | apparently linux isnt capable as TPL in the omap case | 12:59 |
| ogra | as long as x-loader is needed to actually initialize subsystems like usb | 13:00 |
| persia | Can detect attached bootable media, and dynamically generate command lines (perhaps based on on-disk configuration) to load QPL from that media. | 13:00 |
| persia | The problem there is that x-loader isn't a good enough SPL to get things working. | 13:00 |
| ogra | only if x-loader is your SPL :) | 13:00 |
| ogra | wrong way round :) | 13:01 |
| persia | Due to long history of using xloader + u-boot, bring-up patches were randomly distributed between the two. | 13:01 |
| ogra | x-loader is abused for initializing bots the kernel should initialize | 13:01 |
| ogra | *bits | 13:01 |
| ogra | not two ... sadly three | 13:01 |
| persia | So, every image should probably reinitialise everything. Not doing so is likely a bug. | 13:01 |
| ogra | x-loader, u-boot and kernel | 13:01 |
| ogra | image ? | 13:02 |
| persia | executable image that is loaded. *PL. | 13:02 |
| ogra | stage :) | 13:02 |
| ogra | but you dont need to initialize everything ... | 13:03 |
| persia | So, I accept that all FPLs must suck, by design. | 13:03 |
| ogra | x-loader only needs ram and the device it pulls the bootloader from | 13:03 |
| persia | I want my SPL to turn on all my hardware. | 13:03 |
| ogra | which as i said above should actually be the job of the rom | 13:03 |
| persia | I want my TPL to use that hardware to figure out how to boot. | 13:03 |
| persia | And I want my QPL as my default operating environment. | 13:04 |
| persia | I just don't happen to like the current SPL and TPL. | 13:04 |
| lool | persia: Note that u-boot is being used increasingly as a SPL rather than the reverse -- but split in two stages | 13:04 |
| ogra | they can be merged though | 13:04 |
| persia | lool, Hrm? So *both* SPL and TPL? | 13:04 |
| lool | yes | 13:05 |
| lool | with different configs | 13:05 |
| persia | Right. | 13:05 |
| persia | I should have said that u-boot is seeing increased use as a TPL, rather than saying it was seeing decreased use as SPL. | 13:05 |
| lool | it takes some efforts to bring u-boot down to a size where it can be used as SPL | 13:06 |
| lool | there are also various platform specific things which prevent it; secure boot is one example :-/ | 13:06 |
| * persia vaguely wonders if the sequence "F, S, T, Q, P" has ever been used for cardinality before, considering that it doesn't match *anything* | 13:06 | |
| persia | How does secure boot prevent u-boot as SPL? Can't one just sign some known perfect SPL u-boot? | 13:07 |
| lool | there are many reasons; first, basing on u-boot has less advantages since other people can't necessarily deploy it | 13:08 |
| persia | Or is it that the secure boot implementation must necessarily be the SPL? | 13:08 |
| lool | second, the GPL is a problem for some people | 13:08 |
| lool | third, the secure boot bits are often developed in R&D before considering u-boot | 13:09 |
| persia | Oh, right. Depending on the IP involved in the secure boot mechanism... | 13:09 |
| persia | Now, you suggested UEFI as SPL: does that address any of these aside from the GPL issue? | 13:10 |
| lool | persia: If you're interested, we've started some long term boot architecture discussion on the boot-architecture@llo list and on weekly calls | 13:10 |
| persia | I'm interested, but I'm not sure I can dedicate that much time. My opinions are mostly driven by user experience, but I think those are shared widely enough that repetition in that forum won't help. | 13:11 |
| persia | Although I'm glad to know it's happening, and will likely browse the ML archives once in a whle. | 13:12 |
| lool | So by UEFI I don't mean one specific implementation of it; we'd likely focus on tianocore ourselves for some boards, but each vendor could provide other compatible implementations | 13:13 |
| lool | they could even be basaed on GRUB, albeit that's extremely unlikely | 13:13 |
| persia | Heh, indeed. | 13:13 |
| persia | From prior exposure, I just thought that UEFI tended to be large, which might cause some of the same issues as for u-boot as SPL. | 13:14 |
| persia | Ah, so the goal of the boot architecture discussions is to have some spec that clearly separates IHV and OSV roles. I *really* like that. | 13:17 |
| persia | And I completely agree that it makes sense to *not* specify specific payloads, etc., but rather just specify how the payload is accessed. | 13:17 |
| persia | s/specific/particular/ | 13:18 |
| * ogra sighs about firefox in oeniric | 13:25 | |
| ogra | oh, sweet | 13:27 |
| * ogra likes software-center | 13:27 | |
| lilstevie | ogra: ? | 13:27 |
| ogra | i didnt know it asks you if it should add a new app you install to the launcher | 13:27 |
| lilstevie | nice | 13:27 |
| lilstevie | what about firefox? | 13:27 |
| ogra | and while the app installs you can read reviews | 13:28 |
| ogra | its slow, clunky and leaks memory | 13:28 |
| ogra | i'm just installing chromium ;) | 13:29 |
| lilstevie | heh | 13:29 |
| lilstevie | I have been using chromium on my tab | 13:29 |
| kunguz | After a while, my usb mouse stop working on ubuntu-arm installed on beagleboard c3, any suggestions? | 13:45 |
| persia | kunguz, Is there anything associated with it stopping? Anything in the syslog? Changes in /dev/input/*, etc.? | 13:47 |
| kunguz | persia: actually on the serial port, there is no output from beagleboard and I can not use any other device. | 13:48 |
| kunguz | persia: I can check the mmc card on other computer for the syslog | 13:49 |
| persia | kunguz, That sounds like a system freeze to me, rather than just the USB mouse stopping. Why do you suspect the USB mouse? | 13:51 |
| kunguz | persia: the same thing happend during the installation but the installation proceeded and completed with success | 13:51 |
| kunguz | persia: for example if I wait long enough the system shows a blank screen saver | 13:52 |
| persia | OK. Do you have any other input devices (keyboard, etc.)? | 13:52 |
| kunguz | persia: only mouse at this moment | 13:52 |
| persia | Nothing happening on the serial port is normal. | 13:53 |
| kunguz | and an unrecognised wireless adapter | 13:53 |
| persia | Hrm. Debugging one's only input device is tricky :) | 13:53 |
| kunguz | persia: now I am trying to reboot it only with an USB mouse attached. | 13:54 |
| kunguz | persia: by the way I am using an usb hub | 13:54 |
| kunguz | persia: so to say only devices attached are screen, an usb hub and an usb mouse. | 13:55 |
| persia | That makes it more likely to work :) | 13:55 |
| kunguz | and in my beagleboard it takes like 5 min. to open the whole system | 13:56 |
| persia | Which image are you booting? | 13:57 |
| kunguz | persia: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz | 13:57 |
| kunguz | this one | 13:57 |
| persia | Ah. The only reason I boot that on my beagle is to remove lots of stuff. I really doesn't perform very well with that little RAM. | 13:58 |
| persia | (I also have a C3) | 13:58 |
| kunguz | persia: is there a lubuntu-arm available? | 13:58 |
| persia | Try http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-headless-armel+omap.img.gz | 13:58 |
| kunguz | persia: gnome is a bit too much for beagleboard | 13:59 |
| kunguz | persia: what is this headless? | 13:59 |
| persia | I don't know of such an image. If you install headless, you can `apt-get install lubuntu-desktop` | 13:59 |
| kunguz | persia: oh i see thank you very much | 13:59 |
| persia | It's a minimal image, so you can install just the stuff you want. | 13:59 |
| kunguz | persia: that looks nice, so I am trying it | 13:59 |
| ogra | you better install the task though | 14:00 |
| persia | Good luck. I don't consider this to be a step towards debugging your USB mouse issue (if you have one), but I don't think we *can* usefully debug it with no keyboard and such sluggishness. | 14:00 |
| ogra | sudo tasksel install ubuntu-desktop | 14:00 |
| ogra | or so | 14:00 |
| kunguz | ogra: task? | 14:01 |
| persia | Or lubuntu-desktop, rather, in this case :) | 14:01 |
| ogra | or that | 14:01 |
| kunguz | ogra: ok I am trying | 14:01 |
| persia | But I don't think lubuntu-desktop has a task for natty. | 14:01 |
| persia | Better to use apt-get and install the metapackage in this special case. | 14:01 |
| ogra | no, lubuntu was just added as a task today | 14:01 |
| ogra | so its only in oneiric | 14:01 |
| persia | Right. The meta landed in maverick, I think. | 14:01 |
| ogra | yep | 14:01 |
| ogra | well, indeed, in this case the package is better | 14:02 |
| persia | In general, it's better to use tasks. | 14:02 |
| kunguz | persia: http://www.sudrap.org/paste/text/14408/ , that's what keeps happening when usb failes | 14:40 |
| persia | Oh, excellent! | 14:41 |
| persia | File a bug. Be sure to include specifics about your hub and mouse. lsusb -vv output is probably helpful. | 14:41 |
| persia | When I have issues like that, I generally try to change my USB routing (move devices and hubs around, swap hubs, etc.). That said, I've never seen that on my beagle, so it may be something different than the issue I work around. | 14:42 |
| === prpplague is now known as prpplague^2 | ||
| Spider-Pork | Hi, i've ubuntu 11.04 headless installed in my pandaboard. It can play correctly sound but if i record, the file will contain only mute sound. I know there is an issue about alsa, thre is a way to get arecord run correctly? Thank you | 16:05 |
| Spider-Pork | I sownloaded and compiled latest stable packages of alsa | 16:06 |
| Spider-Pork | *downloaded | 16:06 |
| ogra | did you read the bug i pointed you to ? | 16:07 |
| Spider-Pork | yep ogra | 16:08 |
| ogra | so you are using an mp3 player as input ? | 16:08 |
| ogra | and have enabled the Record verb ? | 16:08 |
| ogra | as described in the bug | 16:08 |
| ogra | and it still doesnt work ? | 16:08 |
| Spider-Pork | sorry for paste | 16:08 |
| Spider-Pork | sudo alsaucm set _verb HiFi sudo alsaucm set _verb Record sudo rm /var/lib/alsa/asound.state sudo reboot | 16:08 |
| Spider-Pork | nope for mp3 player | 16:09 |
| ogra | right, that enables all driver bits | 16:09 |
| Spider-Pork | i do it now | 16:09 |
| ogra | the input is wired as line in ... mics wont work | 16:09 |
| Spider-Pork | ok thank you ogra | 16:09 |
| Spider-Pork | i'll try with an mp3 player | 16:10 |
| ogra | note that you might have overwritten alsa stuff with your self compiled stuff now | 16:10 |
| Spider-Pork | and a male/male 3.5 cable | 16:10 |
| Spider-Pork | ah | 16:10 |
| ogra | so no guarantee it still works :) | 16:11 |
| Spider-Pork | if it will not works with mp3 player i will reinstall from zero | 16:11 |
| Spider-Pork | aplay sounds good | 16:11 |
| Spider-Pork | ogra: is there some route must be enabled with alsamixer? | 16:12 |
| Spider-Pork | to record i mean | 16:12 |
| ogra | no | 16:12 |
| Spider-Pork | ok | 16:12 |
| ogra | the defaults should just work after you issued the two alsaucm commands | 16:12 |
| Spider-Pork | ah ok | 16:13 |
| ogra | they do for everyone else at least | 16:13 |
| Spider-Pork | but maybe not for me | 16:13 |
| ogra | though you said you are using headless, not sure how well that works without pulse in the loop | 16:13 |
| Spider-Pork | ok | 16:13 |
| ogra | we only test such stuff on the desktop/netbook images | 16:13 |
| Spider-Pork | so maybe i can try to install pulse too | 16:13 |
| Spider-Pork | pulse on your repo | 16:14 |
| Spider-Pork | http://people.canonical.com/~ogra/natty-omap4-pulse/ | 16:14 |
| ogra | no | 16:15 |
| ogra | thats outdated testing crap | 16:15 |
| Spider-Pork | ah ok | 16:15 |
| ogra | the pulse in the archive works just fine | 16:15 |
| Spider-Pork | ok thank you ogra | 16:15 |
| === fairuz is now known as fairuz_ | ||
| infinity | apachelogger: I hear you have an iMX53 Quickstart that does fancy things like boot? | 18:45 |
| apachelogger | yes | 18:47 |
| infinity | apachelogger: Did you use the provided Ubuntu-esque micro-SD from Freescale, or did you have to homebrew something to make it work? | 18:48 |
| apachelogger | infinity: https://wiki.ubuntu.com/ARM/iMX53QuickStartBoard | 18:49 |
| infinity | apachelogger: Yeah. I've been pointed to that. Was curious if anyone's booted one with the SD Freescale is now shipping. | 18:49 |
| apachelogger | FWIW the default microsd image did not manage to bring up VGA for one reason or another | 18:49 |
| infinity | apachelogger: But I guess I'll try the crazy homebrew method. | 18:49 |
| apachelogger | I replicated the image and it worked | 18:49 |
| apachelogger | which is also pretty simple | 18:50 |
| apachelogger | just get the image tar.gz from freescale and follow the guide that is shipped inside the tar | 18:50 |
| infinity | apachelogger: Not bringing up VGA, I'd be okay with, but the default image doesn't seem to give me serial either, so I have no way of knowing if it's doing... Anything. | 18:50 |
| apachelogger | well, recreating the image definitely works | 18:50 |
| infinity | Kay. | 18:51 |
| apachelogger | infinity: http://i.imgur.com/WTJbh.jpg | 18:51 |
| infinity | Where do I get this freescale tgz? I only see linaro links on the wiki. | 18:51 |
| apachelogger | that is running the ubuntu image | 18:51 |
| apachelogger | infinity: freescale's quickstart board site | 18:51 |
| apachelogger | there is a downloads section | 18:51 |
| === Ursinha is now known as Ursinha-lunch | ||
| persia | apachelogger, So, one potential candidate for what is "wrong" with the 2.6.38 image is that the 2.6.35 kernel is a BSP kernel, and has *all* the patches, whereas the 2.6.38 kernel is a targeting-mainline kernel, and so doesn't have as many ugly hacks. | 20:05 |
| apachelogger | persia: that adds kernel patch issues to the list of possible causes for not working EGL init :S | 20:15 |
| persia | Indeed. So, Quintasan was talking with paulliu about stuff, and paulliu is working on linux-linaro-lt-mx5, which is 2.6.35 | 20:16 |
| persia | But the shiny is linux-linaro-mx5, which is 2.6.38 | 20:16 |
| persia | The *lt* kernels aren't in Ubuntu, and aren't likely to be. | 20:17 |
| apachelogger | persia: I see | 20:41 |
| === jkridner_ is now known as jkridner | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === Jack87|Away is now known as Jack87 | ||
| === prpplague^2 is now known as prpplague | ||
| === Jack87 is now known as Jack87|Away | ||
| === Jack87|Away is now known as Jack87 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
