| bjf | mnaser, are you still there? | 00:14 |
|---|---|---|
| mnaser | yes hi bjf | 00:14 |
| bjf | mnaser, yeah that one is hitting us hard | 00:14 |
| mnaser | bjf: http://puu.sh/apMOE/81afd2ddc9.png | 00:15 |
| mnaser | guess when i turned it off.. | 00:15 |
| bjf | mnaser, here's the deal. we should be releasing 14.04.1 today and 12.04.5 on aug. 7 | 00:15 |
| bjf | mnaser, we will have a kernel with the ksm fix built and ready to be released to updates on aug. 8 | 00:16 |
| mnaser | bjf: that sounds awesome to hear, i'm on 12.04 with trusty lts enablement kernel | 00:16 |
| mnaser | so i'll be looking forward for that | 00:16 |
| bjf | mnaser, ok, we'll roll that out on the same day | 00:17 |
| bjf | mnaser, check with me next week. it might be in -proposed | 00:17 |
| mnaser | bjf: thank you so much for this, i will do so, i'm subscribed to the bug as well | 00:18 |
| mnaser | feel free to ping anytime here | 00:18 |
| bjf | mnaser, my plan right now is to upload it on tuesday | 00:18 |
| bjf | mnaser, it will take a little to work through the system and we can't impact the .5 release | 00:18 |
| mnaser | i understand that, disabling ksm was a life saver (not that much of a dependency on it) | 00:19 |
| mnaser | so i can live with it until then | 00:19 |
| bjf | ack | 00:19 |
| mnaser | anyways, gotta head out to gym, thanks for your time and info bjf :-) | 00:19 |
| bjf | np | 00:19 |
| pcarrier | hi! I can't fetch from git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git: "fatal: remote error: access denied or repository not exported: /ubuntu/ubuntu-quantal.git" | 01:06 |
| pcarrier | any idea? | 01:06 |
| TJ- | pcarrier: yes; it has moved to the archive since it is EOL | 01:31 |
| pcarrier | TJ-: thanks! for reference, ubuntu-archive/ instead of ubuntu/ | 01:32 |
| TJ- | pcarrier: Indeed :) | 01:33 |
| === shuduo_afk is now known as shuduo | ||
| diwic | hi, | 10:18 |
| diwic | is there a macro like KERNEL_VERSION() that also includes the ubuntu version? | 10:18 |
| diwic | e g, if I want different code for 3.13.0-24 and 3.13.0-32 | 10:18 |
| apw | diwic, in recent kernels there is an UBUNTU_something_ABI | 10:31 |
| diwic | apw, okay, so I'm looking for something like LINUX_VERSION_CODE >= KERNEL_VERSION(3.13.0-24) | 10:32 |
| diwic | or -30 in this case | 10:33 |
| diwic | apw, can one do comparison >= on the UBUNTU_something_ABI symbol? | 10:33 |
| apw | diwic, it is just hte 24 in that case | 10:42 |
| apw | i guess one could do like | 10:42 |
| apw | (LINUX_VERSION_CODE * 1000) + UBUNTU_SOMETHING_ABI >= KERNLE_VERSION(3.13.0) * 1000 + 24 | 10:43 |
| ogra_ | thats a french kernel ... | 10:43 |
| ogra_ | kern le | 10:43 |
| ogra_ | :) | 10:44 |
| diwic | le kern | 10:44 |
| apw | it is indeed | 10:44 |
| brendand | 'kern. le version 3.13' | 10:44 |
| diwic | apw, hmm, what's "something"? I thought it resolved to the version, like UBUNTU_24_ABI or something. | 10:44 |
| apw | #define UTS_UBUNTU_RELEASE_ABI $(abinum) | 10:46 |
| apw | no it is that | 10:46 |
| apw | i think you want like: | 10:47 |
| apw | #define UBUNTU_VERSION(a,b,c,d) ((KERNEL_VERSION((a),(b),(c)) * 1000) + (d)) | 10:48 |
| apw | and use that | 10:49 |
| apw | and if you paired that with | 10:49 |
| apw | #ifndef UTS_UBUNTU_RELEASE_ABI | 10:49 |
| apw | #define UTS_UBUNTU_RELEASE_ABI 0 | 10:49 |
| apw | #endif | 10:49 |
| apw | you could use it with normal code too | 10:49 |
| apw | normal versions | 10:49 |
| diwic | apw, ok, thanks! | 10:50 |
| apw | plus | 10:50 |
| apw | #define UBUNTU_VERSION_CODE ((KERNEL_VERSION_CODE * 1000) + UTS_UBUNTU_RELEASE_ABI) | 10:51 |
| apw | and i think you would have a winner | 10:51 |
| apw | it is possible some of these should come with the kernel as it were | 10:51 |
| diwic | yup, sounds like a nice improvement indeed if UBUNTU_VERSION and UBUNTU_VERSION_CODE were already there | 10:52 |
| apw | i'll poke rtg about it when he wakens | 11:00 |
| === psivaa is now known as psivaa-afk | ||
| === psivaa-afk is now known as psivaa | ||
| xevious | Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version? | 15:26 |
| YoungSoo | hello | 16:07 |
| ProfessorKaos64 | I saw the report that kernel 3.13.0-32 was released, but when I go to upgrade, it is held back. Is there a dependency I am missing? | 22:53 |
| === Kaloz_ is now known as Kaloz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
