| === kentb_ is now known as kentb-out | ||
| === ScottSanbar is now known as SanbarComputing | ||
| === SanbarComputing is now known as ScottSanbar | ||
| === ScottSanbar is now known as SanbarComputing | ||
| === kengyu_ is now known as kengyu | ||
| === smb` is now known as smb | ||
| smb | Morning .+ | 07:16 |
|---|---|---|
| * apw yawns | 07:34 | |
| === artnay_ is now known as artnay | ||
| === yofel_ is now known as yofel | ||
| Kano | hi apw , did you notice that your build server for mainline runs out of space? | 11:14 |
| * ppisati -> lunch | 11:30 | |
| _ruben | bah .. still can't seem to find out how to match 'ata4' to 'sdX' .. and seem to be not alone in that, but no solutions found thusfar :/ | 13:47 |
| apw | _ruben, not sure i understand your problem | 13:48 |
| _ruben | [589302.281732] ata4: soft resetting link | 13:49 |
| _ruben | want to know which disk to replace | 13:49 |
| apw | doesn't udev have a like by-path name for each disk as well | 13:49 |
| jk- | apw: yes, but it doesn't show ataX | 13:50 |
| _ruben | indeed | 13:50 |
| jk- | ls -l /sys/class/ata_device | 13:50 |
| _ruben | no such file or directory | 13:50 |
| * apw wonders if he wants to know how old the release you are running is | 13:50 | |
| _ruben | lucid server 32bits | 13:51 |
| jk- | ah | 13:51 |
| === kentb-out is now known as kentb | ||
| mdeslaur | herton: you reverted the commit that caused my dpms fuzzy screen? I thought it was an important part of hardware enablement? | 14:13 |
| herton | mdeslaur: yes, hardware enablement team is aware of the revert, steve talked with them | 14:13 |
| herton | it was agreed best action was to revert it for now | 14:14 |
| mdeslaur | herton: ah, ok, thanks for the explanation...I was just curious. I have the issue with the current oneiric kernel, fyi. | 14:14 |
| ogasawara | tgardner: you haven't already started on pulling in the 3.0.5 and 3.0.6 updates have you? I just want to make sure I'm not duplicating work. | 14:15 |
| tgardner | ogasawara, yep, was just working on the compile | 14:16 |
| ogasawara | tgardner: sweet | 14:16 |
| tgardner | then I'm gonna look 'em all over pretty close | 14:16 |
| bjf | ## | 14:27 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 14:27 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 14:27 |
| bjf | ## | 14:27 |
| * ogasawara back in 20 | 14:29 | |
| apw | smb, might you be able to test a hardy cve for me, http://people.canonical.com/~apw/CVE-2011-2495-hardy/, test whether you can read /proc/$$/io as a user and root, both before and after the kerenl | 14:30 |
| ubot2 | apw: ** 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-2495) | 14:30 |
| apw | (or more likely mitre is majorly out of date) | 14:30 |
| smb | apw, I can, but might be rather later today or tomorrow | 14:31 |
| apw | smb, ahh yes poor timing on my part | 14:32 |
| apw | whenever | 14:32 |
| tgardner | ogasawara, 'git://kernel.ubuntu.com/rtg/ubuntu-oneiric v3.0.6' if you want to do some smoke testing. | 15:07 |
| ogasawara | tgardner: cool, thanks. | 15:08 |
| === BenC__ is now known as BenC | ||
| bjf | ## | 16:00 |
| bjf | ## Kernel team meeting in one hour | 16:00 |
| bjf | ## | 16:00 |
| sconklin | tgardner, hey I'm looking at the tool failure you pasted to mumble. Is the tree you ran it in pushed anywhere? I need to reproduce it | 17:18 |
| tgardner | sconklin, git://kernel.ubuntu.com/rtg/ubuntu-oneiric v3.0.6 | 17:19 |
| tgardner | sconklin, git://kernel.ubuntu.com/rtg/ubuntu-oneiric.git v3.0.6 | 17:20 |
| sconklin | tgardner, thanks. It's choking on something it parsed from the Makefile. I'll reproduce it | 17:21 |
| apw | sconklin, hey ... looks liek the issue is that oneiric doesn't have anything on the EXTRAVERSION and your split there assume there will be ' = ' which isn't present | 17:25 |
| sconklin | probably so. I'm cloning but it's only at 7% | 17:26 |
| apw | VERSION = 3 | 17:26 |
| apw | PATCHLEVEL = 0 | 17:26 |
| apw | SUBLEVEL = 4 | 17:26 |
| apw | EXTRAVERSION = | 17:26 |
| sconklin | that's it then | 17:27 |
| apw | if am reading this right we don't use the value at all, so the split could be elided | 17:27 |
| sconklin | it assumes that is the string 'EXTRAVERSION" is there, then something follows it | 17:27 |
| apw | well it assume its is EXTRAVERSION<space>=<space> | 17:28 |
| apw | as the next line has a strip, just splitting on '=' would like do the job | 17:28 |
| sconklin | apw, ack, and I think that's true for all those values which are parsed. And we should never have any other '=' characters in there | 17:31 |
| apw | sconklin, pretty sure that split takes a max splits, so you could add a 1 to make sure it only pops the first one | 17:31 |
| cking | until the next time it breaks | 17:32 |
| apw | >>> print a.split('=', 1) | 17:32 |
| sconklin | apw, right, except that I would argue that if you have anything else on the line something should explode, as it's an error | 17:32 |
| apw | ['this that ', ' you me = other'] | 17:32 |
| sconklin | v3 | 17:35 |
| sconklin | grrr input management | 17:36 |
| apw | focus management with unity is perfect | 17:36 |
| sconklin | This is a natty box | 17:45 |
| === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0.0 || Ubuntu Kernel Team Meeting - October - 11 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| sconklin | tgardner, you spec 3.0.0 on the command line, but the makefile has 3.0.6 | 17:53 |
| sconklin | That's not the cause of the original failure, just the 'next one' :-) | 17:53 |
| tgardner | sconklin, the _package_ version is 3.0.0 | 17:53 |
| sconklin | ok, checking | 17:54 |
| sconklin | tgardner, why are the package and kernel versions not the same? | 17:56 |
| tgardner | sconklin, well, they are. the package version is 3.0.0 as is the kernel. | 17:56 |
| sconklin | tgardner, from the Makefile: | 17:57 |
| sconklin | VERSION = 3 | 17:57 |
| sconklin | PATCHLEVEL = 0 | 17:57 |
| sconklin | SUBLEVEL = 6 | 17:57 |
| sconklin | EXTRAVERSION = | 17:57 |
| sconklin | from your 3.0.6 branch | 17:58 |
| tgardner | sconklin, hmm, I guess thats some fallout from the version change. | 17:58 |
| tgardner | EXTRAVERSION appears to be superfluous | 17:58 |
| bjf | tgardner, isn't that because we are versioning differently than upstream ? | 17:58 |
| bjf | tgardner, shouldn't the sublevel be 0 and the extraversion be 6 ? | 17:59 |
| tgardner | bjf, thats the way it used to work. | 17:59 |
| tgardner | so we're gonna have to accommodate that change | 17:59 |
| bjf | tgardner, not sure what that means. who needs to accomodate, which change, do we need to make the Makefile reflect our versioning ? | 18:00 |
| tgardner | bjf, our scripts are gonna have to recognize that if the version is 3.0 or higher, then EXTRAVERSION is empty | 18:01 |
| sconklin | not to overstate it, but this breaks everything | 18:01 |
| tgardner | sconklin, well, it certainly adds some complications | 18:02 |
| sconklin | well, ok. and until the complications are embodied in code, it breaks everything. | 18:02 |
| sconklin | everything == stable tools | 18:03 |
| cking | or unstable tools perhaps? ;-) | 18:05 |
| tgardner | sconklin, herton: perhaps this is an opportunity to consolidate version checking into one module so we only have to fix this once. | 18:06 |
| sconklin | more accurately, this challenges one of our fundamental assumptions. If it turns out we were wrong, we'll deal with it. But I don't think we're wrong. | 18:06 |
| tgardner | sconklin, you fundamentally assumed the kernel version would match the package name ? | 18:07 |
| sconklin | Yes, and that (at least post-release) there is only one kernel version per series | 18:08 |
| tgardner | sconklin, don't we already break that assumption with mvl-dove ? | 18:09 |
| sconklin | i.e. after release there's a 1:1 associative mapping between kernel version and series | 18:09 |
| sconklin | the association is encoded by package name, so we can associate different kernels for ARM, etc - but it can't change | 18:09 |
| bjf | tgardner, when you built and tested this kernel what did a uname -a give you | 18:10 |
| bjf | ? | 18:10 |
| tgardner | sconklin, I guess we're gonna have to figure out how to accommodate both 2 and 3 digit version numbers. | 18:11 |
| tgardner | bjf, 3.0.0-12 (I think) | 18:11 |
| tgardner | bjf, 3.0.0-13.20 | 18:12 |
| sconklin | and why are we changing the way we use sublevel and extraversion? | 18:12 |
| tgardner | sconklin, whats the _we_ shit? Linus made that change. | 18:12 |
| bjf | sconklin, tgardner so if uname can report 3.0.0 maybe we can get the sublevel and extraversion from the same place that it references, that has to come from kernel sources somewhere | 18:13 |
| tgardner | bjf, it comes from the changelog | 18:14 |
| bjf | sconklin, though i wrote it, i don't remember why i'm looking at the makefile, can we change to use the changelog version ? | 18:14 |
| tgardner | bjf, actuall, it is extracted from the changelog and built into the kernel at prep time by setting CONFIG_VERSION_SIGNATURE | 18:15 |
| tgardner | bjf, sconklin - I think you can depend on the changelog _always_ having a 3 digit version because we set the policy for that. | 18:16 |
| sconklin | bjf, yeah. I have no idea why it parses the Makefile, either | 18:16 |
| bjf | sconklin, i do agree that as part of this fix, "we" should look at where we parse the kernel version and do some refactoring if possible | 18:16 |
| sconklin | tgardner, ack, we should probably abandon the Makefile and only parse the changelog | 18:17 |
| tgardner | is there a python equivalent of dpkg-parsechangelog ? | 18:17 |
| bjf | sconklin, i'm sure i did that for "a really good reason"(tm) but i can't remember what that might be now | 18:17 |
| sconklin | and also agree with bjf | 18:17 |
| tgardner | remember that the kernel version isn't _really_ related to the package name, its only convention. | 18:17 |
| * tgardner needs brain food | 18:18 | |
| * tgardner -> lunch | 18:18 | |
| sconklin | tgardner, noted, although that assumption really is deeply embedded in almost all the tools. Although, the reality is that we can change versions in the tools, you just won't be able to go back and use them for the older version (I think) | 18:19 |
| tgardner | sconklin, the assumption that should be deeply embedded in tools is that the version is extracted from the changelog. that is, after all, the debian way. | 18:50 |
| sconklin | tgardner, ack, that's what I'm looking at now. | 18:58 |
| bjf | tgardner, and everyone agrees that "uname -a" returns the package version, right? not the kernel version. | 19:28 |
| tgardner | bjf, correct | 19:28 |
| tgardner | bjf, Linux sb 3.0.0-13-server #20 SMP Tue Oct 4 15:28:19 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux | 19:29 |
| * jjohansen -> lunch | 19:30 | |
| sconklin | tgardner, the way I read the uname man page, it returns "kernel release" | 19:33 |
| sconklin | and version and other things | 19:33 |
| tgardner | sconklin, true, but remember that the value returned by 'uname -a' is set in the kernel at build time. | 19:34 |
| tgardner | its not extarcted from the Makefile, but rather from the changelog | 19:34 |
| tgardner | extracted* | 19:34 |
| sconklin | well yeah, there's no other way to do it | 19:34 |
| sconklin | so debian (and we) have determined that "kernel release" means something other than what it means to upstream? | 19:35 |
| tgardner | sconklin, in fact the version returned by 'uname -a' comes from this line in debian/rules.d/2-binary-arch.mk: cat $^ | sed -e 's/.*CONFIG_VERSION_SIGNATURE.*/CONFIG_VERSION_SIGNATURE="Ubuntu $(release)-$(revision)-$* $(raw_kernelversion)"/' > $(builddir)/build-$*/.config | 19:37 |
| sconklin | and it returns 3.0.0(something), even though the makefile from upstream contains the version 3.0.6 | 19:40 |
| ohsix | wasn't the .0 thing a stopgap until things could catch up in the kernel build stuff? | 19:41 |
| tgardner | sconklin, but thats my point. the content of the makefile isn't relevant. | 19:41 |
| tgardner | its convention, albeit one that some tools depend on | 19:41 |
| sconklin | ;et | 19:42 |
| sconklin | ignoring the tools issue for a moment . . . | 19:42 |
| sconklin | It's significant to me to know which version I am running. If uname and the package name tell me I am running 3.0.0, and I'm in fact running 3.0.6, then I have a problem with that | 19:43 |
| sconklin | granted at this point it's a personal problem . . . but I think it creates potential for widespread confusion | 19:44 |
| tgardner | sconklin, well, you're never running the version in the Makefile because we add our own patches, and sometimes don't include all of the patches in a stable update. | 19:44 |
| sconklin | right. But generally I want to know whether some improvement or fix from upstream is included in what I have, and now I've lost that | 19:45 |
| tgardner | thats why we list the actual patches included in a stable update | 19:45 |
| sconklin | and you know how many of our consumers actually go read the changelog, right? | 19:46 |
| tgardner | sconklin, some of them do, but I agree it can be misleading. | 19:46 |
| sconklin | and how many "when are you going to ship 3.0.6?" questions will we get? | 19:47 |
| tgardner | you say that like this is a new problem. | 19:48 |
| tgardner | bbiam | 19:49 |
| Kano | apw: it seems you have to update your scripts for mainline stable builds to use http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/tags/v3.0.6 | 20:51 |
| Kano | as there is no 3.0.5/3.0.6 build | 20:51 |
| Kano | well 3.0.5 wil fail anyway | 20:51 |
| Kano | but i would like to test 3.0.6 mainline | 21:13 |
| Kano | daily seems to work so far | 21:14 |
| === jjohansen is now known as jj-afk | ||
| jj-afk | back on later | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!