| === amitk is now known as amitk-afk | ||
| smb | morning | 06:31 |
|---|---|---|
| ppisati | moin | 06:49 |
| === Ming is now known as Guest74462 | ||
| * ppisati is in 'email catchup mode' | 07:41 | |
| ikepanhc | ppisati: you mean deadlock or infinite loop? | 08:09 |
| diget | ls | 08:12 |
| diget | ohh sorry - definately wrong window ;) | 08:12 |
| Daviey | Hai.. can bug 1030600 be included in the next precise sru, and 12.10 next kernel please? | 08:27 |
| ubot2 | Launchpad bug 1030600 in linux "please build/install highbank dtb file" [Undecided,Confirmed] https://launchpad.net/bugs/1030600 | 08:27 |
| apw | Daviey, shark ? | 08:33 |
| smb | Daviey, Where is the shark? | 08:33 |
| === amitk-afk is now known as amitk | ||
| lifeless | in midair. | 09:01 |
| Daviey | apw: shark? | 09:12 |
| dileks | hai means German shark | 09:14 |
| ppisati | is monday morning even for tangerine?!?! | 09:16 |
| ppisati | ppisati 62325 99.2 0.0 4135820 2516 pts/0 R+ 09:37 37:15 /usr/bin/qemu-arm-static /bin/gzip --no-name --rsyncable -9 | 09:16 |
| === cking_ is now known as cking | ||
| cking | bah, now on 3G, ISP failure | 09:31 |
| * Eimann is on 3G for >3 Months, T-Mobile works good :) | 09:36 | |
| * henrix is having DNS issues as well... | 10:02 | |
| * ppisati -> back in 10mins | 10:13 | |
| === Ming is now known as Guest32569 | ||
| apw | Daviey, what do we need the dtb file for? we clearly arn't using it right now :) | 10:37 |
| Daviey | apw: And that is the problem.. :)... highbank qemu emulator requires device tree, the dtb file. | 10:38 |
| apw | we have real machines? | 10:39 |
| Daviey | we have some | 10:39 |
| apw | Daviey, is this file different in each kernel? is it really kernel specific? how large is it? do we make CDs for highbank and will they still fit with this extra on them | 10:40 |
| apw | Daviey, and ... this patch is not even against a branch that exists any more, its not flavour specific, so i'll have to rework it completely ... sigh | 10:41 |
| Daviey | apw: no cd is created... it's really small.. I have a panda one to hand.. # ls -alh board.dtb | 10:42 |
| Daviey | -rw-r--r-- 1 linaro linaro 340 May 18 19:14 board.dtb | 10:42 |
| Daviey | I believe it to be hardware specific, and as each hardware seems to have it's own kernel, it's therefore kernel specific | 10:43 |
| Daviey | But.. i could be wrong. | 10:43 |
| apw | Daviey, its definatly h/w specific, i was more wondering if you have one installed for every kernle you have installed will they differ | 10:44 |
| Daviey | apw: i suspect not, but i don't know | 10:45 |
| apw | ./boot/highbank.dtb-3.5.0-7-highbank | 10:45 |
| apw | Daviey, this seems like a silly name to me | 10:45 |
| Daviey | apw: but in any case, it's going to be ~3.5K | 10:46 |
| apw | Daviey, can you see any reason to have highbank in the name more than once ? | 10:46 |
| Daviey | apw: I believe real highbank kernel doesn't need it, only qemu emulated. | 10:46 |
| Daviey | apw: twice is twice the awesome. | 10:46 |
| apw | i suppose there might be more than one machine supported by a flavour in a perfect world | 10:47 |
| Daviey | NFI ;) | 10:47 |
| apw | hmmm, that does not inspire me with confidence to apply the change | 10:47 |
| Daviey | apw: wise. | 10:48 |
| Daviey | apw: I don't care if it is called mickeymouse.dtb TBH :) | 10:48 |
| apw | Daviey, do we really care about this in P, surely everyone in development is on Q now? | 10:59 |
| infinity | apw: Customers being able to test/prototype in qemu is pretty important. | 11:01 |
| infinity | apw: And their target is generally the LTS. | 11:01 |
| ikepanhc | apw: where you get the highbank.dtb? it shall not be with linux-image | 11:08 |
| apw | ikepanhc, its in the kernel sources isn't it? | 11:09 |
| apw | ikepanhc, though i assume thats because someone included it | 11:09 |
| ikepanhc | apw: yes, but device tree should be something bootloader hands to kernel in memory | 11:09 |
| apw | ikepanhc, oh yeah i understand it is useless on the filesystem for booting, as we need it before we start running | 11:10 |
| apw | ikepanhc, this is for the qemu users, i can also see in the future that you might have one on filesystem for a variant of flash-kernel to use when installing kernels to boot | 11:10 |
| ikepanhc | apw: right, it is ok, but not necessary to be put into filesystem | 11:10 |
| apw | ikepanhc, specifically here the only reason to include it is so qemu has somewhere to find it | 11:11 |
| ikepanhc | apw: that's also right, for qemu user, they need the dtb in the filesystem | 11:11 |
| apw | ikepanhc, so the requst was to include it for highbank in the kernel package, and i am happy for it to be in /boot as that is where we might want it for the conceptual flash my kernel with this generic arm kernel in the distant future | 11:12 |
| ikepanhc | that raise another question, shall we support for qemu user? | 11:13 |
| apw | ikepanhc, i don't see any formal support being requested for it | 11:13 |
| ikepanhc | apw: sounds like I can close my eyes | 11:14 |
| apw | Daviey, i assume there is no support for this its for testing | 11:14 |
| ikepanhc | Daviey: you need the dtb in /boot for supporting qemu env? | 11:15 |
| ikepanhc | what I know is that there is gap between qemu env and real hardware | 11:16 |
| infinity | ikepanhc: It could be distributed on floppies mailed to the user, it doesn't need to be in /boot, but the general rule for DTBs should be to put them in /boot, so why deviate here just because it's not technically needed on the hardware? | 11:16 |
| * apw is assuming the DTB here is for the real hardware rather than qemu, as its the one in the kernel | 11:18 | |
| ikepanhc | infinity: I just see the discussing about dtb in /boot. | 11:18 |
| ikepanhc | what I am sure is that on real hardware, dtb is not something comes from kernel | 11:19 |
| infinity | No, on real hardware, the dtb is burned into ROM. | 11:19 |
| infinity | Though it's basically the same as the one shipped from the kernel sources. | 11:19 |
| infinity | Which is kinda the point. | 11:19 |
| infinity | ikepanhc: flash-kernel on real highbank hardware is mostly a no-op anyway, so yeah, the dtb doesn't get used, but that's not a big deal. Do you actually have a concern with it being shipped? | 11:21 |
| apw | ikepanhc, right for highbank its not that useful as its in the firware and we don't supply it with the kernel, but if we did here is the right place for it i recon | 11:21 |
| ikepanhc | infinity: I think it shall not be shipped with linux-image | 11:21 |
| apw | and this change needs to be approximatly right for the future too, its not a highbank change, its an ARM DTB change | 11:21 |
| ogra_ | shoultnt it be in the u-boot package ? | 11:22 |
| infinity | ikepanhc: That's not an argument, or a concern, it's a statement. | 11:22 |
| infinity | ogra_: God no. | 11:22 |
| ogra_ | but it is something th ebootloader should supply to the kernel, no ? | 11:22 |
| apw | ogra_, the kernel is something the boot loader supplies to the machine and we don't include that in the bootloader | 11:22 |
| infinity | ogra_: That's like saying u-boot should ship initrds. | 11:22 |
| apw | heh thats a better way of putitng it | 11:23 |
| ikepanhc | ogra_: dtb may different based on hardware, its hardware description | 11:23 |
| apw | if the dtb comes from the kernel sources, then the kernel is not a dumb place to supply it | 11:23 |
| Daviey | sorry, went AFK | 11:23 |
| Daviey | Real hardware no longer requires it, i believe it's provided by the kernel dynamically | 11:24 |
| Daviey | Qemu, splits kernel from filesystem.. meaning it needs to be provided separately | 11:24 |
| apw | Daviey, to the kernel dynamically by the bootloader indeed | 11:24 |
| apw | Daviey, we are now arguming about location for it | 11:24 |
| Daviey | apw: Right, but i mean.. real hardware doesn't need this mod | 11:24 |
| infinity | Daviey: Yes, we know. | 11:24 |
| apw | Daviey, so by your own argument you should supply the dtb with qemu as its part of the hardware, and qemu is your hardware | 11:25 |
| ogra_ | who cares about real HW anyway ... its not what the intersted admin will have there first if he determines if highbank is for him | 11:25 |
| infinity | Still, we'll need to ship DTBs for a ton of other devices Real Soon Now, so this is as much about setting a sane policy for how to ship those as it is about highbank on qemu. | 11:25 |
| ogra_ | ++ | 11:25 |
| Daviey | apw: Is that what you want? Really? | 11:25 |
| ogra_ | i think omap and tegra switch to it in their next kernel iteration too | 11:26 |
| apw | Daviey, no i want a sane discussion on where it should go, and you seemed to be arguing we shouldn't ship it with the kernel; having just sent me a patch to do just that | 11:26 |
| Daviey | not my patch, but yes. | 11:26 |
| Daviey | So what is to discuss ? | 11:26 |
| ogra_ | and in the longterm there wont be SoC specific kernels at all anymore you will just install the -arm flavour | 11:26 |
| ogra_ | how does ppc deal with it btw ? | 11:26 |
| ogra_ | iirc it uses DT much longer already | 11:26 |
| apw | ogra_, all PPC machines have firmware which holds the dtb | 11:26 |
| infinity | ogra_: PPC device trees are all in firmware. | 11:27 |
| ogra_ | and qemu ? | 11:27 |
| infinity | (Though patchable at the kernel level) | 11:27 |
| ogra_ | ships a fake firmware ? | 11:27 |
| infinity | openbios-ppc has a device tree in it. | 11:27 |
| ogra_ | ah | 11:27 |
| apw | so the question is really, is this a one off, and highbank qemu is an aberation, or will other cheap arms need a DTB somewhere | 11:28 |
| apw | i guess one other option would be to add them to the firmware package | 11:28 |
| ogra_ | all arms will | 11:28 |
| ogra_ | at some point | 11:28 |
| ogra_ | at least all that linaro ever touched | 11:28 |
| apw | ogra_, all arms will have a DT, but will it come with the board, be on the board, or will it be something we need to know about | 11:28 |
| ogra_ | DT planning for arm in ubuntu is even older than linaro | 11:29 |
| apw | ogra_, on ppc you don't need to know about them as they are never something you handle | 11:29 |
| infinity | apw: Having them in linux-firmware wouldn't hurt my feelings. | 11:29 |
| ogra_ | apw, by design it cant come with the board on omap (no flash) | 11:29 |
| infinity | apw: As for where it lives, that depends on if the board HAS firmware. ;) | 11:29 |
| apw | infinity, well it all depends if they are kernel specific at all, ie version specific | 11:29 |
| infinity | apw: They can't be kernel specific, or the burned-in ones would fail to work with kernel upgrades. | 11:29 |
| infinity | apw: Which would be a pretty nasty design flaw. :P | 11:30 |
| apw | though i suppose having an /lib/firmware/dtb/arm-highbank.dtb-version is no worse | 11:30 |
| Daviey | well, they are kernel flavour specific ... whilst each SoC requires a different kernel flavour, until thye converge | 11:30 |
| apw | infinity, that would seem a reasonable statement, it implies the DT semantics are very stable | 11:30 |
| infinity | Daviey: They'll never converge, that's the point of a device tree. | 11:30 |
| apw | Daviey, that makes them system specific | 11:30 |
| Daviey | this discussion seems circular | 11:31 |
| ogra_ | the kernel will converge | 11:31 |
| Daviey | infinity: i mean kernel will converge | 11:31 |
| ogra_ | the HW wont :) | 11:31 |
| apw | though this implies that DT might grow over time but still be 'per system' | 11:31 |
| infinity | Daviey: Yes, but you seemed to imply the device trees would as well, which clearly they won't. :P | 11:31 |
| infinity | Daviey: The device trees are the reason the kernel will be able to converge. | 11:31 |
| Daviey | infinity: sorry, i wasn't implying that.. I was stating that kernel flavour is a reasonable separator for system, UNTIL the kernel converges the systems. | 11:32 |
| apw | if anything they will grow new nodes as more things become parameterised, so they will be enlarging so changing over time, but one assumes backwards compatible | 11:32 |
| apw | Daviey, right but that means right now we should not use flavours, as they are wrong 'soon' | 11:32 |
| Daviey | apw: agreed | 11:32 |
| Daviey | but soon could be years away. | 11:32 |
| infinity | apw: linux-firmware seems like a good fit for them. | 11:32 |
| * ogra_ still thinks it being a firmware it should live in the HW initialization (i.e. SPL or bootloader) | 11:33 | |
| Daviey | And it's easy enough to change the path.. we can spend all year predicting what will happen. | 11:33 |
| infinity | apw: Maybe we should look into making linux-firmware not be arch:all, so we can trim fat on some arches. :P | 11:33 |
| ogra_ | but seems i'm alone with that opinion :) | 11:33 |
| ogra_ | rsalveti, ^^^ | 11:33 |
| ogra_ | what does linaro plan here ? | 11:33 |
| infinity | ogra_: Burning it into u-boot means a different u-boot build for every platform, which is also something DT may well get rid of some day. | 11:33 |
| apw | Daviey, well as they are h/w specific they really feel more like firmware, so linux-firmware might make more sense | 11:33 |
| ogra_ | yes, u-boot will use the DT tables | 11:34 |
| infinity | ogra_: The whole point is that you take a kernel, slap on a device tree, feed it to u-boot, and it all works. | 11:34 |
| infinity | Three distinct parts. | 11:34 |
| ogra_ | thats why i think they should be shipped in there | 11:34 |
| Daviey | apw: linux-firmware seems good nuff to me :) | 11:34 |
| ogra_ | and we will *always* need board specific SLP | 11:34 |
| ogra_ | *SPL | 11:34 |
| apw | ogra_, what if they have redboot instead | 11:34 |
| apw | ogra_, we don't want to put them all in there as well | 11:34 |
| Daviey | they can go to hell. | 11:34 |
| infinity | ogra_: Not always. Not on all platforms. | 11:34 |
| ogra_ | no idea, i dont know redboot will ever support DT | 11:34 |
| ogra_ | (i dont think its being developed since 5 years) | 11:35 |
| apw | they feel like a bootloader independant thing | 11:35 |
| ogra_ | (or even 10) | 11:35 |
| apw | they feel like a kernel independant thing | 11:35 |
| ogra_ | u-boot will fully depend on DT in the future | 11:35 |
| apw | they feel like a hardware you have specific thing | 11:35 |
| apw | which i think means to me they are firmware-esque | 11:35 |
| ogra_ | so you *have* to have the DT data available before you have a kernel or rootfs | 11:35 |
| Daviey | why not just put it in -firmware for now, and we can switcheroo later if needed. | 11:35 |
| Daviey | it's a reasonable starting block. | 11:35 |
| * ogra_ would really like to hear from linaro, they have it planned through and will implement it | 11:36 | |
| ogra_ | we can discuss it til death but after all we will have to use what linaro makes out of it | 11:36 |
| infinity | Eh? | 11:37 |
| infinity | ogra_: Linaro has nothing to do with it. | 11:37 |
| ogra_ | then their main objective changed recently | 11:38 |
| infinity | ogra_: What package we ship it in, and where we put it on the filesystem, is, well, meaningless bikeshedding, and there's no reason any two distros have to match. | 11:38 |
| ogra_ | unified kernel and bootloader was one | 11:38 |
| infinity | ogra_: Yes, unified kernel is happening, that has nothing to do with this discussion. | 11:38 |
| ogra_ | infinity, what i mean is that the filesystem is the totally wrong place | 11:38 |
| infinity | This is pure bikeshedding about where to put some files. | 11:38 |
| apw | right we concur that linaro will drive all arm kernels to need and use a DT | 11:38 |
| infinity | ogra_: It's going to be on the filesystem SOMEWHERE. | 11:39 |
| ogra_ | your SPL wont have any access to it | 11:39 |
| apw | so we can have one kernel, but how we get those together and where we put them is surley something 'we' are best quantified to grok | 11:39 |
| infinity | ogra_: Cause you have to "cat vmlinux dtb > newblob" to feed it to u-boot. | 11:39 |
| ogra_ | oh, sure, but it wont be used from there during boot | 11:39 |
| apw | SPL ? | 11:39 |
| ogra_ | first stage bootloader | 11:39 |
| infinity | The SPL has no access to it at all in the current world order. | 11:40 |
| ogra_ | well, actually the S stands confusingly for "second" ... since the ROM is the first stage | 11:40 |
| infinity | Also not changing this month. | 11:40 |
| ogra_ | surely not, indeed | 11:40 |
| apw | please never :) | 11:40 |
| infinity | So, again, not relevant. | 11:40 |
| ogra_ | relevant if they change it in a month though | 11:40 |
| ogra_ | thats why i think we need linaro input, they do the upstream work | 11:41 |
| infinity | If they change how everything on the platform works, we get to sort it out then. | 11:41 |
| infinity | Right now, we need to sort out how to boot with the current kernel/dtb/u-boot trio. | 11:41 |
| infinity | Which we know how to do. | 11:41 |
| infinity | We're just arguing about WHERE TO PUT FILES. | 11:41 |
| infinity | No knowledge of the future changes that. | 11:42 |
| infinity | At all. | 11:42 |
| apw | i would say even if it needs to be in /gableblotchet to make something like u-boot work | 11:42 |
| ogra_ | right, but they know what the plan for the near future | 11:42 |
| apw | its still a firmwary thing and sound come out of the firmware packages | 11:42 |
| infinity | ogra_: But that doesn't matter! | 11:42 |
| ogra_ | and we could already work towards this instead of having to change it massively again | 11:42 |
| infinity | ogra_: We need a plan for today. The plan can't be "do nothing until it changes". | 11:42 |
| ogra_ | th eplan should be "ask the implementor first" imho | 11:42 |
| infinity | ogra_: And whatever they plan to do, it has no relevance AT ALL to where we ship files. | 11:43 |
| infinity | They're not implementing an OS, they're implementing a boot method. | 11:43 |
| infinity | It's up to us to make it work with our OS. | 11:43 |
| ogra_ | they implement something where bootloader and kernel use the same file ... while the bootloader doesnt have any access to this file | 11:43 |
| infinity | It's glued to the kernel. | 11:44 |
| Daviey | ---✂------✂------✂------✂------✂TRIM BIKESHED ---✂------✂------✂------✂--- | 11:44 |
| Daviey | Sorry, just a marker for my logs. | 11:44 |
| ohsix | wouldn't ### have sufficed | 11:44 |
| Daviey | ohsix: no. | 11:45 |
| ohsix | has it occured in the discussion already?! | 11:46 |
| * ppisati likes the scissors... :) | 11:46 | |
| * smb tries to see through the pillars of smoke... | 11:56 | |
| * cking now sees why earlyprintk=dbgp is flaky on his H/W | 12:41 | |
| rtg | cking, is it a generic issue, or just on your HW ? | 12:49 |
| cking | rtg, i'm comparing a bunch of machines to see if it is machine specific | 12:49 |
| cking | the fix is trivial, but i need to sanity check it first on a broad range of machines | 12:50 |
| rtg | cking, ack | 12:50 |
| rsalveti | infinity: ogra_: apw: currently we have the "reference" dtb file at the kernel tree itslef | 13:03 |
| rsalveti | which is produced during the kernel build | 13:03 |
| rsalveti | in our case we're installing it together with the linux package and at /boot/, so flash-kernel can copy it over while installing uImage and uInitrd | 13:03 |
| ogra_ | rsalveti, right, but what will you do wrt SPL and u-boot ? | 13:03 |
| rsalveti | that's complicated, as it's hardware dependent | 13:05 |
| rsalveti | as we don't yet have a "final" dtb that would ideally be provided by the hardware, we're shipping the latest one provided by the kernel build | 13:05 |
| rsalveti | which would be loaded by u-boot | 13:05 |
| ogra_ | k | 13:05 |
| rsalveti | so having it at linux-firmware is ok, but if you're planning on updating it over the time, that can be dependent to the kernel used by the system | 13:06 |
| rsalveti | until there's a single dtb file that can be used as reference | 13:06 |
| rsalveti | the same that would be provided by the hardware itself | 13:06 |
| rsalveti | the problem is that we could even have hardwares that doesn't support a valid u-boot and needs dtb to work :-) | 13:07 |
| rsalveti | which would need the distro to merge both dtb and the kernel into one single file | 13:07 |
| rsalveti | but I don't think we need to cover that specific use case at ubuntu now | 13:07 |
| ogra_ | k | 13:08 |
| rsalveti | so unfortunately this logic would still be part of flash-kernel | 13:08 |
| ogra_ | thats not the prob :) | 13:08 |
| apw | rsalveti, i assume the dtb would be backward compatible conceptually is not kernel specific | 13:09 |
| rsalveti | it should, and the drivers should only use the dtb if it's actually provided by the boot | 13:10 |
| rsalveti | as the dtb files can also be produced by the kernel, as a reference one, I don't see why we shouldn't just provide them as part of the kernel package itself | 13:11 |
| rsalveti | even if we copy them over to linux-firmware, it'd still be just a reference of the latest one integrated from the latest kernel tree | 13:12 |
| infinity | rsalveti: Sure, that was understood. | 13:12 |
| infinity | rsalveti: Though the kernel tree one certainly doesn't change that often. | 13:12 |
| ogra_ | having them in a non kernel package will make quemu stuff more tricky though | 13:13 |
| rsalveti | currently people are changing them quite frequently | 13:13 |
| infinity | rsalveti: And, of course, shipping them from the kernel build is "wrong" when the linux-image can support more than one hardware platform. | 13:13 |
| ogra_ | as users will need to get two packages | 13:13 |
| rsalveti | because the port is on going | 13:13 |
| rsalveti | sure, but would still be just a reference | 13:13 |
| * infinity nods. | 13:13 | |
| ogra_ | not a biggie indeed, but documentation issue and likely causeing support requests | 13:13 |
| rsalveti | the problem would be once we get to the situation where the dtb is needed just to boot the device | 13:14 |
| infinity | Anyhow, shipping it from linux-image in /boot was our first gut reaction anyway. | 13:14 |
| infinity | linux-firmware just seemed like a more elegant ongoing solution. | 13:14 |
| rsalveti | so we'd need some sort of dtb available at the system for flash-kernel to use | 13:15 |
| ogra_ | it surely is, but might be unexpected for users | 13:15 |
| rsalveti | it'd say it's unexpected because you can produce them from the kernel build itself :-) | 13:15 |
| infinity | Though, the part where you can technically have linux-image without firmware makes it make more sense to put it in linux-image. | 13:15 |
| Daviey | I really couldn't give a monkeys where it is btw :) | 13:15 |
| rsalveti | so if it's produced from the kernel build, why it sholdn't be part of the kernel package? :-) | 13:15 |
| * infinity waffles. | 13:15 | |
| Daviey | infinity: well, you can technically use linux-image without dtb :) | 13:16 |
| infinity | rsalveti: Yeah, perhaps it should just be in linux-image, and as we get platform convergence, linux-image can just ship multiple DTs. | 13:16 |
| infinity | Daviey: We're not talking about highbank. | 13:16 |
| infinity | Daviey: We're talking about the whole concept. | 13:16 |
| Daviey | Yeah, i gave up all my monkeys 3 hours ago on the concept. | 13:17 |
| infinity | Daviey: Some kernels won't boot without DTs on some hardware, in the future. That's a consideration we need to think about. | 13:17 |
| infinity | apw: Given that, it probably makes more sense to ship it in linux-image, and when we end up with platform convergence, we'll just ship multiple DTs in linux-image-arm-generic. | 13:17 |
| infinity | Though, filesystem-wise, boot then feels ugly, cause you could have dozens of them. | 13:18 |
| infinity | So, linux-image, the package, but /lib/firmware, the filesystem namespace? | 13:18 |
| apw | infinity, well i presume i could put them in /lib/firmware/device-tree still ? | 13:18 |
| infinity | apw: Absolutely. | 13:19 |
| infinity | apw: And that feels sane to me. | 13:19 |
| infinity | apw: Just ship them from linux-image-$(abi), though. | 13:19 |
| Daviey | Can we start bikeshedding over path now? | 13:19 |
| apw | infinity, ok that works for me i guess... | 13:19 |
| * apw /kickbans Daviey | 13:20 | |
| infinity | apw: I'd have no issues with /boot either, except for this theoretical future where /boot would end up littered with 50 dtbs for all the platforms the generic kernel supports. | 13:20 |
| infinity | (And I can't wait for that to be a reality) | 13:20 |
| infinity | apw: Anyhow, if we fuck it up, it's not like it's hard to move things around later. :P | 13:21 |
| Daviey | Okay, package name.. ✓ ... path... ✓ .. now we need to discuss filename. | 13:22 |
| infinity | No we don't. | 13:22 |
| * apw uses the filename the kernel produces for the hardware | 13:22 | |
| * Daviey blinks. | 13:22 | |
| apw | as someone else has bikeshedded about the filename upstream and made sure it is unique | 13:23 |
| Daviey | Hmm, i ws thinking we could make this discussion go on all day? | 13:23 |
| * smb thinks Daviey needs some real work assigned... | 13:25 | |
| infinity | bjf: Say, does the bot hande "prepare package" bug tasks based on scanning the PPA, or is that a manual thing? | 13:31 |
| bjf | herton: ^ i can never remember all the things the bot does automagically | 13:32 |
| infinity | bjf: Mostly curious if Ike should be updating https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1030308 manually, or if the bot will get to it. | 13:32 |
| ubot2 | Ubuntu bug 1030308 in linux-armadaxp "linux-armadaxp: 3.2.0-1606.9 -proposed tracker" [Medium,In progress] | 13:32 |
| infinity | bjf: I also assume, though, that if impatient people jump the gun on automated tasks, the bot won't have a hissy fit? | 13:32 |
| bjf | infinity: yes, the bot is happy to let humans play along | 13:33 |
| herton | infinity, bjf: yes, the bot looks in the build status in the ppa | 13:33 |
| infinity | Check. Maybe I'll just jump the gun so I can get to my copying and overriding. :) | 13:33 |
| infinity | herton: Okay, good to know. | 13:33 |
| infinity | ikepanhc: ^-- The bot would have updated it "eventually", but I'm going to short the process and JFDI. | 13:33 |
| * ikepanhc reads | 13:34 | |
| ikepanhc | infinity: you are going to copy it? thanks | 13:35 |
| herton | infinity, but in the case of armadaxp, the prepare-package must be fix-released, and upload-to-ppa in progress. | 13:35 |
| infinity | ikepanhc: Like I said, I have to fix it after it's copied anyway, so I may as well. | 13:35 |
| infinity | herton: Ahh, so Ike messed up his tasks so the bot won't look. :P | 13:35 |
| infinity | ikepanhc: ^ | 13:36 |
| herton | for these derivative packages it was intended that we would do the upload, so there is this extra upload-to-ppa task | 13:36 |
| ikepanhc | probably the bot does not like me | 13:36 |
| herton | may be for armadaxp we should remove it, since ike is doing the uploads | 13:36 |
| ikepanhc | herton: nono, we just kidding here | 13:37 |
| bjf | ikepanhc: after uploading the package you need to set the "prepare-package" to "fix-released" | 13:37 |
| ikepanhc | herton: oh, you mean the upload-to-ppa? | 13:37 |
| ikepanhc | herton: how about set to invalid? | 13:37 |
| ikepanhc | bjf: ACK | 13:38 |
| bjf | ikepanhc: you should be setting the "upload-to-ppa" as well | 13:38 |
| infinity | Anyhow. Tasks all fixed up, and packages copied. I'll fix overrides in half an hour. | 13:38 |
| herton | the idea was, for example, the derivative maintainer sets the prepare-package to fix released. the bot would set the upload-to-ppa task to confirmed, to notify us. then we would upload the package and set the upload-to-ppa to in progress | 13:39 |
| herton | but things ended up being different for armadaxp | 13:39 |
| ikepanhc | bjf: eh, its done, anyone did it? or bot? | 13:39 |
| infinity | ikepanhc: I did. | 13:39 |
| infinity | ikepanhc: It was "New" when I got there. | 13:39 |
| ikepanhc | infinity: thanks | 13:40 |
| infinity | herton: Do the wiki step-by-step docs point out which tasks the bot manipulates, and under what conditions? | 13:40 |
| herton | ikepanhc, so for your case for now, just set prepare-package to fix released and upload-to-ppa to in progress | 13:40 |
| infinity | (I haven't read that doc for a while...) | 13:40 |
| herton | ikepanhc, when doing the upload | 13:41 |
| ikepanhc | herton: ACK | 13:41 |
| ikepanhc | herton: keep the status correct.. understood | 13:41 |
| herton | infinity, yes, there is some description on what the bot does, may be not ideal, https://wiki.ubuntu.com/Kernel/kernel-sru-workflow | 13:42 |
| infinity | herton: Oh, see, I'd never before read that with s/Worflow Mgr./The Bot/ | 13:42 |
| infinity | herton: Makes a bit more sense if I do. ;) | 13:43 |
| infinity | Workflow, even. | 13:43 |
| === Guest52991 is now known as mfisch | ||
| === mfisch is now known as Guest54314 | ||
| herton | infinity, bjf, I updated that wiki page (kernel-sru-workflow). I noted there was some missing pieces/outdated info. | 14:52 |
| * ogasawara back in 20 | 14:53 | |
| bjf | herton, thanks | 14:54 |
| * herton -> lunch | 15:02 | |
| === Guest54314 is now known as mfisch | ||
| rtg | ogasawara, cracked the ubuntu-r repo. builds for amd64, and am working on the rest of the arches. updated dropped.txt, etc. we should -cr1 by weeks end I think. | 15:27 |
| rtg | -rc1 even | 15:27 |
| ogasawara | rtg: sweet | 15:27 |
| ogasawara | rtg, apw: I was going to plan on a quantal upload today too if you guys had anything you haven't pushed yet that you want in | 15:31 |
| apw | ogasawara, have a highbank change i'd like to see in, its a passive file | 15:32 |
| rtg | ogasawara, I'll be pushing firmware patches for the kernel throughout the week, but I see no reason not to upload soon. | 15:32 |
| ogasawara | apw: ack | 15:32 |
| apw | ogasawara, ok pushed | 15:37 |
| ogasawara | apw: cool, thanks | 15:37 |
| apw | ogasawara, i have also shoved an abi bump underneath | 15:37 |
| cking | ubuntu-r already? is it that time of the year again?! | 15:38 |
| apw | cking, always | 15:38 |
| cking | apw, seems shorter each time, argh, time must be speeding up | 15:39 |
| apw | cking, you are getting slower :) | 15:39 |
| cking | noooooo | 15:39 |
| ogasawara | apw: available to mumble? | 15:43 |
| === rtg is now known as rtg-afk | ||
| * cking --> EOD (early for once) | 17:17 | |
| * ppisati -> gym | 17:34 | |
| === shadeslayer is now known as shadeslayer_ | ||
| === shadeslayer_ is now known as shadeslayer | ||
| * henrix -> EOD | 18:25 | |
| herton | smb, when running maint-startnewrelease I'm still getting some errors related to SIGPIPE (stdout: broken pipe) | 18:51 |
| herton | from this on getabis script: | 18:51 |
| herton | # Prevent exposing some errors when called by python scripts. SIGPIPE seems to get | 18:51 |
| herton | # exposed when using the `find ...` form of the command. | 18:51 |
| herton | ko=$(find lib/modules/$verabi-$sub/kernel \ | 18:51 |
| herton | -name '*.ko' | head -1) | 18:51 |
| herton | smb, this fix I'm testing on kteam-tools seems to do the trick, avoiding the problem: http://pastebin.ubuntu.com/1120029/ | 18:53 |
| smb | herton, Hm, would be a better explanation than the change of shell script. Though it seemed to work for me | 19:10 |
| herton | smb, seems because head finishes earlier, then find tries to write again and then there is an error, since how python setup sigpipe | 19:11 |
| smb | herton, Heh, guess it depends then whether you use a netbook or a real computer... :) | 19:13 |
| herton | yep, sometimes if head finishes "later", there wouldn't be an error. that's why probably when reordering that line introduced a time change that made it work sometimes | 19:14 |
| herton | *finishes later than the last find write | 19:16 |
| === rtg-afk is now known as rtg | ||
| herton | smb, I found this which has a good example, gzip being affected as well: http://blog.nelhage.com/2010/02/a-very-subtle-bug/ | 19:24 |
| apw | rtg, did you tag the sync point to R in the quantal repo ? | 19:26 |
| rtg | apw, not yet | 19:26 |
| rtg | it should be agaist -6.6 | 19:26 |
| rtg | against* | 19:26 |
| rtg | apw, besides, I don't think a sync point tag does much good as long as we're rebasing | 19:29 |
| rtg | rebasing quantal, I mean | 19:29 |
| apw | rtg, well at least you can see the top commit, the title should remain the same, but yes till the rebase stops its not a simple git log | 19:30 |
| rtg | though I suppose a tag, even though not lineraly accurate, would at least tell you to begin in the stack of UBUNTU patches | 19:30 |
| rtg | linearly* | 19:30 |
| rtg | where to begin* | 19:31 |
| apw | rtg, right | 19:34 |
| rtg | apw, pushed Ubuntu-R-sync | 19:51 |
| * ppisati just had a huge kebab | 20:00 | |
| ppisati | *burp* | 20:00 |
| bjf | jjohansen: bug 1029937 (just so it's on your radar) | 20:30 |
| ubot2 | Launchpad bug 1029937 in qa-regression-testing "test-kernel-security failures on Precise with 3.5.0-6 kernel" [Undecided,New] https://launchpad.net/bugs/1029937 | 20:30 |
| jjohansen | bjf: ack | 20:31 |
| jjohansen | apw: btw your kernel that rolled out fixed my S/R issue even though the testing kernel didn't :/ | 20:32 |
| apw | jjohansen, wibble, good in some sense, but | 20:56 |
| jjohansen | apw: yeah, I don't understand and haven't looked at it more yet, just noticed it on the weekend, when I slept my machine by accident | 20:58 |
| apw | well at least it is in the positive | 20:58 |
| autojack | hi. I was following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel trying to customize a Lucid kernel for my i386 ec2 instance. I've built kernels from scratch before, though not since the LILO days :) when I run 'fakeroot debian/rules binary-headers binary-generic' it eventually errors, saying there is no target named binary-generic. what am I doing wrong? | 21:10 |
| autojack | Google didn't lead me to a solution. | 21:11 |
| cheako | bug 1007089 | 22:04 |
| ubot2 | Launchpad bug 1007089 in linux "overlayfs alters /proc/self/exe link(s), making result a dead link." [Medium,Confirmed] https://launchpad.net/bugs/1007089 | 22:04 |
| cheako | This bug is causing several other packages to have issues. | 22:05 |
| cheako | It's importance should be set at High (2.7 points) or Critical (1 point), I've mentioned this in #ubuntu-bugs. | 22:14 |
| cheako | Err, I can't count. That's 3.3 points for High. | 22:14 |
| * rtg -> EOD | 22:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!