[02:37] , thanks [06:26] morning === Quintasan_ is now known as Quintasan === smb` is now known as smb [07:18] morning [07:18] morning smb [07:19] amitk, Hey, someone barely known by now... :-P [07:19] amitk, Hows things? [07:20] * apw laughs at smb ;) morning [07:21] apw, At least at and not about? :) morgning [07:21] * apw was giggling about your "hey stranger" message [07:21] as i said the same thing yesterday [07:22] apw, Oh well, we seem to have this thing ongoing. :D [07:22] yep [07:30] smb: hehe, Doing good, today being a somewhat laidback day.. [07:31] any of you staying back on sat after plumbers? [07:31] we're planning to sample the local juice [07:31] amitk, Nice. :) Oh yeah, its Friday anyways... Probably not. We mostly arrive before [07:32] we'll have to sample the juice on tuesday i suspect :) [07:33] locals tell me they're open between 1100 and 1600 and a 4-5 varieties per juice shop he's never survived more than 3 shops [07:34] s/a/at [07:35] Isn't there something about the "grapes of wrath"... [07:38] its the prune juice that'll takes you on [09:43] hi [09:43] can someone change linux-source-3.0.0 to conflict/replace with linux-source-3.0? [10:08] hrw can look at that yep, do you have a bug open? [10:09] apw, I think that was sort of not seen necessary as any release update path never would see 3.0... and probably assuming whoever installs an alpha knows how to get rid of it... [10:16] apw: not yet [10:16] yeah not many people ever even install it [10:18] Bug #834586 [10:18] Launchpad bug 834586 in linux "linux-source-3.0.0 should replace/conflict with linux-source-3.0" [Undecided,New] https://launchpad.net/bugs/834586 [10:19] I use linux-source-VER to bootstrap cross compiler [10:25] hrw thanks [10:58] hi [10:58] i have upgrade from 11.04 to 11.10 and i still have this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791089 [10:58] Ubuntu bug 791089 in linux "crash after rebooting or shutting down from Ubuntu 11.04" [Undecided,Confirmed] [10:58] i have this problem and with 11.04 \ [11:21] bugs... I need to do git bisect and find when backlight control on my laptop died [12:12] apw, I've just pushed the patches for CVE-2011-2918 and noticed (at the very end) that there is no BugLink in any of them. [12:12] tgardner: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2918) [12:14] apw, hmm, it must be bug #834121 [12:14] Launchpad bug 834121 in linux-ti-omap4 "CVE-2011-2918" [Medium,Invalid] https://launchpad.net/bugs/834121 [12:31] apw, ok, all fixed and repushed [12:33] tgardner, how the heck did i lose that? sorry for the effort [12:33] apw, np. you should check the bug report and make I've set everything correctly [12:33] make sure* [12:33] tgardner, in theory kees' processing will fix any errors you make === ghostcube is now known as zoowaerter === yofel_ is now known as yofle === yofle is now known as yofel === zoowaerter is now known as ghostcube [13:50] * ogasawara back in 20 [14:12] tgardner, the freescale kernel we are working on - we want to separate the large bulk of GPU code out of the tree, but DKMS apparently doesn't work very well - as it's taking too much time to compile on the target machine, and it needs all the dev packages [14:12] tgardner, so I'd think the l-b-m way might be a better choice [14:12] ericm|ubuntu, indeed, I don't think DKMS is appropriate for an ARM platform. [14:12] tgardner, ok thanks Tim [14:12] * apw suspects lbm style may work better, but why does it need to be separate in the first place [14:12] ericm|ubuntu, ^^ [14:12] apw, we want to keep a tree as close as upstream [14:12] apw, and in the end of the day - a linaro kernel will ideally be generated from the upstream version, and an out-of-tree GPU module will be something workable if someone wants an accelerated graphics [14:13] ericm|ubuntu, the problem is you still tie yourself together upload time wise, as you cannot upload the final meta package until your graphics driver part is built. otherwise people tend to lose their kernle or graphics or both [14:13] apw, yeah - that's a big headache [14:13] ericm|ubuntu, it might make package management simpler if you put the GPU code in the ubuntu directory (which is sort of a wart on the side) [14:14] * apw nods, good point [14:14] tgardner, true [14:15] does that imply we have gpu code for arm which is under a sensible licence [14:23] ARRRG, /me was upgrading a build box, and the power cable dropped out the wall... the worst possible time in the middle of an update-manager -d update [14:24] apw, doh! [14:24] tgardner, i know, that sickening feeling as the background noise just falls away [14:25] luckily a scratch install is completely possible the machine has nothing on it [14:25] but ... i hope to get away with it yet [14:26] apw, it'll be just your luck that there is /var/lib/dpkg borkage :) [14:26] well unexpectedly it booted ... so fingers crossed [14:53] apw, tgardner: everything should be sorted on the tracker/bug stuff [14:53] kees, thanks [14:56] kees, ack [15:19] ogasawara, ping [15:20] pgraner, you scared her off [15:21] ogasawara, I think she is having network issues then, they were waiting for her in the release meeting [15:22] s/ogawawara/tgradner/g [15:22] pgraner, fat fingers this morning ? [15:22] apw: how bout here? [15:22] yep .. all good now [15:31] so pitti brought up a question in #ubuntu-devel as to why we don't reflect the actual stable version in out packages now that we have a 3 digit version scheme... [15:32] is there any reason I'm not seeing that we shouldn't start using for ex 3.0.3-x.y instead of 3.0.0-x.y [15:32] ogasawara, because we don't always take all of stable, so the version number isn't very reliable [15:32] tgardner: that's true [15:34] ogasawara, or we end up reverting stuff where those reverts don't always go back to upstream stable. I think a version number that tracks stable would lead folks to a false assumption [15:38] plus it would engender false abi changes just to take the upstream version into account [15:45] kees, I've got an archive issue that is stumping me. On a pristine Lucid server with -security and -updates enabled, why can't I install linux-headers-generic-lts-backport-maverick ? [15:45] The following packages have unmet dependencies: [15:45] linux-headers-generic-lts-backport-maverick: Depends: linux-headers-2.6.35-30-generic but it is not going to be installed [15:48] yet it works if I enable -proposed [15:49] tgardner: hmm, that means something is missing from the archive :( [15:49] kees, rmadison looks right [15:49] * kees looks [15:51] * kees scratches his head [15:52] kees, good, I don't feel quite so stupid [15:53] tgardner: what I find strangest is that apt-cache policy shows it. [15:53] $ apt-cache policy linux-headers-2.6.35-30-generic [15:54] Candidate: 2.6.35-30.56~lucid1 [15:54] wtf. [15:54] linux-headers-2.6.35-30-generic: Depends: linux-headers-2.6.35-30 but it is not installable [15:54] bug 824080? :) [15:54] Launchpad bug 824080 in linux-lts-backport-maverick "missing binary package linux-headers-2.6.35-30" [Undecided,Confirmed] https://launchpad.net/bugs/824080 [15:54] yes, that would be it :) [15:55] tgardner: looks like the backport kernel is missing a binary package in its build [15:56] e.g. normal "linux" source has: [15:56] linux-headers-2.6.38-8: Header files related to Linux kernel version 2.6.38 [15:56] kees, its interesting that linux-headers-generic-lts-backport-natty works. [15:57] yeah [15:58] kees, I think the binary _does_ exist: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2628554/+files/linux-headers-2.6.35-30-generic_2.6.35-30.56~lucid1_amd64.deb [15:58] tgardner: that's "...-30-generic", it's missing "...-30" [15:59] and yet... [15:59] Package: linux-headers-2.6.35-30 [15:59] that's in the control file for it. O_o [16:00] hm. there's an arch: difference, not sure why that would cause issues, though [16:00] kees, cause we only build for amd64/i386 [16:00] for LTS kernels [16:03] tgardner: right, should be fine [16:11] kees, linux-headers-2.6.35-30 does not exist in -updates, only in -proposed. linux-headers-2.6.35-30-generic which depends on linux-headers-2.6.35-30 exists in -updates as well as -proposed. It looks like linux-headers-2.6.35-30 did not get copied to -updates correctly. [16:11] tgardner: but it doesn't even show up in launchpad [16:11] The following three fixes have not been verified in Lucid or Maverick, and will be reverted unless they are verified 'real soon now': [16:12] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/583760 [16:12] Ubuntu bug 583760 in gentoo "[PATCH] Mouse cursor dissappears with nouveau" [High,Confirmed] [16:12] kees, where does rmadison get its onfo ? [16:12] https://bugs.launchpad.net/ecryptfs/+bug/509180 [16:12] Ubuntu bug 509180 in linux "ecryptfs sometimes seems to add trailing garbage to encrypted files" [Undecided,Fix committed] [16:12] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610 [16:12] Ubuntu bug 801610 in linux "Include enic & fnic drivers in ubuntu-installer" [Undecided,Fix committed] [16:14] tgardner: from the Packages files in the archive, iiuc [16:14] tgardner: from the Cloud! [16:14] :) [16:15] kees, well, according to rmadison, linux-headers-2.6.35-30 only exists in lucid-proposed, which explains the problem. [16:15] it should _also_ exist in lucid-updates [16:18] tgardner: right, so it must have been overwritten before it was correctly copied. [16:19] kees, is this something an archive admin can correct? [16:23] tgardner: I'm not sure. the missed copy is pretty serious -- that implies some kind of AA tool failure. [16:23] tgardner: so we should get an AA involved. [16:24] tgardner, kees There was a failure in copying some kernel packages recently that resulted in some files going into universe. Maybe this is another case or a symptom of that [16:24] cjwatson fixed it [16:24] sconklin, possibly. [16:51] I don't think the thing I fixed has anything to do with this [16:51] TBH, it would probably be easiest to fix this by copying the new one from lucid-proposed, if that's at all feasible [16:51] hm, one red bug there [16:53] linux-lts-backport-maverick 2.6.35-30.56~lucid1 (in lucid-updates) plain didn't ship that binary package. Expand that version in https://launchpad.net/ubuntu/+source/linux-lts-backport-maverick and look at the list of binaries ... [16:53] so not an AA tool failure, the package was just wrong [16:53] (somebody pass this on to tgardner when he comes back?) [16:54] 2.6.35-30.58~lucid1, the newer version in lucid-proposed, appears to have corrected this [16:54] whether that was intentional or a consequence of something else I have no idea [18:41] * jjohansen -> lunch === _LibertyZero is now known as LibertyZero === medberry is now known as med_out === med_out is now known as medberry