| === stgraber_ is now known as stgraber | ||
| ohsix | so, i have a problem i'm trying to find in a program; it seems to happen when only certain pages need to be faulted in, i can sort of provoke it by setting vm.swappiness=100 and doing echo 1 > /proc/pid/clear_refs and waiting an arbitrary amount of time, what i need is something that can evict a page to swap with high likelyhood, is there something in /sys or /proc i can poke to do that? | 02:25 |
|---|---|---|
| ohsix | the program can be modified if madvise or something can be close to forceful (like with DONTNEED) but basically invoking the path taken for the process for hibernate would be perfect | 02:28 |
| ppisati | moin | 07:37 |
| === smb` is now known as smb | ||
| === directhe` is now known as directhex | ||
| smb | morning | 08:44 |
| === yofel_ is now known as yofel | ||
| smb | apw, -ENOHEAR | 09:43 |
| ppisati | brb | 10:08 |
| apw | tseliot, i had a long chat with the rcu maintainers about the issue we worked on in the binary shim | 10:19 |
| apw | tseliot, it does seem like there should be some kind of locking accessor for those | 10:19 |
| tseliot | apw: do you mean additional locks? | 10:19 |
| apw | tseliot, no i mean some kind of wrappers which expose that functionality, so more like a _get _put pair for the iee data which does the right thing | 10:20 |
| apw | tseliot, i am thinking about how they might look at the moment | 10:20 |
| apw | tseliot, for now i would advise ignoring it for us, and lets see if we can fix this upstream for everyone else | 10:21 |
| tseliot | apw: ok but it's not really a lot of work to workaround locally. I'll also have to fix a few more things for 3.8 in the broadcom driver anyway | 10:22 |
| apw | tseliot, ok cool | 10:23 |
| * ppisati hopes for a 'changeset' feature in git, sooner or later... | 10:55 | |
| apw | ppisati, meaning ? | 10:55 |
| apw | bjf, we still have tips which have the wrong series in them, i've just fixes quantal-signed, but this is a timebomb waiting to bite someone | 10:57 |
| ppisati | apw: 'changeset' a way to group together bunch of related patches | 10:58 |
| apw | ppisati, in a way to email them? | 10:58 |
| ppisati | apw: i'm backporting overlayfs to nexus7, picking stuff from 3.2, and i noticed after the 3rd try | 10:58 |
| ppisati | apw: that i actually needed 8/9 patches | 10:59 |
| ppisati | apw: with a 'changeset' we could group together all those patches under the same sha | 10:59 |
| ppisati | apw: and say 'pick the overlayfs changeset' | 10:59 |
| ppisati | apw: fixes could go in later, but when yo cherrypick the changeset, you get all the stuff | 10:59 |
| ppisati | apw: perfore has it | 10:59 |
| ppisati | *perforce | 10:59 |
| apw | ppisati, that is called a branch | 10:59 |
| apw | ppisati, you put all the fixes etc on the branch | 11:00 |
| apw | an then you merge the branch repeatedly into 'master' | 11:00 |
| ppisati | apw: yep, but when you feature enter master, how do you extract it? | 11:00 |
| apw | you never do, you always have the original branch to refer to to find teh patches | 11:00 |
| xnox | rebase. | 11:00 |
| ppisati | apw: but we don't have topic branches many times | 11:01 |
| apw | ppisati, we never do | 11:01 |
| ppisati | apw: that was my point | 11:01 |
| xnox | also git merge-base, can later find the merge commits and sub-branches. to see what got merge into where/when. | 11:02 |
| apw | ppisati, no our desire to maintain a simple history does not make it easy | 11:08 |
| apw | ppisati, we have proposed it, but it would make maintenance a lot higher for everything else | 11:08 |
| ppisati | apw: i see | 11:09 |
| * ppisati notes it doesn't compile yet... | 11:09 | |
| ppisati | apw: anyway, git lg | grep overlayfs was enough to get all the dependencies | 11:09 |
| apw | ok | 11:09 |
| ppisati | apw: so adding "$feature" to the subject is a good thing IMO | 11:10 |
| apw | ppisati, we deffo try to do that for anything we count as an 'ubuntu' drvier | 11:10 |
| ppisati | apw: that's good | 11:10 |
| apw | ppisati, mostly to stop tim from losing the patches when he rebases us :) | 11:11 |
| ppisati | apw: yeah, let's put all the blame on rtg :) | 11:13 |
| xnox | ppisati: if you have overlayfs capable nexus7 kernel, I'd be happy to be an early tester. I know how to use abootimg and flash custom kernels onto my nexus7 ;-) | 11:40 |
| ppisati | xnox: i'll ping you later | 11:43 |
| xnox | =) | 11:43 |
| * rtg_ grumbles about daylight savings time | 11:58 | |
| apw | rtg_, you guys fiddling with your clocks at the wrong time agian ? | 11:59 |
| rtg_ | it always seems to be the wrong time of year for messing with the clocks | 11:59 |
| apw | there is that | 12:00 |
| rtg_ | apw, aren't you guys this coming weekend ? | 12:00 |
| apw | rtg_, i think we are a couple of weeks behind, having aligned with your old dates | 12:00 |
| apw | rtg_, i think it was two weeks either end you lot added | 12:01 |
| ogra_ | yeah, will be a few weeks of gcal fun again | 12:01 |
| rtg_ | I read that DST is basically useless now | 12:01 |
| ogra_ | was it *ever* useful ? | 12:01 |
| rtg_ | not in my opinion | 12:01 |
| apw | there are lots of claims it saves oil, seems unlikely | 12:02 |
| rtg_ | it causes jet lag for sure | 12:02 |
| * ogra_ thinks it was just a bad joke of george washington when he had too much weed one night | 12:02 | |
| ogra_ | (iirc he invented it, didnt he ?) | 12:03 |
| rtg_ | seems a bit before his time. we didn't start it in the states until the fifties | 12:03 |
| apw | ogra_, wikipedia says it was a george, but not that one | 12:03 |
| rtg_ | http://en.wikipedia.org/wiki/Daylight_saving_time | 12:04 |
| ogra_ | heh, k | 12:04 |
| apw | seemingly the first people to do it were the germans :) | 12:07 |
| ogra_ | but an new zealander invented it ... | 12:07 |
| ogra_ | probanly to be closer to the rest of the world for a few days :) | 12:07 |
| apw | indepenandanly invented it, it seems, before the interwebs | 12:07 |
| ogra_ | *probably | 12:07 |
| ppisati | ogra_: after i dpkg -i a new kernel on the nexus7, what do i need to run to "flash it" on the boot partition? | 12:11 |
| rtg_ | ppisati, is this the desktop image ? | 12:12 |
| ppisati | rtg_: phablet | 12:12 |
| rtg_ | ppisati, hmm, dunno about that one. flash-kernel runs on the desktop image and DTRT | 12:13 |
| ppisati | rtg_: i guess i'll have to reflash it then... | 12:13 |
| ogra_ | ppisati, phablet has nothing implemented to handle kernels, it uses androids update.zip method (or is supposed to) | 12:13 |
| * ppisati goes reflashing... | 12:13 | |
| ogra_ | technically you should be able to just use abootimg though | 12:14 |
| ogra_ | since that works on n7 (just not in the other pagblet setups) | 12:14 |
| ogra_ | *phablet | 12:14 |
| ppisati | ogra_: can you reflash the desktop img over the phablet? or do i need to go back to android first? | 12:16 |
| ppisati | ogra_: *can i | 12:16 |
| ogra_ | you can, just go into fastboot and flash it | 12:17 |
| ppisati | ogra_: using today's daily, screen is REALLY dark | 12:39 |
| ppisati | ogra_: but i can see the normal installation process going on | 12:40 |
| ogra_ | k | 12:40 |
| ppisati | ogra_: isn't is supposed to be a preinstalled img? | 12:40 |
| ogra_ | yes | 12:40 |
| ogra_ | it uses oem=config to do the initial configuration | 12:40 |
| ogra_ | *oem-config | 12:40 |
| ppisati | ogra_: but it's unusable | 12:41 |
| ppisati | ogra_: it's uninstallable actually | 12:41 |
| ppisati | i'ts *not* installable | 12:41 |
| ogra_ | i had several positive reports for the last image | 12:41 |
| ppisati | ogra_: do you connect it to an external screen? | 12:41 |
| ogra_ | how exactly is it not installlable ... does it unpack the tarball and you get into X/oem-config ? | 12:42 |
| ppisati | ogra_: i can't see what's going on the screen | 12:42 |
| ppisati | ogra_: it's so dark, i can barely see some shadow | 12:42 |
| ogra_ | you use landscape mode, right ? | 12:42 |
| ogra_ | hmm | 12:42 |
| ogra_ | not for me | 12:42 |
| ogra_ | are you sure your backlight isnt broken ? | 12:42 |
| * ogra_ starts a download of todays image | 12:43 | |
| ppisati | ogra_: it was working wit the phablet img | 12:43 |
| ppisati | i can try to reflash it | 12:43 |
| ogra_ | i wonder if the android kernel caused that | 12:43 |
| ogra_ | s/android/cyanogenmod/ | 12:43 |
| ogra_ | i.e. setting soem HW register that makes it go darker than usual | 12:43 |
| ppisati | ogra_: i rebooted it | 12:44 |
| ogra_ | i havent tried phablet on a tablet, only ported it to my galaxy S2 and run it there so far | 12:44 |
| ppisati | ogra_: ok so | 12:46 |
| ppisati | ogra_: during boot, i see the "google" logo and plymouth "ubuntu" is ok | 12:46 |
| ppisati | ogra_: bright as always | 12:46 |
| ogra_ | ok | 12:46 |
| ppisati | ogra_: but when the installation starts, it goes in TOTALLY power save mode | 12:47 |
| ogra_ | but you can still see something through that ? | 12:47 |
| ppisati | ogra_: today's daily is unusable for me | 12:47 |
| ppisati | ogra_: nope | 12:47 |
| ppisati | ogra_: only a very very very pallig img | 12:48 |
| ppisati | *pallid | 12:48 |
| ogra_ | that doesnt sound like power save mode but like ubiquity having a start up issue ... is that todays image ? | 12:48 |
| ogra_ | so it *is* showing something, just not with bright enough backlight ? | 12:48 |
| ppisati | ogra_: right | 12:49 |
| ppisati | ogra_: i see the installer | 12:49 |
| ogra_ | do you have a lamp near you ? | 12:49 |
| ppisati | ogra_: choose language, timezone, etcetc | 12:49 |
| ppisati | ogra_: uhm | 12:49 |
| ogra_ | can you hold it with the top part of the display directly under the lamp ? | 12:49 |
| ppisati | ogra_: no :) | 12:49 |
| ppisati | ogra_: let me first reflash it, just in case... | 12:50 |
| ogra_ | it looks to me like the phablet kernel redefined the minimal brightness | 12:50 |
| ogra_ | so that the luxd script (which just shorcuts the ambient sensor to the brightness control) gets you a too dark setting | 12:51 |
| ppisati | rebooting after reflash... | 12:52 |
| ogra_ | to check the luxd script you would need a lamp and hold it close to the ambient sensor | 12:54 |
| ogra_ | the display should adjust automatically | 12:54 |
| ppisati | ogra_: again, night mode... | 13:00 |
| * ppisati goes trying the "last-good-image' | 13:02 | |
| ogra_ | that one definitely works, i tested it myself | 13:04 |
| ogra_ | (but then i didnt have phablet installed ever on my n7 ... i really think its something with the pahblet kernel) | 13:04 |
| ppisati | ogra_: let's see | 13:05 |
| ogra_ | yeah | 13:05 |
| ogra_ | download will still take 20/30min here | 13:05 |
| * ppisati goes for an apple... | 13:06 | |
| ogra_ | ppisati, pad or book ? | 13:06 |
| ppisati | ogra_: fruit :) | 13:07 |
| ogra_ | ... so nostalgic :) | 13:08 |
| ppisati | ogra_: even with the good img i had the same problem, i'm back to android now | 13:33 |
| ppisati | ogra_: and it's ok | 13:33 |
| smb | ogra_, I suppose not too many will note the fun double meaning of the "pahblet" image... ;-P | 13:35 |
| rtg_ | sforshee, I don't think the efivarfs fixes you were anticipating made it into -rc2 | 13:44 |
| sforshee | rtg_, I think 123abd76edf56c02a76b46d3d673897177ef067b is the one we're looking for | 13:48 |
| sforshee | git describe --contains 123abd76edf56c02a76b46d3d673897177ef067b | 13:48 |
| sforshee | v3.9-rc2~14^2^2~1 | 13:48 |
| rtg_ | sforshee, doh, of course. | 13:49 |
| rtg_ | sforshee, prolly need that in raring as well | 13:49 |
| rtg_ | it is marked stable | 13:50 |
| sforshee | rtg_, yep, the bug came into raring via the stable updates | 13:50 |
| ogra_ | smb, lol | 13:59 |
| ogra_ | ppisati, so there is definitely something wrong with our kernel or userspace wrt backlight handling | 13:59 |
| ppisati | ogra_: dunno | 14:00 |
| ogra_ | ppisati, and since i dont see it here its is also definitely caused buy the phablet android kernel | 14:00 |
| ppisati | ogra_: now it seems i can't even get to the installer :( | 14:00 |
| ppisati | ogra_: i'm back to android for the secondo time | 14:00 |
| ogra_ | (and you are actually the first one to report it at all) | 14:00 |
| ppisati | ogra_: and it's ok, again | 14:00 |
| ogra_ | yes, i got that | 14:00 |
| ogra_ | so our nx7 kernel does something weird | 14:01 |
| ppisati | ogra_: http://askubuntu.com/questions/259369/ubuntutouch-mako-nexus-4-black-screen-after-install | 14:01 |
| ogra_ | (whatever that is) | 14:01 |
| ogra_ | thats totally unrelated | 14:01 |
| ogra_ | it happens on phablet if the userspace unpacking failed | 14:01 |
| ogra_ | not related | 14:02 |
| cking | hrm, does that mean we now have askubuntu.com + LaunchPad to check for bugs? | 14:02 |
| * jsalisbury reboots | 14:02 | |
| ogra_ | cking, since a while already ... though the ask moderators are usually clever enough to point people to LP for real bugs | 14:03 |
| === kentb-out is now known as kentb | ||
| ogra_ | cking, its kind of supposed to replace the LP questions api that nobody really uses | 14:03 |
| cking | ogra_, yup, it's just *another* thing to scan for "the world is on fire" bugs | 14:04 |
| ogra_ | yeah | 14:04 |
| ppisati | ogra_: ok, i officially give up with the desktop img | 14:17 |
| ppisati | ogra_: if anyone feels brave enough, here is a kernel with overlayfs | 14:18 |
| ppisati | http://people.canonical.com/~ppisati/linux-image-3.1.10-9-nexus7_3.1.10-9.27~overlayfs_armhf.deb | 14:18 |
| apw | cking, na another thing to ignore until ogra_ tells you the world is on fire :) | 14:18 |
| apw | ppisati, i have desktop on mine ... i can try later | 14:18 |
| ogra_ | xnox, ^^^ | 14:18 |
| ogra_ | he wanted to be beta tester for it :) | 14:19 |
| xnox | =))))) | 14:19 |
| xnox | \o/ awesome | 14:19 |
| * ogasawara back in 20 | 14:37 | |
| ppisati | ogra_: and for the records, i'm back to the phablet img and it works fine | 14:38 |
| ogra_ | ppisati, yes, i belive you | 14:38 |
| ogra_ | ppisati, so our nexus7 kernel has a bug | 14:39 |
| ogra_ | which i cant trigger here at all | 14:39 |
| ppisati | ogra_: is there an old img somewhere? | 14:39 |
| rtg_ | ogra_, I'd guess its more likely a difference in config options | 14:40 |
| ogra_ | rtg_, or that, yeah | 14:40 |
| ogra_ | ppisati, just FYI, todays desktop image works absolutely flawless here | 14:48 |
| ppisati | ogra_: :( | 14:48 |
| ogra_ | so i suspect android sets some HW register or so that causes the brightness lowlevel to be lower than usual | 14:49 |
| ppisati | ogra_: that is weird | 14:49 |
| ppisati | ogra_: after so many reflashes, it shouldn't bother anymore | 14:49 |
| ogra_ | ppisati, well, if we dont set that same register back it indeed wont work | 14:50 |
| ogra_ | ppisati, i think the actual darkening happens through our luxd script though .... i'll drop that from the settings package and the next image will then just rely on kernel stuff for brightness | 14:51 |
| ogra_ | so i would ask you to try that one (once it is out) to see if the issue is gone | 14:51 |
| ppisati | ogra_: if i press the volume down button, i see all the services starting | 14:51 |
| ppisati | ogra_: but after apparmor | 14:52 |
| ppisati | ogra_: the screen goes black, and never resumes | 14:52 |
| ogra_ | how long did you leave it sitting like that ? | 14:52 |
| ogra_ | ubiquity is *very* slow starting | 14:52 |
| ogra_ | can take a minute or a bit more | 14:52 |
| ppisati | ogra_: some minutes | 14:53 |
| === kentb is now known as kentb-afk | ||
| ogra_ | k | 14:53 |
| ogra_ | then its not ubiquity | 14:53 |
| ppisati | still black | 14:53 |
| ogra_ | and you tried that with todays image ? | 14:53 |
| ppisati | yes | 14:53 |
| ogra_ | 100% sure ? | 14:53 |
| ogra_ | we had a bug about a week ago where whoopsie would cause a black screen after plymouth | 14:53 |
| * xnox will be trying soon with my automatic preseeding of wifi & user config, but with added custom kernel as well ;-) | 14:53 | |
| ppisati | [flag@luxor ~]$ md5sum ~/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.bootimg | 14:54 |
| ppisati | f68e802b866f2b73b54c0890a8138005 /home/flag/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.bootimg | 14:54 |
| * ogra_ is in the last stages here ... oem-config-remove already running | 14:54 | |
| ppisati | [flag@luxor ~]$ md5sum ~/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img.gz | 14:54 |
| ppisati | 4f6f33be6ef8671f1b5a45ab3e467c6d /home/flag/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img.gz | 14:54 |
| ogra_ | lets compare the unzipped image | 14:54 |
| ogra_ | ogra@anubis:~/Desktop/images/raring/20130311$ md5sum raring-preinstalled-desktop-armhf+nexus7.img | 14:55 |
| ogra_ | 5b5e69daa5c2238cc2c8221483d8eb50 raring-preinstalled-desktop-armhf+nexus7.img | 14:55 |
| ogra_ | (i never keep the gz around ... pointless :) ) | 14:55 |
| ppisati | Mar 10 16:13? | 14:55 |
| ogra_ | yep | 14:55 |
| ogra_ | does your unzipped image match mine ? | 14:56 |
| ogra_ | probably your gzip is screwed ? | 14:56 |
| ogra_ | :P | 14:56 |
| ogra_ | (unlikely indeed :) ) | 14:56 |
| * ogra_ is at the freshly installed desktop | 14:56 | |
| ppisati | [flag@luxor ~]$ md5sum Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img | 14:57 |
| ppisati | 5b5e69daa5c2238cc2c8221483d8eb50 Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img | 14:57 |
| ogra_ | hmm, yeah, its the same | 14:57 |
| ppisati | ogra_: mine is a... | 14:57 |
| ogra_ | weird that mine works flawless then | 14:57 |
| ppisati | ogra_: 8G nexus7 FWIW | 14:57 |
| ogra_ | same here | 14:57 |
| ogra_ | first model goodle sold | 14:57 |
| ogra_ | 14:57 | |
| ppisati | ogra_: did you upgrade android to the latest version? | 14:58 |
| ppisati | ogra_: i didn't | 14:58 |
| ogra_ | i didnt | 14:58 |
| ppisati | :( | 14:58 |
| ogra_ | my device only had android on it for some hours | 14:58 |
| ogra_ | never seen it again | 14:58 |
| ogra_ | you flashed the .img, not the .img.gz, right ? | 14:58 |
| ppisati | ogra_: the installer did for me | 14:59 |
| ogra_ | i never used the installer :) | 14:59 |
| ogra_ | so much overhead for two commands | 14:59 |
| ogra_ | yay, and the nautilus bug is fixed | 14:59 |
| ogra_ | fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg | 15:00 |
| ogra_ | fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img | 15:00 |
| ogra_ | fastboot reboot | 15:00 |
| ogra_ | thats what i use | 15:00 |
| ogra_ | to be on the safe side i often also do: fastboot erase boot ; fastboot erase userdata ... before running that though | 15:01 |
| ppisati | ogra_: what's different between erase and format? | 15:04 |
| ppisati | ogra_: "******** Did you mean to fastboot format this partition?" | 15:04 |
| ogra_ | dunno if there is one :) | 15:04 |
| ogra_ | its moot anyway, since we flash a new filesystem | 15:04 |
| ogra_ | i just like to be sure its empty before flashing ... but theoretically fastboot flash does it already | 15:05 |
| brendand | bjf, henrix - if someone is running the 3.5 kernel in precise (i.e. they installed 12.04.2), does that mean that they get -proposed kernels from quantal? | 15:21 |
| rtg_ | brendand, no, they get official LTS kernels from the precise archive | 15:22 |
| rtg_ | from -updates | 15:22 |
| apw | which in theory are identicle, but not quite | 15:22 |
| bjf | brendand, works like all the rest. we produce a lts-hwe-quantal kernel, run it through -proposed etc. if they enable proposed they would get that | 15:22 |
| brendand | bjf, - but it follows this tracking bug, right? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1133429 | 15:23 |
| ubot2` | Launchpad bug 1133429 in kernel-sru-workflow/verification-testing "linux: 3.5.0-26.40 -proposed tracker" [Medium,In progress] | 15:23 |
| bjf | brendand, look at comment #1 | 15:23 |
| bjf | brendand, "linux-lts-quantal (precise) - bug 1133589" | 15:24 |
| ubot2` | Launchpad bug 1133589 in Kernel SRU Workflow prepare-package "linux-lts-quantal: 3.5.0-26.40~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1133589 | 15:24 |
| brendand | bjf - does that kernel follow the same SRU process as the other ones? | 15:25 |
| bjf | brendand, yes, haven't you been testing it? | 15:25 |
| brendand | bjf - it seems to be marked invalid for us | 15:26 |
| bjf | brendand, i think that is correct | 15:26 |
| brendand | bjf, we've been testing the 3.5 kernel, but with quantal userspace | 15:27 |
| brendand | bjf, on systems that we certified with quantal | 15:27 |
| bjf | brendand, that makes sense | 15:27 |
| brendand | bjf, we want to start testing systems we certified with 12.04.2 | 15:27 |
| bjf | brendand, that's fine, but you also have to keep testing Precise | 15:28 |
| brendand | bjf, and we will | 15:28 |
| brendand | bjf, we'd kind of like to not test quantal either, since we aren't certifying systems with quantal | 15:29 |
| bjf | brendand, you must test the previous release and all LTS releases | 15:30 |
| brendand | bjf - ok, well assuming we continue to test quantal. how do we go about getting in the loop for the backports kernels such that we know when they're ready and can start testing them with 12.04.2? | 15:32 |
| bjf | brendand, the process should work exactly the same. we can fix the tracking bugs so that cert. testing is no longer invalid | 15:33 |
| brendand | bjf - but is the backports kernel following a different cadence then? at the moment the one you linked to is in 'prepare-package' | 15:34 |
| bjf | brendand, same cadence. i'm looking at why that bug is stuck in "prepare-package" | 15:35 |
| bjf | brendand, however, please note that we are respinning that kernel due to a regression | 15:36 |
| brendand | bjf, ok | 15:37 |
| bjf | brendand, that was not the correct tracking bug. bug 1135219 is the correct one | 15:38 |
| ubot2` | Launchpad bug 1135219 in Kernel SRU Workflow verification-testing "linux-lts-quantal: 3.5.0-26.40~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1135219 | 15:38 |
| === kentb-afk is now known as kentb | ||
| rtg_ | apw, do you have time to look at overlayfs in 3.9 ? looks like the dentry_open function has morphed into atomic_open with way different parameters. | 15:58 |
| apw | rtg_, yeah will do, i think we was expecting something like that | 15:58 |
| rtg_ | apw, I updated aufs | 15:59 |
| apw | rtg_, great, does it still work :) | 15:59 |
| apw | (now work) | 15:59 |
| rtg_ | apw, dunno. you have a test for it IIRC ? | 15:59 |
| apw | i would rather say i know how to basically touch test it | 15:59 |
| rtg_ | apw, well, I know basically how to compile it :) | 15:59 |
| cking | kirkland, test results in your inbox | 16:02 |
| rtg_ | cking, aes-ni ? | 16:08 |
| cking | rtg_, yep, wanna copy of them? | 16:08 |
| rtg_ | cking, please | 16:08 |
| cking | rtg_, bottom line, if you have a fast device (SSD) you will see some excellent improvements, HDD probably not (depends on usecase) | 16:10 |
| ppisati | cking: how long does it take before it blows up? | 16:55 |
| ppisati | cking: anyhow, i'll leave it running | 16:59 |
| * ppisati -> workout | 16:59 | |
| ppisati | cking: anyhow | 17:00 |
| ppisati | Test Summary: | 17:00 |
| ppisati | 23 passed | 17:00 |
| ppisati | 1 failed | 17:00 |
| ppisati | enospc FAIL | 17:00 |
| ppisati | all the rest was ok | 17:00 |
| ppisati | cking: tell what i need to do after | 17:00 |
| * ppisati is out for real now | 17:01 | |
| * cking ponders why all the tests fail in the QA lab | 17:11 | |
| infinity | apw: *poke* | 17:19 |
| apw | infinity, hi | 17:19 |
| infinity | apw: Your linux-signed upload to quantal is crufty. | 17:19 |
| apw | oh what did i knob on that | 17:19 |
| infinity | Had a local tree with junk in it? | 17:20 |
| infinity | https://launchpadlibrarian.net/133709453/linux-signed_3.5.0-26.40_3.5.0-26.42.diff.gz | 17:20 |
| infinity | apw: To avoid having to do weird version number bumps, if you want to fix that and upload directly to the archive instead of the PPA... | 17:21 |
| infinity | apw: (And make sure it was just your local system with junk, not git) | 17:21 |
| apw | infinity, toss ... ok | 17:22 |
| bjf | apw, are you doing the signed pkgs or is the stabel folks? | 17:34 |
| apw | bjf, i was doing it originally because steve didn't do it | 17:34 |
| apw | and i was asked for it over the weekend | 17:34 |
| apw | i don't want to do it :) | 17:34 |
| apw | but as i ballsed it up, i should clean up my own mess | 17:35 |
| bjf | i think it could have waited til today | 17:35 |
| apw | perhaps so | 17:35 |
| bjf | sconklin, ^ don't do the quantal signed pkgs, it seems that apw is doing it | 17:35 |
| sconklin | bjf: ack | 17:36 |
| tseliot | apw: can you think of any reasons why I'm getting a warning about "rcu_read_unlock_special" being undefined even though I included <linux/rcupdate.h>? | 17:38 |
| apw | tseliot, isn't that RCU TINY only ? | 17:39 |
| tseliot | apw: __rcu_read_unlock uses that in rcupdate.c | 17:40 |
| tseliot | apw: and I can see this in linux/rcupdate.h : extern void rcu_read_unlock_special(struct task_struct *t); | 17:47 |
| apw | the code there is only included if CONFIG_PREEMPT_RCU is enabled | 17:51 |
| apw | in both header and main .c file | 17:52 |
| tseliot | apw: right, and that's enabled in our lowlatency flavour | 17:52 |
| * rtg_ -> lunch | 17:59 | |
| infinity | apw: Want to nudge me when that fixed linux-signed is uploaded? | 18:16 |
| infinity | apw: Or I can do it myself and get you to double-check git later. | 18:17 |
| infinity | apw: Either works for me. | 18:17 |
| apw | infinity, will do it shortly just on the phone trying (trying trying) to order broadband | 18:18 |
| infinity | Heh. | 18:18 |
| apw | infinity, ok in the pipe, hopefully right this time, direct to quantal-proposed | 19:00 |
| infinity | apw: That looks much cleaner, thanks. | 19:06 |
| apw | infinity, phew i did one thing right today | 20:28 |
| apw | the second time ... :( | 20:28 |
| infinity | apw: Heh. | 20:35 |
| === kloeri_ is now known as kloeri | ||
| * rtg_ -> EOD | 21:16 | |
| === jdstrand_ is now known as jdstrand | ||
| === kentb is now known as kentb-out | ||
| === lifeless_ is now known as lifeless | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!