[00:00] <balloons> elopio, no, because it's under ~/, not our fake home
[00:00] <balloons> I mean, yes it's created but not where it needs to be
[00:01] <elopio> balloons: yes, because I suppose gi.repository uses the env var HOME, not the initctl var HOME
[00:01] <elopio> but we can't patch both because the app will not open.
[00:02] <elopio> balloons: maybe on the phone we can stop patching home for now.
[00:02] <balloons> elopio, music is currently shipping with a backup/restore
[00:03] <balloons> it's the same problem
[00:03] <elopio> balloons: well, we can do it without restore either.
[00:03] <balloons> elopio, but I think we can work around it for reminders
[00:03] <elopio> it will fail in the case you already have evernote accounts on the phone.
[00:03] <balloons> launch the app, then set initctl
[00:04] <elopio> and it will leave accounts behind if you stop the test before clean up
[00:04] <elopio> balloons: how will the app see the new HOME if it's already launched?
[00:05] <balloons> I'm trying to think.. but it's the account creation bit that doesn't have the proper home right?
[00:05] <balloons> so launch, then tweak for account creation. The app just cares about env HOME
[00:08] <balloons> i'll try what I'm thinking
[00:08] <elopio> balloons: you mean
[00:08] <elopio> 1. launch with initctl patched
[00:08] <elopio> 2. create the account patching also env var
[00:08] <elopio> 3. enjoy.
[00:08] <balloons> elopio, yes.. let me try :-[)
[00:08] <elopio> if that's the case, 1. will fail anyway because it seems the app has no permission to access the patched initctl home.
[00:09] <elopio> the step #2 I think will work
[00:13] <balloons> elopio, the patched home is the same as initctl home
[00:14] <balloons> atm, you have initctl home as ~/ and HOME as our fake dir
[00:15] <elopio> balloons: on the phone?
[00:15] <balloons> elopio, indeed
[00:15] <elopio> I don't think so, but I've been slow for 2 hours now
[00:16] <balloons> lol.. I think it's time to call it
[00:16] <balloons> let's land as-is with everything
[00:16] <balloons> agreed?
[00:16] <elopio> balloons: in the end, I reverted to the patch_home you made
[00:16] <elopio> that's if click, patch only initctl
[00:17] <balloons> alright.. and jenkins is hating on my pep8 changes
[00:17] <balloons> i think this is a wrap for tonight
[00:18] <elopio> :D
[00:18] <elopio> yeah, lets continue tomorrow.
[00:18] <balloons> cheers elopio :-_
[00:18] <elopio> I think we have two things to find out
[00:18] <balloons> ty much as usual
[00:18] <elopio> why it doesn't launch if HOME is patched.
[00:18] <elopio> and why when initctl is patched, the app can't read it.
[00:19] <balloons> my brain is mush.. I was thinking you were only patching home not initctl home
[00:19] <balloons> that's very odd then
[00:19] <elopio> it's the other way around. Well, I started patching both and that works for credentials.py, but the app can't be launched which should be the purpose :)
[00:19] <elopio> but you go and get some rest. I will switch context.
[04:19] <pitti> Good morning
[08:30] <jibel> pitti, for sudo on the ssh host, what I did is: if there is a password passed to the ssh runner (can be a file containing the password or the password in clear text) I setup askpass, then the runner tries to determine if it can sudo with askpass and sudo without it. Depending on the result it adds root-on-testbed and write the right auxverb, do you think it's okay?
[08:33] <pitti> jibel: where "sudo without it" means "sudo with an SSH_ASKPASS which just returns an empty string"?
[08:33] <pitti> jibel: it must never try and call sudo without an askpass, that might hang eternally
[08:34] <pitti> jibel: yes, that sounds nice; so with sudo being available, the auxverb would always run commands as root
[08:34] <jibel> pitti, sudo -n /bin/true
[08:34] <pitti> fun, so we'd call sudo su -c ... phablet :)
[08:34] <pitti> jibel: oh cool, I didn't know about -n
[10:33] <jibel> pitti, I pushed latest version of the ssh driver to lp:~jibel/+junk/adt-virt-ssh
[10:36] <jibel> pitti, tried on mako connected other usb with libpng and tabix
[10:37] <jibel> the command looks like: ./run-from-checkout -d libpng --- ssh -s virt-subproc/adb.ssh -d -l phablet -P /tmp/test -- --rw -s 04dc228756e547e7
[10:38] <jibel> where /tmp/test contains the password for user phablet and the id at the end is the serial of the device
[10:38] <jibel> not needed if there is only one device
[10:38] <pitti> \o/
[10:42] <pitti> jibel: only 6 retries to re-fix nut, go broken tests!
[10:45] <pitti> jibel: ah, I suppose root-on-testbed can go from the "capabilities" initialization at the top?
[10:47] <pitti> jibel: FYI, any bomb() terminates the whole thing, so a "return False" will never be needed; so execute_ssh_script() doesn't need to return a bool (exceptions are more pythonic, anyway)
[10:50] <pitti> jibel: oh, I see you do "if not execute_ssh_script('revert')", then perhaps that bomb() should rather be adtlog.warning()?
[11:02] <pitti> jibel: ah, need to figure out the magic to export the session bus and other environment to that shell
[11:18] <elfy> wxl: just a gentle prod that the lubuntu alpha images will want to be marked as ready
[11:29] <pitti> jibel: I imported it into a new branch for now: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=shortlog;h=refs/heads/adt-virt-ssh
[11:30] <pitti> jibel: I'm running into a few cases which don't work (specifying password, not specifying a script, etc.), I'll hack on it, commit fixes there, and once everything is ready consolidate the commits
[11:30] <pitti> jibel: many thanks!
[11:34] <jibel> pitti, I didn't expect it to be very robust as I just tried the happy path with basic deb tests
[11:34] <jibel> pitti, feel free to change it the way you think it best
[11:34] <jibel> is
[12:41] <pitti> jibel: meh @ all those new broken tests -- folks in Debian really ought to actually try their tests before uploading :/
[12:42] <jibel> pitti, and lot of them are failing with the same error "cannot locate Dh_Lib.pm ..."
[12:42] <pitti> yeah
[12:44] <pitti> jibel: can I just delete http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-kubuntu-precise-trusty-desktop-backports-{i386,amd64} (see shadeslayer's ping) or does that need some bzr update?
[12:46] <jibel> pitti, you can it won't be auto-recreated (unless I republish trusty) Which channel did he ping? I missed it
[12:46] <pitti> jibel: in #u-devel
[12:50] <jibel> pitti, I'll remove the profiles from the branch too. So they won't be recreated just in case I'd need to for 14.04.1
[12:50] <pitti> jibel: merci
[13:10] <elfy> balloons: if you could cast your eye over https://code.launchpad.net/~elfy/ubuntu-manual-tests/1334643/+merge/224612 that would be super :) would like to get that done prior to me calling for the next set of our tests
[13:59] <pitti> jibel: do I see that right, you only pass the --password to the setup script for configuring sudo? or did you actually have an SSH_ASKPASS command somewhere that I'm missing?
[14:00] <pitti> jibel: I now taught adt-virt-ssh to create SUDO_ASKPASS if the setup script didn't return a sudo_askpass and there's a --password
[14:03] <jibel> pitti, right if you do that then you can probably remove all the askpass thing from adb.ssh. It's better to have this in adt-virt-ssh as it's quite generic for any type of host
[14:04] <pitti> jibel: ack, thanks for confirming
[14:04]  * balloons looks at https://code.launchpad.net/~elfy/ubuntu-manual-tests/1334643/+merge/224612
[14:05] <jibel> so adb.ssh will only setup the forwarding rule and copy the keys which is saner
[14:06] <balloons> elfy, I'm going to leave a few inline comments on your mp
[14:18] <elfy> balloons: thanks for that - done those - pushed it back again I have
[14:18] <elfy> that inline comments thing is pretty useful :)
[14:18] <jibel> pitti, ah I remember why I did it this way, it's because in adt-virt-ssh you can only setup SUDO_ASKPASS over ssh, so you have to 1rst setup the connection then create SUDO_ASKPASS. But since we are using the connection anyway to verify if the user can sudo it doesn't matter where it's done, and it's better to do it in adt-virt-ssh anyway
[14:19] <pitti> jibel: right, can_sudo() already has the ssh_cmd, it doesn't need to use the full auxverb
[14:20] <pitti> jibel: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=6839dc works quite well here
[14:20] <balloons> elfy, approved :-)
[14:21] <elfy> balloons: cheers I'll merge and sync it then :)
[14:22] <jibel> pitti, very nice!
[14:23] <balloons> excellent.. did we get phillw's bug yet elfy ?
[14:23] <elfy> balloons: not seen one yet
[14:23] <elfy> as soon as I do I will pounce on it though
[15:09] <jibel> pitti, thinking about the ssh runner for cloud instances, the ssh script needs know the instance-id for example for shuting down the instance. What do you think is best to make it persistent, pass it to the runner then back to the script that manages the instances in the close hook would be ok?
[15:10] <pitti> jibel: I think more generically it could return a workdir= which gets passed back on subsequent invocations
[15:10] <jibel> pitti, right that was the idea.
[15:11] <jibel> nothing specific to any type of cloud but some kind of data field that is passed back
[15:11] <pitti> jibel: or maybe just a "state=", which the setup script can interpret in any way it likes
[15:11]  * jibel nods
[15:36] <pitti> jibel: the adb setup script determines the key from your ~/.ssh; it should export that as identity=, right?
[15:36] <jibel> pitti, right
[15:36] <pitti> jibel: i. e. search for private keys instead of public keys, copy the corresponding pub key, and identity= the private key
[15:36] <pitti> jibel: ok, doing that
[16:01] <wxl> elfy: now i need to check if i have permissions to do so :)
[16:03] <elfy> :p
[16:03] <elfy> wxl: you done the release notes?
[16:04] <wxl> elfy: phillw mentioned some template that i don't think i've yet had a link to but it won't be too hard
[16:04] <wxl> elfy: sadly i had no luck rallying the ppc/amd64+mac crowd :(
[16:05] <elfy> pretty much evrywhere is quiet I think
[16:05] <phillw> wxl: it's not urgent at alpha1 :)
[16:05] <wxl> elfy: where does one mark the images as ready?
[16:05] <wxl> phillw: i know but i fear it's a harbinger of what's to come
[16:05] <balloons> my guess is you'll see posts after it's released about how it doesn't work :-)
[16:05] <elfy> http://iso.qa.ubuntu.com/qatracker/milestones/317/builds
[16:05] <balloons> which is fine for alpha1
[16:06] <elfy> wxl: ^^ - find the looby lou ones - click the button in the 'grey' bar for it - selects all
[16:06] <phillw> wxl: julien will be adding you as lubuntu-product-manager (hopefully today).
[16:06] <elfy> wxl:  then you go to the bottom - administration - status - mark as read and update build status
[16:06] <wxl> sigh don't see any option there elfy. my guess is i still lack permissions to do it.
[16:07] <elfy> wxl:  you want me to do it for you?
[16:07] <wxl> yeah no administration business so it's on julien i guess
[16:07] <wxl> elfy: sounds like i'll need yyou to siiiiiiiiiiiiiiigh
[16:07] <elfy> or that :P
[16:07] <wxl> unfortunately he takes a bit to respond and i bothered him about it on monday in two separate ways..
[16:07] <phillw> elfy: if you'd kindly mark the tested ones as good to go :)
[16:07] <elfy> I can't mark them - ask balloons to do it for you
[16:08] <phillw> or balloons ^^
[16:08] <elfy> phillw: no has perms to mark it - I'd be able to do xubuntu and studio only
[16:08] <elfy> s/no/I no have perms
[16:09] <balloons> mark which ones?
[16:09] <elfy> lubuntu alpha 1's
[16:10] <balloons> everything you say?
[16:10] <elfy> wxl: ^^
[16:10] <wxl> oh sorry
[16:10] <balloons> I marked what had results
[16:10] <wxl> not ppc/amd64+mac
[16:10] <wxl> everything else
[16:10] <wxl> so yeah that's right :/
[16:12] <balloons> gotta love the prints :-) <3 queuebot!
[16:12] <wxl> yay thanks balloons
[16:14] <elfy> just the release notes now then :p
[16:14] <elfy> I love this not having alphas to worry about this cycle \o/
[16:15] <phillw> elfy: you guys not playing alphas?
[16:15] <elfy> not this time around
[16:19] <wxl> phillw: so release note template?
[16:21] <phillw> wxl: https://wiki.ubuntu.com/TrustyTahr/Alpha1/Lubuntu
[16:21] <phillw> only new thing is kernel :)
[16:23] <wxl> phillw: stupid question but i assume i should copy and paste to /UtopicUnicorn/Alpha1/Lubuntu, no? ;)
[16:23] <phillw> wxl: that's as easy a way as any :)
[16:23] <wxl> phillw: that's what i thought :)
[16:24] <phillw> or, you can chose copy from the drop down of options :)
[16:24] <phillw> which is easier :)
[16:24] <wxl> ah k
[16:27] <wxl> argh logging in is taking FOR-EV-ER
[16:35] <phillw> wxl: do you want me to copy it over?
[16:35] <wxl> phillw: no i'm editing now. is upgrading from previous versions relevant?
[16:36] <phillw> it could be. I usually switch to release+1 once A1 is out :)
[16:36] <phillw> but, I'm a glutton for punishment :P
[16:37] <wxl> phillw: https://help.ubuntu.com/community/UtopicUpgrades%7CUpgrade%20Instructions is a fail
[16:37] <wxl> for that matter, so is trusty
[16:39] <phillw> wxl: use the command line... http://manpages.ubuntu.com/manpages/precise/man8/do-release-upgrade.8.html
[16:39] <phillw> it will be release agnostic :)
[16:40] <phillw> if someone wants to run lubuntu a1, they should now of the command line.... they will no doubt need it at some point :D
[16:40] <phillw> s/now/know
[16:51] <wxl> phillw: um, what's new? :)
[16:52]  * wxl looks up the kernel
[16:55] <wxl> 3.15.0
[16:58] <wxl> not seeing anything particularly exciting :)
[17:02] <wxl> um how do i find out what the upstream is for the kernel?
[17:02] <phillw> wxl: let me just fire up the VM :)
[17:03] <phillw> wxl: 3.15
[17:04] <phillw> ditto :)
[17:04] <wxl> phillw: how does one figure this out?>
[17:05] <phillw> I just do a uname :), you can ask on #ubuntu-kernel to confirm that it will remain as 3.15. But as it is A1, just state what it comes with?
[17:05] <wxl> ah
[17:05] <phillw> the kernel freeze is late in the cycle.
[17:43] <phillw> wxl: I've replaced me with you at https://wiki.ubuntu.com/Lubuntu/Testing/#When_do_they_build I will keep an eye on the builds and ping Julien if I see them fail to build :)
[17:43] <phillw> But, that page is now yours :P
[18:12] <elopio> ping ubuntu-qa, somebody around for a quick review?
[18:12] <elopio> https://code.launchpad.net/~elopio/ubuntu-calendar-app/fix1334777-pep8/+merge/224700
[18:13] <la_juyis> elopio, I'll take a look, but we'll need someone else as well :)
[18:13] <elopio> la_juyis: thanks
[18:14] <elopio> la_juyis: this is just static checks, so if you can run flake8 on an up-to-date trusty and you like the diff, it's good to go.
[18:15] <la_juyis> elopio, yeah, was just realising that
[18:15] <la_juyis> let's see
[18:22] <la_juyis> elopio, and some code cleanup as well! good
[18:22] <la_juyis> elopio, everythin looks good from here
[18:22]  * balloons awaits la_juyis to approve :-)
[18:23] <la_juyis> balloons, coming!
[18:23] <la_juyis> :)
[18:23] <balloons> hehe
[18:24] <la_juyis> balloons, done :)
[18:27] <elopio> la_juyis: thanks.
[18:27] <elopio> la_juyis: for when you get bored and want to do some programming, this is waiting for you:
[18:27] <elopio> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1327354
[18:28] <balloons> I may have had something to do with that bug :-)
[18:30] <la_juyis> elopio, I'll have some time tomorrow. Wanna pair up? :)
[18:31] <elopio> la_juyis: sure, but you lead.
[18:38] <wxl> phillw: https://wiki.ubuntu.com/UtopicUnicorn/Alpha1/Lubuntu#preview
[18:38] <wxl> s/\#preview//
[18:39] <phillw> wxl: If I vanish, it will be because
[18:39] <phillw> update-manager -d -c
[18:39] <phillw> killed piglet :)
[18:39] <wxl> phillw: uh oh ;)
[18:40] <phillw> wxl: looks great to me :)
[18:42] <wxl> phillw: official release coming right up
[18:42] <phillw> I ran out of room on / last attempt, have freed up some room.
[18:44] <wxl> alpha2 won't be available until ~july 3rd, right?
[18:44] <phillw> wxl: yeah, wait for the release team to say 'go'. Premature announcements are frowned upon :)
[18:44] <wxl> ko
[18:45] <phillw> wxl: bookmark https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule :)
[18:45] <wxl> phillw: already done :)
[18:45] <phillw> not sure who is announcing it, possibly stgraber ?
[18:47] <stgraber> phillw: yeah, that'll be me
[18:47] <phillw> ooh, net split!
[18:49] <phillw> stgraber: thanks, I'm just easing our new release manager in. Thanks for all your and balloons help in getting him up to speed on things. He is an experienced lubuntu tester, just needs to find his way round release management :)
[18:49] <phillw> ooh, and elfy :)
[18:51] <wxl> announced
[18:51] <phillw> wxl: had you got confirmation from stgraber ? :)
[18:53] <phillw> greetings DalekSec
[18:54] <wxl> phillw: oops. :(
[18:54] <wxl> i didn't announce alpha2. that's what i thought you meant phillw
[18:54] <phillw> wxl: wait for the duty announcer to say it is live. As it's A1, no real harm done. :)
[18:55] <DalekSec_> Howdy.
[18:55] <elfy> hi DalekSec_
[18:55] <wxl> phillw: well i'll wait before spreading the word any farther. sorry stgraber
[18:57] <phillw> wxl: also, if I'm not about on milestone release, give unit193 a polite ask to update the mirror server. As he is here as DalekSec I'm sure he will do so once the announcement goes out :)
[18:57] <phillw> well, was before net split :P
[18:59] <elfy> lol
[19:00] <elopio> balloons: on calendar, the clean environment is not working, right?
[19:06] <balloons> elopio, I seem to remember saying that yes
[19:07] <elfy> balloons: replied to the mail - did you see the pastebin in PMs ?
[19:08] <balloons> elfy, no weird.. it didn't ping me, but I see the pm now
[19:09] <elfy> ok - must have been the tomaw business I guess
[19:09] <balloons> blame the netsplit ;-)
[19:09] <elfy> yep :)
[19:10] <ianorlin> hmm testcase for pcmanfm still mentions open folder as root although that was removed in version 1.2.0
[19:10] <balloons> so for time, yea 30 mins to maybe an hour of demo.. hopefully not an hour, heh
[19:10] <balloons> ianorlin, file a bug, or even file and propose something to fix :-
[19:10] <balloons> it's quick to do, and me and elfy would happily help you
[19:11] <elfy> indeed
[19:11] <balloons> ianorlin, https://bugs.launchpad.net/ubuntu-manual-tests/+filebug
[19:12] <phillw> elfy: once 14.10 upgrade is done (running), I'll go through the alternate test cases, the dual boot has changed terminology and there could well be a bug with the 32bit one.
[19:13] <elfy> ianorlin: make sure to put the testcase number in the bug
[19:13] <elfy> saves someone searching for it :)
[19:14] <elfy> phillw: okey doke
[19:16]  * wxl hums the final jeopardy song
[19:16] <phillw> 32 bit one did not offer me any options in side-by-side. But I was running off-line as using a 3G device gets expensive :)
[19:17]  * elfy just sits back and watches wxl 
[19:17] <elfy> :p
[19:18] <balloons> elfy, what's a good day for you for the hackfest for testwriting?
[19:18] <balloons> I'll make an event page for it once we have a day.. let's just pick now
[19:18] <balloons> July 8th ok?
[19:19] <elfy> if we run them 19-22 UTC any day is good
[19:19] <balloons> elfy, yep I'm thinking that;s the timeframe to run it
[19:20] <balloons> ok, I'll put down July8th 19-22 UTC
[19:20] <elfy> but I'd rather have it a bit later in the schedule - give me some time to sort it out
[19:20] <balloons> elfy, yea we need to tag the bugs or otherwise link them so we can provide it on the event page
[19:20] <balloons> so say July 15th instead?
[19:20] <elfy> ok - that's fine with me :)
[19:23] <balloons> elopio, I have a surprise for you
[19:24] <balloons> but first a question, do you have a tag for bugs for the toolkit helper that need completed>/
[19:24] <elopio> balloons: no, I don't
[19:24] <elopio> generally I tag them 'elopio'
[19:25] <balloons> elopio, hmm.. need something that tags all of them, so I can get a list of bugs affecting only the AP helper
[19:25] <elopio> balloons: feel free to make up one.
[19:25] <balloons> elopio, the reason is the same as the surprise. We're going to make fixing the toolkit helper bugs part of the hackfest ;-)
[19:26] <elopio> woohoo.
[19:26] <elopio> balloons: when is that?
[19:26] <balloons> elopio, I'll go through and try and tag everything with autopilot-helper
[19:26] <balloons> elopio, it's what elfy and I were just talking about
[19:26] <balloons> he'll be focusing on the manual side of things, while I'm hoping to con you into helping out on the automated side
[19:26] <balloons> does July 15th from 1900-2200 UTC work for you?
[19:27] <elopio> balloons: sure, I'll be there.
[19:28] <elopio> balloons: https://docs.google.com/a/canonical.com/document/d/1cpLCK3DMfos9A4hiS-EHuP5pJmHVBnZwmQu-0uLTLus/edit#
[19:29] <balloons> sounds great. Any meta-bugs for the tests that happen to still exist I figure we could tackle then as well.. Like replacing custom code with a helper, or removing OSK useage, stuff like that
[19:29] <elopio> not all of them have bugs reported, but almost all of them are mentioned on that documetn.
[19:29] <balloons> I'd like to host several of these.. looks like we have plenty of content to do :-)
[19:35] <wxl> stgraber: soooo we can announce now officially?
[19:35] <wxl> ahhh hahah thanks :)
[19:38] <elfy> thanks ianorlin
[19:38] <elfy> I'll try and get to that over the next day or so balloons
[19:50] <balloons> elfy, elopio here's the event page: https://wiki.ubuntu.com/QATeam/Hackfest/20140715. I'll send the mail to the list
[19:51] <elopio> thanks
[19:52] <elfy> thanks balloons
[19:53] <elfy> balloons: at some point can we have a look at the manual bugs together - with regard to what you'd like to see worked on - then I'll tag things and change the wiki page to suit
[19:54] <elfy> would perhaps be useful to have that conversation with stgraber before that
[19:57] <balloons> elfy, yea, we'll just nab a tag or tags we want to target for the event. I'd be happy to review with you. With stgraber, might be best to send a mail
[19:58] <elfy> ok
[19:59] <elfy> I just hate seeing those bugs sitting there :p
[20:02] <elfy> balloons: I've added the manual testcase check script where appropriate on the wikis
[20:13] <elopio> balloons: do you know somebody from the calendar that could help with:
[20:13] <elopio> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1334833
[20:17] <balloons> elopio, hmm.. no one right at the moment. you missed the meeting that was this morning :-)
[20:18] <elopio> balloons: ok, I'll work it around because I don't understand the code.
[20:18] <balloons> elopio, I can ask kunal to have a look, but he's asleep atm I'm sure
[20:18] <balloons> elopio, is it a toolkit bug or calendar?
[20:19] <elopio> balloons: don't know.
[20:19] <elopio> I guess calendar.
[20:25] <balloons> elopio, I'll take a look.. at least confirm things for you
[20:45] <balloons> elopio, I don't see what you are seeing in https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1334833
[20:46] <balloons> the timeline components I see correspond to the 3 visible days
[20:47] <balloons> do you have a failing test, or what is driving this?
[20:47] <balloons> ohh wait; ok I do see the duplicate eventbubble now
[20:47]  * balloons invesitgates
[20:47] <elopio> it's not the timeline components the ones that get duplicated, it's the events.
[20:48] <balloons> elopio, yes sorry I see it now
[20:48] <elopio> balloons: don't worry, it's a long path to find them.
[20:48] <balloons> and indeed, the first is duplicated
[20:49] <elopio> balloons: I think this might be affecting the delete too
[20:49] <elopio> because some of the events I delete remain on the screen.
[20:49] <elopio> I have it solved for my test, so I'm going to have lunch.
[20:50] <balloons> elopio, k.. I confirmed and will chase the dev on
[20:50] <elopio> thanks
[20:53] <balloons> I made 4 events, I have 10 objects
[20:54] <balloons> seems to be pretty straightforward duplication