[01:15] ogasawara, checked that kernel on a quantal install and seems good, I don't think it liked my fglrx driver on mint, but that's a driver issue, not a kernel issue [05:13] moin [07:04] morning [07:50] * ppisati -> back in 20mins [08:57] * apw giggles [09:09] * smb slaps apw [09:24] * cking --> popping out for a mo [10:05] * ppisati is already hungry... [10:39] ppisati, bug 746137, how hard do you think would it be to have the suggested changes from comment 16 in the kernel for a test ? [10:39] Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137 [10:47] ogra_: creating the patch is easy, but i doubt it'll fix any real problem [10:47] ogra_: omap3 or omap4? [10:49] ppisati, well, plaing around with omap4 is probably less intrusive (since you dont need to hack around in the mainline tree) [10:49] up to you, hqappy to test it on either platform [10:49] omap3 exposes it easier though since the ram is less [10:50] i'm in the middle of the tilt porting [10:50] when i cut a working new kernel [10:50] i'll create the patch [10:50] someone suggested the rx200 commit upstream [10:50] but i can't find that comment in that bug report [10:50] do you remember where it is? [10:51] no, but ask marvin24, he was the one suggesting the fix to me [10:51] ack [10:51] i suppose he was also the one sending it upstream [10:52] when i've a bit of time i'll comment on that bug too [10:52] (he is usually very german^Wstrict with upstreaming) [10:53] ogra_: just pinged him [10:53] great [10:56] apw: when you have some time, could you take a look at my oneiric lts git trees? [10:57] apw: ubuntu-lucid and ubuntu-lucid-meta, branches lts-backport-oneiric [11:11] henrix, ack [11:13] apw: thanks [11:17] * henrix goes grab some food [12:02] henrix, reviewed and pushed [12:02] apw: great, thanks! [12:22] ayan, ppisati, jjohansen, henrix: rebooting tangerine for kernel update [12:24] rtg: okay. [12:33] apw: i've uploaded packages for signing into zinc [12:47] cking, rebooting gomeisa for kernel update [12:47] ok [12:47] * cking logs off [12:58] * henrix is out for ~20mins === amitk_ is now known as amitk [13:08] * apw giggles again [13:11] * amitk know what the outcome will be this time :) [13:11] *knows [13:11] 14:27 * apw giggles [13:11] 14:39 * smb slaps apw [13:13] amitk, you are welcome to do it yourself. :) [13:18] smb: too many in one day might cause damage and cause you more work ;) [13:27] apw: What's with the giggling? [13:28] infinity, 20m ... obviously [13:33] infinity, And apw's dirty imagination [13:33] apw: Oh, heh, I'm too tired to go looking for context. :P [13:33] apw: IT WAS FOUR WHOLE LINES UP. [13:34] infinity, was that yesterday? i lost some context yesterday due to bip fookage [13:34] infinity, The context need even more than just 4 lines [13:35] smb: I've been filled in on the rest of the context. ;) [13:35] infinity, :) I bet [13:47] I think I've hit a btrfs bug: https://pastebin.canonical.com/70912/ [13:48] df says I have plenty of free space but when things like apt-get upgrade start to run, it fails with have no free space [13:48] \/home is a subvolume that the precise installer created, perhaps \/ and \ /home are being double counted? [13:50] ppetraki, cking is likely your best bet for knowledge, but i do recall that freespace in btrfs is basically random and useless [13:51] ppetraki, another example why it is so not ready for use [13:51] * smb believes to recall the same... [13:51] apw, sigh... I saw something similar a couple weeks ago when using a chroot but thought it was chroot related. [13:51] well, it won't get better if we don't dogfood it :) [13:51] I was wondering whether "df -i" is sensible for btrfs. That was another factor at least on ext4 [13:51] ppetraki, the free space is a bit "off" in btrfs [13:52] use btrfs fi df [13:53] ppetraki, see https://btrfs.wiki.kernel.org/index.php/FAQ [13:53] yeah, I've been reading that, what isn't clear though is that if their df mechanism is integrated into the system df? [13:53] ppetraki, nope, df on btrfs seems like fiction [13:56] urgh, who changed the libreoffice splash screen? it's way ugly [14:00] sigh... will try disabling cow and run balance, good thing my backups are current [14:01] hi [14:35] * ppisati notes it *almost* compiles again... [14:36] and with that said, calls it a day [14:36] * ppisati -> EOD [14:36] hi. does anyone have overlayfs working for v3.5? [14:37] i just looked at the v3.5 packages in the kernel-ppa, but it looks like overlayfs is missing frmo there. [14:54] * ogasawara back in 20 [14:54] bjf, dput -uf ppa:canonical-kernel-team/ppa *.changes [14:59] rtg, look at the bottom of: https://wiki.ubuntu.com/Kernel/StableReleaseCadence [15:00] rtg: i usually just do: dput -u kernelteam:lucid .changes [15:00] bjf, huh. maybe we should change the directions that are on the PPA page [15:00] rtg: but i have the .dput.conf with the ppa configuration [15:11] bjf, henrix: so, I think the commit log messages in 'ubuntu-lucid-meta ports ' are difficult to distinguish from master if we are using them to create tags (which I normally do). For example, the most recent ports branch commit is Ubuntu-2.6.32.42.34, whereas master is Ubuntu-2.6.32.42.49. You cannot quickly pull a tag and know which branch it references. [15:12] hmm, I see that someone has been creating tags that don't match the commit, e.g., ports-Ubuntu-2.6.32.41.33 [15:13] ogasawara, rtg - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027851 is there a workaround? [15:13] Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Confirmed] [15:13] skaet, hold down the red button until everything is quiet. [15:14] rtg, ack [15:14] skaet, ok, there were some suspend/resume fixes that I think affected shutdown. [15:15] they would be in -6 [15:17] skaet, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027851/comments/4 [15:17] Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Confirmed] [15:18] rtg: hmm... ok [15:19] rtg: so, from the history, it looks like the ports tree follows a different logic: tag is different from commit [15:19] herton: ^ is this correct? [15:20] yes, that's what being done, putting a 'ports-' prefix to the tag [15:20] rtg: and if that's true, my last tag *is not* correct: i tagged with Ubuntu-2.6.32.42.34 instead of ports-Ubuntu-2.6.32.42.34 [15:20] as it's a branch on the repo, it could potentially clash with tags from master for example [15:20] so I think that's why it's done this way [15:21] henrix, I'm generating my own tags after a fetch, so we're OK. [15:22] cking, this problem : FAILED [HIGH] DMIInvalidHardwareEntry: Test 1, Unmatched Chassis Type SMBIOS [15:22] cking, is it generic or would it need to be fixed on each system affected? [15:22] cking, or was that something that was taken care of in FWTS? [15:22] rtg: ok, i meant: Ubuntu-2.6.32.42.49 instead of port-Ubuntu-2.6.32.42.49 [15:23] s/port-Ubuntu-2.6.32.42.49/ports-Ubuntu-2.6.32.42.49 [15:23] brendand, i can't tell from almost zero context, can you send me the entire output [15:23] henrix, I just created a ports tag that matched the others, then pushed that [15:24] rtg: still can't see it... [15:25] henrix, doh! now pushed... [15:25] ah, now i can see it. thanks :) [15:26] cking - http://paste.ubuntu.com/1110316/ [15:26] cking, there was https://bugs.launchpad.net/bugs/1021674 [15:26] Ubuntu bug 1021674 in fwts "DMIInvalidHardwareEntry - Unmatched Chassis Type" [High,Fix released] [15:26] cking, wonder if it's covered by that [15:27] brendand, yes it does, and it will be fixed in 0.25.06 [15:28] ..I'm just waiting for it to be packaged and uploaded [15:29] brendand, so skip this one, it's a non-bug (fwts false positive) [15:29] cking, will that end up in precise too? [15:29] brendand, not unless we explicitly get it uploaded to precise, I will talk to kengyu about this [15:55] * herton -> lunch [15:59] apw, cking, https://pastebin.canonical.com/70912/ , evidently btrfs fi balance is not "optional" [15:59] ran a defrag too, everything is good, and faster [16:00] once I disabled cow, lots of space opened up, it's enabled by default [16:01] once cow is disabled you will see file updates performance drop [16:01] turned out ssd wasn't enabled by default, added that too, overall the system feels snappier [16:04] ppetraki, ..until it eats your data :-/ [16:04] cking, regular backups :) [16:04] cking, ext4 has failed me more on ssd than btrfs has [16:05] * cking wonders how many hours ppetraki has run ext4 vs btrfs ... [16:06] cking, well its my primary workstation so... since Dec 2011 [16:07] spent about a year on ext4, that didnt go so well. my early days of btrfs however, 2.6.32, when I was using compression, ended badly when I had an epic power failure. So I don't do that anymore [16:08] ppetraki: i was just running btrfs on my laptop (encrypted home) and it was slooooowwww [16:09] bjf, ever try it without cryptfs? [16:10] ppetraki: yes about a year ago, slow and it ate data [16:10] bjf, yeah, it moves fast, when I was using compression, everything that was zipped ended up with zero file size after a power outage [16:10] but that was 2.6.32 === juarlex_ is now known as juarlex [16:31] * smb -> EOD [17:17] skaet, https://bugs.launchpad.net/ubuntu/quantal/+source/linux/+bug/1027851/comments/8 [17:17] Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Fix released] [17:36] * rtg -> lunch [17:43] rtg, agree. [17:49] * henrix -> EOD [18:04] HI frieds [18:06] Libreoffice: cut'n'paste does not mean cut'n'crash, doh [18:06] yes [18:10] * cking --> beer time [20:35] * rtg -> EOD === BenC_ is now known as BenC