| zul | Kano: | 01:33 |
|---|---|---|
| === reynaldo_ is now known as reynaldo | ||
| === pgraner_ is now known as pgraner | ||
| === asac_ is now known as asac | ||
| === Traxer|off is now known as Traxer | ||
| rtg | cking: there is info about the SRU process here: https://wiki.ubuntu.com/StableReleaseUpdates | 13:40 |
| cking | rtg: thanks! | 13:41 |
| rtg | cking: if pitti agrees, then we ought to package up dapper just for that one bug. I'm pretty sure it affects a bunch of folks. | 13:43 |
| cking | rtg: I've subscribed ubuntu-sru - I suppose this will prompt pitti into action on it - not sure how to "package up dapper" though. | 13:47 |
| amitk | rtg: can we still do a hardy kernel + lum upload for lpia only? | 13:48 |
| rtg | amitk: yeah, but not until after the point release freeze has thawed a bit. | 13:49 |
| rtg | cking: this is when you get to start learning Debian packaging. | 13:50 |
| amitk | rtg: what does that mean? We do want this in the point release w/o an ABI change... | 13:50 |
| amitk | cking: lucky man! :) | 13:51 |
| rtg | amitk: ok, so it _only_ affects lpia ? | 13:51 |
| cking | it was inevitable. | 13:51 |
| cking | oh joy | 13:51 |
| amitk | rtg: yes, since it only touches config.lpia. But a lum recompile is necessary because ABI is changing for lpia. | 13:52 |
| rtg | amitk: so that means a forced version bump on LUM? | 13:53 |
| rtg | e.g., that is what triggers a rebuild. | 13:53 |
| amitk | rtg: I have a LUM lpia-only patch that could be snuck in there to go with the version bump. Intel would be happy... | 13:54 |
| rtg | amitk: ok, so the issue is that there are already a number of SRU fixes pending in the Hardy repo. Steve is _not_ going to want those in the upload. What you have to do is prep a kernel and LUM upload that contains _only_ the lpia changes, then merge the changelog, etc, back into the master branch. Does that sound right? | 13:56 |
| rtg | these freezes are a real pain in the ass, but I understand why he wants it done this way. | 13:57 |
| amitk | rtg: correct. I can reorder that patches in the tree so only lpia ones are picked up... others will be 'floated' up towards the top. | 13:58 |
| amitk | it will requires a git push -f | 13:58 |
| rtg | amitk: well, now is as good a time as any. | 14:00 |
| BenC | amitk, rtg, cking: Not sure if you guys noticed, but 2.6.26 is default in intrepid now (or should be if the NEW process is done) | 14:28 |
| BenC | new lrm was uploaded last night | 14:29 |
| cking | BenC: Excellent | 14:29 |
| BenC | And you guys might enjoy the new Kconfig system is lrm | 14:30 |
| BenC | I'm going to use it as a basis for lbm in intrepid as well | 14:30 |
| BenC | basically it's a full Kconfig like in the kernel, and you can do "debian/rules updateconfigs" like in the main kernel after adding or removing kconfig options | 14:30 |
| BenC | even has an "-include .../autoconf.h" for the local results added to the build | 14:31 |
| cjwatson | I processed at least some kernel stuff through NEW earlier today | 14:42 |
| BenC | cjwatson: basically it was lrm and linux-meta | 15:00 |
| BenC | rtg: and to make you happy, lrm is now in git :) | 15:00 |
| BenC | Big fat note, is all of our firmware is now in lrm, and is installed via the linux-restricted-modules-common package | 15:01 |
| BenC | IOW, firmware is not versioned based on the kernel now | 15:01 |
| BenC | I'll do some documentation on this scheme later, but the simple description is, we will make an effort to version firmware by filename instead of installed duplicate copy of it for each kernel flavour/abi | 15:02 |
| * BenC thinks he is done with his rambling now | 15:04 | |
| rtg | BenC: I versioned firmware for iwlwifi by changing the firmware file name in the source. | 15:05 |
| BenC | rtg: exactly...that's the preferred way, IMO | 15:08 |
| === pgraner_ is now known as pgraner | ||
| * pgraner notes BenC found coffee this AM | 15:21 | |
| BenC | pgraner: No, I was _served_ coffee | 15:22 |
| * BenC keeps a tight leash on the little minions | 15:22 | |
| * pgraner just remembered why he had kids, to get served .... | 15:23 | |
| amitk | BenC: SELINUX is on by default in 2.6.26. Shouldn't we turn it off? | 15:28 |
| BenC | amitk: enabled or actually on and being used? | 15:30 |
| BenC | debian/config/amd64/config:CONFIG_SECURITY_SELINUX_BOOTPARAM=y | 15:30 |
| BenC | debian/config/amd64/config:CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 | 15:30 |
| BenC | I show it as being enabled, but turned off by default | 15:30 |
| BenC | debian/config/i386/config:CONFIG_SECURITY_SELINUX_DISABLE=y | 15:31 |
| amitk | BenC: I didn't notice the BOOTPARAM_VALUE. That looks ok.. | 15:32 |
| BenC | pgraner: I'm sure you remember being the channel changer when you were a kid....I vowed to have my own channel changers when I grew up, but then they came out with remotes | 15:32 |
| pgraner | BenC: yea now mine have become remote fetchers | 15:32 |
| BenC | hehe | 15:32 |
| BenC | amitk: drm-poulsbo keep/remove in intrepid? | 15:48 |
| amitk | BenC: remove | 15:50 |
| amitk | I will integrate it into the mobile kernel tree | 15:50 |
| BenC | thanks | 15:52 |
| BenC | Anyone have an atheros, broadcom 4312 or ltmodem they can test with intrepid kernel+lrm? | 15:53 |
| rtg | BenC: I might have a 4312 | 15:53 |
| BenC | rtg: if you have any broadcom...maybe you can echo VEN:DEV into new_id for the driver and see if that works too :) | 15:54 |
| rtg | BenC: its a 4328 | 15:56 |
| hallyn | rtg: did you have any questions about file capabilities? Are you at all considering enabling them in the hardy kernel? | 16:13 |
| BenC | cjwatson: Any gotchas in d-i stuff in 2.6.26/intrepid kernel? | 16:18 |
| cjwatson | BenC: the 386 udebs aren't there | 16:19 |
| cjwatson | I've disabled the netboot/386 build for now | 16:19 |
| cjwatson | haven't found anything else so far, only found that five minutes ago ;) | 16:21 |
| BenC | cjwatson: I thought you didn't use those? | 16:24 |
| cjwatson | use which, the udebs, or the netboot/386 builds? | 16:25 |
| BenC | we moved -386 to linux-ports | 16:26 |
| cjwatson | yes, and that's fine, but it doesn't build the udebs any more | 16:26 |
| BenC | cjwatson: ok. I'll take a look at that | 16:26 |
| cjwatson | I believe some people do need to use them, or at least I'm not confident that they don't :) | 16:27 |
| rtg | hallyn: kirkland brought that one up earlier this morning. I have a couple other issues to run to ground, then I'll take a look at it again. I did see your comment in the report. | 16:30 |
| kirkland | hallyn: enabling for hardy kernel will be almost impossible, unless there's a security vulnerability. enabling for Intrepid is what I think you're requesting.... | 16:32 |
| hallyn | kirkland: i'm a demanding jerk | 16:32 |
| kirkland | hallyn: ;-) | 16:32 |
| hallyn | rtg: ok, thanks, whenever you get a chance | 16:32 |
| rtg | kirkland: as hallyn pointed out, it may well be a security vulnerability. | 16:33 |
| hallyn | huh, what did i point out? | 16:33 |
| kirkland | hallyn: in your bug comment | 16:33 |
| rtg | hallyn: remind which bug number it was | 16:33 |
| rtg | maybe I'm confusing things | 16:34 |
| rtg | we're talking about the SET_PCAP stuff, right? | 16:35 |
| kirkland | rtg: hallyn: bug #95089 | 16:35 |
| kirkland | hallyn said: "CAP_SETPCAP is dangerous when CONFIG_SECURITY_FILE_CAPABILITIES=n because then it allows a task to grant capabilities to other tasks." | 16:35 |
| rtg | kirkland: right. I'll get to it as soon as kees and I are done with the -security uploads. | 16:36 |
| kirkland | rtg: it = discussing, or it = enabling? | 16:36 |
| hallyn | ah, excellent, i see chris friedhoff stumbled into a linked thread and wants to help :) | 16:37 |
| rtg | kirkland: "it" being a nonspecific promise of attention. | 16:37 |
| kirkland | rtg: ;-) cool | 16:37 |
| BenC | IRC meeting time | 17:00 |
| BenC | Give me 2 minutes to prepare | 17:01 |
| mrec__ | BenC: ping | 17:02 |
| BenC | Ok, sorry for the delay | 17:04 |
| BenC | amitk_, rtg, cking: You guys present and accounted for? | 17:04 |
| cking | Here | 17:05 |
| rtg | BenC: dude | 17:05 |
| BenC | Just to get started, the primary agenda for this meeting is to discuss what's happening in Intrepid now and in the coming months | 17:05 |
| BenC | So as of last night some time, 2.6.26-rc6 went default in intrepid | 17:06 |
| BenC | If you pay attention to the git repo's, you will notice that much of lum has moved back into the main tree under ubuntu/ | 17:06 |
| BenC | There are a few drivers still left to move, and that will occur over the coming weeks | 17:07 |
| BenC | In addition, lrm has been uploaded for intrepid | 17:08 |
| BenC | All of our firmware has been moved to linux-restricted-modules-common package | 17:08 |
| BenC | This includes firmware that was in lrm and in lum | 17:08 |
| BenC | The only drivers in lrm at the moment are broadcom 4312 hybrid driver, madwifi (still 0.9.4) and ltmodem | 17:09 |
| cking | BenC: Are many of the lum modules been updated, e.g. lirc? | 17:11 |
| BenC | nvidia and fglrx are being moved to a DKMS style package and will be available separately | 17:11 |
| BenC | (and just to note, almost all of this is documented on the kernel team wiki, and was discussed at UDS) | 17:11 |
| BenC | Speaking of UDS/wiki, the specs from there will get fleshed out soon to provide more implementation details | 17:11 |
| BenC | rtg, amitk_, cking: Do you guys have anything to add? | 17:11 |
| BenC | cking: the ones in the tree already have been refreshed to the latest stable versions | 17:11 |
| rtg | BenC: nah, just working on SRUs for older kernels. | 17:11 |
| BenC | The ones left to move (lirc included) will also be refreshed | 17:11 |
| BenC | Well that's all I have...anyone want to add anything, or have any questions? | 17:13 |
| BenC | mrec__: did you have something for the meeting, or was that a general ping? :) | 17:13 |
| cking | BenC: Will the build for lrm be different to that of Hardy? | 17:14 |
| BenC | it is based on the lum/lbm packaging | 17:14 |
| BenC | but has the addition of better config handling | 17:14 |
| BenC | it is also in git | 17:15 |
| cking | Better all round then | 17:16 |
| BenC | yeah, should make working with all the kernel related trees more consistent now | 17:16 |
| BenC | We'll need a good doc refresh on the kernel team wiki to match the changes too | 17:17 |
| BenC | If no one else has anything to add... | 17:17 |
| BenC | Ok, meeting adjourned then | 17:18 |
| BenC | Thanks everyone | 17:18 |
| kees | infinity: you around? rtg and I are trying to debug a security buildd failure on amd64 lbm | 19:13 |
| kees | rtg: does the amd64 failure match the prior one? | 19:34 |
| rtg | kees: no, its slightly different, but no less confusing. however, it does build locally under a gutsy chroot. | 19:36 |
| rtg | kees: I'm gonna package it with an ubuntu1 version and upload it to my PPA. | 19:37 |
| kees | rtg: okay | 19:38 |
| lamont | which suite? | 19:40 |
| rtg | lamont: gutsy? | 19:40 |
| lamont | package logic is flawed | 19:41 |
| lamont | dpkg -x $(ls ../linux-backports-modules-$i\_*amd64.deb) \ | 19:41 |
| lamont | so what happens when -nn.xx and -nn.yy exist in the parent directory??? | 19:41 |
| lamont | one must never make assumptions about the contents of the parent directory, other than that maybe the deb we just packaged landed there | 19:42 |
| rtg | lamont: so dak must have a package alreay there that matches, right? | 19:42 |
| lamont | rtg: the buildd does | 19:42 |
| lamont | specifically, s/3/2/ in the package name... and they're both there. | 19:43 |
| rtg | lamont: I guess that explains why the previous version built ok. | 19:43 |
| lamont | yep | 19:43 |
| rtg | and why my local versions don't fail, since I clean first. | 19:44 |
| lamont | rtg: next time you're messing around in the build process, that '*' should be replaced with the version number... :-) | 19:45 |
| rtg | lamont: well, I think I have to do it for this version, un;ess you can remove older releases. | 19:45 |
| lamont | rtg: can do | 19:46 |
| rtg | lamont: looks like hardy has the same issue. | 19:46 |
| lamont | kees: do I need to figure out how to do the give back as well, I assume? | 19:46 |
| lamont | rtg: I doubt the source has ever been right... | 19:47 |
| kees | rtg: so the -15.12 failure was due to accidental changes outside of just abi bump, and -15.13 failed due to -15.12 existing? | 19:48 |
| kees | (and why only for amd64?) | 19:48 |
| lamont | meh. what's the source package name? | 19:48 |
| rtg | lamont: linux-backports-modules-... | 19:49 |
| lamont | yeah... it's the ... that I'm curious about | 19:49 |
| lamont | and I see that I can tell that | 19:49 |
| rtg | linux-backports-modules-2.6.22 | 19:49 |
| rtg | lamont: I should be able to reproduce this in a chroot. | 19:50 |
| lamont | given back | 19:51 |
| kees | lamont: cool, thanks muchly | 19:51 |
| lamont | rtg: yeah - in the same place where you said dpkg-source -x (parent of linux-backports-modules-2.6.22-2.6.22), say touch linux-backports-modules-2.6.22_foo.amd64.deb | 19:52 |
| lamont | and then cd into linux-backports-modules-2.6.22-2.6.22 and do a build | 19:52 |
| rtg | lamont: right | 19:53 |
| rtg | lamont: that also explains why the PPA always works, it creates xen instance from scratch | 19:56 |
| lamont | yep. | 19:56 |
| lamont | pls to fix before next upload, kthx. :-) | 19:57 |
| kees | geh, failed again | 20:05 |
| rtg | kees: did lamont not remove the enough debs? | 20:08 |
| lamont | meh | 20:09 |
| lamont | I thought I had | 20:09 |
| lamont | find: debian/updates-modules-2.6.22-15-generic-di: No such file or directory | 20:10 |
| lamont | updates-modules-2.6.22-15-generic-di will be empty | 20:10 |
| lamont | make: *** [binary-udebs] Error 1 | 20:10 |
| lamont | not my doing | 20:10 |
| lamont | and that'd be why -15.12 was still sitting there... | 20:10 |
| lamont | looks like you _do_ get to fix it. :0) | 20:10 |
| rtg | kees: ok, gimme a bit. | 20:10 |
| lamont | that was the output from kernel-wedge find-dups 2.6.22-15-generic | 20:11 |
| infinity | kees: Yeah, I'm around. | 20:11 |
| rtg | infinity: I think we're getting it figured out. | 20:12 |
| kees | rtg: let me know if I can help | 20:14 |
| rtg | will do | 20:14 |
| infinity | lamont: Err, eww. It was using ../ ? | 20:16 |
| lamont | infinity: with a wildcard, no less. | 20:17 |
| lamont | because, I mean, why would there be files in the parent directory??? :-( | 20:18 |
| infinity | And, on a different note, why ARE there files there? | 20:18 |
| infinity | As in, why is there stuff built that's not in .changes? | 20:18 |
| infinity | linux-backports-modules-2.6.22-15-generic_2.6.22-15.13_amd64.deb | 20:18 |
| infinity | linux-backports-modules-2.6.22-15-rt_2.6.22-15.13_amd64.deb | 20:18 |
| infinity | linux-backports-modules-2.6.22-15-server_2.6.22-15.13_amd64.deb | 20:18 |
| infinity | linux-backports-modules-2.6.22-15-xen_2.6.22-15.13_amd64.deb | 20:18 |
| infinity | Tsk, tsk. | 20:19 |
| lamont | infinity: oh, those are from the build failure that followed | 20:19 |
| lamont | they're smashing them into .changes as they go. why would they use dpkg-deb like everyone else?? | 20:19 |
| lamont | and then the build fails, and they leave detris to trip on the next time,. | 20:19 |
| * infinity cries. | 20:20 | |
| infinity | Okay, rebuilding. | 20:20 |
| lamont | otoh, if I fetch a whole bunch of source versions and for i in *.dsc; do dpkg-source -x && $appropriate_cd && debuild -B; done; it'll blow up | 20:20 |
| lamont | infinity: I gave back -15.13 and it blew up with the empty generic-di thing | 20:20 |
| lamont | which, I expect, will require a new upload | 20:21 |
| infinity | Ahh, I see. | 20:21 |
| infinity | Relying on an empty build directory is stellar, though. | 20:21 |
| rtg | lamont: actually, the empty generic-di thing was the first build failure, and I don't understand it. | 20:22 |
| infinity | Cause, like, who ever builds in a directory with stuff in it? | 20:22 |
| rtg | infinity: did Fabio write this originally? | 20:22 |
| infinity | rtg: Is it based on LRM? | 20:22 |
| rtg | infinity: no, probably LUM | 20:22 |
| infinity | rtg: Ahh, I don't know if Fabio had much to do with LUM. | 20:23 |
| infinity | rtg: I thought that was Ben. | 20:23 |
| infinity | rtg: LRM was Fabio, then half rewritten by me. | 20:23 |
| rtg | infinity: could be. It likely came from Feisty, and I've just inherited it. | 20:23 |
| infinity | rtg: We have a saying for that around here... I think it goes something like "Sucks to be you." | 20:24 |
| rtg | infinity: such sympathy. | 20:25 |
| infinity | rtg: I'm known far and wide for my lovely demeanor and sympathetic ear. | 20:25 |
| rtg | infinity: hmm, I've noticed. | 20:25 |
| infinity | *cough* | 20:25 |
| lamont | infinity: remember to turn your head. | 20:27 |
| lamont | so now that I've finally upgraded to 2.6.24-19, how soon is the next kernel going to land and make me do it all over again? | 20:29 |
| rtg | lamont: a couple 3 weeks yet | 20:29 |
| lamont | kewl | 20:29 |
| infinity | rtg: The PPA upload you did a while ago seems to have worked... | 20:30 |
| rtg | infinity: its the clean xen instance creation. | 20:30 |
| infinity | rtg: Also, completely offtopic. Now that -19- is out, have you rolled those hppa changes into git for -20-? | 20:30 |
| infinity | rtg: Err, a dirty chroot can't be causing "find: debian/updates-modules-2.6.22-15-generic-di: No such file or directory | 20:31 |
| rtg | infinity: glad you reminded me. need to do that still. | 20:31 |
| rtg | infinity: perhaps not, but its a condition that appears to be unique to the security buildd | 20:32 |
| infinity | rtg: Or, perhaps, unique to chroots using pkg-create-dbgsym and pkgbinarymangler? | 20:34 |
| infinity | rtg: (PPA doesn't, because it's not a primary archive) | 20:34 |
| rtg | nifinI'll have to take your word for it :) | 20:34 |
| rtg | infinity: I'll have to take your word for it :) even | 20:35 |
| * infinity grabs a chroot and does a test build for kicks. | 20:35 | |
| infinity | rtg: For the record, the security chroot is as clean as can be. No stray packages, nothing in /build/buildd. nothing in /tmp, etc. | 20:37 |
| infinity | rtg: I'm going to try to reproduce this on my laptop, though, so we can stop blaming poor king. | 20:37 |
| rtg | infinity: k | 20:37 |
| infinity | rtg: Same failure on my laptop. | 20:51 |
| infinity | rtg: You want precise reproduction instructions? | 20:52 |
| rtg | infinity: ok | 20:53 |
| infinity | rtg: Kay. Just testing to see if your PPA version fails the same way. | 20:54 |
| infinity | rtg: If so, I'll give you directions to reproduce locally. :) | 20:54 |
| infinity | rtg: Your PPA version built fine here. | 20:55 |
| infinity | rtg: So, whatever cruft you cleaned up, that fixed the bug. | 20:56 |
| infinity | rtg: (To reproduce, if you were so inclined, you'd need to untar a chroot from chinstrap:~adconrad, fiddle with resolv.conf and sources.list to be sane, install build-deps, "sudo chroot chroot-autobuild su - buildd", "cd /build/buildd" "dpkg-source -x /tmp *.dsc" (assuming you put the source in tmp), and then dpkg-buildpackage from there. | 20:58 |
| infinity | rtg: But might just be easier to take my word for it that "15.33 doesn't work, 15.33ubuntu1 does". | 20:58 |
| rtg | infinity: they ought to be identical except for 'ubuntu1' | 20:59 |
| infinity | rtg: They really aren't. | 20:59 |
| rtg | just to be clear, the version is -15.13, right? | 20:59 |
| infinity | Err, 13, not 33, yes. | 21:00 |
| infinity | Ugh, -15.13ubuntu1 has all sorts of binary cruft in it, though. :/ | 21:01 |
| infinity | That said, it "works". :/ | 21:01 |
| rtg | infinity: could be, I didn't debdiff it before uploading | 21:01 |
| infinity | I suspect this is what's making it "work": | 21:02 |
| infinity | linux-backports-modules-2.6.22-2.6.22/debian/updates-modules-2.6.22-15-generic-di/DEBIAN/control | 21:02 |
| infinity | Though that just feels icky and wrong, cause that so looks like it should be autogenerated. | 21:02 |
| rtg | infinity: I'm pretty sure it is generated | 21:02 |
| infinity | Possibly not, though. | 21:04 |
| infinity | It doesn't get cleaned on debian/rules clean, at least. | 21:04 |
| infinity | And the package sure seems to be unhappy about it not being there. | 21:04 |
| infinity | *shrug* | 21:04 |
| infinity | Oh, wow, this clean target is retarded. | 21:04 |
| infinity | The package (and git, possibly) will develop cruft if people build with one arch, but clean with another. | 21:05 |
| infinity | (As is the case here... I'm cleaning on amd64, but have i386 cruft lying around) | 21:05 |
| infinity | And that's why there's cruft in the PPA source. | 21:07 |
| infinity | debian/d-i-i386 needs to be manually cleaned if you're on amd64, and vice versa. | 21:07 |
| infinity | (And same for the other arches, I guess) | 21:08 |
| infinity | rtg: Anyhoo. If you just rm -rf debian/d-i-i386, fix the version number to -15.34, and regenerate control, upload, should be good. | 21:12 |
| infinity | rtg: (Or seems to be here) | 21:12 |
| rtg | infinity: ok, I about have the exact fine match pattern figured out. | 21:13 |
| rtg | s/fine/fuile/ | 21:13 |
| rtg | you get the picture... | 21:13 |
| infinity | I hope it's better than that regex .;) | 21:14 |
| rtg | infinity: yep - it uses existing make variables that have all the info I need. | 21:14 |
| rtg | infinity: how about this: 'dpkg -x ../linux-backports-modules-$${i}_${pkgversion}-${revision}_${arch}.deb $(udebdir)/' | 21:20 |
| infinity | rtg: Assuming that works, it looks slightly saner. | 21:41 |
| rtg | infinity: it seems to, and its an exact match, no wild cards | 21:42 |
| infinity | Yay. | 21:43 |
| === thegodfather is now known as fabbione | ||
| mario_limonciell | hi guys: is it possible to provide a blacklist for a module on the kernel command line itself? I didn't see anything in quick searches, but I was hoping so | 22:35 |
| mkrufky | ah, you're here now | 22:36 |
| mario_limonciell | yeah hi :) | 22:37 |
| mario_limonciell | multiple fires i'm unfortunately fighting simultaneously | 22:37 |
| mkrufky | i have a link for you ... any second | 22:38 |
| mkrufky | brb | 22:38 |
| mario_limonciell | argh: it looks like it was a brainstorm idea but it didn't happen yet http://brainstorm.ubuntu.com/idea/86/ | 22:38 |
| kees | rtg: any closer to happiness on the l-b-m build? | 22:43 |
| rtg | kees: I finally got it to fail on my PPA. I gotta take off for awhile, but will work on it more tonight. | 22:57 |
| kees | rtg: yay reproduction! | 23:00 |
| kees | rtg: okay, cool | 23:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!