| cjohnston | asac can you please op me in both -core- channels | 14:53 |
|---|---|---|
| slangasek | https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo | 14:57 |
| stgraber | slangasek: can I get the URL? (I don't think I've got a whole lo to say though, just personal interest as I had to deal with that mess all too often) | 15:01 |
| cjohnston | tsimpson-uds: ping | 15:01 |
| slangasek | stgraber: https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo | 15:01 |
| xnox | blueprint URL: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-dmraid2mdadm | 15:01 |
| xnox | pad URL: http://pad.ubuntu.com/uds-1311-core-1311-dmraid2mdadm | 15:01 |
| tsimpson-uds | cjohnston: \o | 15:01 |
| cjohnston | tsimpson-uds: do you run udsbot ? | 15:01 |
| tsimpson-uds | yep | 15:02 |
| cjohnston | tsimpson-uds: can you please have it join -core-1 -core-2 and -design-1 | 15:02 |
| tsimpson-uds | cjohnston: I can, but it won't do much without some chanserv magic | 15:02 |
| cjohnston | tsimpson-uds: I did it in -design-1 I'm waiting to do it in here | 15:03 |
| asac | cjohnston: let me know iif its good | 15:04 |
| slangasek | "Almost British"> lol | 15:04 |
| cjohnston | ta | 15:04 |
| asac | anyone else? | 15:04 |
| cjohnston | nope | 15:04 |
| apw | xnox, you are visible here | 15:05 |
| arges-uds | is the video live | 15:05 |
| apw | arges-uds, t'is for me | 15:05 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Transitioning to use MDADM by default for some of the FakeRAID devices | Url: http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/ | ||
| apw | smb, i assume it does not work at all righ | 15:18 |
| apw | smb, i assume it does not work at all right now even, so someone has to fix it if we can | 15:18 |
| apw | dm_raid45 76611 0 | 15:19 |
| apw | it seems to be loaded on my non dm-raid45 system | 15:19 |
| stgraber | that's unfortunate, would have been nice to get some stats... | 15:20 |
| apw | stgraber, stick a work-item on us to figure out if we can tell, it maybe i have done something odd on this system to make this occur | 15:20 |
| smb | apw, Do you have dmraid installed | 15:20 |
| smb | (the user-space) | 15:20 |
| apw | smb, i would assume so indeed | 15:20 |
| apw | smb, yes i do | 15:21 |
| apw | (the userspace) | 15:21 |
| apw | so it maybe triggered by that, so as i say, lets get a WI to investigate if we can mine launchpad bugs for S to get stats or not | 15:21 |
| cjwatson | indeed, on server images dmraid should generally only be installed if dmraid is actually in use | 15:22 |
| cjwatson | I suspect kernel engineers are outliers :-) | 15:22 |
| apw | (yeah as i say assume it is me fiddling on this issue which has gotten me here) | 15:22 |
| apw | and lets investigate | 15:22 |
| * apw sends some large vicious looking people to visit with xnox | 15:23 | |
| xnox | cjwatson: thanks. | 15:23 |
| xnox | apw: =)))) | 15:23 |
| xnox | apw: if they come with harddrives and motherboards that's fine. | 15:23 |
| apw | xnox, doesn't that depend if the failure mode is "not boot" or "eats my data" | 15:25 |
| apw | smb, are you going to be investigating if you can back the old userspace with the builtin mdadm targets instead ? | 15:26 |
| smb | apw, that might be a plan b I guess | 15:27 |
| cjwatson | I suspect that the grub2 transition should not be regarded as a model here | 15:27 |
| smb | hm better than not working | 15:27 |
| apw | smb, if it makes sense, maybe we should at least evaluate it | 15:28 |
| smb | apw, agree | 15:28 |
| arges-uds | Are there going to kernel config changes? or will dm raid still be built as modules? | 15:28 |
| xnox | arges-uds: still build modules by the looks of it for dm-raid. | 15:29 |
| apw | arges-uds, that will depend if we are able to map the dmraid userspace to the new ones | 15:30 |
| smb | arges-uds, there is dm-raid and dm-raid45 | 15:30 |
| smb | the latter is the special one we want to drop | 15:30 |
| arges-uds | ok gotcha | 15:30 |
| arges-uds | now finally get the video response | 15:31 |
| arges-uds | : ) | 15:31 |
| xnox | cjwatson: so far I have been told to do a clean switchover, without a fallback (for intel raids, and ddf) | 15:31 |
| apw | there is quite some lag, not the 7s jono suggested | 15:31 |
| slangasek | how much? | 15:34 |
| apw | xnox, there is a middle case, were might be able to back the dmraid (non-intel) using 'dm raid' not 'dm raid4-5' on the kernel side | 15:34 |
| apw | slangasek, feels more like 30s at least | 15:34 |
| slangasek | hmm :/ | 15:34 |
| slangasek | lag on IRC> yes, people should just join the hangout instead :) | 15:35 |
| apw | i suspect the lag is proporionate to the distanve between the originator and viewer | 15:35 |
| apw | slangasek, heh, maybe so but they are doing just fine over there | 15:35 |
| stgraber | we definitely still have room in the hangout, so just join :) | 15:35 |
| apw | xnox, we have a WI for that now already | 15:36 |
| apw | smb, only need that if we have to move people up to 14.04 on 12.04 and that breaks them | 15:38 |
| smb | apw, ERrm /me fails to parse | 15:39 |
| cjwatson | well ... if people aren't used to having to use UUIDs by now ... | 15:39 |
| cjwatson | but yeah, a quick safety check wouldn't hurt | 15:39 |
| apw | 14.04 will replace all the lts-backport kernels on 12.04 | 15:39 |
| cjwatson | xnox: I wouldn't say it happened without *any* bugs :-) | 15:40 |
| apw | we need to not break that | 15:40 |
| cjwatson | But they should be shaken out by now, given it was, er, edgy or so? | 15:40 |
| smb | apw, Ah ok... So if t kernel has no dm-raid45 we have to backport the new dmraid (or partions of) | 15:40 |
| apw | smb, that indeed | 15:40 |
| apw | so it might be easier to make dm-raid45 work here you never know | 15:41 |
| * smb grubles | 15:41 | |
| apw | not that we shouldn't migrate people non the less on real 14.04 regardless | 15:41 |
| xnox | cjwatson: =)))) you are the first one to mention there actually were bugs with that upgrade. (/dev/sda1->UUID) | 15:41 |
| apw | smb, for us to discuss now we know the issues | 15:41 |
| smb | yup | 15:42 |
| * apw likes the idea of mapping over, if that works on all kernels back to P's on P | 15:42 | |
| * apw slaps self for rath | 15:42 | |
| * apw slaps self for ratholing | 15:42 | |
| cjwatson | xnox: Don't get me wrong, considering its complexity it went remarkably well | 15:42 |
| xnox | ok. | 15:42 |
| apw | smb, yeah we should likely only have the module enabled in the lts-backport-trusty and _not_ in the real 14.04 kernel | 15:44 |
| apw | if we are forced to have it for that kernel | 15:45 |
| apw | (the module == dmraid4-5) | 15:45 |
| apw | to prevent 14.04 having the same problem | 15:46 |
| apw | slangasek, we normally do them 3-4 weeks after, but not recommending htem to the first point release | 15:46 |
| slangasek | ok | 15:49 |
| slangasek | ah, actually 15 minutes to the next session | 15:50 |
| smb | Great, enough time to go downstairs to the coffee machine | 15:51 |
| pitti | slangasek: are you driving the TRIM hangout? | 15:58 |
| slangasek | pitti: ogasawara is | 15:58 |
| pitti | ogasawara: probably easiest to just put the URL here? | 15:59 |
| ogasawara | pitti: you have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en | 15:59 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Enable automatic trimming of SSD drives | Url: http://summit.ubuntu.com/uds-1311/meeting/21974/core-1311-ssd-trimming/ | ||
| ogasawara | stgraber: https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en | 16:02 |
| pitti | stgraber, ogra_, xnox: ^ if you want to join | 16:02 |
| ogra_ | pitti, i cant, running the bootsplash session myself next door | 16:03 |
| pitti | ogra_: just FYI, not critical | 16:03 |
| xnox | pitti: i'm joining encryption session. | 16:03 |
| xnox | pitti: i think we are mostly aligned on the topic - i.e. cron it. | 16:03 |
| pitti | xnox: ack, thanks | 16:03 |
| arges | i can see video | 16:05 |
| chiluk | so I disagree with using fstrim | 16:10 |
| chiluk | I think we should be using discard. | 16:10 |
| chiluk | from the benchmarks I've seen that discard does not actually trim in real time, but marks blocks for later trimming | 16:11 |
| chiluk | https://patrick-nagel.net/blog/archives/337 | 16:11 |
| chiluk | apw we the statistics I see are that discard does not affect writes because of caching in the vfs layer | 16:14 |
| apw | chiluk, come join | 16:14 |
| xnox | all other core sessions finished =) | 16:49 |
| xnox | o/ | 16:49 |
| xnox | terrible lag on the video | 16:53 |
| stgraber | xnox: so I think slangasek expressed an interest for that mountall workitem in the past, so it's probably worth discussing this with him | 16:53 |
| stgraber | xnox: basically the plan is to have mountall remount any mounted fs where the existing flags don't match what's listed in /etc/fstab | 16:53 |
| chiluk | I just realized something. | 16:53 |
| xnox | stgraber: why wouldn't they? | 16:53 |
| stgraber | xnox: and in the case of /, we'd want to only do a single remount, so have any missing flag added at the same time we remount it rw | 16:54 |
| xnox | stgraber: mountall reads /etc/fstab in the initramfs case. | 16:54 |
| chiluk | for phone it may be beneficial to only run fstrim when plugged in | 16:54 |
| chiluk | pitti, ^^ | 16:54 |
| stgraber | xnox: I believe we at least had the case of /dev/pts not having matching mount options and that's what triggered that discussion originally | 16:54 |
| pitti | chiluk: same for laptop actually, but it's a trade off | 16:55 |
| pitti | chiluk: you could easily miss a few cron cycles if you mostly run on battery | 16:55 |
| chiluk | I still like discard better for normal use. | 16:55 |
| xnox | stgraber: it was non-matching in initramfs-less case as I far as I remember (and hence things breaking for infinity and his powerpc machines), but yeah in the initramfs-less case /root will have wrong/non-matching flags. | 16:55 |
| stgraber | chiluk: well, phones will run with discard, so fstrim will be a very fast noop there anyway | 16:55 |
| pitti | chiluk: and of course we cannot control this at all with discard, which we already agreed to on the phone.. | 16:55 |
| stgraber | xnox: ah yeah, that could have been. | 16:56 |
| xnox | stgraber: pitti: did you agree for discard mount option on the desktop as well ? | 16:56 |
| stgraber | xnox: no, we agreed on it for the phone. For desktop it's pending benchmarking by cking | 16:56 |
| xnox | stgraber: ok. cool. | 16:56 |
| pitti | xnox: right; chiluk brought up that it might not actually be synchronous any more on current kernels | 16:57 |
| xnox | pitti: nice =) | 16:57 |
| chiluk | yeah I'm fairly certain the discards get cached in the vfs like everything else. | 16:57 |
| chiluk | at least that's what the benchmarks I've seen imply. | 16:57 |
| pitti | chiluk: still a bit sceptical; http://goo.gl/1mdjzl benchmarks show 25% penalty on a "compile" test case | 16:58 |
| pitti | (which would create and remove lots of small temp files) | 16:59 |
| pitti | but then again I don't trust this benchmark much | 16:59 |
| pitti | many numbers are very implausible | 16:59 |
| xnox | pitti: what are typical phone usage patters? write only, delete occasionally. | 17:00 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html | ||
| pitti | xnox: yeah, deletion mostly for downloads/browsing, I suppose | 17:00 |
| xnox | right, all the media / streaming caches. | 17:01 |
| pitti | xnox: but in general you write a lot less on the phone, so keeping it "always clean" on small file systems which are mostly full is the more pressing concern there | 17:01 |
| xnox | pitti: well, my laptop is ssd and I'm using "discard" mount option, and I haven't tried / compared with cronned fstrim. | 17:02 |
| pitti | xnox: that's the kind of benchmark we want to do | 17:02 |
| xnox | so far i am happy, but it is nowhere near full (disk uage) | 17:02 |
| pitti | xnox: i. e. delete with lots of little, and a big file, with and without discard | 17:02 |
| pitti | the discard overhead shouldn't really depend on how full the fs is? | 17:03 |
| pitti | the "do it once a week" performance certainly does | 17:03 |
| ogra_ | if you measure this on a phone, please take wakeups and battery usage into account | 17:03 |
| ogra_ | thats my only concern about doing it cronned | 17:04 |
| pitti | ogra_: that woudl rather be my concern about doing "discard", but yes | 17:04 |
| pitti | ogra_: but the summed workload should be the same | 17:05 |
| ogra_ | well, indeed, if discard can cause wakeups in sleep state that would be bad | 17:05 |
| pitti | in the end you need to trim all deleted blocks, either in one big chunk or in lots of little steps | 17:05 |
| ogra_ | i#m specifically talking about waking up from suspend to run the cron job | 17:05 |
| pitti | ogra_: no, it's pretty much tied to removing, which is already keeping the process and drive awake | 17:05 |
| ogra_ | if the device is fully on thats a no brainer | 17:05 |
| pitti | ogra_: but on the phone we already decided for "discard" anyway for other reasons | 17:06 |
| pitti | ogra_: the benchmark/question is only about desktops at this point | 17:06 |
| ogra_ | on arm the system can simply wake only parts of the peripherial devices ... if cron kicks in (the clock is always on on arm) it might cause a wakeup on the lower system level to just do the removing | 17:06 |
| ogra_ | ah, k | 17:07 |
| ogra_ | (sorry, didnt follow the session, if discard is set by default thats fine) | 17:07 |
| slangasek | stgraber, xnox: mountall> there's an open bug report on mountall about this | 17:12 |
| pitti | can't find ^ right now | 17:17 |
| pitti | I looked at some with plausible titles, but they sounded different | 17:18 |
| jderose | is this the correct room for "Enable automatic trimming of SSD drives"? | 17:21 |
| ogra_ | jderose, it was ... for the last hour | 17:22 |
| pitti | jderose: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming has the session notes and WIs | 17:22 |
| jderose | ah, oops, guess i'm watching the recording :P | 17:22 |
| jderose | pitti: FYI, System76 has been working toward enabling discard on imaging time. in our experience, on modern SSDs, there is very little overhead to discard. deletes are slower, but deletes are extremely fast anyway. So personally, we're leaning toward discard over cron + fstrim | 17:24 |
| jderose | although on some older ssds, discard is very expensive | 17:24 |
| jderose | (some anyway) | 17:24 |
| xnox | jderose: cool, thanks for input. | 17:25 |
| pitti | jderose: thanks | 17:25 |
| xnox | jderose: i believe discard is now available in d-i, thus one can preseed discard already today, i think. | 17:26 |
| pitti | xnox, stgraber, chiluk: something crossed my mind: on upgrades, when we alter fstab, we should probably call fstrim once | 17:26 |
| jderose | xnox: gotcha, but we don't need it. we have very flexible imaging software :) | 17:26 |
| pitti | otherwise we won't trim the already existing free blocks, just the future ones | 17:27 |
| pitti | ^ added to BP | 17:28 |
| stgraber | pitti: yep, that makes sense | 17:28 |
| xnox | pitti: well one wants to run fstrim on first reboot once the file system is mounted with discard. | 17:36 |
| pitti | xnox: self-destroying upstart job? (eww) | 17:37 |
| pitti | xnox: perhaps better let the cron job do that? | 17:37 |
| xnox | jderose: is it open sourced? | 17:38 |
| jderose | i'm still listening to the recording, but this point was just raised: that using discard can be a better choice when an ssd in fairly full, so that you don't have inconsistent performance (degrading performance through the week till fstrim is run). this is another reason that System76 is leading toward discard | 17:38 |
| xnox | pitti: hm. well we can leave a flag file (similar to reboot flag) and clear it once we successfully fstrimmed. | 17:38 |
| pitti | xnox: right; the cron job could watch for that? | 17:39 |
| jderose | xnox: no, it's not. i'm not the man who writes the paychecks, not my call :P | 17:39 |
| xnox | pitti: yeah, and it would be @reboot type of job. | 17:41 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Cgroup manager for LXC | Url: http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/ | ||
| cjwatson | xnox: discard> well - except that when I tried to SRU-QA that I found that it was broken | 17:57 |
| cjwatson | xnox: I've been waiting for git.d.o to come back so that I can check whether it's fixed in Debian and if not fix it there | 17:57 |
| cjwatson | (It's definitely on my plate) | 17:57 |
| xnox | cjwatson: well mjt wrote a perl script to re-assembled the raid array, so all data is restored. last time I looked it was getting rsynced to a new VM. | 17:58 |
| xnox | (literarly looking up bad blocks from the kicked out drive and doing writes) | 17:59 |
| cjwatson | xnox: Yeah, I'm following #alioth too :-) | 18:00 |
| xnox | cjwatson: s/git.debian.org/moszumanska.debian.org/ fetches d-i repositories for me =) | 18:01 |
| cjwatson | xnox: I'm not touching the new host (even "read-only", which will probably in practice generate some writes) until they say it's OK, in case I disturb the recovery process | 18:01 |
| cjwatson | I'd advise doing the same ... | 18:01 |
| xnox | ok. | 18:01 |
| chiluk | pitti, that makes sense, although you need to be careful on which side of the reboot that happens | 18:02 |
| stgraber | slangasek, ogasawara: which of you is start the hangout? | 18:02 |
| stgraber | *starting | 18:02 |
| ogasawara | stgraber: slangasek is | 18:02 |
| cjwatson | Even though I am itching to push stuff | 18:02 |
| slangasek | https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas | 18:04 |
| pitti | stgraber: would this by any chance be compatible to systemd's cgroup handler/service? that would unblock us being stuck at v204 (and at any rate, with this we would need to port logind 204 to that new service) | 18:11 |
| depp | systemd's cgroup implementation is perfectly stackable | 18:15 |
| depp | systemd runs fine inside of containers | 18:15 |
| pitti | stgraber: ^ I added notes to the pad | 18:16 |
| depp | so, you haven't looked at the api but claim it "wasn't flexible" enough? | 18:16 |
| depp | are you aware that libcgroup is not maintained anymore upstream at RH? | 18:17 |
| hallyn_ | depp: yes, we are. the cgroup daemon in libcgroup was unworkably racy | 18:17 |
| depp | hallyn_: and now you want to make use of libcgroup nonetheless? | 18:17 |
| depp | are you aware that dbus just uses a UNIX socket too? you could just create one of those and mount it into the container, too | 18:18 |
| apw | depp, you should join the hangout | 18:18 |
| slangasek | https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas | 18:19 |
| xnox | .. | 18:19 |
| hallyn_ | depp: only of some of the userspace commands, and we're not sure. actually lmctfy is what i was going to leverage | 18:19 |
| xnox | dbus supports starting private socket. and let your apps talk to you via private socket. | 18:19 |
| xnox | .. | 18:19 |
| xnox | without actually having a session/system dbus. | 18:19 |
| xnox | .. | 18:19 |
| depp | upstart itself even uses a private dbus socket... | 18:19 |
| xnox | even an annonymous one. | 18:20 |
| depp | are you aware that there are no real linux implementations that could run inside a container that doesn't come with libdbus anyway? | 18:20 |
| depp | because dbus is based on unix sockets, it can do *anything* unix sockets can do, as good and well as any other IPC... | 18:21 |
| stgraber | depp: I have a whole lot of users running minimal busybox based environment who'd beg to differ | 18:21 |
| pitti | stgraber: you want to have cgroup management tools in that environment, but not libdbus? | 18:22 |
| slangasek | pitti: I don't think that's the argument | 18:22 |
| apw | pitti, he wants to be able to pass it into a container, and that pass it to a second container which consumes it, without the intermediate needing anything including libdbus | 18:23 |
| pitti | stgraber: but in either case, it seems that our systemd-shim could take the org.freedesktop.systemd1.StartTransientUnit call on D-BUS and translate it to our service, so we'd be back to being compatible | 18:23 |
| depp | sooo, you want to come to a conclusion here, admit that you have neither looked at systemd's cgroup stuff, nor on the google thing, do not have any idea about dbus? how's that going to work? | 18:23 |
| pitti | apw: ack | 18:24 |
| stgraber | pitti: yes, that's what I suggested earlier, having a small dbus service that just wraps our generic API to systemd's, then logind could just use that | 18:25 |
| pitti | stgraber: right, we have that already for suspend/reboot/etc. | 18:25 |
| pitti | stgraber: great | 18:25 |
| pitti | meh, pad seems down | 18:25 |
| slangasek | yep :/ | 18:25 |
| * apw pokes people | 18:27 | |
| hallyn_ | depp: have looked at lmctfy; systemd has told us at plumbers directly that only one pid on host should control cgroups. please write more concisely what exactly you're advocating for. we're just gathering reuirements and options here. | 18:32 |
| hallyn_ | (last time i looked deeply into dbus, it had a bad bug in how it passed lsm creds; fixed that, but it did not inspire confidence) | 18:32 |
| slangasek | hallyn_: if we're using a private socket, should all be fine | 18:33 |
| hallyn_ | slangasek: yeah i'm pretty sure i followed up at the time (2010) to get the bug fixed :) | 18:41 |
| slangasek | heh | 18:41 |
| depp | what about devices that come and go, whose major/minor need to be updated in the cgroup properties? afaik google doesn't do dynamic devices... | 18:46 |
| depp | what about propagation between groups? any thoughts on that? | 18:46 |
| slangasek | depp: I don't understand your question. the major/minor of any given device is fixed, even if the device node comes and goes; the only exception to this is within containers themselves, where lxc diverts console devices | 18:49 |
| depp | slangasek: the major/minor changes on each plug, you cannot use it for configuration | 18:51 |
| slangasek | the major/minor changes only if the device name also changes | 18:51 |
| hallyn_ | that's related to what Michael Warfield is working on for lxc. | 18:51 |
| depp | slangasek: that is non-sense, sorry, that's now how it works. the kernel just allocates the lowest free minor for most devices these days | 18:51 |
| slangasek | yes, and the device *name* reflects the major/minor | 18:52 |
| hallyn_ | (well that dpeends on udev rules :) | 18:53 |
| slangasek | but if the concern is for devices that don't have persistent names, then sure, that's back to what hallyn_ says that Michael is working on this | 18:53 |
| pitti | hallyn_: no, udev rules don't set/change device names | 18:56 |
| hallyn_ | pitti: they soon might :) | 18:57 |
| pitti | hallyn_: ?? | 18:57 |
| hallyn_ | pitti: udev rules may fire and link devices into /dev/.lxc/$container | 18:57 |
| hallyn_ | pitti: that's part of what Michael is working on | 18:57 |
| pitti | hallyn_: well, links, yes, but not names; the kernel defines device names | 18:57 |
| hallyn_ | pitti: eh, the kernel wants to tell me that it defines devices names but that i can't rely on them. so i don't care :) | 18:58 |
| pitti | hallyn_: the "rely" part are persistent symlinks :) (and we've had them for ages) | 18:58 |
| pitti | but yes, in general device names are pretty uninteresting in most cases | 18:58 |
| pitti | (for storage, USB, etc.) | 18:59 |
| hallyn_ | pitti: the specific problem Michael has is a 4-port (or so) serial board, | 18:59 |
| hallyn_ | where the specific ports are randomly assigned at boot, apparently | 18:59 |
| hallyn_ | lunch - \o | 18:59 |
| pitti | lunch, too; thanks guys! | 19:00 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Discuss reconciling the Qt requirements for Ubuntu vs. Kubuntu | Url: http://summit.ubuntu.com/uds-1311/meeting/21986/core-1311-qt5-versions-in-ubuntu/ | ||
| janimo | no video yet for the Qt session? | 19:04 |
| Mirv | shoud be in 1min (starts :05), but no idea yet | 19:05 |
| * sil2100 is waiting as well | 19:05 | |
| slangasek | https://plus.google.com/hangouts/_/72cpjem29pg1ifaht4etlvkqc0 | 19:06 |
| slangasek | come one, come all | 19:06 |
| Mirv | Kubuntu people? | 19:08 |
| pmcgowan | proposal is Qt 5.2 | 19:11 |
| Mirv | Saviq: joining? | 19:15 |
| sil2100 | Saviq: ping! Can you join? | 19:15 |
| greyback | updated Qt version does not break public API or ABI, only the private stuff | 19:15 |
| mzanetti | Mirv: unity uses some internal headers from qtdeclarative. not too much but we have a couple of patches to do on every upgrade. | 19:16 |
| rsalveti | greyback: only private in the 5.x series? | 19:16 |
| greyback | rsalveti: yes. There's no api guarantee with private stuff. But public has | 19:17 |
| rsalveti | right, then we need to reduce that | 19:18 |
| Mirv | mzanetti: ah, ok | 19:18 |
| Mirv | and sorry, the hangout toolbox not starting for me so I don't have a name tag | 19:19 |
| sergiusens | slangasek, add an action item to add the action item on the other session :-) | 19:49 |
| * sergiusens jokes | 19:49 | |
| xnox | sergiusens: -EJOKERAISED | 19:49 |
| === ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!