20:00:55 #startmeeting 20:00:55 Meeting started Wed May 16 20:00:55 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:04 #chair pwhalen jonmasters bconoboy ctyler pbrobinson 20:01:04 Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen 20:01:22 #topic 1) Release of the Fedora 17 Beta - Are there any remaining issues blocking the release? 20:02:03 please re-post the etherpad url for the alpha/beta vfad 20:02:33 * jonmasters believes we can ship beta 20:02:46 does anyone have the link for the etherpad doc handy? 20:03:12 http://etherpad.proximity.on.ca:9001/p/Fedora_ARM-VFAD-2012-05-11 20:03:27 do we have a working 3.x kernel for Panda? 20:03:50 no. 20:03:55 no, however that does not need to block release 20:04:11 * djdelorie never got usb working on TS but that's likely not a blocker either 20:04:15 we have a 3.x kernel that works on Beagle. Panda will be unsupported in the beta with the existing kernel 20:04:24 given that the usb *ssd* worked 20:04:26 it's not a blocker, but it would be nice to have 20:04:47 let's treat the panda kernel issue as a high priority post-beta issue. 20:04:51 #agreed it would be nice to support Panda but there is an upstream kernel bug that needs resolution - fix for GA 20:05:13 agreed on skipping TS usb bug for now? 20:05:27 +1 on skipping TS usb bug for now 20:05:31 * jonmasters will spend sufficient time today completing my investigation and sending it on to upstream for analysis 20:05:42 (IOW making it someone else's problem) 20:05:46 it means I couldn't test the "auto mounting of removable media" beta bullet 20:06:04 I can confirm removable media works on TS 20:06:10 believe that bullet is only valid for X-based images which does not include TS 20:06:11 using the SD Card slot 20:06:17 anyone check the auto-check-for-updates bullet? 20:06:34 jonmasters: can anyone help with that? 20:06:51 jcapik1: sure, if you've got hardware and know how to debug a kernel 20:07:04 it'll reliably panic on boot 20:07:08 do our images have the official firstboot in them? 20:07:29 djdelorie: can we turn it around this way...Does anyone have any objections to shipping F17 beta? 20:07:38 the only other thing to check is to see if a clean shutdown shuts down LVM/raid arrays 20:07:42 jonmasters: you know .... I have a working 3.x kernel from ubuntu ... how that comes, that they managed to make it working? 20:07:50 I'm just going over the pre-agreed-on alpha/beta list 20:08:11 jonmasters: no objection, but I think we should make a point of testing a few skipped things before GA 20:08:13 jcapik1: different config. I can boot a kernel with a different config - e.g. all debug options on. It's a percpu bug I think 20:08:21 ctyler: AGREE 100% 20:08:38 jonmasters: ok .... I could also look at the issue tomorrow in the office 20:08:47 jcapik1: I'll send an update TODAY on Panda. So others can pick up that baton from me 20:08:50 in that case, the RIGHT thing to do is to agree to change the alpha/beta list so that we "happen" to pass everything 20:09:33 * djdelorie has no philosophical reason to not release a beta, just wants to see it properly documented 20:09:48 +1 djdelorie 20:09:51 * jonmasters suggests that we have made a good effort to verify the release criteria. I suggest we ship the beta and review what we missed/consider post-mortem considerations for future improvement 20:10:19 does anybody object to jonmasters' suggestion? 20:10:21 IOW we do not change the list, we just document what we failed to meet in review 20:10:44 how will the beta be tagged (in koji, etc.) so we know what went into it? 20:11:01 buenos dias amigos 20:11:11 hola release engineer 20:11:34 better documentation of what/how was tested would be nice. For example, I did test that simple partitions were cleanly unmounted, just not LVM/raid (I couldn't mount a second disk due to the usb problem, and didn't have time to set up an iscsi volume for it) 20:11:34 dmarlin: we could make a snapshot tag. though we do not do that on primary 20:12:19 dgilmore: how are betas tagged or otherwise marked on primary? 20:12:31 (how could they later be reproduced?) 20:12:41 dmarlin: managed via bodhi 20:12:54 dmarlin: we lock down what gets tagged into f17 20:13:05 limit it to only release blockers 20:13:19 dgilmore: ok, so how are _we_ going to handle it (fedora-arm)? 20:13:20 right, so at the point of beta the spiggot is turned off and things go through bodhi 20:13:51 dmarlin: really its just a snapshot in time. the only thing we will release is the images 20:14:10 there is no Fedora tree since we do not have anaconda install images 20:14:15 * jonmasters thinks there's some value to a special tag, but we don't need to go too crazy for beta. Most people using it are already involved in e.g. #fedora-arm and will probably do an yum upgrade to the latest versions anyway 20:14:31 the Everything repo is development/17 that gets updated automatically nightly 20:14:50 we could make a f17-beta tag that shows the packageset snapshot 20:14:55 * djdelorie suggests "rpm -qa" in the wiki under "what we did for beta" 20:15:15 +1 rpm -qa 20:15:30 betas are too transient to worry about reproducing them later 20:15:31 dgilmore: ok, I just think some way to identify what went into this would be nice, in case we later want to know. 20:15:35 #idea most people want the beta to have a known-good pre-built image with some testing. The images we have meet that criteria. Most people will want to upgrade packages and get F17 updates anyway. Therefore, take no special action to tag beta at this stage. 20:15:41 djdelorie: simple and elegant :-) 20:16:02 +1 jonmasters 20:16:05 +1 djdelorie and jonmasters 20:16:11 (i.e., wiki list only) 20:16:15 * jonmasters suggests just doing a koji repo query and document all current versions used for the images 20:16:26 thanks 20:16:36 i.e. not just image content, but also the versions of all other packages that might have been picked up or otherwise used in the beta process 20:16:57 essentially the same thing, just more global. I'm OK with that 20:17:00 that's easy enough to do for the 17 devel repo, right. I'm sure dgilmore could stash that on the wiki in 10 seconda 20:17:13 as long as they haven't changed since bconoboy's images :-) 20:17:23 its easier to just clone the f17 tag to f17-beta 20:17:34 dgilmore: then let's do that 20:17:42 it's easy to remove the tag later 20:18:16 so shall we release the current nightlies as beta? And for Panda we won't release an image. Right? 20:18:32 how about we release beta tomorrow? Gives some time to sync bits to mirrors 20:18:41 ok with me 20:18:46 if we're going with the images currently available via yum I can do one last update to ensure they match. 20:18:59 will we need to test them again? 20:19:09 yes 20:19:11 believe we should. things have happened since friday. 20:19:17 agreed 20:19:20 +1 20:19:22 we should 20:19:35 I don't want to "just upgrade" beyond that. I'm ok with "just upgrade" if we're going to re-test each one this afternoon 20:19:39 (I am, infact, regenerating some images right now) 20:20:05 so if dgilmore creates the beta tag right now, pull that in and then let's leave it alone and not change the beta images again 20:20:18 sounds good 20:20:19 jonmasters: its created 20:20:31 we know from history that "we'll just..." results in images that don't work :) 20:20:41 dgilmore: thanks 20:21:07 dgilmore: after the meeting let's decide where to put these images 20:21:17 ok, so bconoboy will ping us when there are more images. If they boot and seem to work tonight, we ship tomorrow? 20:21:31 bconoboy: i already know :) ill just tell you 20:21:56 sounds good, all agreed on shipping tomorrow? 20:21:59 dgilmore: in that case I will tell you when it's safe to pull them from scotland :-) 20:22:00 +1 20:22:18 +1 20:22:21 +1 20:22:31 +1 20:22:31 * ctyler wondering what our target for GA is (or should be) 20:22:41 bconoboy: for GA we really need to have the VEXPRESS image using virtio :) packages are still installing 20:22:47 ctyler: let's get through agenda and then talk about that 20:22:50 * dmarlin thinks that's for another meeting 20:23:11 How many +1's do we need before we call it passed? 20:23:16 #agreed final tests on images before F17 beta release tomorrow 20:23:19 bconoboy: +1 its passed 20:23:23 woot 20:23:34 bconoboy: we need just positive sum i guess 20:23:45 #topic 2) Release criteria for a F17 ARM final - Release criteria - http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Final_Release_Criteria 20:24:53 There are a lot of ARMTracker issues still open. Do we really need to close them all? 20:25:05 bconoboy: we need to triage them all 20:25:14 bconoboy: decide if they are blockers or not 20:25:21 Okay, that's fine 20:25:23 if they are blockers they need resolved 20:25:42 bconoboy: we probably should have a ARMF17Blocker tracker 20:25:54 and use that to track the blokcers that must be resolved 20:26:00 sounds reasonable 20:26:39 I'd like to see specific hosts to be supported listed in the final release requirements. If it's just vexpress and everything else is icing that's fine 20:27:28 the panda and vexpress were the only targets we had 20:27:35 How bad/long does this Panda issue look? 20:27:36 * djdelorie would like minimum functionality on hardware, even if it means custom kernels. X, usb, sound, etc, whatever's supportable 20:27:40 do we want to stick with panda for final? 20:27:56 ctyler: pretty bad .... 20:28:05 ctyler: it's solvable, just not solved. 20:28:26 bconoboy: we want :] 20:28:27 * dgilmore thinks we should support guru/sheevaplug, panda, beagle, trimslice, vexpress 20:28:46 dgilmore: as release blockers? 20:29:30 * djdelorie thinks there's two support levels: targets with F17 official kernels, and targets with custom kernels 20:30:06 djdelorie: custom kernels == on your own 20:30:07 I think we should support them and release images but not block on them 20:30:26 if we release we must support 20:30:35 dgilmore: I mean, we provide a kernel-less image like we already do, or an image with a custom kernel 20:30:47 nightly snapshots are at your peril, but this is different 20:31:18 whether we *support* them or not is a different question 20:31:23 dgilmore: Don't know about plugs (haven't created images for them), but your list is otherwise fine. Which of those would we provide X support on? 20:31:27 ctyler: it's likely trivially solvable, just needs some cycles. I've two other things to get to today, then I'll throw the rest of the day at it. If I can't fix Panda tonight, I'll at least send an email to make it upstream's problem with some analysis 20:31:29 djdelorie: we shouldnt, people are free to take a image and replace the kernel 20:32:45 bconoboy: X-capable subset of that list is Panda, Trimslice, Beagle, vexpress. Do we have an open source fb implementation for each? 20:33:06 ctyler: afaik, only vexpress works with X today. 20:33:08 bconoboy: are you still trying to create a Panda/X image? 20:33:08 I tested vexpress X last week 20:33:28 iirc trimslice FB needs 3.5 or 3.6 20:33:28 omap has omapdrm 20:33:29 jcapik1: no, awaiting confirmation that it's useful to do so 20:33:36 bconoboy: it is 20:33:43 I tested vexpress X too, worked fine 20:33:46 but not sure of status of omapdrm actually working in f17 20:33:47 our panda kernel has X support? 20:34:03 tergadrm needs a bunch of stuff in linux-next 20:34:04 that kernel has a staging driver for drm 20:34:06 bconoboy: it currently works with ubuntu kernel only, but ... 20:34:13 so likely will be able to be added in 3.5 20:34:23 jcapik1: right, so, to add X support is just a yum install command 20:34:26 bconoboy: we'll certainly have OMAP in F18, might be able to do an update in F17 for it 20:34:27 bconoboy: I hope we'll get a working panda kernel soon 20:34:43 jcapik1: using a ubuntu kernel is not a supported recommened whatever you want to call it option 20:34:50 Okay, so the only X image for F17 Final, as a release blocker, is vexpress? 20:35:13 * djdelorie is OK with that 20:35:19 dgilmore: we can at least prepare it 20:35:20 I think so, and I wouldn't even make it a blocker, but I guess 20:35:25 dgilmore: and test 20:35:35 jonmasters: We need something to test X release criteria on. 20:35:43 sure, ok, do vexpress then 20:35:58 jcapik1: there is no point in testing using something we will never ship 20:36:23 dgilmore: don't we wanna ship it? 20:36:38 * jonmasters has no interest in using an Ubuntu kernel for testing - we can build some hacked up kernel package for testing based on Fedora if we want to stash something on a fedorapeople page 20:36:40 Okay. So for F17 final we will support: Serial Console Panda, Beagle, Trimslice, VExpress. For X we will support VExpress. We can evaluate the dream/guruplug after this meeting and add it later if wanted. 20:37:04 if we don't already have a plug image, let's skip it. 20:37:04 bconoboy: sure 20:37:16 +1 20:37:18 bconoboy +1 20:37:23 bconoboy: +1 20:37:27 +1 20:37:58 bconoboy: would be good to have a guru image, gives us a v5tel platform 20:38:05 pwhalen: I think they like it :-) Anything else on release criteria? 20:38:13 I can setup the ARMF17Blocker tracker mentioned earlier 20:38:18 ctyler: I'm actually making a beagle armv5tel image for pbrobinson's benefit... 20:38:33 jcapik1: we want to ship it, its enabled in our kernel, testing a ubuntu kernel is invalid as a test case, as they have who knows what patching in it. and it doesnt match what we ship, either way we can introduce/fix bugs by the differences 20:38:39 ... plus the rpi images, but expect those to be deprecated soon 20:38:53 bconoboy: i have a very happily working guruplug 20:38:55 rpi deprecated? 20:39:03 bconoboy: need to update and test my sheevaplug 20:39:04 we can't ship the rpi images in Fedora, they have to be a remix 20:39:11 ctyler, oh 20:39:16 nb: bconoboy-rpi images deprecated when seneca does an official release 20:39:32 dgilmore: ok .... let's test it once we have our own kernel 20:39:48 #agreed F17 final we will support: Serial Console Panda, Beagle, Trimslice, VExpress. For X we will support VExpress 20:39:50 dgilmore: Let's discuss guru images after the meeting 20:40:00 #topic 3) Upgrade Koji builders to F17? - Is there a reason to upgrade at this time? 20:40:15 I'd like to, at a minimum, see F17 kernels on our arm builders. 20:40:22 what's the ETA on dropping F15 support in koji-arm ? 20:40:24 when does primary arch update their builders? 20:40:27 bconoboy: ok 20:40:39 fossjon: primary uses RHEL kernels on their builders. We don't have that option 20:40:40 fossjon, primary arch uses rhel 20:40:41 primary arch builders aren't Fedora anyway 20:40:47 fossjon: primary builders run latest RHEL 20:40:48 hmm 20:40:52 i forgot that 20:40:54 I'd like to wait at least until F17 is GA 20:40:54 ok nm 20:40:58 bconoboy: a large number of our builders here are Pandas, aren't we gated on getting that kernel? 20:40:59 I don't feel good about using a 2.6.4x kernel with Fedora 17. 20:41:14 bconoboy, why 20:41:18 F15 will be EOL for primary 1 month after f17 GA 20:41:24 ctyler: Yes, but I expect we'll resolve that soon enough 20:41:38 so i feel that between GA and EOL we should migrate them 20:41:39 since we skipped F16, does F15 stay on the "supported" list until F18? F15 is the "previous" release in our case... 20:41:46 dgilmore: +1 20:41:50 we could start building builder images and doing some testing 20:41:54 Right, and we can test on a couple builders at that point, and roll out when we get a good result. 20:41:56 jwb: Because there may be (undocumented) differences on how packages behave differently when the version string is 2.6.x vs 3.0 20:42:19 i would have expected those to all get flushed out by now 20:42:26 bconoboy: me neither :] it can possibly affect our tests 20:43:05 In addition, the 3.3+ kernel may have capabilities that packages rely upon that we just don't know about, that are not present in 2.6.42 (3.2) 20:43:12 We have bcfg2 implemented across the buildsystem here (thanks Frojoe!) and we can use that to builderify a standard image once we get the kernels sorted. 20:43:19 bconoboy: +1 20:43:28 * jonmasters advocates for keeping f15 alive until F18 beta 20:43:31 f15 primary is on 2.6.43, which is 3.3 20:43:35 jonmasters: Why? 20:43:38 or alpha 20:43:41 jonmasters: not viable 20:43:42 jonmasters: ??? 20:43:46 if you've been following that on arm properly, arm should be on 2.6.43 20:43:57 jonmasters: +1 20:44:00 jonmasters: I think you meant "f17 beta" :-) 20:44:02 jonmasters: define "alive"? 20:44:13 we should at least keep F15's "yum update" working until F18, even if there are no new packages 20:44:14 jwb: ive not built 2.6.43 for arm due to the issues we had with audit not working on 3.3 20:44:19 we're missing f16 .... 20:44:21 We won't be getting fixes from upstream starting 5 weeks from now 20:44:21 ctyler: available for downloading packages, etc. 20:44:23 i see 20:44:29 djdelorie: yum will always work for f15 20:44:34 jonmasters: available but not updated, sure 20:44:39 until mirrors stop carrying it 20:44:39 ctyler: yea 20:44:47 I suggest, once F17 is *final* we start migrating builders to it. 20:45:01 djdelorie: primary mirrors archive things, but never remove 20:45:09 dgilmore: ha! 20:45:15 * jonmasters specifically made the F15 comment actually because I don't want to rush to touch the builders :) 20:45:16 +1 bconoboy 20:45:19 bconoboy: Ithink that's what dgilmore suggested, no? 20:45:21 bconoboy: s/migrating builders/testing a couple builders/ 20:45:40 ctyler: It can be a very conservative migration, over the course of months 20:45:40 the builders are working (more or less). Testing a couple and doing a planned migration is ok, but very slowly 20:45:43 * djdelorie has an F15 arm server he'd rather not rush to update, too 20:45:44 bconoboy: ok 20:46:19 * jonmasters is known to be very conservative about software updates :) 20:46:29 it's good to have at least 2 (stable) releases 20:46:41 bconoboy: are there other issues with a "mixed" environment (F15 & F17 builders) ? 20:46:54 jcapik1: right, we won't get that, but we should keep f15 available somewhere for download, like the old mirrors on primary 20:47:05 dmarlin: Only the kernel version is at issue- and I'd say it's more fragmented on our builders than it would be if we were on F17. 20:47:16 jonmasters: just because its EOL doesnt mean its not available 20:47:20 right 20:47:27 jonmasters: just means that its not updated at all 20:47:30 Switching builders is *different* From retiring F15 from repositories. Let's not combine the two. 20:47:31 yea, indeed 20:47:35 yum etc will still work 20:47:37 bconoboy: I thought all the F15 builders were on the same kernel version 20:47:44 and the bits will still be on the mirrors 20:47:49 dmarlin: I don't think so 20:48:08 bconoboy: please check 20:48:23 * jonmasters thinks the correct thing to do is to leave the builders alone for now. Once we have shipped F17, let's have a VFAD or two dedicated to making some very nice test images for builders and do some testing 20:48:31 bconoboy: if not, I think they should be 20:48:33 we really do want builders to all be identically configured 20:48:44 dgilmore: +1 20:48:45 then we can make some nice standard builder images 20:48:46 that only works if they're identical hardware 20:48:52 +1 jonmasters 20:49:00 (reproducible) 20:49:02 djdelorie: identical nvr wise 20:49:23 jonmasters: +1 20:49:24 +1 jonmasters 20:49:30 the same scripts being used for the nightlies can be used to make some nice builder images 20:49:31 we dont have the same hardware on primary. but we do have the same nvrs and config files everywhere 20:49:48 dgilmore: I was referring to just the kernel. Let's nope the nvrs are the same otherwise 20:49:50 i dont get something 20:49:52 then in another 6 months we can move to livemedia made builder images 20:49:58 if pa never updates their builders then why do we have to>? 20:50:09 or do they update their own rhel versions 20:50:17 bingo 20:50:19 fossjon: because it's better for us :-) 20:50:20 PA doesn't use fedora. they do update their rhel instances 20:50:24 fossjon: indeed, they run a supported RHEL version 20:50:29 i know they dont use fedora 20:50:33 but do they update? 20:50:36 yea 20:50:36 rhel and PA get *much* better testing than arm. using f17 as builders is good testing. 20:50:37 fossjon: we update the builders on primary once a month 20:50:38 and if so how often 20:50:48 fossjon: and reboot when there is a kernel update 20:50:54 i see 20:50:58 I think it makes sense to upgrade to F17 only because F15 is going to be EOL 20:51:12 otherwise I would advocate for remaining on F15 indefinitely :) 20:51:14 f15 is also the first version of the combined arm/armhfp... Package origins are *slightly* dicey. Much better situation with F17 20:51:19 (if it aint broke...) 20:51:28 #agreed once f17 arm is final we hold a vfad to create builder images and discuss the upgrade further 20:51:35 and if I'm not mistaken, we still have F15 builders crashing on a fairly regular basis. 20:51:40 jonmasters: it will be broke, kernel features at least 20:51:47 yea 20:51:50 Just because we've gotten accustomed to rebooting a few systems a day doesn't mean that we have achieved stability. 20:51:51 * djdelorie agrees F17 is "better" but still thinks two available versions is better than one ;-) 20:51:58 And we're never going to track down stability issues in an F15 kernel. 20:52:12 #topic 4) vexpress kernel - who will take the lead on this? 20:52:21 bconoboy: not sure if it's "F15 builders" or "alpha-level hardware builders" that are doin' the crashing 20:52:21 djdelorie: well F15 is going to be EOL so the best we can do is what we said, keeping the old bits available for download 20:52:32 yes, that's what I want 20:52:32 Sonar_Gal, frankly, it *is* broken. And moving to F17 is the best path to a fix. It can be incremental, but we need to agree when to do this. 20:52:54 bconoboy: we did... once F17 is GA 20:53:06 did we? 20:53:12 yup 20:53:20 bconoboy: sure, see the topic has changed 20:53:25 :) 20:53:32 whew. okay. 20:53:47 we agreed with the builders to do a VFAD after F17, get some nice builder images tested, then plan a migration 20:53:56 okay, vexpress :-) 20:54:18 at this point vexpress is not a kernel internals issue so I do not need to own it 20:54:30 we have a workaround for F17 to keep MMCI as a module 20:54:39 therefore I suggest dgilmore and pbrobinson continue to work that 20:54:48 Somebody needs to make non-scratch vexpress builds in F17 and F18 that actually work. 20:54:57 I think dgilmore has f17 in hand 20:55:09 what we need is a rebuilt official F17 kernel with the vexpress (not versatile) config either with MMCI built in or with the dracut config 20:55:16 bconoboy: i have the changes sitting in my git checkout will commit and build 20:55:25 I personally favor building MMCI in but I am happy with the dracut hack if you guys insist 20:55:42 dgilmore: Okay, if you're taking F17 *and* F18 please communicate that to pbrobinson. Jon will be hands off as well, so it's all yorus. 20:55:46 i will also update dracut with patches to pull in modules needed on various arm systems 20:56:10 bconoboy: right, I isolated the original problems with vexpress. My work is done ;) 20:56:26 dgilmore: Is this a before-beta-release item? 20:56:26 ok 20:56:40 bconoboy: will be done today 20:56:47 okay 20:56:48 but a kernel build takes a long time 20:57:10 #agreed dgilmore, pbrobinson to take the lead on vexpress kernels for f17, f18 20:57:20 #topic 5) Your topic here 20:57:36 however, for testing and making images we do need to agree what is landing, etc. So there is a dracut update, ok. Then there's a kernel rebuild. If you want to wait for the kernel then can be hit the button on that now? 20:57:37 anything else to be discussed in our final 3 minutes? 20:57:42 do we have a guess for F17 final? 20:57:48 We have the kernel config for vexpress, etc. Who's hitting the build button? 20:58:13 topic 5: What's the deal with raspberry pi f17? 20:58:14 jonmasters: i am 20:58:18 Actually, a Target would be better than a guess :-) 20:58:23 ok 20:58:50 bconoboy: mine is ETA end of June still 20:59:05 er, I mean, the F17 release for the raspberry pi 20:59:09 s/release/respin/ 20:59:25 bconoboy: We're close to a beta. Need to beat the Debian frankenimage on a couple of performance issues :-) 20:59:56 I'm hoping to get the kernel/firmware combo nailed down tomorrow. 21:00:43 ctyler: how goes the getting support upstream? 21:01:42 dgilmore: communication is still swamped out, it's like a CPU that's trashing. I got word from Eben on one issue out of 5 I asked him about :-S 21:02:27 I have commit on the github linux repo for the rpi, will push the fedora config. We really need to get it upstreamed from there or we'll be patching forever. 21:02:44 * ctyler meant, really need to get the rpi patches upstreamed to the kernel 21:03:33 anything else we would like to discuss? its after 5 now.. 21:03:45 (no other meetings scheduled here) 21:03:57 * ctyler has some topics that can wait 21:04:15 nothing else 21:04:21 +1 on -1 meeting :-) 21:04:28 +1 21:04:29 .... last call! 21:04:41 #endmeeting