| === sconklin is now known as sconklin-gone | ||
| === kamal is now known as kamal-away | ||
| * abogani waves all | 07:30 | |
| abogani | Why "Bug Watch Updater" changes priorities? Is it a bot, isn't it? Which rules it follows for that type of changes? | 07:32 |
|---|---|---|
| RAOF | It's refreshing the Launchpad status of upstream bugs. So, those bugs have had their priorities changed upstream, and this is being reflected in Launchpad. | 07:36 |
| persia | Good day. I decided to work on a kernel today, and I'm a bit lost in terms of git and quilt and stuff, and hoped someone could help me understand what commands would let me manipulate the code. | 07:43 |
| persia | I've run git clone on a linux-2.6 tree and a separate git clone on a tree that appears to contain some quilt patches. | 07:43 |
| persia | I'd like to regress the linux-2.6 tree to the commit that is listed as the last time the quilt series was rebased, apply the quilt series, and move forward through the linux-2.6 revision history to try to get to current. | 07:44 |
| abogani | RAOF: Thanks! | 07:48 |
| RAOF | persia: That should be relatively straightforward. | 07:52 |
| abogani | persia: Why don't you reset the tree to current and so apply the quilt series? | 07:52 |
| persia | RAOF, I'd think so, but after reading about git branch and git checkout and remote branches, I'm left a bit confused as to the mechanism. | 07:53 |
| RAOF | Yeah. git can do that :) | 07:53 |
| persia | abogani, Because the git history of the quilt series identifies a specific revision against which it was based and I want to test a build from that before I add more patches, so I can distinguish between issues with moving the patches forward and issues with the patches themselves. | 07:54 |
| RAOF | So, my instinct would be to checkout the branch you want to apply the patches to, then “git reset --hard $REVISION_SHA” to go back to where the patches want to be applied to. | 07:55 |
| RAOF | Then, apply and commit the applied patches one at a time. | 07:55 |
| persia | And checking out the branch is something like `git checkout -b origin/mybranch` (where "origin/mybranch" is shown from `git branch -r`)? | 07:55 |
| RAOF | Checking out is more “git checkout -b nameI'dLikeMyBranchToHave origin/TheNameOfTheRemoteBranchItShouldBeBasedOn” | 07:56 |
| persia | OK. That makes sense. | 07:57 |
| RAOF | *Sometimes* you can omit the -b and the local branch name, and git will strip the “origin/” bit off as the local branch name. | 07:57 |
| RAOF | I've not worked out when this behaviour occurs. | 07:57 |
| persia | Next, the git manual said that commiting things was a multistep process, but I got a bit confused about the details. Is there something better than 1) apply the patch, 2) iterate over the output of lsdiff on the patch and run git add for each, 3) compare git diff --cache to the patch to make sure it took, 4) git commit ? | 07:58 |
| persia | In this case I can't omit that: it just created a new branch that didn't seem to have any differences in the output of git log | 07:58 |
| RAOF | I think the “git apply” command is what you're after. | 07:59 |
| abogani | git quiltimport | 07:59 |
| RAOF | abogani: Oh, really? Even better! | 08:00 |
| persia | Indeed. The manpage of git-quiltimport seems much more straightforward than the manpage for git-apply | 08:00 |
| persia | Next question is about going back to the start when I do something wrong. From directory content inspection, it appears that git creates a new HEAD with a checksum and my identity from git clone. Is there an easy way to get back to this, even after doing things like git revert --hard? | 08:02 |
| persia | Err, git reset | 08:03 |
| RAOF | git reset --hard doesn't *remove* any commits, so if you still know the SHA of the commit you want you can get it out. | 08:03 |
| RAOF | There's probably a method for iterating over all the heads in the repository, too. | 08:04 |
| persia | So I should record the SHA of the last commit in git log before starting, and then I ought to be able to get back to it (with history)? | 08:04 |
| RAOF | Yes. | 08:04 |
| RAOF | It's quite hard to actually kill commits, and each commit has a reference to its parent. | 08:04 |
| persia | So applying a given commit inherently applies all it's parents? | 08:05 |
| RAOF | That depends on what you mean by ‘apply’. | 08:05 |
| RAOF | If you get *exactly* that commit into your tree, then you've also got all of its parents. | 08:05 |
| persia | I tend to conceptualise VCSs as funny ways to interact with something akin to quilt, if that helps understand the semantics of "apply" as used above. | 08:06 |
| RAOF | git *also* makes it easy to apply the *contents* of that commit as a diff to your current tree. In that case, a *new* commit with just the contents of the old one is created. | 08:06 |
| persia | Ah, I perceive the difference. | 08:06 |
| RAOF | Yeah. The quilt model is insufficient for describing how git (or bzr, for that matter) actually works, because a commit is inseparably diff+a bunch of metadata. | 08:07 |
| persia | So, with reset, I'd end up back to the original point where the quilt series is supposed to apply, then with quiltimport I'd apply the patch series, and then I'd want to iterate over the set of outstanding bits of work to apply the contents of each to the tree? | 08:07 |
| persia | Indeed, and most of my experience with VCSs is learning how to work around the metadata :) Not entirely best practice, but perhaps I'll learn some day. | 08:08 |
| abogani | persia: Which quilt series are you talking about? | 08:09 |
| RAOF | Actually, in on reflection I think that what I suggested won't be any better than trying to apply the existing quilt series on top of trunk. | 08:09 |
| RAOF | What *would* be better is applying the quilt series and then merging it into trunk. | 08:10 |
| abogani | Agreed. The best thing is drop "quilt form" as soon as possible. | 08:11 |
| RAOF | And, since git is stupid and thinks merges are symetrical, that would replace “git pull --rebase” with “git merge $BRANCH_TO_MERGE_INTO” | 08:11 |
| RAOF | That way git will do some of the conflict resolution for you. | 08:11 |
| persia | Hmm... | 08:11 |
| persia | So, given a git tree, would it make sense to create two branches: one based on the reset, and the other based on an -rc3 merge, and separately apply the quilt series to each to achive my testing goals? | 08:12 |
| RAOF | No, I don't think so. | 08:13 |
| rigved | hi everyone...i'm interested in kernel programming...can anyone guide as to where should i start | 08:13 |
| RAOF | You would create one branch - one based on the reset, with the quilt patches applied. | 08:13 |
| persia | And I'd build off that, and go test | 08:13 |
| RAOF | Oh. You would then merge that into rc3, and resolve any conflicts. | 08:14 |
| RAOF | Which, I guess, would create a new branch based on rc3, with the patches applied. I just wouldn't think of it like that :) | 08:14 |
| persia | Um. except there's outstanding stuff in the tree that needed changes to merge into -rc3 (and those change commits are in the tree, but ahead of the quilt application point) | 08:14 |
| RAOF | I guess it comes down to: what do you *want* to test? | 08:15 |
| abogani | :-) | 08:15 |
| RAOF | Do you want to test the patches on the most recent kernel, or do you want to test the patches on the kernel they specify? | 08:16 |
| persia | I want to test two things: a) something that kinda looks like the code that the author of the quilt series was working on; b) the results of applying the same quilt series to a branch that recently was merged against -rc3; and c) the results of merging the Ubuntu sauce on top of that combination. | 08:17 |
| persia | Err, three things. | 08:17 |
| RAOF | Ok. Well, the first thing to do in all those cases is to start with the commit the author was working on, and apply the patch series. | 08:18 |
| RAOF | Once you've tested that branch, you can merge it into the branch that was recently merged against -rc3, and test that; then merge in the ubuntu sauce. | 08:19 |
| persia | So git reset, git quiltimport, (twiddle, build, test), git merge, (twiddle, build, test), git remote add, git merge, (twiddle, build, test) ? | 08:21 |
| RAOF | Yes. | 08:21 |
| RAOF | Exactl. | 08:21 |
| RAOF | git should help a little with the twiddle phase, and “git status” will list conflicted files as “both modified” | 08:22 |
| RAOF | Oh, yes. git also doesn't automatically detect when you've reconciled a conflict, so you'll need to “git add” the reconciled file. | 08:23 |
| persia | Excellent. I think that lets me fiddle the code enough to make progress. Monday, I can learn about kernel packaging :) | 08:28 |
| === smb` is now known as smb | ||
| * persia grumbles about SHA mismatches for commits at almost the same time and with the same message, and clearly the same thing, except something odd happened. | 09:07 | |
| * apw realises xchat isn't running :) | 09:35 | |
| smb | Productivity increased by at least 100% :) | 09:36 |
| apw | smb, heh i wouldn't call preparing for a release meeting productive, depressing more like | 09:41 |
| smb | apw, Ok, not really productive in the usual sense. But I would think not being interrupted by mumble or irc could half the time needed, thus half the pain. :) | 09:43 |
| apw | heh some of that of course | 09:46 |
| * cking can get some emails and docs written at last ;-) | 09:51 | |
| * smb stares scared on the amount of potential upstream stable changes that missed xen shadow files | 09:52 | |
| apw | smb, that xen split is a nightmare | 09:54 |
| smb | apw, o_O (indeed) | 09:54 |
| apw | i was quite serious when i said we should consider turnign it back into an overlay | 09:57 |
| smb | apw, I just go ahead and start to sync up the auto-generated patches for stable releases to xen files from the tarball. Not that those all will have some impact, but I we really want no differences there to the original files | 09:57 |
| smb | If that is done, we can think of the second step of folding them back | 09:57 |
| apw | smb, you got an amd64 box you could boot test a kernel on? | 10:14 |
| smb | apw, As long as 64bit is the only requirement, sure. I "guess" Natty? (not sure I have an install already, but I could at least do Natty kernel on Maverick) | 10:16 |
| apw | yep natty on maverick is fine, just want to know it boots ok ... still building, will shout when its ready | 10:16 |
| smb | ok, booting up the test box meanwhile | 10:17 |
| apw | smb, couldn't be bothered to hump a second laptop with me | 10:17 |
| smb | apw, Understandable | 10:18 |
| * smb even found a natty install... with kernel 2.6.37... I guess that needs a slight update | 10:19 | |
| evdvelde | hi all, do you need to patch the Linux kernel to use Mobile IPv6? | 10:39 |
| apw | evdvelde, not sure i know the answer to that off the top of my head | 10:41 |
| evdvelde | apw: thanks for the honesty :) been googling for it, but last posts about it are from 2008, with a patch to the kernel... | 10:42 |
| apw | evdvelde, if you have a link to the patch i may be able to tell if its in already | 10:45 |
| evdvelde | apw: i found the patch again: ftp://ftp.linux-ipv6.org/pub/usagi/patch/mipv6/umip-0.4/kernel/patch/ | 10:49 |
| apw | smb, could you boot test the amd64 -2.29 kernels here http://people.canonical.com/~apw/master-next-natty/ ... thanks | 10:53 |
| apw | smb, well 32 bit is good at least | 11:01 |
| apw | Ubuntu 2.6.38-2.29masternext201102041001-generic 2.6.38-rc3 | 11:01 |
| pgraner | apw, ping | 11:02 |
| apw | pgraner, hiya | 11:02 |
| apw | i've emailed you the update for the meeting today | 11:03 |
| smb | apw, I think I probably should have started that dist-upgrade... | 11:03 |
| smb | I mean not | 11:03 |
| apw | shouldn't ? | 11:03 |
| smb | yeah | 11:03 |
| apw | perhaps ... no worries | 11:03 |
| pgraner | apw, can you send me the meeting invite, for some reason it dropped of the Ubuntu Engineering Cal | 11:03 |
| apw | pgraner, sure | 11:03 |
| pgraner | apw, thanks | 11:04 |
| apw | you should get an invite shortly | 11:05 |
| apw | pgraner, but it is at 16:00 UTC | 11:06 |
| === _LibertyZero is now known as LibertyZero | ||
| pgraner | apw, got it | 11:12 |
| apw | pgraner, cool. is your laptop a 64 bit install ? | 11:13 |
| pgraner | apw, yep | 11:23 |
| === diwic is now known as diwic_afk | ||
| === sconklin-gone is now known as sconklin | ||
| === herton is now known as herton_lunch | ||
| === kshadeslayer is now known as shadeslayer | ||
| smoser | smb, i'll get to your xen image question today | 15:09 |
| smb | cheers. Sadly I realized that with the laptop approach I currently use, I won't be able to do anything beyond a t1.micro anyway. But for the future I hope to set up a more capable environment. :) | 15:11 |
| JFo | going to be 'nearby' for a bit. I am finally starting up my python focused time every week. Just ping me here and I'll check periodically, but I am mostly going to be buried in a book. :) | 15:14 |
| === herton_lunch is now known as herton | ||
| === bjf[afk] is now known as bjf | ||
| ohsix | apw: posted the cgroup-bin suspend bug https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/713187 | 16:44 |
| ubot2 | Launchpad bug 713187 in libcgroup "cgroup-bin default configuration breaks suspend" [Undecided,New] | 16:44 |
| === diwic_afk is now known as diwic | ||
| bjf | JFo, i'm now starting to look at the arsenal issue | 18:21 |
| JFo | bjf, ok, I think I have broken/fixed it further :) | 18:21 |
| JFo | so there is another update to that one in the kernel-arsenal | 18:21 |
| === sforshee is now known as sforshee-lunch | ||
| * tgardner --> lunch | 18:52 | |
| * cking --> beer time | 18:59 | |
| === sforshee-lunch is now known as sforshee | ||
| === Edgan_ is now known as Edgan | ||
| poelzi | could someone check this bugfix in please: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/706394 | 20:04 |
| ubot2 | Launchpad bug 706394 in linux "kernel should have CONFIG_CFQ_GROUP_IOSCHED" [Undecided,Incomplete] | 20:04 |
| tgardner | poelzi, looking... | 20:06 |
| poelzi | i really would like that blk cgroups is enabled the next ubuntu kernel. it is so powerfull when used correctly :-) | 20:07 |
| jjohansen | rebooting | 20:29 |
| tgardner | sconklin, linux-meta-mvl-dove 2.6.32.214.15 did not get pocket copied whereas the kernel _did_ get copied. | 20:45 |
| sconklin | ok, it'll probably be Monday if pitti's already gone | 20:46 |
| sconklin | I'll try now | 20:46 |
| sconklin | tgardner: he's gone for the weekend | 20:47 |
| tgardner | sconklin, ok. I'll have fsl-imx51 kernels to annoy him with on Monday anyways. | 20:48 |
| bjf | JFo, ping | 20:59 |
| doctormo | My System76 compal based computer is currently running Ubuntu 10.10 but with the kernel 2.6.32 from lucid. This is because the newer kernel can not see pci memory for some reason which system76 have been unable to reproduce on their test machines. There is a report that this bug is still present in the natty alpha2 kernel. | 21:12 |
| doctormo | I'm at a bit of a loss of what I can do. The bug is highly severe, but lost in the noise and lacking a fix. | 21:13 |
| bjf | doctormo, don't know what to tell you, you are saying that somewhere between 2.6.32 and 2.6.35 the kernel broke for your system | 21:22 |
| ohsix | it should be noted that the alternate init systems can use sysvinit type scripts as a lowest common denominator | 21:22 |
| ohsix | so you can work from there and specialize if the package can take advantage of it | 21:23 |
| bjf | doctormo, and the issue still exists even in natty | 21:23 |
| ohsix | oops, sorry, wrong window | 21:23 |
| doctormo | bjf: Yes | 21:23 |
| jjohansen | doctormo: have you tried upstream kernels | 21:24 |
| jjohansen | doctormo: basically you could try say a .33 and .34 based kernel and see if either of those are good | 21:24 |
| doctormo | jjohansen: I could, but I'd like to try kernels in a ppa or some other easy to install and remove form. | 21:25 |
| jjohansen | doctormo: and then knowing that we could work to a bisection point to find which patch caused the problem | 21:25 |
| bjf | doctormo, jjohansen is correct, it could be a difference between the ubuntu kernel and a stock upstream kernel | 21:25 |
| bjf | doctormo, that would help with bisecting the problem | 21:26 |
| jjohansen | doctormo: we do publish an upstream kernel in deb form | 21:26 |
| jjohansen | doctormo: https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds | 21:27 |
| jjohansen | you should be able to pick a .33 and .34 from the archive | 21:28 |
| jjohansen | eg. http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.7-maverick/ | 21:29 |
| jjohansen | sudo dpkg -i to install | 21:29 |
| jjohansen | dpkg -r to remove | 21:30 |
| jjohansen | doctormo: just knowing whether it shows up in one of these is going to help isolate the bug | 21:30 |
| jjohansen | doctormo: have you opened a bug in ll yet so that this can be tracked? | 21:31 |
| doctormo | jjohansen: That wiki page says the mainline is a ppa, but it doesn't look like a ppa, it looks like a repository | 21:31 |
| doctormo | But it gives no instruction on how to install the repository. | 21:32 |
| jjohansen | doctormo: hrmm, I've never used it as a ppa I just grabs .debs from it | 21:33 |
| jjohansen | nor would you want to in your case, as you don't want the latest | 21:33 |
| jjohansen | you want to install specific older kernels for testing | 21:33 |
| bjf | doctormo, those are in an account with "ppa" as part of the name, it's not a true ppa | 21:34 |
| doctormo | It's not a ppa at all, perhaps renaming the thing would avoid future confusion? | 21:35 |
| bjf | doctormo, it probably would but we're stuck with the name | 21:39 |
| doctormo | bjf: Why are you stuck with the name? | 21:54 |
| bjf | doctormo, we just are | 21:54 |
| doctormo | bjf: No, seriously, I do community for work for ubuntu, what will happen if you change the name? | 21:55 |
| bjf | the kernel team is used to it, it can't be a true ppa it has to be just an account with web access | 21:56 |
| bjf | we have a bunch of automated scripts that build various kernels and put them there | 21:56 |
| bjf | it's just not going to change | 21:57 |
| doctormo | bjf: Based on convention, you're going to continue to confuse? | 21:59 |
| doctormo | I'm going to report it as a bug with the community team, it's bad to have this sort of thing. | 21:59 |
| bjf | good luck with that | 22:03 |
| doctormo | bjf: *shrug* conventions like this need fixing. | 22:06 |
| === bjf is now known as bjf[afk] | ||
| vanhoof | /whois doctormo | 22:32 |
| === elmo is now known as elmo_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!