| === hughhalf is now known as hugh_afk | ||
| === hugh_afk is now known as hughhalf | ||
| === hughhalf is now known as hugh_afk | ||
| BruceMa | --help | 05:50 |
|---|---|---|
| BruceMa | test | 05:50 |
| apw | NikTh, i've replied in your bug | 11:00 |
| NikTh | apw: Thanks. But how can I find the later ones ? I mean, git bisect bad does not result in anything else when I hit the last commit. It has this 6-7 commits, I've tested them all, but then what can I do ? | 11:04 |
| NikTh | this/these | 11:04 |
| apw | NikTh, if you read my comment, i think you only reverse the initial good/bad, but used bad for bad ones in the actual bisect steps, they all need to be switche | 11:06 |
| NikTh | apw: What ? heah heah... The procedure was wrong ? Do I have to do it again, but with git bisect good, instead of bad in the commits ? | 11:08 |
| apw | for "reasons" bisect only works one way, finding a bug introducing commit, you want to find a bug fixing commit | 11:09 |
| NikTh | apw: If I mark a commit as bad, then is not built in the kernel when I build the kernel ? | 11:09 |
| apw | so you have to use bisect backwards, a reverse bisect. which means you say good when you mena bad, and bad when you mean good, everywhere | 11:09 |
| apw | if i read your log right you did that right for the first two, for v3.17-rc7 and v3.17, but not when answering for the ones you tested | 11:10 |
| NikTh | apw: Yes, I've understand this now, but really when one marks a commit as bad, then is not included in the building procedure ? What I tested then ? :P | 11:11 |
| apw | no you are marking that point in the bisect bad | 11:11 |
| apw | a bisect is a tree of splits | 11:12 |
| apw | you gave it top and botom, it takes the middle and says "is this working" | 11:12 |
| apw | if you say yes it picks one half to split again, if you say no it splits the other half | 11:12 |
| apw | a "bad" says this direction is the wrong direction in the bisect | 11:12 |
| apw | if you say "good" it means you went the right way | 11:13 |
| NikTh | So, in any bisect test, you mark the commits as good until you find the bad one, but in reverse bisect you swap the first, the initial ? But you must mark the bisect as good in order to pick this one and build and test the software ? | 11:16 |
| apw | no for any offered commit you say whether it worked or not, but ... when reverse bisecting you reverse the meaning of good/bad when answering | 11:17 |
| apw | it will offer you a random collection of working not working ones as it homes in on the break commit | 11:18 |
| NikTh | but it always picks the commit, either bad or good, so it can be included in building ? I mean, in order to test it afterwards. I have to be sure that the commit I have picked is included in the kernel. | 11:19 |
| apw | somtimes it will be mostly one or the other but that is a factor of where in the list the break is, later and you'll see mostly working, earlier and you see mostly broken | 11:19 |
| apw | bisect checks out your current tree at the commit it is offering, at that exact commit as tip of the tree | 11:19 |
| NikTh | Ok, what will be the difference if I mark the commits as good, in this particular case ? It will offer me another tree then, I guess ? | 11:21 |
| apw | whatever you are offered, it will take your answer and use that to guide its next move | 11:21 |
| apw | offering you another tree until there is only one commit left | 11:21 |
| apw | which is mostly the wrong one | 11:22 |
| NikTh | Ok, lets test it again then. I will mark all the commits as good (because of reverse bisect) and build and test the kernels again one by one. Right > | 11:22 |
| NikTh | ? | 11:22 |
| NikTh | If I find the commit that solves the problem, I will mark it as bad (even if it's good), because of reverse bisect. Right ? | 11:23 |
| apw | no | 11:24 |
| apw | each commit it offers you will either be working or not, you need to answer that each time, until it stops asking -- at which point it will tell you which commit was the broken one | 11:24 |
| apw | as it is a reverse bisect you will invert your answer at each point, but they may be either good or bad, you won't know in advance, and it changing from one to the other does not mean you know where it is, until it stops | 11:25 |
| NikTh | But i have tested them all, all the commits it offered me, and non of them worked. | 11:26 |
| apw | yes, but you answered wrong, you said things "worked" when they did not, because it was a reverse bisect, they faild, but you said bad | 11:26 |
| apw | if you lie to bisect, it produces utter shit | 11:26 |
| NikTh | Ok. | 11:27 |
| apw | a true GIGO moment | 11:27 |
| apw | if you say the wrong thing, it pushes the search into the wrong half never to return, it can never ever find the answer | 11:27 |
| NikTh | So I will test them again, and I will mark them as worked (good) when they are not working. That's the only difference here in reverse bisect. | 11:27 |
| apw | yes, any time you want to say good, say bad, anytime you want to say bad, say good. even with the initial commits, everywhere | 11:28 |
| NikTh | When I find (I hope) the commit that solves the problem ? What then ? | 11:28 |
| NikTh | I will save it as a .patch and upload it to Launchpad ? | 11:29 |
| apw | well it depends what you are trying to find it for, as it is in v3.17, any vivid kernel will include it by default | 11:29 |
| NikTh | Probably, so what am I trying here ? :P The fix it will be included in Vivid anyway. | 11:30 |
| NikTh | Maybe it can be backported to Utopic ? (3.16) | 11:30 |
| apw | maybe indeed, and knowing the commit is useful there | 11:31 |
| NikTh | Either way, this procedure is a learning curve for me ;-) | 11:31 |
| NikTh | I'm in git right now, I will mark the last bad kernel as the head (checkout) , right ? | 11:33 |
| NikTh | Then git bisect start , and then git bisect good.. blah,blah, but in reverse order. | 11:34 |
| NikTh | I see now. It goes through another tree of commits if I mark them as good (and not bad as I did before). | 11:36 |
| NikTh | Nice to learning with you apw. Thanks for another help :) | 11:37 |
| apw | you just can use git bisect start; git bisect good "v3.17-rc7"; git bisect bad "v3.17" | 11:38 |
| NikTh | apw: What commit is this ? Is this an actual commit, or just an announcement ? Do I have to pass it and go to the next one, or I must build a kernel with this? http://pastebin.com/raw.php?i=0b9qbKeY | 13:07 |
| apw | that is an actual commit merging in a whole pile of changes, from a maintainer, so yes it needs testing | 13:07 |
| NikTh | Ok. | 13:10 |
| rtg | tseliot, did you see my annoyance about Vivid 3.18 kernel and DKMS packages yesterday ? | 13:31 |
| ricotz | tseliot, rtg, nvidia is just missing a single include for 3.18 https://devtalk.nvidia.com/default/topic/783291/linux/kernel-module-won-t-compile-against-current-kernel-3-18-rc1/post/4340765/#4340765 | 13:32 |
| ricotz | works fine locally with 331.104, havent prepared a proper package/patch though | 13:33 |
| NikTh | Oh yeah! apw, that's the commit. What next ? Should I mark this as bad ? | 14:10 |
| apw | whats the commit? you should mark each and every test it asks you to make with good/bad | 14:11 |
| apw | it will tell you when it is done | 14:11 |
| NikTh | Yes, I mean with the commit I showed you before (http://pastebin.com/raw.php?i=0b9qbKeY) the resume now works. I will mark this as the bad one, right ? (because of the reverse bisect) | 14:12 |
| apw | yes, if it was good you say bad, it will likely give you another to test | 14:12 |
| NikTh | Of course I don't know what the cisfs and smb3 have to do with the resume and nouveau, but that's another story. | 14:13 |
| apw | it is jumping about in the range, splitting the gap between good and bad | 14:13 |
| NikTh | Ok. | 14:13 |
| apw | that is just the first time you have seen it work right? the first commit it has asked you to test which worked | 14:13 |
| apw | so it now knows it is between there and the last not good you marked | 14:13 |
| NikTh | Yes, that is the first time | 14:13 |
| apw | it keeps halving the gap until there is only one commit left | 14:13 |
| apw | this way to jumps in closer quicker, literally "bisecting" the gaps | 14:14 |
| NikTh | I have to go through the end, building all the commits it offers me and marking the ones that working as bad and the ones that don't work as good (because of the reverse) until the end. | 14:15 |
| apw | yes, as it is jumping about in halves, each time you test one that becomes a new upper or lower bound for the offending commit | 14:16 |
| apw | each time you do that it cuts the remainder in 1/2 and gets you to test that one, having teh search space in teh process | 14:17 |
| NikTh | Ok, 3 steps roughly says.. | 14:17 |
| apw | repeat until only 1 left | 14:17 |
| NikTh | and then ? | 14:17 |
| apw | they you have the 'one' which made it work | 14:18 |
| apw | then | 14:18 |
| NikTh | Ok | 14:18 |
| apw | then you would normally reset to v3.17-rc7 and cherry-pick that one commit to see if that also works | 14:18 |
| apw | as confirmation that that one is the one really | 14:18 |
| NikTh | Yes, this is another matter now.. I will bother you later (if you are here) :-) | 14:20 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| tseliot | rtg: yes, thanks | 14:44 |
| === Elimin8r is now known as Elimin8er | ||
| NikTh | apw: Bisect completed and it gave me the possible fix. Now, how can I apply this commit to 3.17-rc7 and see if it actually solves the problem ? | 18:08 |
| NikTh | apw: I guess, git checkout v3.17-rc7 and then git checkout COMMIT and then building ? | 18:09 |
| apw | NikTh, nope | 18:09 |
| apw | git checkout -b <branch> v3.17-rc7 | 18:09 |
| apw | git cherry-pick -x COMMIT | 18:09 |
| NikTh | branch ? which branch ? | 18:09 |
| apw | make one up | 18:09 |
| apw | git checkout -b lp<number> v3.17-rc7 | 18:10 |
| apw | is the sort of thing i do | 18:10 |
| NikTh | ok | 18:10 |
| JayJ | neoark: you there? | 18:12 |
| NikTh | apw: I have to setup an e-mail first, right ? "unable to auto-detect email address" it says. | 18:13 |
| apw | git config --global user.email "your_email@example.com" | 18:15 |
| apw | git config --global user.name "Your Name" | 18:15 |
| apw | iirc | 18:15 |
| NikTh | apw: Yes, that is what telling me. | 18:15 |
| apw | it is worth getting those right, in case you use git for anything sensible | 18:15 |
| apw | but for these purpose, a commit you don't care about nor intend to publish, it matters little | 18:16 |
| NikTh | Yes, but it does not moving, I think. Stuck there. | 18:17 |
| apw | ? | 18:17 |
| NikTh | Do I have to reset/end bisecting first ? | 18:18 |
| NikTh | status gives me the files as untracked | 18:18 |
| apw | probabally yes | 18:19 |
| === freyes is now known as zz_freyes | ||
| === roadmr is now known as roadmr_afk | ||
| NikTh | apw: The first bad(good in reverse bisect) commit was not what I needed. But I think I have spotted which bad (good) commit is responsible and I'm building another kernel image now. | 19:54 |
| === zz_freyes is now known as freyes | ||
| === roadmr_afk is now known as roadmr | ||
| NikTh | apw: Is it possible 2 or 3 commits combined, fixing the problem and not only one ? It is I guess. | 21:31 |
| Soval | Hello, ubuntu kernel team. I have an inquiry. My technical level is above the average person, but at this point I don't even know how to write a bash script. I google around on the internet, looking for answers and instructions. | 23:36 |
| Soval | I'm using Lubuntu 14.04 64bit. | 23:36 |
| Soval | I recently purchased the c930e Logitech webcam. The h264 pixel format doesn't seem to be an option, when I've tried "v4l2-ctl --list-formats", "v4l2-ctl --list-formats-ext", and "avconv -pix_fmts /dev/video*" | 23:36 |
| Soval | I've read someone say that kernel 3.2 supports the h264 pixel format. | 23:36 |
| Soval | So my question is... Does the kernel in *buntu 14.04, kernel 3.13, support the h264 pixel format? I would suspect that 3.13 is older than 3.2, and therefore does not include the support, yet 3.2 was included in older distributions. So is it an older kernel? | 23:36 |
| ohsix | 13 > 2 :] | 23:37 |
| Soval | Ohh.... Okay, thank you... Where would be the best place for me to get help on getting the h264 pixel format to work? | 23:37 |
| ohsix | i have no idea, linux-media has their own tree and only some crossover to mainline, you'll probably want to check any support status there first | 23:38 |
| Soval | Okay. Thank you. | 23:38 |
| ohsix | you can use lsusb -vvv or something to show the usb properties | 23:38 |
| ohsix | it will list picture formats and stuff if it is a uvc class device | 23:39 |
| Soval | Okay. I tried "lsusb -s 003:007 -v | egrep "264"" and lsusb -s 003:007 -v | less" and I didn't see anything that resembles h264. If the device is advertised as having h264 compression internally, could that mean that something is wrong with my kernel or linux-media packages? | 23:45 |
| Soval | (that's the correct device btw :P) | 23:46 |
| Soval | This is effectively my first time in the ubuntu kernel irc too, so if I should be asking elsewhere, just say so :) | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!