apetrescu | I started a kernel build using: | 04:52 |
---|---|---|
apetrescu | AUTOBUILD=1 fakeroot debian/rules binary-debs | 04:52 |
apetrescu | it's been going for four or five hours and I swear to God as the compilation targets scroll by I can swear I've seen some of these subtrees before | 04:52 |
apetrescu | Is there any known situation where it gets stuck in an infinite loop and keeps on recompiling the same things over and over again? | 04:52 |
apetrescu | It even got to the "LD vmlinux" stage once | 04:53 |
apetrescu | And now it's back to compiling drivers/infiniband | 04:53 |
apetrescu | Which I'm almost certain was compiled about two hours ago | 04:53 |
lifeless | its building all the different flavours | 04:54 |
apetrescu | Oh, okay | 04:54 |
apetrescu | How many flavors are there? 3? | 04:54 |
apetrescu | Generic, xen, and rt? | 04:54 |
lifeless | dunno | 04:54 |
apetrescu | Damn, I should have told it just to do generic | 04:54 |
lifeless | binary-generic, for instance,w ould build one flavour | 04:54 |
apetrescu | At least that explains it | 04:54 |
apetrescu | Thanks a lot :) | 04:54 |
=== _LibertyZero is now known as LibertyZero | ||
vish | hi, while git bisect I accidentally did $git bisect skip , instead of $git bisect good , but then I tried to "fix" it by doing $git bisect < previous skipped commit> , so now the log looks like » http://paste.ubuntu.com/646220/ | 05:16 |
vish | if you notice the last two bisects, they are the same commit# one is now marked skip and then as good.. is that correct or how do i fix it? | 05:16 |
vish | s/correct/OK | 05:17 |
ohsix | vish: you could start the bisect again with the valid outer commit id's instead of your original starting ones | 05:28 |
vish | ohsix: yea, I did consider that, but which way would that be? just leave the new commit# as good and the old one as bad? | 05:29 |
=== luftikuss is now known as bullgard4 | ||
vish | I had started with $ git bisect start Ubuntu-2.6.35-1.1 Ubuntu-2.6.34-5.14 | 05:30 |
vish | i so just s/Ubuntu-2.6.35-1.1/6b2c676bf32be91f43215d5874c07c1becaba013 ? | 05:31 |
vish | so I* | 05:31 |
vish | err, wait the first one was bad! | 05:31 |
vish | s/Ubuntu-2.6.34-5.14/6b2c676bf32be91f43215d5874c07c1becaba013 ? | 05:32 |
ohsix | git bisect log shows all the decisions made; they alternate, between the last good and the most recent bad should be the inner set | 05:34 |
vish | the weird thing is I got only good bisects(until now).. o.0 | 05:36 |
=== smb` is now known as smb | ||
smb | vish, The output of git bisect log should be the sequence of commands needed to set you up. So if you put that into some text file and delete things after the point you want to start over with and then reset your tree to the start of the whole bisect, you can run that file and get where you want to be | 06:43 |
cking | morning folks | 07:12 |
vish | smb: yea i see it in the log.. so if I delete the second last 'skip' lines would it be OK? also when i $ git bisect reset | 07:12 |
vish | error: Untracked working tree file 'debian.master/NOTES' would be overwritten by merge. | 07:12 |
smb | cking, morning | 07:12 |
* vish could probably update the wiki with a lot more bisect info, (that is when i'm done) :D | 07:13 | |
smb | vish, It should be ok for replay, yes. Sounds like for the reset you need to throw away generated files (git clean -d -x -f (warning gets rid of everything in the git directory not in git) | 07:14 |
smb | So the log better goes one dir level up to be persistently saved | 07:14 |
vish | k.. | 07:14 |
smb | git checkout -f resets the files to what they are in the current HEAD | 07:15 |
smb | I often do both to get back to where I was before playing around | 07:16 |
vish | the git bisect help now makes better sense; thanks smb :) | 07:20 |
smb | vish, welcome :) | 07:21 |
vish | smb: looks like git reset went fine » http://paste.ubuntu.com/646288/ i'm only concerned about line 7 and ln 17,18 referring to the same KVM and commit# , is that right? | 08:01 |
vish | btw, after the git clean how do i make a new debian.master and debian ? or is it OK if I copy them back from a backup or from master? | 08:01 |
smb | vish, at least line 7 tells you where HEAD _was_ before. That could well be what you already had at a certain point... | 08:04 |
vish | yea.. | 08:05 |
smb | The debian* dirs you should be able to copy from the release you are trying to bisect | 08:05 |
smb | Maybe a updateconfigs run would be good as well (to get the configs into a state where you get no questions) | 08:06 |
vish | k | 08:07 |
* ogasawara back in 20 | 14:44 | |
=== brendand_ is now known as brendand_n310 | ||
* jjohansen -> lunch | 19:01 | |
dupondje | http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2308 | 19:24 |
ubot2 | bugzilla.intellinuxwireless.org bug 2308 in RF-Kill "rfkill issue on Intel Centrino Advanced-N 6230" [Normal,New] | 19:24 |
dupondje | have we seen something simular ? | 19:24 |
vanhoof | dupondje: only thing that comes to mind recently is this: https://patchwork.kernel.org/patch/920262/ | 19:28 |
dupondje | Oneiric kernel does have that commit yet ? | 19:30 |
dupondje | or not yet ? | 19:30 |
vanhoof | dupondje: looks like its in: 3.0-3.4 actually | 19:32 |
vanhoof | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/775281 | 19:32 |
ubot2 | Ubuntu bug 775281 in linux "[Dell Latitude 2120/Vostro 1015/1014] Turning off wi-fi with hotkey seems to permenantly disable wi-fi" [High,Fix committed] | 19:32 |
dupondje | The issue looks a bit different tho | 19:33 |
dupondje | Quite annoying issue imo | 19:38 |
dupondje | as it stops me from disabling bluetooth | 19:38 |
=== yofel_ is now known as yofel | ||
bdmurray | sconklin: you were asking about apport-package kernel bugs before - you might look in some of the log files for failures with update-initramfs and grub | 21:27 |
bdmurray | bug 810236 is a good example | 21:28 |
ubot2 | Launchpad bug 810236 in linux "package linux-image-3.0.0-5-generic 3.0.0-5.6 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1" [Undecided,New] https://launchpad.net/bugs/810236 | 21:28 |
manjo | sconklin, bjf, Ricoh 0xe823 card reader does not work for certain SD/MCC Cards, Bug# 773524, there are 2 patches, 1. is in stable 2. just submitted upstream and will be in 3.1 and has stable@ tag. But I would like to have them SRUed in Natty... I am thinking of SRU the 2nd patch as Sauce, any issues with doing that ? | 21:35 |
sconklin | manjo, don't ask me questions like this - read the SRU requirements, and if you think it's a viable patch, submit it as an SRU | 21:35 |
manjo | sconklin, :) ok | 21:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!