| === chiluk is now known as chiluk_away | ||
| === mfisch` is now known as mfisch | ||
| === mfisch is now known as Guest96749 | ||
| === chiluk_away is now known as chiluk | ||
| === chiluk is now known as chiluk_away | ||
| === Guest96749 is now known as mfisch | ||
| === mfisch is now known as Guest95055 | ||
| === Guest95055 is now known as mfisch | ||
| apw | infinity, that'd be me | 08:57 |
|---|---|---|
| infinity | apw: Good morning, sunshine. | 08:58 |
| apw | ugg | 08:58 |
| infinity | Ugg indeed. I just woke up 20m ago. At 1:40am. | 08:59 |
| infinity | I think I need to find something caffeinated. | 08:59 |
| * apw makes tea, its somewhat so | 09:00 | |
| apw | infinity, so ... anything other than the lack of a flavour component in the daemon name ? before i go ahead and fix that | 09:19 |
| infinity | apw: I'd remove the _lbm thing too, just make it hv_kvp_daemon_$(uname -r) | 09:20 |
| infinity | apw: But no, the bigger thing is that I'd also like to remove the daemonisation. | 09:20 |
| infinity | apw: (I'd like to submit a patch upstream to make it an option, but we don't have time for that today) | 09:21 |
| infinity | apw: And a one-line sauce change for Ubuntu doesn't seem a bit deal. | 09:21 |
| infinity | s/bit/big/ | 09:21 |
| apw | it can't be _uname-r cause it clashes with the main kernel then | 09:22 |
| apw | it is meant to match the main kernel and have _lbm | 09:22 |
| infinity | apw: It doesn't clash with the main kernel. | 09:22 |
| infinity | apw: The main kernel is just daemon_$(version-abi) | 09:23 |
| infinity | apw: Since linux-tools isn't flavour-specific. | 09:23 |
| apw | so it is, and hense why i have only added _lbm to avoid the clash, doh | 09:24 |
| infinity | apw: Right, so s/_lbm/-{generic,virtual,generic-pae}/ and it all works. | 09:24 |
| apw | so the real error is that the hv thing is flavour specific in the first place | 09:24 |
| infinity | apw: Well, the error is that it's even version-specific, but yay linux-tools. | 09:25 |
| apw | the cost of not having an api indeed | 09:25 |
| infinity | apw: Still, I have userspace bits that just check and prefer foo_ver-flavour over foo_ver, so that works. | 09:26 |
| infinity | apw: And since we can assume that foo_ver-flavour only happens in lbm builds, since linux-tools will always be foo_ver, then done. | 09:26 |
| apw | yeah that all works, but it is so very wrong really | 09:26 |
| infinity | apw: But the bigger change here is also making their upstart job not crack, which requires a one-line patch to hv_kvp_daemon itself. | 09:27 |
| infinity | Huh. And since my latest Intel GPU crash, B is being rendered as a capital J. *blink* | 09:28 |
| apw | i assume its respawning it do death ? | 09:28 |
| infinity | Hrm? No, it just can't track a triple-fork. | 09:28 |
| apw | and the ramifications of that is ? | 09:28 |
| infinity | You don't have a job managed by upstart anymore? | 09:29 |
| apw | but it is still running ok right? | 09:29 |
| infinity | And people write perversely incorrect init scripts that use "killall" as job control. | 09:29 |
| apw | i am trying to work out how bad this is, not avoid fixing it | 09:29 |
| infinity | Yeah, it runs. But accepting this init job into main isn't something I want to do. | 09:29 |
| apw | i assume you have the patch already | 09:30 |
| infinity | s#daemon(1, 0);#/* daemon(1, 0); */# :P | 09:31 |
| apw | presumably we need to add an option to change that behavior now its existed with the previous | 09:32 |
| infinity | I was going to whip up a proper getopt-using patch for upstream that introduces a -D option, but for us, I think just knocking out the daemon() call entirely is fine, and we can submit a proper fix later. | 09:32 |
| infinity | Given that the previous daemon doesn't work right anyway, I think we're calling this all a wash. | 09:32 |
| infinity | I'm installing a wrapper that refuses to run the linux-tools version of the daemon on kernel << 3.7 | 09:33 |
| infinity | And you don't ship it on 3.7 yet, so... | 09:33 |
| infinity | That covers all possible cases. :P | 09:33 |
| apw | "shipping a wrapper" ? | 09:33 |
| infinity | http://paste.ubuntu.com/1444907/ | 09:34 |
| infinity | dpkg-diverting the wrapper shipped by linux-tools. | 09:34 |
| apw | shipping that in what ? | 09:34 |
| infinity | In hv-kvp-daemon-init | 09:34 |
| infinity | The userspace bit that enables all this junk. | 09:35 |
| apw | and ... that is why i was asking you about divert, as i think i should be doing that in lbm to support the lbm specific versioning | 09:35 |
| apw | but that would probabally implode in the face of multiple flavour | 09:35 |
| infinity | Doing it in lbm is trickier, since you have more than one package shipping it. | 09:35 |
| apw | that indeed | 09:35 |
| infinity | Updating the wrapper in the next linux SRU would be lovely, but not an option this Monday morning. | 09:36 |
| apw | yeah that is indeed the plan, to update the official wrapper in tools | 09:36 |
| apw | now are we sure the pre 3.7 version is even broken on 'not azure' ? | 09:37 |
| infinity | Is there a "not azure" hv that matters? | 09:37 |
| apw | that we know about, likely no, ... | 09:37 |
| apw | can we make this thing just depend on lbm somehow, i suppose not | 09:38 |
| infinity | Wow, this thing poops in /var/opt/ | 09:38 |
| infinity | We kinda should FHSify this some day. | 09:38 |
| infinity | Oh well. | 09:38 |
| infinity | That's not important right now. | 09:38 |
| * apw closes his eyes and pretends not to see | 09:39 | |
| cking | la la la la not hearing that | 09:39 |
| infinity | Hey, at least it's not /opt | 09:39 |
| infinity | /var/opt is so dangerously close to /var/cache, I think we'll just pretend it's fine for this week. :P | 09:39 |
| apw | i would have not been supprised at the latter either, it is a mess. i am not totally sure we should even build this thing in the kernel package at all | 09:40 |
| infinity | apw: No, we probably should tear it out and build it out-of-tree from the same package that ship the init script. | 09:40 |
| apw | i wonder if the right thing would be to rip it out of lbm and of the kernel, and ... | 09:40 |
| apw | that indeed | 09:40 |
| infinity | apw: But, again, not sure there's time to change that. | 09:40 |
| infinity | Though, if you have a recipe to build it out of tree, I'm all ears. | 09:41 |
| === henrix_ is now known as henrix | ||
| infinity | Dropping the insane dependency of hv images on linux-tools wouldn't be a bad thing. | 09:41 |
| infinity | Of course, it could actually have some vague coupling to the linux version it's built against. | 09:42 |
| infinity | And if it does, we've lost. | 09:42 |
| infinity | /* | 09:43 |
| infinity | * Get the address of default gateway (ipv4). | 09:43 |
| infinity | */ | 09:43 |
| infinity | sprintf(cmd, "%s %s", "ip route show dev", if_name); | 09:43 |
| infinity | strcat(cmd, " | awk '/default/ {print $3 }'"); | 09:43 |
| infinity | ^-- Surely, there's a non-shell way to do that... | 09:43 |
| infinity | I kinda don't want to read this code anymore. | 09:43 |
| apw | i would indeed suggest not reading it any more | 09:43 |
| infinity | There's no way this would pass an MIR audit if it wasn't already stapled and glued into the kernel sources. | 09:44 |
| apw | ok my understanding on kernel dependancy is that the daemon is at least "now" meant to work with any kernel newer than the one it was built against | 09:44 |
| apw | i cannot say for sure when that might have happened | 09:45 |
| apw | s/ahppened/ become true/ | 09:45 |
| infinity | Well, when that became true doesn't matter, if we just take the 3.7 sources and build them against 3.2, and assume it works everywhere. | 09:45 |
| infinity | But we already have this hackish "just ship it in LBM" solution for now, let's just flavour that up and call it done. | 09:46 |
| apw | mir> indeed when we first enabled it, it didn't do any of this IP shit or have really any external activity like this, they have growed like topsy on the side of it | 09:46 |
| infinity | And for 3.7/raring, where you're not building it yet ANYWAY, maybe we can fix it better. | 09:46 |
| apw | we may be building it again by now, depending if i pushed the patch to fix its build | 09:46 |
| infinity | (PS: it not being built for raring confused the crap out of me when I went to test things) | 09:46 |
| apw | as it confused me as well | 09:47 |
| infinity | I saw nothing in the changelog to indicate it should be building now, but I haven't upgraded linux-tools yet either. | 09:47 |
| infinity | Oh man, this lack of capital Bs is confusing. | 09:47 |
| apw | just stop using capitals | 09:47 |
| apw | ok indeed this reenable fo hv is sitting pending on one of my branches | 09:48 |
| apw | can i assume you have taken control of the hv_init_script package in the short term, as any change to lbm needs to be coordinated with that | 09:49 |
| infinity | Yes. | 09:49 |
| infinity | http://lucifer.0c3.net/~adconrad/CapitalB.png <-- I have Jytes instead of Bytes. | 09:49 |
| apw | that is well fooked | 09:51 |
| apw | i assume you have textures mixed up somewhere in there | 09:51 |
| apw | and its not a real J either, its a J slightly down to the left plus a slight dotty thing | 09:52 |
| infinity | Yeah. Still, it's pretty cool to have bandwidth measure in kilojoules per second. | 09:52 |
| infinity | s/measure/measured/ | 09:53 |
| apw | infinity, as for building outside the kernel, i believe actually its requirement is the linux-libc-dev headers, plus linux/hyperv.h from the kernel (which is not in tose headers currently) | 09:53 |
| infinity | Ahh, so that could just be a buglet to include that header? | 09:54 |
| infinity | Anyhow, I suspect that's something we want for raring, and potentially to backport later, but not something we want to do in P/Q a day before their deadline for all this crap. | 09:54 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| brendand | henrix, is the quantal -proposed kernel being released today too? | 10:55 |
| henrix | brendand: i think so, but not sure. apw^^ | 10:56 |
| apw | i would imagine so but it is not my call | 10:57 |
| henrix | the info i got from brad is that both P and Q should be released today | 10:58 |
| === asac is now known as asac_the_hacker | ||
| === asac_the_hacker is now known as asac | ||
| infinity | henrix / brendand: Both P and Q should go out today, if we get all our ducks in a row WRT testing/validation. | 12:10 |
| b-quirk | Hi! cking, a while ago I asked you about wmi in my laptop. It turned out that these buttons are actually an unsupported synaptics hardware | 12:10 |
| henrix | infinity: ack, thanks | 12:10 |
| infinity | henrix: If they don't go out today, we'll end up with some cloud images built against -proposed, which won't be world-ending, but I think we can all agree that's suboptimal. | 12:11 |
| infinity | henrix: (As the generation of said images has a hard deadline of "Really Soon") | 12:11 |
| === chiluk_away is now known as chiluk | ||
| * henrix -> late lunch | 14:31 | |
| brendand | henrix, how will the next -proposed kernels work with the holidays? | 15:58 |
| henrix | brendand: i expect some delay, as most (all?) of us will be out. herton, do you have any details? | 15:59 |
| herton | henrix, well, I belive we will skip next week, and resume work on Jan. 2 | 15:59 |
| henrix | herton: yeah, that's what i would expect | 16:00 |
| henrix | brendand: ^ | 16:00 |
| brendand | henrix, reasonable | 16:01 |
| herton | that means new SRUs on new year only | 16:01 |
| infinity | hggdh: Do I get regression-testing on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088979 today? | 16:24 |
| ubot2` | Launchpad bug 1088979 in Kernel SRU Workflow certification-testing "linux: 3.5.0-21.32 -proposed tracker" [Undecided,In progress] | 16:24 |
| infinity | hggdh: (The correct answer is "yes", FWIW) | 16:24 |
| hggdh | infinity: yes | 16:27 |
| hggdh | infinity: (since this is the correct answer ;-) | 16:27 |
| * infinity throws hggdh a cookie. | 16:27 | |
| * hggdh eats the cookie and goes into a hyperglycemic crisis | 16:27 | |
| hggdh | infinity: in fact, running now | 16:28 |
| infinity | It was a sugar-free flax cookie. | 16:28 |
| infinity | (God, what an awful thought) | 16:28 |
| hggdh | infinity: heh | 16:28 |
| hggdh | infinity: I will add flash-kernel to the package list on the armada issue with updating kernel and flash-kernel at the same time; perhaps dpkg also? | 16:29 |
| infinity | hggdh: No, it's just flash-kernel's fault. Though it's not a problem specific to flash-kernel, it does triggers much the same as many other packages. | 16:30 |
| infinity | hggdh: Happy to look into it post-Christmas. Totally not a priority now, it's been like this for ages. | 16:31 |
| hggdh | infinity: some sort of warning should be given, then. I will replace linux-armada with flash-kernel then | 16:31 |
| infinity | Well, the only real problem is that you'll reboot into your old kernel. It's not like it renders your system broken or anything. | 16:32 |
| infinity | (But yes, it would be better if it didn't have this oops) | 16:32 |
| hggdh | indeed. | 16:33 |
| hggdh | infinity: there is also bug 1090591 on the armada. | 16:35 |
| ubot2` | Launchpad bug 1090591 in linux-armadaxp (Ubuntu) "armadaXP: Unable to handle kernel NULL pointer dereference at virtual address 00000000 on shutdown" [Undecided,New] https://launchpad.net/bugs/1090591 | 16:35 |
| infinity | hggdh: Fun. Tell Jani and Ike. ;) | 16:36 |
| hggdh | infinity: will do, but this does not sound like a critical issue, so I am passing this kernel too | 16:36 |
| infinity | hggdh: Well, it's not a regression. | 16:37 |
| infinity | hggdh: Looks like it could point at a rather subtly more awful bug, but if it was already there, no point holding up a CVE fix. | 16:37 |
| hggdh | yeah | 16:37 |
| infinity | hggdh: Can you assign that flash-kernel bug to me? I may not end up being the person who fixes it, but I want to be reminded of it in the New Year. | 16:38 |
| infinity | (Since, if f-k is buggy there, so is eglibc, and any number of other packages...) | 16:38 |
| hggdh | infinity: done | 16:40 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === yofel_ is now known as yofel | ||
| === henrix is now known as henrix_ | ||
| infinity | hggdh: regression testing still running for Q? | 21:07 |
| dhanasekaran | Hi Guys I am facing problem my machine not boot it's still showing BUG: soft lockup - CPU#10 stuck for 23s! [kworker/0:3:566] | 21:14 |
| dhanasekaran | How to fix this , It's Hardware issue or kerenel issue | 21:14 |
| dhanasekaran | please guide mme guys | 21:14 |
| hggdh | infinity: still running | 21:41 |
| hggdh | infinity: still running, one job to finish | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
