#ubuntu-uds-core-2 2013-11-19 <cjohnston> asac can you please op me in both -core- channels <slangasek> https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo <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) <cjohnston> tsimpson-uds: ping <slangasek> stgraber: https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo <xnox> blueprint URL: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-dmraid2mdadm <xnox> pad URL: http://pad.ubuntu.com/uds-1311-core-1311-dmraid2mdadm <tsimpson-uds> cjohnston: \o <cjohnston> tsimpson-uds: do you run udsbot ? <tsimpson-uds> yep <cjohnston> tsimpson-uds: can you please have it join -core-1 -core-2 and -design-1 <tsimpson-uds> cjohnston: I can, but it won't do much without some chanserv magic <cjohnston> tsimpson-uds: I did it in -design-1 I'm waiting to do it in here <asac> cjohnston: let me know iif its good <slangasek> "Almost British"> lol <cjohnston> ta <asac> anyone else? <cjohnston> nope <apw> xnox, you are visible here <arges-uds> is the video live <apw> arges-uds, t'is for me * 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 <apw> smb, i assume it does not work at all right now even, so someone has to fix it if we can <apw> dm_raid45 76611 0 <apw> it seems to be loaded on my non dm-raid45 system <stgraber> that's unfortunate, would have been nice to get some stats... <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 <smb> apw, Do you have dmraid installed <smb> (the user-space) <apw> smb, i would assume so indeed <apw> smb, yes i do <apw> (the userspace) <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 <cjwatson> indeed, on server images dmraid should generally only be installed if dmraid is actually in use <cjwatson> I suspect kernel engineers are outliers :-) <apw> (yeah as i say assume it is me fiddling on this issue which has gotten me here) <apw> and lets investigate * apw sends some large vicious looking people to visit with xnox <xnox> cjwatson: thanks. <xnox> apw: =)))) <xnox> apw: if they come with harddrives and motherboards that's fine. <apw> xnox, doesn't that depend if the failure mode is "not boot" or "eats my data" <apw> smb, are you going to be investigating if you can back the old userspace with the builtin mdadm targets instead ? <smb> apw, that might be a plan b I guess <cjwatson> I suspect that the grub2 transition should not be regarded as a model here <smb> hm better than not working <apw> smb, if it makes sense, maybe we should at least evaluate it <smb> apw, agree <arges-uds> Are there going to kernel config changes? or will dm raid still be built as modules? <xnox> arges-uds: still build modules by the looks of it for dm-raid. <apw> arges-uds, that will depend if we are able to map the dmraid userspace to the new ones <smb> arges-uds, there is dm-raid and dm-raid45 <smb> the latter is the special one we want to drop <arges-uds> ok gotcha <arges-uds> now finally get the video response <arges-uds> : ) <xnox> cjwatson: so far I have been told to do a clean switchover, without a fallback (for intel raids, and ddf) <apw> there is quite some lag, not the 7s jono suggested <slangasek> how much? <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 <apw> slangasek, feels more like 30s at least <slangasek> hmm :/ <slangasek> lag on IRC> yes, people should just join the hangout instead :) <apw> i suspect the lag is proporionate to the distanve between the originator and viewer <apw> slangasek, heh, maybe so but they are doing just fine over there <stgraber> we definitely still have room in the hangout, so just join :) <apw> xnox, we have a WI for that now already <apw> smb, only need that if we have to move people up to 14.04 on 12.04 and that breaks them <smb> apw, ERrm /me fails to parse <cjwatson> well ... if people aren't used to having to use UUIDs by now ... <cjwatson> but yeah, a quick safety check wouldn't hurt <apw> 14.04 will replace all the lts-backport kernels on 12.04 <cjwatson> xnox: I wouldn't say it happened without *any* bugs :-) <apw> we need to not break that <cjwatson> But they should be shaken out by now, given it was, er, edgy or so? <smb> apw, Ah ok... So if t kernel has no dm-raid45 we have to backport the new dmraid (or partions of) <apw> smb, that indeed <apw> so it might be easier to make dm-raid45 work here you never know * smb grubles <apw> not that we shouldn't migrate people non the less on real 14.04 regardless <xnox> cjwatson: =)))) you are the first one to mention there actually were bugs with that upgrade. (/dev/sda1->UUID) <apw> smb, for us to discuss now we know the issues <smb> yup * apw likes the idea of mapping over, if that works on all kernels back to P's on P * apw slaps self for rath * apw slaps self for ratholing <cjwatson> xnox: Don't get me wrong, considering its complexity it went remarkably well <xnox> ok. <apw> smb, yeah we should likely only have the module enabled in the lts-backport-trusty and _not_ in the real 14.04 kernel <apw> if we are forced to have it for that kernel <apw> (the module == dmraid4-5) <apw> to prevent 14.04 having the same problem <apw> slangasek, we normally do them 3-4 weeks after, but not recommending htem to the first point release <slangasek> ok <slangasek> ah, actually 15 minutes to the next session <smb> Great, enough time to go downstairs to the coffee machine <pitti> slangasek: are you driving the TRIM hangout? <slangasek> pitti: ogasawara is <pitti> ogasawara: probably easiest to just put the URL here? <ogasawara> pitti: you have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en * 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 <pitti> stgraber, ogra_, xnox: ^ if you want to join <ogra_> pitti, i cant, running the bootsplash session myself next door <pitti> ogra_: just FYI, not critical <xnox> pitti: i'm joining encryption session. <xnox> pitti: i think we are mostly aligned on the topic - i.e. cron it. <pitti> xnox: ack, thanks <arges> i can see video <chiluk> so I disagree with using fstrim <chiluk> I think we should be using discard. <chiluk> from the benchmarks I've seen that discard does not actually trim in real time, but marks blocks for later trimming <chiluk> https://patrick-nagel.net/blog/archives/337 <chiluk> apw we the statistics I see are that discard does not affect writes because of caching in the vfs layer <apw> chiluk, come join <xnox> all other core sessions finished =) <xnox> o/ <xnox> terrible lag on the video <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 <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 <chiluk> I just realized something. <xnox> stgraber: why wouldn't they? <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 <xnox> stgraber: mountall reads /etc/fstab in the initramfs case. <chiluk> for phone it may be beneficial to only run fstrim when plugged in <chiluk> pitti, ^^ <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 <pitti> chiluk: same for laptop actually, but it's a trade off <pitti> chiluk: you could easily miss a few cron cycles if you mostly run on battery <chiluk> I still like discard better for normal use. <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. <stgraber> chiluk: well, phones will run with discard, so fstrim will be a very fast noop there anyway <pitti> chiluk: and of course we cannot control this at all with discard, which we already agreed to on the phone.. <stgraber> xnox: ah yeah, that could have been. <xnox> stgraber: pitti: did you agree for discard mount option on the desktop as well ? <stgraber> xnox: no, we agreed on it for the phone. For desktop it's pending benchmarking by cking <xnox> stgraber: ok. cool. <pitti> xnox: right; chiluk brought up that it might not actually be synchronous any more on current kernels <xnox> pitti: nice =) <chiluk> yeah I'm fairly certain the discards get cached in the vfs like everything else. <chiluk> at least that's what the benchmarks I've seen imply. <pitti> chiluk: still a bit sceptical; http://goo.gl/1mdjzl benchmarks show 25% penalty on a "compile" test case <pitti> (which would create and remove lots of small temp files) <pitti> but then again I don't trust this benchmark much <pitti> many numbers are very implausible <xnox> pitti: what are typical phone usage patters? write only, delete occasionally. * 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 <xnox> right, all the media / streaming caches. <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 <xnox> pitti: well, my laptop is ssd and I'm using "discard" mount option, and I haven't tried / compared with cronned fstrim. <pitti> xnox: that's the kind of benchmark we want to do <xnox> so far i am happy, but it is nowhere near full (disk uage) <pitti> xnox: i. e. delete with lots of little, and a big file, with and without discard <pitti> the discard overhead shouldn't really depend on how full the fs is? <pitti> the "do it once a week" performance certainly does <ogra_> if you measure this on a phone, please take wakeups and battery usage into account <ogra_> thats my only concern about doing it cronned <pitti> ogra_: that woudl rather be my concern about doing "discard", but yes <pitti> ogra_: but the summed workload should be the same <ogra_> well, indeed, if discard can cause wakeups in sleep state that would be bad <pitti> in the end you need to trim all deleted blocks, either in one big chunk or in lots of little steps <ogra_> i#m specifically talking about waking up from suspend to run the cron job <pitti> ogra_: no, it's pretty much tied to removing, which is already keeping the process and drive awake <ogra_> if the device is fully on thats a no brainer <pitti> ogra_: but on the phone we already decided for "discard" anyway for other reasons <pitti> ogra_: the benchmark/question is only about desktops at this point <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 <ogra_> ah, k <ogra_> (sorry, didnt follow the session, if discard is set by default thats fine) <slangasek> stgraber, xnox: mountall> there's an open bug report on mountall about this <pitti> can't find ^ right now <pitti> I looked at some with plausible titles, but they sounded different <jderose> is this the correct room for "Enable automatic trimming of SSD drives"? <ogra_> jderose, it was ... for the last hour <pitti> jderose: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming has the session notes and WIs <jderose> ah, oops, guess i'm watching the recording :P <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 <jderose> although on some older ssds, discard is very expensive <jderose> (some anyway) <xnox> jderose: cool, thanks for input. <pitti> jderose: thanks <xnox> jderose: i believe discard is now available in d-i, thus one can preseed discard already today, i think. <pitti> xnox, stgraber, chiluk: something crossed my mind: on upgrades, when we alter fstab, we should probably call fstrim once <jderose> xnox: gotcha, but we don't need it. we have very flexible imaging software :) <pitti> otherwise we won't trim the already existing free blocks, just the future ones <pitti> ^ added to BP <stgraber> pitti: yep, that makes sense <xnox> pitti: well one wants to run fstrim on first reboot once the file system is mounted with discard. <pitti> xnox: self-destroying upstart job? (eww) <pitti> xnox: perhaps better let the cron job do that? <xnox> jderose: is it open sourced? <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 <xnox> pitti: hm. well we can leave a flag file (similar to reboot flag) and clear it once we successfully fstrimmed. <pitti> xnox: right; the cron job could watch for that? <jderose> xnox: no, it's not. i'm not the man who writes the paychecks, not my call :P <xnox> pitti: yeah, and it would be @reboot type of job. * 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 <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 <cjwatson> (It's definitely on my plate) <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. <xnox> (literarly looking up bad blocks from the kicked out drive and doing writes) <cjwatson> xnox: Yeah, I'm following #alioth too :-) <xnox> cjwatson: s/git.debian.org/moszumanska.debian.org/ fetches d-i repositories for me =) <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 <cjwatson> I'd advise doing the same ... <xnox> ok. <chiluk> pitti, that makes sense, although you need to be careful on which side of the reboot that happens <stgraber> slangasek, ogasawara: which of you is start the hangout? <stgraber> *starting <ogasawara> stgraber: slangasek is <cjwatson> Even though I am itching to push stuff <slangasek> https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas <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) <depp> systemd's cgroup implementation is perfectly stackable <depp> systemd runs fine inside of containers <pitti> stgraber: ^ I added notes to the pad <depp> so, you haven't looked at the api but claim it "wasn't flexible" enough? <depp> are you aware that libcgroup is not maintained anymore upstream at RH? <hallyn_> depp: yes, we are. the cgroup daemon in libcgroup was unworkably racy <depp> hallyn_: and now you want to make use of libcgroup nonetheless? <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 <apw> depp, you should join the hangout <slangasek> https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas <xnox> .. <hallyn_> depp: only of some of the userspace commands, and we're not sure. actually lmctfy is what i was going to leverage <xnox> dbus supports starting private socket. and let your apps talk to you via private socket. <xnox> .. <xnox> without actually having a session/system dbus. <xnox> .. <depp> upstart itself even uses a private dbus socket... <xnox> even an annonymous one. <depp> are you aware that there are no real linux implementations that could run inside a container that doesn't come with libdbus anyway? <depp> because dbus is based on unix sockets, it can do *anything* unix sockets can do, as good and well as any other IPC... <stgraber> depp: I have a whole lot of users running minimal busybox based environment who'd beg to differ <pitti> stgraber: you want to have cgroup management tools in that environment, but not libdbus? <slangasek> pitti: I don't think that's the argument <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 <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 <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? <pitti> apw: ack <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 <pitti> stgraber: right, we have that already for suspend/reboot/etc. <pitti> stgraber: great <pitti> meh, pad seems down <slangasek> yep :/ * apw pokes people <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. <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) <slangasek> hallyn_: if we're using a private socket, should all be fine <hallyn_> slangasek: yeah i'm pretty sure i followed up at the time (2010) to get the bug fixed :) <slangasek> heh <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... <depp> what about propagation between groups? any thoughts on that? <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 <depp> slangasek: the major/minor changes on each plug, you cannot use it for configuration <slangasek> the major/minor changes only if the device name also changes <hallyn_> that's related to what Michael Warfield is working on for lxc. <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 <slangasek> yes, and the device *name* reflects the major/minor <hallyn_> (well that dpeends on udev rules :) <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 <pitti> hallyn_: no, udev rules don't set/change device names <hallyn_> pitti: they soon might :) <pitti> hallyn_: ?? <hallyn_> pitti: udev rules may fire and link devices into /dev/.lxc/$container <hallyn_> pitti: that's part of what Michael is working on <pitti> hallyn_: well, links, yes, but not names; the kernel defines device names <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 :) <pitti> hallyn_: the "rely" part are persistent symlinks :) (and we've had them for ages) <pitti> but yes, in general device names are pretty uninteresting in most cases <pitti> (for storage, USB, etc.) <hallyn_> pitti: the specific problem Michael has is a 4-port (or so) serial board, <hallyn_> where the specific ports are randomly assigned at boot, apparently <hallyn_> lunch - \o <pitti> lunch, too; thanks guys! * 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? <Mirv> shoud be in 1min (starts :05), but no idea yet * sil2100 is waiting as well <slangasek> https://plus.google.com/hangouts/_/72cpjem29pg1ifaht4etlvkqc0 <slangasek> come one, come all <Mirv> Kubuntu people? <pmcgowan> proposal is Qt 5.2 <Mirv> Saviq: joining? <sil2100> Saviq: ping! Can you join? <greyback> updated Qt version does not break public API or ABI, only the private stuff <mzanetti> Mirv: unity uses some internal headers from qtdeclarative. not too much but we have a couple of patches to do on every upgrade. <rsalveti> greyback: only private in the 5.x series? <greyback> rsalveti: yes. There's no api guarantee with private stuff. But public has <rsalveti> right, then we need to reduce that <Mirv> mzanetti: ah, ok <Mirv> and sorry, the hangout toolbox not starting for me so I don't have a name tag <sergiusens> slangasek, add an action item to add the action item on the other session :-) * sergiusens jokes <xnox> sergiusens: -EJOKERAISED * 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 #ubuntu-uds-core-2 2013-11-20 * 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/20/%23ubuntu-uds-core-2.html * ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Improve the cross-compilation story for Ubuntu Touch by 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21991/core-1311-cross-compilation/ <slangasek> https://plus.google.com/hangouts/_/7ecpj1uhgvnl346mfisfouopu0 <dholbach> did anyone press the "go live" button already? :) <slangasek> no <apw> feels like not here <slangasek> we're missing doko, trying to decide if it's worth having the session for :) <pitti> slangasek: he pinged me half an hour ago, he's on crappy mobile network <slangasek> ok <pitti> not good enough for hangouts <slangasek> not even audio? <pitti> I don't know <pitti> he said "let's see.." <apw> slangasek, we can see you <pmcgowan> hear you <Saviq> \o/ <pbass> we see you * xnox runs off to find my 2fa token. <doko> slangasek, I'm online, lets see how this works out ... <slangasek> doko: ok - https://plus.google.com/hangouts/_/7ecpj1uhgvnl346mfisfouopu0 if you can; I was looking to see if we could call you to bridge you in, but hangouts have hidden the button again <apw> xnox, is there any reason mako cannot use v4.6 as well if that is what is upstream <apw> xnox, we probabally only use that because v4.8 didn't work, and v4.7 did <cjwatson> There's already a 4.7 cross stack in the archive, so no reason to take that backward <apw> ok <cjwatson> gcc-4.7-arm-linux-gnueabihf - GNU C compiler <asac> do we know why they kept going with 4.6 on kernels? <asac> (dont need to address in hangout, just question for channel) <xnox> asac: e.g. goldfish gives kernel panic before it completes boot, when compiled with 4.7 or 4.8. <ogra_> i think maguro too <asac> right. but i am sure google could have fixed that easily if there were no other reasons for staying on 4.6 <apw> slangasek, can you add a WI for me to make that switch where needed <xnox> at the moment: all nexus kernels use 4.6, mako uses 4.7. <xnox> apw: done. <asac> e.g. i believe there might be good reasons... in particular if they use 4.7 for the userspace <slangasek> apw: which switch? to libiberty <asac> xnox: do they use 4.7 in userspace? or even 4.4? <ogra_> asac, 4.6 <xnox> asac: haven't checked recently, I believe there was a newer toolchain for kitkat, in user-space only. <xnox> asac: pre-kitkat is 4.6 <cjwatson> doko: (repeating from the hangout) binutils-dev already ships libiberty.a, so I don't quite get how it's an extra maintenance burden to just ship that as a separate binary package instead rather than duplicating the source - I guess I'm missing something? <asac> cjwatson: slangasek: talking about cross compiling kernels... any thoughts about allowing to cross compile kernels in PPAs? <ogra_> asac, for what ? to save 20min ? <lool> why dont I get a live stream of this session <cjwatson> Cross-PPA support is interesting - the trick is (maybe) limiting it to only things that would actually work so that people don't get a profoundly disappointing experience <asac> right <ogra_> lool, i do <lool> odd <cjwatson> My thoughts on this to date have been that it's better to focus on expanding the scope of things that we can cross-build so that it's less disappointing <lool> maybe I have too many streams open <doko> is there a way to turn off video in hangouts? <cjwatson> yes, there's a camera icon at the top that you can click <ogra_> doko, click the camera icon <cjwatson> or do you mean everyone else's video? <doko> the latter <pitti> turn bandwith usage down <ogra_> yeah <asac> lool: your computer doesnt like anything related to video streams... no hangouts, no yuoutube :) <pitti> in the "signal strenght" like slider <asac> etc. <ogra_> cjwatson, cant highbank do proper virtualization ? i thought it could ... i would rather see all PPAs get faster than having a list of pÃ¼ackages that can cross build in a PPA <lool> asac: :-) actually it was due to too many streams open (was trying to follow two other sessions) * asac wonders how lool can listen to multiple streams <asac> i can imagine two ... one for each ear <asac> everything else must also be hard for you to process <asac> hehe <ogra_> asac, 5:1 dolby surround ... <ogra_> 6 channels ;) <cjwatson> ogra_: I don't think highbank can, I think we're waiting for next-gen (A57 or similar) <ogra_> ah, ok <ogra_> i still think we should wait <ogra_> instead of having to maintain an artificially made up list <lool> asac: mute everything and listen i n2 minutes chunks :-) <rsalveti> xnox: I believe kitkat should be using 4.7/4.8 <cjwatson> I indeed don't think that a whitelist (or even blacklist) is a scaleable approach <rsalveti> but the kernel is still using that very old toolchain <ogra_> rsalveti, even the N5 one ? <rsalveti> ogra_: sorry, was thinking about the goldfish target (the one requiring 4.6) <ogra_> ah, good <ogra_> would be odd if hammerhead still used such an old kernel <pmcgowan> sounds good <mzanetti> I think app development would be mostly qmake <apw> did we just lose the feed, or si that me <mzanetti> apw: works here <mardy> and QBS! :-) <sergiusens> shouldn't the sdk should default to cmake for ubutnu touch projects? <mzanetti> thing is, qtcreator generates everything qmake for you. cmake is completely manually <cjwatson> qtcreator's under our control, at least partially <apw> firefox crashage, yay ... <mzanetti> cjwatson: well, we could extend qtcreator to properly support cmake, which sounds a lot to me tbh <mzanetti> fine with me personally. but it's more complex for app developers. <cjwatson> It might be more complex for the SDK team <slangasek> right <cjwatson> It should surely be invisible to app developers <slangasek> the SDK should DTRT <mardy> for app development QBS is easier, and it's probably going to be the build system better supported by QtCreator in the long term <cjwatson> (Unless they poke around at their build system) <mzanetti> cjwatson: no. it's never completely visible to the developer. <cjwatson> Is qmake == QBS? <mzanetti> err. completely invisible <mzanetti> QBS == QMake Build System <mzanetti> the new thing to come soonish <mardy> cjwatson: no, it's a new stuff, with a JSON/QML-like syntax <mzanetti> err.. QML Build system <cjwatson> Well, the reality is that right now we know how to make cmake support cross-building and we know that there are significant difficulties with qmake <cjwatson> Long-term I'd like to have all build systems cross-build-capable, but there's the matter of which we can do first <Saviq> https://bugreports.qt-project.org/browse/QTBUG-29987 <mardy> cjwatson: makes sense <cjwatson> (And upstream cross-build-capability isn't necessarily the same as it working properly for Ubuntu - non-multiarch cross-building can be significantly different if done badly) <dholbach> (qt4) and checkbox I think, but AFAIK that's being rewritten <Saviq> qbs == Qt Build Suite apparently <Saviq> http://qt-project.org/doc/qbs-1.1/index.html <mardy> cjwatson: but not all the stack is built with cmake <lool> cjwatson: and similarly we should start by cross-compiling the clicks that we include I guess <cjwatson> mardy: not all the stack is built with any one system :-) <cjwatson> mardy: so yes, I expect that fixing the whole stack will involve fixing multiple build systems <cjwatson> lool: perhaps, yeah <mardy> cjwatson: yep :-) <lool> sergiusens: ^ FYI on cross-compilation topic, we're thinking of testing/dogfooding the cross-compilation story with the builds of the preinstalled click <lool> s <cjwatson> which of those are arch-dep right now? <lool> at the moment we pull some prebuilt files from .debs <lool> so the actual builds are not arch-specific, except for the armhf debs they download <mzanetti> o/ <sergiusens> cjwatson, lool notes-app is the only one building that way <sergiusens> it's cmake based <lool> great * ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Upstart Roadmap for 14.04 LTS release | Url: http://summit.ubuntu.com/uds-1311/meeting/21977/core-1311-upstart-roadmap/ <slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970 <slangasek> jodh: ^^ <stgraber> xnox: coming? <zyga> live * slangasek waves <zyga> jodh: what are the small projects? * xnox o/ <slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970 <slangasek> I'm gonna keep repeating that until people join ;) <zyga> slangasek: topic it <zyga> what is the goal of using cgroups in upstart? <xnox> zyga: resource control. <slangasek> zyga: just like we support ulimits / chroot primitives, we should support cgroups * zyga needs to learn more about cgroups <apw> why can we not move the process to the cgroups after, i thought you could shift runnign things <apw> and if we have upstart running we have enough disk to make the cgroup mamanger startable directly rather than via a job <slangasek> apw: what do you mean, "directly"? <apw> slangasek, fork/exec it directly before parsing jobs <slangasek> hmm <apw> so it is part of upstart, but not killing upstart if it explodes <zyga> there is one more case to consider, what it there are no cgroups at all (or they are disabled for any reason) <zyga> the way cgroups are tied to jobs starting needs to address that <apw> yeah what if the kernel has no cgroup support ... <apw> slangasek, ^^ <zyga> but I agree that cgroup helper should be special so that state is consistent <zyga> and that there are no arbitrary periods of time after a jobi started before its cgroup profile is applied <zyga> s/i / is / <zyga> time bridge would be fantastic <zyga> "start 10 minutes after system-booted" <zyga> system-booted is just a job name <marrusl> killing stuck jobs. is that part of "refining ptrace handling" ? <slangasek> zyga: "arbitrary periods of time" - well, the only way to do that is to delay the boot until the cgroup manager is started <slangasek> marrusl: yes <marrusl> I am so happy. <zyga> slangasek: indeed <zyga> slangasek: my point is that that arbitrary period feels bad from a design perspective <gQuigs> and it would actually fix a bug that we don't know when to kill dbus which the X app exits over ssh <gQuigs> this bug: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434 <udsbotu> Launchpad bug 592434 in dbus (Ubuntu) "ssh -X user@machine hangs when using exit to terminate" [Low,Triaged] <gQuigs> re: track user SSH sessions ^ <zyga> slangasek: perhaps the alternative is to have a stanza that controls this <zyga> slangasek: so for most jobs, that would be immediate, and blocking <zyga> slangasek: but for certain early jobs we can relax that to 'when possible' and perhaps send some signal to communicate the fact (or tie that requirement to SIGSTOP support) <zyga> slangasek: like startup-SIGSTOP-cgroups-SIGCONT <zyga> ^^ :D <zyga> socket bridge is not optional <zyga> cgropus can or can not be available and the job should not differ * zyga might join the session but doesn't feel like a system level engineer to speak up really <zyga> jodh, slangasek, stgraber: ^^ <slangasek> zyga: please join ;) <beidl> it has to be special cased because it provides the infrastructure for jobs <apw> slangasek, i think i liked your statement there "it backs a stanza implementation" <apw> "start on using_stanza_cgroups" <apw> xnox, i think you want upstrart syntax for that different words for optional and not <apw> cgroup <stuff> <apw> cgroup optional <stuff> <mdeslaur> it's not something we need, it's something we'd be interested in looking at if it was available <gQuigs> why ever depend on having swap? <apw> jodh, could you do something like hte kernel does, and have the cgroup stanza actually start the job, like a modprobe for a protocol family in the kernel <apw> jodh, limits, can there not be a wrapper which applies those and used as an exec script prefix ? * ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Secure Boot work for 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21978/core-1311-secure-boot/ <roadmr> oh that's today! yay <cjwatson> Hangout URL? <cjwatson> (Who's running the video? slangasek I assume) <slangasek> https://plus.google.com/hangouts/_/72cpj2k5dn4bjr053d5ehn1lpo <slangasek> cjwatson: ^^ <apw> do we have a stream yet ? <slangasek> yes <rtg> not that we can see <slangasek> hmm <apw> white space for me <slangasek> checking <slangasek> oops, got the URLs backwards :P <slangasek> fixed <apw> slangasek, have it now <slangasek> also, why are you people not joining the hangout ;) <apw> is there any kernel work :) <rtg> haven't combed my hair yet * apw has no hair <cjwatson> that's what video-off is for <apw> :) <cjwatson> (actually I just don't want to deal with bw awfulness) <slangasek> apw: do you want there to be? <apw> slangasek, i normally listen till it sounds like one needs kernel input <josepht> lower thirds please <apw> "sitting in the second row" <smoser> slangasek, link? <apw> slangasek, often to do with clocks yes <slangasek> hum <apw> slangasek, i don't thnk it was ubiquitus or anything <rtg> slangasek, yeah, that'll get important pretty quick <apw> stgraber, we will be interested in those, get us the bug #'s <stgraber> Nov 12 12:58:48 castiana kernel: [213981.764426] Request for unknown module key 'Magrathea: Glacier signing key: f440a253eb498df923d438caa09b3b5d99308405' err -11 <apw> slangasek, keys have valid date ranges on them, a bad system clock can break the key load <rtg> slangasek, certificate authority date is related to the clock (I think) <slangasek> apw: hmm; so I don't think that was the cause for me <slangasek> [ 2.523405] video: module verification failed: signature and/or required key missing - tainting kernel <slangasek> that's here on the most recent boot, and my system clock isn't dodgy <apw> slangasek, hmmm, yeah, i've added a WI to investigate them, if you could file a bug on that and get me the number, stgraber also <apw> slangasek, i can only assume it is an ordering issue, we boot too quick or something helpful <rtg> apw, there are plenty of bugs mentioning this problem. maybe jsalisbury would know one . <stgraber> slangasek: ah yeah, I see that one too <apw> rtg, good idea, will engage him <stgraber> slangasek: I'll file a bug <slangasek> stgraber: ta * apw bets you both use somethign which gets graphics into your initrd <stgraber> we both use cryptsetup <apw> that ... see <apw> i bet that is why i don't see it * 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/20/%23ubuntu-uds-core-2.html <slangasek> ok <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1253155 <udsbotu> Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [Undecided,New] * ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Foundations for app developer workflow | Url: http://summit.ubuntu.com/uds-1311/meeting/21989/core-1311-foundations-for-app-developer-workflow/ <dholbach> xnox, I'm leading another session at the same time :-/ <dholbach> err, slangasek: ^ <slangasek> dholbach: ok. Do you need this rescheduled? <slangasek> I just sent the hangout invite to everyone subscribed to the session <dholbach> no, I don't think I need to be there, I'll watch the video later on <slangasek> ok, cool <karni> slangasek: Thanks for the invite Steve. For this session I'll be mostly a listener. <cjwatson> slangasek: I didn't get it AFAICS <slangasek> https://plus.google.com/hangouts/_/7acpje7f3dnktlourn64tm45kg <cjwatson> oh, maybe on my phone, which is no use to me :) <slangasek> cjwatson: I guess I sent it to the wrong you, sorry :) <slangasek> should've gone to the canonical-you <cjwatson> ok - I'll be there in a sec, I'm just finishing updating my local emulator with some rapid use of 3G <cjwatson> :-) <zyga> hi * rsalveti waves <karni> o/ * ogra_ shores <ogra_> video ! <karni> You're live <rickspencer3> o/ <xnox> and it's live! <ogra_> oh, and colin made his hair ... (he switched the cam on) <asac> :) <karni> the whole browser, yes <xnox> yes. <asac> yes <xnox> cjwatson: still browser. <lool> cjwatson: works well <zyga> cjwatson: it's hard to share that one <zyga> orks <zyga> works <xnox> cjwatson: awesome. <karni> good <lool> I see the browser <lool> I see my browser window with cjwatson inside <slangasek> it's working now - we sorted it out on the hangout rather than waiting for the IRC round-trip :) <slangasek> lool: you must be desynced <lool> I am, but I was trying to make a silly joke too <lool> it's all good now :-) <karni> hehe <rsalveti> and graphics should be working with latest emulator :D <lool> hehe <karni> rsalveti: \o/ <lool> rsalveti: is that with passthrough? <slangasek> yes <rsalveti> lool: yes, because we need opengles v2 <ogra_> we do !! <zyga> is the child one can hear behind the scenes coming from the current speaker? <ogra_> yes <zyga> ah, ok <karni> yes, shell <zyga> yes <ogra_> yes <zyga> but very small <zyga> too small to be readable <xnox> cjwatson: yes, we do, but it's small font =)))) <zyga> or un-maximize the window <rsalveti> still small? <karni> much better <rsalveti> don't know if it's the delay <xnox> cjwatson: awesome. <ogra_> yeah <zyga> cjwatson: google gives you roughly the same texture for any size of your screen <rsalveti> there's a huge delay <zyga> cool demo! <xnox> fingers crossed. <ogra_> cjwatson, it takes 10min <sergiusens> just be patient! <xnox> cjwatson: very slow emulated processor. <ogra_> 400MHz ... 512M <ogra_> single core <zyga> ogra_: what is that emulated with? qemu? <ogra_> yep <ogra_> a very old version <zyga> ogra_: graphics patches holding it back? <ogra_> well, its heavily patched for goldfish <zyga> I see <ogra_> not just graphics <zyga> ah, I see * zyga mutters something about tizen / bada emulator ;) <zyga> can we run the emulator with a prebuilt image <zyga> that we can download from somewhere? <zyga> I tried it today in trusty but the package was broken <janimo> zyga, it worked for me in trusty today <sergiusens> if it confuses people, just don't launch with -shell <janimo> zyga, I used the build image script as documented <zyga> janimo: the script for building the image is broken <ogra_> worked fine for me <zyga> janimo: it references stuff that's not in the package <zyga> I was following the wiki basically <sergiusens> zyga, you might of downloaded an older wrong package <zyga> I can take it offline if you want to know what I did <ogra_> zyga, then you got the broken package <sergiusens> zyga, you need -0ubuntu2 <janimo> zyga, I was lucky I guess :) I did not check what it actually does, but it made a working sd.img <zyga> sergiusens: nope, never installed that before <ogra_> which also breaks your host <lool> I was asking on teh wrong chanel blah <lool> QUESTION: do we need separate chroots for native builds and cross-builds due to multiarch deps still? <ogra_> (if it is amd64) <lool> I mean if I'm on trusty/amd64 and I want to a) cross-build to saucy/armhf and b) build for saucy/amd64, can I use a single chroot? <zyga> oh * zyga checks <ogra_> lool, cjwatson cant see his IRC <zyga> darn <xnox> slangasek: ^ relay question to cjwatson from lool <zyga> yeah I have 2 <zyga> er <zyga> 1 <ogra_> probably someone can forward the question to the hangout <zyga> can I just upgrade now? I recall scary recovery instructions <rsalveti> zyga: yes, latest should be safe <zyga> ok <ogra_> zyga, just never ever remove libc6-amd64 <sergiusens> cjwatson, rsalveti check if it's processing a crash * zyga reboots rarely so proably breaks-on-boot would be a bad thing to do now <ogra_> (which the broken package pulled in) <zyga> ogra_: heh, ok :) <zyga> ogra_: oh <rsalveti> sergiusens: I disabled whoopsie for now <zyga> ogra_: -amd64 vs :amd64? <ogra_> zyga, right <sergiusens> rsalveti, yay :-) <ogra_> rsalveti, evil you ! how are we getting all these crach reports now <zyga> ogra_: is there a way to safely get rid of that somehow? <ogra_> zyga, once the bug in libc is fixed perhaps <ogra_> for now, just dont touch it <slangasek> zyga: to fix it, just boot with break=bottom, and copy your ld.so/libc back from the initramfs to the rootfs ;P <slangasek> piece of cake <rsalveti> ogra_: well, otherwise you're basically unable to use it <ogra_> lol <cjwatson> zyga: sorry, my children can be a bit noisy at times indeed ... <ogra_> rsalveti, details :P <lool> cjwatson: ok, thanks <slangasek> (this happened to me a few weeks ago while sprinting, but sadly I did not link this in any way to the emulator package) <zyga> thanks! <lool> cjwatson: it was no strong reason except limiting the number of chroots people needed (space, ability to download them etc.) <lool> time to update them etc. * cjwatson nods <lool> I feel the pressure for fixing the content-hub hook is increasing <zyga> thanks, interesting demo <zyga> cjwatson: could you record a video with start-to-end (till it boots) and publish that sometime later? I would think many people would be interested <sergiusens> cjwatson, do you have a link to the chroot setup/building? I might have missed it if you did mention it <xnox> cjwatson: don't hit ctrl-c <xnox> =) <ogra_> lol <xnox> cjwatson: you can open adb shell <zyga> cool, sounds good for me <cjwatson> click chroot -aarmhf create (from lp:click at present, soon from the click-dev package) <zyga> cjwatson: don't disregard the tutorial nature of a complete video though <cjwatson> zyga: agreed <cjwatson> would need a bit more prep than this got :-) <zyga> :-) <sergiusens> great <cjwatson> thanks all <cjwatson> sorry for the not-quite-fully-in-place demo, but I hope you'll agree it was close :-) <karni> thanks all! <sergiusens> thanks <karni> cjwatson: it was close! :) <cjwatson> and thanks as ever to rsalveti for tireless work on the emulator <ogra_> ++ <rsalveti> still a lot to do, but we're getting there :-) <cjwatson> and to xnox <ogra_> ++ too <karni> yes we are! <ogra_> :) <ogra_> it is intresting though, for me the emulator worked on first try and a lot sooner than yours * cjwatson tries ctrl-c and re-running <cjwatson> oh, I forgot one thing, instructions on the emulator * ogra_ thinks the graphics HW you use has also some impact <cjwatson> https://wiki.ubuntu.com/Touch/Emulator <cjwatson> just make sure to use the very latest version in trusty <cjwatson> one thing this really highlights is the need to rewrite click in C, as all that Python is slow on first boot :-/ <ogra_> yeah <cjwatson> ha! unity is up now <ogra_> and there is whoopsie (which is currently disabled) and apparmor creating profiles on first nboot <rsalveti> \o/ <ogra_> yay <cjwatson> I should have ctrl-ced during the presentation :-) <karni> cjwatson: :D <ogra_> ureadahead too ... we might want to disable that <cjwatson> or fix ... cf earlier discussions <cjwatson> http://people.canonical.com/~cjwatson/tmp/emulator-yay.png <cjwatson> (sorry, import -window root is a bit odd with multi-monitor) <rsalveti> yay <sergiusens> cjwatson, write it in go :-) <sergiusens> that's just a pun ;-) <karni> cjwatson: thanks for the screenshot! * ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Planning the hardware enablement strategy for 14.04 LTS | Url: http://summit.ubuntu.com/uds-1311/meeting/22029/core-1311-hwe-plans/ <slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s <slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s <slangasek> more people please join the hangout, this should be a discussion <slangasek> don't leave me all alone in here with the kernel guys <diwic> slangasek, ok, I'll try :-) <tjaalton> i'm thinking about it <tjaalton> but my wife has the laptop now :P <tjaalton> yup <tjaalton> maarten didn't reply to my pings <tjaalton> ok got the laptop, will take a while to set things up.. <xnox> ogasawara: well at the moment upgrade fails, so one will fail to upgrade from -lts-saucy to quantal. <xnox> infinity: ^ <xnox> are upgrades ever tested from all enablements to trusty? <xnox> including -lts-trusty -> trusty <slangasek> currently, none are tested <infinity> xnox: No, but we need to. <arges> do we test LTS dkms packages against all hwe-kernels? <slangasek> arges: are there any dkms packages that are in main? <ogasawara> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1244438 <udsbotu> Launchpad bug 1244438 in linux (Ubuntu) "EOL notification system required for HWE kernels in LTSs" [Medium,Triaged] - Assigned to Ubuntu Kernel Team (ubuntu-kernel-team) <geofft> at some point I'd like to ask about OpenAFS, which is in universe and broke with the most recent HWE kernel <apw> geofft, what broke with it ? did it fail to install or fail to work <arges> slangasek: or maybe more general do we have a good way for dkms packages to support multiple kernels? Is it just #ifdef'ing properly or doing things like this: https://launchpad.net/ubuntu/precise/+package/openvswitch-datapath-lts-raring-dkms <geofft> apw: The DKMS modules failed to compile, and we're not really sure about the process for getting fixes <apw> geofft, cirtainly filing a bug, if that is a universe package it is then best efforts <marrusl> I had a large customer opt-in to HWE kernels accidentally because when they moved forward with the project they grabbed "the latest iso" <marrusl> they were ok with it in the end, but they weren't clearly aware of what they were doing. <apw> marrusl, messaging could be better yes <slangasek> geofft: it's a suitable target for SRU <xnox> marrusl: 12.04.0 images are out there. the messaging on the ubuntu.com website is clear about hardware and non-hardware ennablement stacks. <geofft> apw, slangasek: LP #1206387 <udsbotu> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387 <slangasek> geofft: we would welcome community SRUs for such issues, but Canonical won't own the update of those packages as part of the HWE stack <geofft> I think one thing is we're not sure if we did the SRU process right -- who should be subscribed to these things, what do we need to do to push it forward? <marrusl> hey I understand, but it's still very confusing to end users. this is a very large corp that we would have assumed "knew better" but they didn't. <slangasek> effectively, you need to get a package uploaded to the queue <geofft> Also it would be _wonderful_ if this didn't break on the day of the upload of a new point release <slangasek> sponsored or otherwise <geofft> because we have users who will grab the new ISO, install, and then complain at us :-( <bjf> xnox, i don't know how you can claim that the messaging is clear .. http://www.ubuntu.com/download/server <geofft> and downgrading their enablement stack is a pain. <xnox> well on the bottom of "http://www.ubuntu.com/download/alternative-downloads" there mentioned about downloading image with "Precise stack" but that's not very clean =/ <xnox> bjf: i don't think there was any on server pages. <xnox> slangasek: infinity: in the pool/*.deb <xnox> ? <bjf> xnox, so, you are assuming people know to go to the alternative downloads page and even on that page it is not clear <xnox> bjf: true. i somehow thought it was better explained, but i can't find it any more. <bjf> xnox, yes, you can go to "past releases and other flavours" <xnox> bjf: i think we need more explanation text right next to "download" button. <xnox> ... and on cdimage.u.c <bjf> xnox, i agree with that <xnox> .. <xnox> cannot hear bryan. <apw> he was asking if we will upgrade people at the end of life for the pre-trusty lts- <apw> backport stacks, and that was a no, we would message them <xnox> thanks. <marrusl> I have a feeling this won't be a popular idea... but I have multiple customers that would LOVE to see the HWE stack extended to networking. specifically: network-manager, modemmanager, wpasupplicant, and usb-modeswitch. <marrusl> (I have a feeling that NM deps will make this a big pain) <diwic> seems nobody wanted to hear about the audio stack perspective, or my mic was muted? <slangasek> marrusl: I don't see why we would make that part of the HWE stack, instead of simple standalone SRUs that nobody gets <infinity> marrusl: Too late, session over. La la. <slangasek> diwic: oh - yes, you were muted! <slangasek> diwic: sorry :/ <arges> diwic: your mic was muted <marrusl> meh <slangasek> diwic: wondered why you were so quiet the whole time... :) <diwic> anyway; so for PulseAudio we decided not to try to
{'channel': 'ubuntu-uds-core-2', 'month': 11}