=== thumper is now known as thumper-afk [04:56] morning [05:21] Mirv: morning [05:21] cyphermox: hullo [05:22] so, so far I haven't been able to find out what's wrong with phonesim -- if I disable it though, the lab devices seem to work properly [05:23] so I think we'll need to involve pitti to look at what's up with phonesim or the related pieces [05:25] cyphermox: define "wrong"? [05:25] * Mirv switches computers to dedicate this one to test libunity [05:25] pitti: unclear, sadly [05:26] pitti: seems that now, the phones in the QA lab tend to get stuck with indicator-network/dbus/ofono in high CPU [05:26] it happens about 30% of the time, apparently [05:27] but you quickly notice indicator-network hiking up to 60%+ CPU for a while when phonesim gets restarted, and sometimes (that 30% I was telling about) on boot [05:27] cyphermox: oh, is that still the "NetworkManager crashes in a loop" problem? [05:27] I looked, but I can't make sense of the reason -- it's hard to figure out what's going on [05:27] bug 1231964 ? [05:27] Launchpad bug 1231964 in network-manager (Ubuntu) "NetworkManager crashes in ofono plugin with phonesim [crashed with SIGSEGV in in ??()]" [High,Triaged] https://launchpad.net/bugs/1231964 [05:27] pitti: NM doesn't seem to be crashed, but hold on [05:27] that could be it, maybe [05:28] I didn't notice this NM crash any more on my recent phone test runs, though [05:28] when I reported the bug, I had to kill NM to make it not go crazy [05:28] but I haven't done this any more for weeks [05:28] this isn't a new bug though, so yeah [05:28] but as NM didn't change, I guess we are missing something there [05:28] well [05:28] so I figure this only happens in some cases [05:28] NM did change -- we're getting 0.9.8.4 now in the images [05:29] cyphermox: oh, it's only happening since that update? [05:29] I haven't tried .4 on the phones yet indeed [05:29] but the ofono code certainly hasn't change between then and now [05:29] cyphermox: is that on the latest trusty image? flashing now [05:29] in theory yes [05:30] I don' think you'd see indicator-network in high CPU though, in that case [05:30] hold on, I can check if NM crashed on the mako used by psivaa as an example [05:31] hmm [05:31] no crash in /var/crash for NM [05:31] and no segfault apparent in /var/log/syslog. [05:31] ok, so it's not that then [05:32] pitti: if you want to play with this stuff, you can use adb -s 01ade38b552014d4 shell [05:32] in the lab [05:32] so 9 hours ago we got https://code.launchpad.net/~boiko/dialer-app/fix_ap_1.4/+merge/194205/comments/447936 which apparently at least succeeded [05:32] ah? [05:33] pitti: didrocks mentioned it was happening since Tuesday. [05:33] https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/3174/? has two crash reports, but they've always happened (and are known bugs) [05:34] yeah, looks consistent with what I have on the device right now [05:37] pitti: as one thing I noticed in recent proposed images was that I didn't have write access to /var/lib/dpkg even with a writable image, maybe this is breaking dbus in some way that upsets phonesim [05:37] or phonesim itself [05:38] nevermind, both are explicitly listed in mounts === duflu_ is now known as duflu [05:46] pitti: so here's the full list of changes from 1105, which would be relevant for what we're looking at, possibly: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes [05:49] * pitti taps foot waiting for flashing to finish [05:50] hehe [05:54] cyphermox: ok, flashed [05:55] cyphermox: so, do you already see this happening when merely starting phonesim, or just when the tests run? [05:55] yeah even just starting with-ofono-phonesim I see it happening [05:55] i. e. should I do "sudo apt-get install ofono-phonesim-autostart"? [05:55] ack [05:55] yup [05:58] 2394 B/s [05:59] oh c'mon, ports.u.c.! [06:00] cyphermox: so this image ("trusty" channel) still has NM 0.9.8.0-0ubuntu22 [06:01] I wonder where ogra_ takes his image from :) [06:01] tursty-proposed :) [06:01] trusty, I mean [06:01] that's what I used [06:01] the proposed one? [06:02] cyphermox: started "sudo with-ofono-phonesim", indicator-network spins CPU at 70% indeed [06:02] well at least now we're confirmed without doubt that it's not NM [06:02] and on the phone, when I open it I see "Empty!" [06:02] but it makes it that much less clear what's wrong [06:03] strace says its spinning on a poll()/write() loop [06:03] yeah, I was seeing the same [06:03] I want to port Ubuntu Desktop on my Development board which is having Android [06:03] isn't write failing? [06:03] Can someone please helpme [06:03] fd 11 is anon_inode:[eventfd], whatever that is [06:03] or maybe it was a read what was failing with EAGAIN before [06:04] cyphermox: no, write succeeds, read() is EAGAIN [06:04] pitti: what process is that? [06:04] and there is a really fast poll which times out [06:04] cyphermox: indicator-network-service [06:04] yeah [06:04] ok [06:05] $ pkill -f indicator-network-service; /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service [06:05] ** (process:4256): ERROR **: network-menu.vala:202: Unable to get D-Bus bus name [06:05] meh, it respawns too fast [06:05] and that's why useful D-BUS services have a "--replace" option :) [06:06] so hey, I couldn't see the ofono-phonesim.conf dbus config file in /etc/ofono, that's because of the mount in with-ofono-phonesim, right/ [06:06] ogra told me to create kernel zImage and initrd.img images ....and pack both these using abootimg utility .......I have created the zImage ....but I don't know how to create initrd.img. Please tell me how to create [06:06] cyphermox: right, it's an unshared tmpfs overlay, to avoid modifying the system [06:07] cyphermox: hm, I managed to start it in the foreground now, but its quiet now [06:07] abhishek_: phone? [06:07] I have IFC6410 development board which is having android [06:08] I have android BSP available to me [06:08] abhishek_: ogra_ should be around again soon, I'd think, you may want to ask him directly, and probably more in #ubuntu-touch if it's for touch [06:08] I want to run Ubuntu on this board [06:08] ok [06:08] It's for Desktop [06:09] cyphermox: Can you please give me some guidlines ....to create initrd.img ... [06:10] cyphermox: I am using Kernel source from Android source ..... [06:10] abhishek_: that usually gets built along with teh zImage [06:10] cyphermox: Please give me some guidelines ...this will help me alot [06:10] cyphermox: got it to spin now in the foreground, but no output at all (except for a single "CRITICAL **: nm_device_get_iface: assertion 'NM_IS_DEVICE (device)' failed" which happened when I started phonesim) [06:11] hrm [06:11] pitti: spin as in do nothing useful? [06:13] cyphermox: do you see polkitd spinning as well? (and apport coming up often) [06:13] I had not noticed it, no [06:13] ERROR: apport (pid 8040) Thu Nov 7 07:13:38 2013: called for pid 8036, signal 5, core limit 0 [06:13] ERROR: apport (pid 8040) Thu Nov 7 07:13:38 2013: executable: /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service (command line "/usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service") [06:13] every 2 seconds [06:13] let me look it up [06:14] hey, that would explain a lot [06:14] but that might be because I'm running it in the foreground now, and D-BUS activation repeatedly fails because the name is taken [06:14] /usr/share/upstart/sessions/indicator-network.conf [06:14] oh dear, why do we have to upstartify everything? [06:14] * pitti yells "D-BUS activation!" [06:15] cyphermox: I didn't found that .....I used update_initramfs to create initrd.img for my Laptop kernel (when I upgraded my laptop kernel) .......But, I don't know how to create the initrd.img for the kernel which is meant for some other board? [06:15] cyphermox: yep, that stopped the apport/polkit loop :) [06:15] cyphermox: ok, running under gdb in the foreground now [06:16] but now it's quiet, of course [06:16] abhishek_: I don't know. I think you should ask ogra_ directly [06:16] pitti: yeah :/ [06:16] cyphermox: Ok ....thanks [06:16] cyphermox: ok, reboot, and attaching gdb directly when it happens [06:17] cyphermox: Is orgra around ? [06:17] unlikely at this hour [06:17] *ogra [06:17] give it another hour or two [06:17] ok [06:17] oh! [06:18] pitti: I got a g_source_destroy_internal() in gdb now [06:19] ah, I get all kinds of things if I'm lucky enough [06:22] yeah, all main loop/poll stuff [06:22] actually, not so much [06:24] aah [06:24] $ pkill -f indicator-network-service; G_DBUS_DEBUG=all G_MESSAGES_DEBUG=all /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service [06:24] for instance: http://paste.ubuntu.com/6374719/ [06:24] cyphermox: ^ that's the magic [06:24] ah, wise! [06:25] I've exceeded my efficiency time for tonight :) [06:25] cyphermox: so you apparenlty can stop the spinning by merely killing the indicator, it'll respawn and behave [06:25] no [06:26] maybe sometimes it works but I did kill it a few times and got it back i nthe same state [06:28] cyphermox: http://people.canonical.com/~pitti/tmp/indicator-network-service.log.xz [06:29] liek http://paste.ubuntu.com/6374736/ ? [06:29] it loops in StartServiceByName() [06:30] cyphermox: yes [06:30] yeah [06:30] The name org.ofono was not provided by any .service files [06:30] !? [06:32] well eventually it does find it though [06:34] I let it spin for 20 seconds or so, ofono was well up and running at that time [06:35] http://paste.ubuntu.com/6374745/ [06:35] yes, it was [06:35] something's wrong [06:35] ^ ofono is up, indicator talks to it [06:36] in the end it's still waiting for something though [06:37] urgh [06:37] http://paste.ubuntu.com/6374764/ [06:40] cyphermox: do you see anything interesting there? [06:41] nevermind no [06:44] can I let you keep looking into it? [06:45] I really should get to bed by now, it's nearing up on 2am [06:45] cyphermox: yeah, better go to bed; I've got some other fires to put out, but I guess it's not that desperately urgent? [06:46] it's pretty crippling for the testing of the phone images, apparently [06:46] but I have really no way to tell how urgent, better ask didrocks about that [06:51] cyphermox: would you be still up to pkg ack? http://pastebin.ubuntu.com/6374808/ [06:52] sure [06:52] (basically bzr 306 + 307 from https://code.launchpad.net/~unity-team/libunity/trunk) [06:52] we need it to unblock unity + ap + everything, I've now tested it [06:53] yeah, it's fine. I just wish they made commit messages a bit more meaningful for changelogs than just "Make tracing easy" [06:53] test_extras_LDFLAGS = -static !? [06:54] the rest looks okay to me [06:54] Mirv: ^ [06:54] yes, I guess it's related to "Making tracing easy" but explanation would be nice [06:54] I wonder if mhr3 would be up soon [06:57] filed bug #1248840 [06:57] Launchpad bug 1248840 in libunity "Make libunity test extras not link static or add a comment" [High,New] https://launchpad.net/bugs/1248840 [06:59] pitti: does it hurt if it's in tests only, so not in published binary packages anywhere? [06:59] Mirv: not sure, but why would you want it in the first place? [06:59] it seems better to me to test the actual .so libs that you built [07:00] pitti: beyond me, my only guess it's related to that tracing one way or another. but I filed the bug to get an explanation committed. [07:02] pitti: it seems all the other tests already had the -static, this just adds it to the _extras too [07:14] pitti: since it's just harmonizing the Makefile to what was already being used, do you think the bug report is enough for now? I'd like to release it, and all tests ran fine. [07:14] it's blocking the autopilot 1.4 transition at the moment [07:15] Mirv: oh yes, I do; thanks for filing [07:15] ok, thanks === slomo_ is now known as slomo [07:45] it happened again! drwx------ 2 root root 80 marra 7 08:46 pulse (in /run/user/1000) [07:45] I wonder what's causing that, I need to chown it to make sound work again [08:03] morning btw :P [08:06] morning mlankhorst [08:18] mornign sil2100 [08:26] Morning! [08:27] Mirv: hmmm, strange, but stuff didn't leave proposed yet from what I see? [08:27] sil2100: nothing strange about that, see landing plan [08:28] Mirv: Ken checked in my evening and he said that the last missing link blocking stuff was unity-autopilot [08:28] Mirv: ah, libunity [08:28] Mirv: this Ken didn't notice, oh well [08:28] sil2100: yep, but it was not really [08:29] Mirv: thanks for publishing that o/ [08:29] testing was hard, that's why it's already 3.5h since I started [08:29] cu2d was of no use etc [09:05] bonjour pitti! ça va? [09:05] bonjour didrocks ! ça va bien, et toi ? [09:06] pitti: on fait aller :) [09:06] didrocks: c'est tard pour toi, c'est encore le jetlag ? [09:06] pitti: cyphermox told me you are looking at what is causing the network indicator to become crazy in the QA lab after boot? [09:06] pitti: oui, encore du jetlag :/ [09:06] pitti: like, it would be an ofono-phonesim issue? [09:06] didrocks: cyphermox and I took a stab at debugging this this morning, but we didn't yet get that far; have to put out some fires first [09:07] didrocks: it seems indicator-network-service is spinning on trying to contact ofono over D-BUS [09:07] pitti: I'm still puzzled as http://people.canonical.com/~ogra/touch-image-stats/20131105.changes doesn't have any ofono/indicator changes [09:08] (and as told in my email, we try to revert network-manager) [09:08] pitti: do you think you'll have time to have a look later on? It's basically what is going to block us to publish some results [09:08] didrocks: not sure where ogra_ took his image from, but I flashed from the "trusty" channel this morning, that got me the old network-manager for example, so I guess it's an older image [09:08] didrocks: don't bother, it's not network-manager [09:08] pitti: trusty-proposed [09:09] err, devel, devel-proposed, trusty, trusty-proposed.. [09:09] didrocks: but as I said, it's nothing to do with http://people.canonical.com/~ogra/touch-image-stats/20131105.changes [09:09] didrocks: where do you see this? [09:09] pitti: on the image containing those changes (in the QA lab only) [09:09] didrocks: we ran a phonesim dialer-app test just about 10 hours ago on mako and maguro which succeeded [09:10] so image 12 and 13 [09:10] didrocks: I mean, which test does now fail which didn't before? [09:10] well, tests are impacted because indicator-network is taking > 63% of CPU [09:10] so a lot of AP fails [09:11] the system isn't idling [09:11] didrocks: do we run all autopilot tests at the same time now, i. e. does the recent addition of ofono-phonesim-autostart to the dialer-app/messaging-app tests now cause all the other autopilot tests to run with that as well? [09:11] didrocks: ah, we don't run the AP tests in separate runs, but all in one session? [09:11] pitti: yeah, there is one boot [09:11] and running all AP tests for this app [09:11] pitti: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/13:20131105.1:20131031.1/4910/ubuntu-rssreader-app-autopilot/ [09:11] didrocks: that sounds a lot like that D-BUS spinning has been there all the time, it just didn't get exposed until now because ofonod wasn't restarted [09:11] for instance, you can see 3 AP failing [09:12] pitti: look at multiple top snapshot at boot: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-ubuntu-rssreader-app-autopilot/16/artifact/clientlogs/top_before.log/*view*/ [09:12] 2197 phablet 20 0 253920 220080 3796 S 70.8 11.5 3:27.03 /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service [09:12] (last run, 5 minutes after the phone booted up) [09:12] didrocks: I need some ~ 10 more minutes to finish fixing the flood of autopkgtest failures, then I can go back to this [09:12] pitti: \o/ thanks a lot :) [09:13] pitti: the additiona of ofono-phonesim-autostart to some tests can explain that [09:13] yes, as these restart ofono [09:13] which probably is the thing that breaks the network-indicator [09:13] but once dialer-app tests are over [09:13] we reboot the device [09:13] wait… doing nothing [09:13] for 5 minutes [09:13] and then start rssreader tests [09:13] yes, but ofono-phonesim-autostart is still installed I guess [09:13] will your mock influence? [09:14] right [09:14] it's not a mock [09:14] it's an actual ofono driver [09:14] ah ok ;) [09:14] and so… it restarts ofono at each boot [09:14] so after boot, ofono will still restart, possibly after indicator-network [09:14] so, depending in which order we do the tests [09:15] as soon as we start one depending on ofono-phonesim-autostart and we install it, all the following tests are screwed [09:15] at least it *starts* to make sense to me [09:15] * didrocks was soooo puzzled yesterday [09:15] we tried to reflash, only rerun some tests… [09:15] I didn't see this kind of failure in the MPs [09:15] something all went fine and suddenly, 100% strike [09:16] and trust me, mako/maguro ran these tests dozens of times :) [09:16] but that was all in isolation, i. e. just the dialer or just the messaging tests [09:16] pitti: yeah, it's weird you didn't get it in the upstream merger [09:16] right [09:16] so those didn't exhibit the indicator going crazy [09:16] didrocks: well, possibly I did (even locally), but I didn't check top [09:17] didrocks: it's perfectly reproducible on my phone, too [09:17] pitti: let me try to install it and confirm ;) [09:17] * didrocks hugs pitti. So happy to have a start of explanation [09:17] didrocks: install ofono-phonesim and xvfb, run "sudo start with-ofono-phonesim", wait a few secs [09:17] was really depressing yesterday [09:17] * pitti hugs you back [09:18] didrocks: but yes, these tests also expose lots of Mir and other crashes :) [09:18] pitti: nice stress test! ;) [09:18] ok, I'll let you go on the autopkgtests, just ping me if you need access to anything [09:18] morning [09:18] (which is why it took me so long to land them in the first place -- Mir crashes caused the MP to get rejected) [09:18] argh "fun" :) [09:18] didrocks: nope, can debug on my device [09:19] pitti: ok, just keep us in touch. I think there is no real value that we run the tests before you get a fix [09:19] didrocks: just uploaded systemd, postponing gvfs autopkgtest, other tests are green again, so looking now [09:19] \o/ [09:20] good morning desktopers [09:20] hey Laney, seb128 [09:20] hey Laney pitti didrocks [09:20] bonjour seb128 === Rodge is now known as Rodge_ [09:22] didrocks: actually, much simpler than that [09:22] didrocks: "sudo stop ofono; sudo start ofono", that makes it go crazy [09:22] didrocks: which is actually a nice test, as it very much does need to cope with htat [09:22] didrocks: so, nothing to do with my 13117 unshare -m tricks or so :) [09:22] pitti: confirmed! [09:23] didrocks: want me to file a bug, or is there one already? [09:23] pitti: I don't think there is any [09:23] didrocks, did you manage to resolve the tests issue yesterday? [09:23] pitti: hum, after a reboot, I can't get the indicator going crazy [09:24] seb128: we are discussing about it, there is a lead already [09:24] didrocks, so it's not ido at the end? [09:24] seb128: can you try "sudo stop ofono; sudo start ofono" [09:24] didrocks, on my desktop or on the device? [09:24] seb128: device [09:24] sure, give me a min [09:25] pitti: grrrr, it's not that easy, worked the first time, but now, can't retrigger it. Is it reliable for you? [09:26] didrocks, that seems to be fine ... but my device is not uptodate ... /me updates [09:27] * pitti files bug 1248880 [09:27] Launchpad bug 1248880 in indicator-network (Ubuntu) "spends lots of time spinning on D-BUS when ofono restarts" [Undecided,New] https://launchpad.net/bugs/1248880 [09:27] didrocks: fairly, yes [09:28] didrocks: I'll add some extra information with d-bus debugging, hold on [09:29] pitti: tried to reboot twice, can't reproduce :/ [09:31] hm, I can reproduce it every time [09:31] pitti: do you have ofono-phonesim installed? [09:31] didrocks: but sometimes it only lasts some 10 seconds until it reconnects, sometimes 3 minutes [09:31] didrocks: yes, but I didn't run it (and I don't have -autostart installed) [09:32] still no luck :/ [09:32] pitti, do you have a sim in the device? does that make a difference? [09:32] seb128: I do, and I don't know [09:32] didrocks, do you have one? [09:33] $ /usr/share/ofono/scripts/list-modems [09:33] [ /ril_0 ] [09:33] Features = net sms gprs sim [09:33] without a SIM, it could indeed make a difference [09:33] that's perhaps why you see it better with phonesim [09:33] as that always exports a device [09:35] didrocks: updated the description accordingly [09:36] I now have a case where it has spun for > 1 minute already [09:36] pitti: confirmed with popey [09:36] it seems it's rolling dice and has an 1% chance of reconnecting or so [09:36] a SIM is needed [09:36] didrocks: or phonesim :) [09:36] didrocks: I updated the description to show how to reproduce without a SIM [09:39] pitti: ah, will try after that meeting, thanks! [09:43] didrocks: also posted a link to the g_bus_watch_name() API docs which I suggest using [09:44] seb128: that dbus api for adding launcher icons works great, but in some circumstances the tooltip says "waiting to install" which is odd [09:45] mfisch, seems like an unity bug, maybe check with bregma/Trevinho [09:45] seb128: yeah I found an old one in LP that I'm looking at [09:45] didrocks: should I do anythign else with this bug? assign it to someone, etc? [09:48] pitti: no, I'll hunt for people :) [09:48] pitti: back from the meeting, let me try installing the various pieces [09:49] pitti: confirmed that with-ofono-phonesim, the indicator goes crazy [09:49] thanks a lot pitti! [09:49] :) [09:50] * didrocks targets a victim now :) [09:50] * seb128 is happy to be off didrocks' enemy list [09:50] seb128: until next time! :-) [09:50] * seb128 is also happy that didrocks let him land the ido segfault fix yesterday [09:50] didrocks, yeah ;-) [09:50] seb128: in fact, it's why it was so puzzling [09:51] seb128: depending on the test order [09:51] you install that package earlier or later [09:51] and then, the package stays installed [09:51] when you run other tests [09:51] that's why it was a "wth" [09:51] right, that's making for fun debugging [09:51] and we didn't find any culpurit in the diff list [09:51] right [09:51] seb128, didrocks: ido> oh yes, so am I, thanks for the fast fix! [09:51] this was so annoying [09:52] pitti: well, thanks seb128 to fight for it :p [09:52] pitti, thanks to larsu ;-) [09:52] * seb128 hugs didrocks [09:52] * pitti donne une accolade à larsu [09:52] * didrocks hugs seb128 [09:52] * pitti hugs seb128 and didrocks [09:52] group hug ;-) [09:52] * didrocks rehugs pitti [09:54] :) [09:55] didrocks: quick, assign larsu to the network indicator issue, too! he's good with gdbus! [09:55] * pitti runs [09:56] larsu: I think you are the perfect target (the first to answer on IRC though) [09:56] larsu: seriously, interested in a somewhat-really-critical indicator-network-gdbus issue? ;) [09:56] it's a nice story, with a lot of praise for fixing it :) === thumper-afk is now known as thumper [09:57] erm... [09:57] no?! [09:57] * larsu is afraid [09:57] larsu: bug #1248880, do you have any idea on how to debug it? [09:57] Launchpad bug 1248880 in indicator-network (Ubuntu) "spends lots of time spinning on D-BUS when ofono restarts" [Critical,New] https://launchpad.net/bugs/1248880 [10:02] (a) I always want pitti-level bug reports from now on [10:03] (b) this looks really interesting :) [10:03] * larsu goes for tea and has a more dtailed look later [10:03] larsu, would you describe pitti's bugs the equivalent of mpt bugs, just applied to technical issues? ;-) [10:03] oh no, we spoiled larsu with high quality bug report :) [10:03] seb128: quick, let's edit it :) [10:05] seb128: exactly [10:05] * description changed to: * [10:05] Itz broken! fix it! [10:05] haha [10:05] ;) [10:06] * pitti removes reproducer, analysis, and pointer to "you should use this" too, way too little fun otherwise! [10:06] * larsu wonders how ServiceUnknown is send sometimes but then the service gets started sometimes [10:07] larsu: it spins on ServiceUnknown for 5 to 500 seconds and eventually seems to hit the sweet spot and reconnect [10:08] or these are just the 10 gazillion queued requests that it sends up in a tight loop [10:08] g_bus_watch_name()!! [10:08] ya, that sounds more like it [10:08] ted is known for "oh, didn't work, let's try again immediately" [10:17] so... indicator-network doesn't even build for me :-( [10:21] larsu, wrong vala version? [10:21] argh, I guess I need to be on trusty to get vala 0.22? [10:22] larsu, no [10:22] seb128: yes, they've just updated it in r312 [10:22] _without_ bumping the vala dep [10:22] * larsu shakes fist at kenvandine! [10:22] larsu, install valac-0.22 [10:22] larsu, then "update-alternatives --config valac" [10:23] no such package [10:23] larsu, that let you pick the default one [10:23] of course [10:23] larsu, https://launchpad.net/ubuntu/+source/vala-0.22/0.22.0-2/+build/5157282 [10:23] get the debs from there and dpkg -i [10:24] they should install fine on saucy [10:24] makes sense, thanks [10:24] yw [10:24] I guess I should jjust update this week [10:30] also needs valac-0.22-vapi [10:30] *sigh*, vala [10:32] larsu, sorry [10:32] larsu: [10:32] https://launchpad.net/ubuntu/+source/vala-0.22/0.22.0-2/+build/5157285 [10:33] larsu, ^ that has the arch all binaries [10:33] thanks :) [10:33] got it to build now [10:33] I'd have just added trusty to sources.list and installed it from there :P [10:33] I was going to suggest that next [10:33]