=== dileks is now known as Guest22711
=== dileks_ is now known as dileks
[08:49]  * apw is having a bad day
[08:49]  * apw listens to his main home disk go 'der-der-der der-der-der'
[08:51] <dileks> die-die-die... das-das-das... then you have all 3 German pronouns (male, female and neuter)
[08:52] <apw> my disk is more neuter i think
[08:53] <dileks> depends... I always loved my hardware, gave them mostly female names
[08:57] <cking> apw, you should have asked Intel for a SSD while at UDS...
[08:57] <apw> dileks, heh i more meant it has been neutered
[08:58] <apw> cking, that'd have been nice ... now i get to test my backups i guess
[08:58] <cking> be interesting to see what the SMART data says about the HDD
[09:00] <apw> cking, the bios says "disk failure"
[09:00] <cking> :-(
[10:38] <ppisati> it compiles... almost...
[11:13] <Kangarooo> hello. mainline means upstream?
[11:14] <Kangarooo> https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds is written to install B & C kernels for 32bit ubuntu. 
[11:14] <Kangarooo> so from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc6-precise/ i take
[11:15] <Kangarooo> whitch one>?
[11:17] <Kangarooo> *image*.deb ?
[11:25] <Kangarooo> if my laptop has pae then i need pae?
[11:26] <Kangarooo> ill check chat log
[11:26] <dileks> if you use x86-32 and your cpu has pae flag supported... yes
[11:35]  * apw looks out from a new machine ... hmmm not bad
=== yofel_ is now known as yofel
[11:52] <ppisati> apw: did you manage to recover everything?
[12:08] <apw> ppisati, in the process ... though i need to source new rust before i can move back to my machine
[12:17] <apw> tgardner, it has taken me so long to get into the directory i have forgotten who i am looking for :)
[12:18] <tgardner> apw, not sure I can help you there :)
[12:18] <apw> tgardner, network manager dude
[12:18] <tgardner> apw, hang on a sec
[12:19] <tgardner> apw: MathieuTrudel
[12:21] <apw> tgardner, perfect thanks... question away
[12:26] <tgardner> apw, what is the rt meta package in precise called ? its not preempt.
[12:26] <apw> you meant the lowlatency kernel ?
[12:26] <apw> tgardner, ^^
[12:26] <tgardner> apw, that one.
[12:26] <apw> its called linux-lowlatency i think
[12:27] <henrix> yep, i guess that's the one
[12:27] <dileks> bfs :-)
[12:28] <apw> that reminds me i need to push out that -virtual update once i have it back
[12:28] <tgardner> apw, yep, we need to get those collapsed soon.
[12:28] <apw> lest we collide hideously and me scream
[12:28] <apw> tgardner, i have it done, just needs re-build testing on top of the current tip
[12:29] <tgardner> apw, I'm mapping the plan for meta package upgrades which depends on being able to drop virtual
[12:29] <apw> tgardner, yep makes sense
[12:30] <apw> tgardner, as far as i can tell from the testing smb has done, we should be able to apply it and things just work
[12:30] <apw> tgardner, its all there, making a -generic in split mode
[12:30] <apw> tgardner, and we were going to rename generic-pae at the same time yes ?
[12:30] <tgardner> apw, I don't understand split mode
[12:30] <tgardner> oh, extras
[12:31] <apw> tgardner, the merge relys on having ... yes extras as well
[12:31] <apw> tgardner, so the meta package will need to be modded to pull in both for -generic and one for -virtual
[12:32] <tgardner> apw, I'm just writing that up. we write the meta package for what we need in Quantal. we use upgrade-manager to manage the transition to Quantal.
[12:33] <tgardner> rather, update-manager-core
[12:51] <apw> tgardner, won't we also need transitional package linkage too ?
[12:51] <tgardner> apw, not if we can do it programmatically
[12:52] <apw> tgardner, i though we had to handle the update/dist-upgrade side too 
[12:52] <tgardner> apw, we don't have to support 'apt-get dist-upgrade' if its not convenient.
[12:52] <apw> ok
[12:53] <tgardner> apw, as far as I can tellm the re is no combination of Provides:, Replaces: or Depends: that will get us where we wanna be
[12:53] <tgardner> the upgrade janitor is the way to go
[13:10] <tgardner> apw, remember that gomeisa is going away tomorrow
[13:21] <apw> tgardner, grrrr
[13:21] <apw> tgardner, yep thanks
[13:21]  * apw will rsync the stuff to tangerine as a backup
=== rsalveti` is now known as rsalveti
[13:42] <ogasawara> tgardner: have we set up the PPA yet for QA to be able to start testing the 12.10 kernel in 12.04?
[13:42] <tgardner> ogasawara, dunno, I have not hassled byrceh yet
[13:43] <tgardner> guess I ought to do that today
[13:43] <tgardner> got sidetracked by the hv mess yesterday
[13:43] <tgardner> ogasawara, I'll send him an email
[13:44] <ogasawara> tgardner: ack, can you CC me on it?
[13:44] <tgardner> ogasawara, no, I plan to keep you in the dark. (just kidding)
[13:44] <ogasawara> :)
[13:54] <tgardner> ogasawara, I just Cc'd the k-team list
[13:54] <ogasawara> tgardner: cool, thanks
[14:00] <arges> ogasawara, good morning. I was wondering what git tree the daily kernel ppa builds being built from?
[14:02] <ogasawara> arges: it should be pulling from the latest tip of our usual trees
[14:04] <arges> ogasawara, ok. essentially what I want to do is bisect between two versions that i've tested on lucid 2.6.33x which i've tested using the daily ppas... was wondering if i just need to find the commits in ubuntu/ubuntu-lucid or if there was another tree that has these patches.
[14:06] <tgardner> arges, the dailies are built from the master-next branch. I don't understand the source of your confusion. wtf is lucid 2.6.33x ?
[14:07] <arges> tgardner, so i noticed the daily builds have a newer version than the release for lucid, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.1-lucid/   
[14:07] <tgardner> arges, ah, those are mainline builds, not dailies.
[14:07] <tgardner> vanilla stable
[14:08] <arges> tgardner, ah. ok so essentially vanilla with the debian.* folders added in?
[14:08] <tgardner> arges, yep
[14:08] <tgardner> no ubuntu cruft
[14:08] <arges> tgardner, ok and which tree is that?
[14:08] <tgardner> arges, right from upstream stable updates
[14:08] <tgardner> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[14:08] <arges> tgardner, ok so just copy and paste the debian folders from ubuntu-lucid if I want to build a lucid-ish kernel
[14:09] <tgardner> arges, why not just use the deb-pkg target ? 'make deb-pkg INSTALL_MOD_STRIP=1'
[14:10] <arges> tgardner, ok i can try that
[14:10] <tgardner> arges, I assume you're bisecting something ?
[14:10] <arges> tgardner, yes
[14:11] <tgardner> arges, then you wanna use a linear tree. If you try to bisect between Ubuntu tags you could get all confused.
[14:11] <tgardner> a linear tree being upstream stable
[14:12] <arges> tgardner, yup did that yesterday, and the bisect landed on a commit that didn't make much sense.  ok i'll use the stable upstream 
[14:13] <tgardner> arges, take the config from Lucid and start with that.
[14:13] <arges> tgardner, ok will do. 
[14:14] <apw> arges, make configs will generate you some in CONFIGS
[14:14] <arges> apw, yea the vanilla defconfigs
[14:15] <apw> arges, i meant to say 'fakeroot debian/rules makeconfigs'
[14:15] <apw> will make you ubuntu configs in CONFIGS/*
[14:15] <arges> ah
[14:18] <herton> bjf, jsalisbury, I was looking again at bug 1000355, since it's a drbd issue on Lucid (drbd was not in the kernel yet), who we should ping to fix/push the update, there is a patch for the package there now
[14:18] <ubot2> Launchpad bug 1000355 in drbd8 "[SRU] drbd fence-peer breaks when using kernel 2.6.32-41" [Medium,Confirmed] https://launchpad.net/bugs/1000355
[14:20] <bjf> herton, not sure, will think on it
[14:20] <jsalisbury> herton, i'm not sure either
[14:38] <arges> apw, don't see 'fakeroot debian/rules makeconfigs' i see a genconfigs, but that doesn't seem to work. in the ubuntu-lucid tree
[14:38] <henrix> arges: i guess apw meant genconfigs
[14:39] <apw> he did, *tard
[14:39] <arges> henrix, ok
[14:39] <henrix> arges: but i believe you need to run fakeroot debian/rules clean before that
[14:39] <apw> it is not my finest hour
[14:39] <apw> waht henrix says
[14:39] <arges> apw, henrix : thanks guys got it now
[14:40] <apw> repeat after me, i have reliable backups and a clue how to restore them
[14:40] <arges> seths awesome build script has made me lazy
[14:40] <arges> uh oh
[14:42] <henrix> apw: i'm considering setting up bacula one of these days... but for now a cron with rsync has been doing the job
[14:43]  * cking was wondering why his dev box was running so slow and just realised it was running an instrumented kernel, doh
[15:00] <bjf> herton, looking at that drbd bug ... the user is using a drbd dkms package. as far as i know that isn't our package. the fix must be applied there (as i understand it)
[15:02] <herton> bjf, yep, seems ivoks also is already preparing for the usual SRU process for drbd8, so I think we are good. I removed the linux task from the bug
[15:02] <tgardner> bjf, I'm just looking at it. I can do the patch and upload.
[15:02] <tgardner> since I'm the one that implemented the original carnage in the kernel
[15:03] <tgardner> or applied, rather.
[15:05] <tgardner> bjf, drbd went mailine in 2.6.33, so I'm wondering why we're still carrying the dkms package
[15:05] <herton> tgardner, it's lucid, 2.6.32
[15:05] <bjf> tgardner: was thinking the same thing
[15:05] <bjf> tgardner: though herton is correct that the user is running .32
[15:06] <tgardner> herton, right, lucid is the last release for which anyone should be compiling drbd8
[15:32] <tgardner> bjf, herton, bug #1000355 is now fix committed
[15:32] <ubot2> Launchpad bug 1000355 in drbd8 "[SRU] drbd fence-peer breaks when using kernel 2.6.32-41" [Medium,Confirmed] https://launchpad.net/bugs/1000355
[15:32] <bjf> tgardner: thanks
[15:33] <herton> tgardner, ack, thanks
[16:10] <apw> cking, so my networking issues are all nm being bust, and all triggered by misshanding of RDNSS record expirey... essentially the broadcast ipv6 DNS servers are timing out and NM then craps itself and disconnects
[16:10]  * ppisati -> rush out to do some stuff, back in a while
[16:10] <apw> every 10m
[16:11] <apw> and its much worse when the network is slow
[16:11] <cking> gah, that's badly behaving userspace app
[16:12] <apw> yeah. very ... the debug is informational from it i guess so thats something
[16:13] <apw> its says "i need to refresh this info which lasts another 610s" then tries to, times out at 5, and pulls the eject cord
[16:13] <cking> guess it has never been tested against IPv6
[16:15] <apw> cking, its a new issue for sure, i used ipv6 for all of O pretty much without any issues, only on P is it plopping
[16:15] <apw> cking, though i am unsure if it used the ipv6 dns servers correctly before, as i'd prolly never know
[16:16] <apw> cking, can you remember where skype comes from ?
[16:16] <cking> apw, skype comes from the pits
[16:17] <cking> http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux
[16:18] <ogasawara> cking: were you able to get around to test installing the latest 3.4.0-2.6 kernel on your atom kit you were updating yesterday?
[16:19] <cking> ogasawara, oops, completely forgot
[16:19]  * cking goes to try
[16:20] <apw> cking, seems its in s/w center if you wait long enough
[16:26] <ogasawara> cking: http://launchpadlibrarian.net/105256001/linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb
[16:26] <cking> ogasawara, ta
[16:31] <cking> ogasawara, just sent you the results
[16:31] <cking> (email)
[16:31] <ogasawara> cking: thanks
[16:32] <ogasawara> cking: hrm, that's not what I was expecting
[16:32] <cking> me neither
[16:33]  * cking needs to grab some food - back in 15
[16:34] <ogasawara> cking: when you get back, can you let me know what your /proc/cpuinfo output is?
[16:36] <apw> ogasawara, it let him install it, erp
[16:36] <ogasawara> apw: it appears so
[16:37] <ogasawara> apw:  It had one error about missing the linux-headers package as I'm assuming he's got some DKMS package involved
[16:38] <ogasawara> cking: ok if I pastebin your email?
[16:42] <ogasawara> bah, I think the check is wrong
[16:42] <ogasawara> +       system ("grep -q ' pae ' /proc/cpuinfo");
[16:42] <ogasawara> +       if ($?) {
[16:42] <bjf> ogasawara: that's what happens when you let tgardner write perl code
[16:42] <ogasawara>        -q, --quiet, --silent
[16:42] <ogasawara>               Quiet;  do  not  write  anything to standard output.  Exit immediately with zero status if any match is found, even if an
[16:42] <ogasawara>               error was detected.  Also see the -s or --no-messages option.  (-q is specified by POSIX.)
[16:43] <tgardner> ogasawara, hmm, I ran this snippet by hand. maybe the -q option is hosing things
[16:43] <ogasawara> tgardner: I think our if ($?) is wrong as $? is 0
[16:44] <tgardner> ogasawara, maybe it should be system ("grep ' pae ' /proc/cpuinfo > /dev/null")
[16:45] <ogasawara> tgardner: but then I'm baffled as to why it would have worked with ppisati's testing
[16:45] <tgardner> yeah, me too
[16:46] <tgardner> apw, push your virtual -> generic patches before you go on holiday
[16:46] <apw> tgardner, ack on my list, first ... will do
[16:46] <tgardner> or gimme a branch and I can finish 'em up
[16:46] <apw> one or t'other indeed
[16:47] <tgardner> bjf, can you help ogasawara sort out this perl shit since I'm clearly incompetent ?
[16:48] <ogasawara> tgardner: I don't think we need to change the grep options, just the check of $?
[16:48] <apw> ogasawara, it may make sense to just read it in perl
[16:49] <apw> open(FOO, "<xxx>") || die "broken"
[16:49] <apw> while (<FOO>) {
[16:49] <tgardner> ogasawara, apw does know perl pretty well :)
[16:49] <apw>  if ($_ =~ / pae /)  {
[16:49] <apw>    $found = 1;
[16:49] <apw>    last;
[16:49] <apw> }
[16:49] <apw> close(FOO);
[16:49] <apw> something like that
[16:52] <ogasawara> apw: yah, I'll give that a go.  something is obviously wrong because when I think about it now, if colin's test passed, then mine should have failed.
[16:52] <apw> fair point
[16:52] <cking> that makes sense
[16:52] <ogasawara> apw: I can probably test all the scenarios here myself by giving it some bogus check like =~ / paefoo / for one test
[16:52]  * apw gets close to completing his recovery ... phew ... my backups appear to work
[16:53] <apw> ogasawara, yep indeed so
[16:53] <cking> apw, how much data do you need to restore?!
[16:53] <apw> or making it use /tmp/cpuinfo when testing
[16:53] <ogasawara> yep
[16:53] <apw> and copy the file off of ckings machine
[16:53]  * cking sends ogasawara /proc/cpuinfo
[16:53] <ogasawara> cking: thanks
[16:54] <bjf> perl -lane 'if ($_ =~ / pae /) { exit(0); } else { exit(-1); }' /proc/cpuinfo
[16:54] <bjf> something like that
[16:55] <cking> hold on, why are we looking at /proc/cpuinfo - weren't we looking at uname -i or something like that?
[16:55] <tgardner> cking, we're looking for the PAE flag
[16:55] <ogasawara> cking: uname -i is the initial check
[16:55] <ogasawara> cking: +$arch = `uname -i`;
[16:55] <ogasawara> +if ($arch =~ m/86/) {
[16:55] <cking> bother - my N270 is pae capable
[16:55] <ogasawara> cking: oh
[16:55] <cking> so, it wasn't a valid test
[16:56] <cking> let me re-run it on the virtual box image
[16:56]  * cking slaps himself
[16:56] <ogasawara> heh, so does anyone have a non-pae machine?
[16:57] <cking> my virtual box install is non-pae, so I can test that right now
[16:58] <cking> ..once it eventually boots...
[17:02] <herton> apw, do you think a patch for precise is coming, or for tomorrow? (the one from discussion yesterday) I was thinking in taking a swap day tomorrow, and bjf is taking a half day, so I may need to be around.
[17:04] <apw> herton, there is a patch available already, which i will email out today, the tip i built for them is now in your tree (the hyperv1 tag) for precise.  i don't think i needs rushing out before monday, we can decide then if we want to spin just that or to let it run in the next sru round
[17:04] <apw> i am leaning to the latter at this moment
[17:07] <cking> yay it works!
[17:08] <cking> Unpacking linux-image-3.4.0-2-generic-pae (from linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb) ...
[17:08] <cking> This kernel does not support a non-PAE CPU.
[17:08] <cking> dpkg: error processing linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb (--install):
[17:08] <cking>  subprocess new pre-installation script returned error exit status 1
[17:08] <cking> cat /proc/cpuinfo | grep pae --> empty
[17:08] <bjf> herton, i'm still pushing on QA and cert. lets shoot for early next week
[17:09] <ogasawara> cking: thanks!
[17:09]  * ogasawara goes to upload meta
[17:10] <herton> apw, bjf, ack, I'm going to be off tomorrow then, but will be around on irc
[17:11] <tgardner> herton, dude, if you're taking a day off then get the hell away from your computer.
[17:12] <ogasawara> herton: yah, I think you should disconnect completely
[17:12] <herton> hehe, actually I'm going to be away on the weekend, going to watch a rally with some friends in south of brazil
[17:12] <cking> a day off is a day off
[17:12] <herton> but preparing for the travel tomorrow
[17:13] <tgardner> herton, and takes more then 30 minutes ?
[17:13] <ogasawara> I do understand the separation anxiety though, but that all goes away once you have a margarita in your hand
[17:13] <tgardner> oh, now there is a plan
[17:14] <herton> tgardner, it's 600km far away, but want to rest before this, and I'll go tomorrow afternoon/night
[17:15] <tgardner> herton, thats a fair drive even by Montana standards
[17:15] <cking> that's like halfway across the UK
[17:16] <herton> ops, it's 500km actually, but yes, you know, living in a large country, everything is far...
[17:18] <bjf> here's one that actually works: perl -e 'while(<>) { if ($_ =~ / pae /) { exit(0); } } exit(-1); ' < /proc/cpuinfo
[17:24] <apw> does exiting a negative number have meaning ?
[17:24] <bjf> apw, doesn't that set the exit status? for checking $?
[17:25] <apw> as far as i know yes, but exit status is only 8 bits and only positive isn't it?
[17:25] <brendand> i've got one system here that after it installs it seems the wireless is soft blocked
[17:25] <brendand> seems strange
[17:26] <brendand> i don't *think* it was happening with the released version of precise
[17:26] <brendand> checking now
[17:26]  * cking wonders what soft blocked means in terms of wireless
[17:27] <bjf> apw, ] echo $?
[17:27] <bjf> 255
[17:27] <brendand> cking, yeah - it's not possible to do that except via rfkill itself, right?
[17:28] <bjf> apw, so 0 or non-zero
[17:28] <brendand> cking, if i 'rfkill unblock 1 (wifi)' then it of course works again
[17:28] <brendand> cking, i'm assuming we haven't gone and certified it where you need to run rfkill to get the wifi to work
[17:29] <cking> assume nothing in this world
[17:30] <cking> bjf, I suspect the 255 the bottom 8 bits returned from WEXITSTATUS() on an exit of -1
[17:31] <brendand> cking - is this a bug we've got before? where a system has the wireless soft-blocked by default?
[17:31] <cking> brendand, no idea, sorry 
[17:31] <greearb> just out of curiosity, any reason CONFIG_IP_MROUTE_MULTIPLE_TABLES isn't enabled by default?  It's rarely used (cept by me, probably), but it seems most other advanced networking stuff is enabled....
[17:33] <apw> greearb, i think it was marked as dangerous or something when we last looked
[17:34] <greearb> ok, it shouldn't be that dangerous now...it has been reasonably well tested by us, of nothing else.
[17:34] <greearb> it is rarely used, however...and I need to change some other things when rebuilding the kernel for my own purposes, so no big deal if it's left disabled...just wanted to make sure it wasn't an oversight.
[17:35] <dileks> apw: had a look into lp #988183 ?
[17:35] <ubot2> Launchpad bug 988183 in network-manager "Logs full with "ICMPv6 RA: ndisc_router_discovery() failed to add default route"" [High,In progress] https://launchpad.net/bugs/988183
[17:36] <dileks> its not only spamming log-files, periodic dis-/re-connects (wlan, IPv6)
[17:46]  * cking now got reliably ecryptfs encryption benchmarks.. -> /me --> EOD
[17:48] <tyhicks> cking: Nice!
=== tgardner is now known as tgardner-lunch
[17:48] <cking> had to turn off the turbo MSR to make it reliable + consistent
[17:50]  * henrix --> EOD
[18:05] <apw> tgardner-lunch, ok gomeisa has been sucked off to tangerine in theory, so we should be safe against loss
=== tgardner-lunch is now known as tgardner
[18:23] <tgardner> apw, ack
=== skaet_ is now known as skaet
[19:09] <apw> tgardner, ok this -virtual thing has a wrinkle, the udebs seem to be being built from the main kernel image package contents, which aren't there ... cause they are in the other package
[19:09] <tgardner> apw, want me to clean it up? you should be getting done for the day
[19:09] <apw>   dpkg -x $(ls ../linux-image-$i\_3.4.0-2.7~virtualgenericmerge201205171935_i386.deb) \
[19:10] <apw> tgardner, so that bit there likely needs to be taught to extract both halves
[19:10] <tgardner> apw, right
[19:10]  * ogasawara lunch
[19:10] <tgardner> simple enough
[19:11] <tgardner> apw, push a branch and I can finish it up. you're outta here tomorrow, right ?
[19:11] <apw> tgardner, yeah, probabally should finish rebuilding this machine, i am pushing waht i have now to my repo; will send you a link in pm when t'is done
[19:11] <apw> tgardner, ^^
[19:12] <tgardner> apw, drop an email if I'm gone. gonna bail here in a bit for awhile.
[19:13] <apw> tgardner, in pm now
=== kirkland` is now known as kirkland
[20:08]  * tgardner -> EOD