17:30:02 <nirik> #startmeeting FESCO (2011-02-09)
17:30:02 <zodbot> Meeting started Wed Feb  9 17:30:02 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:02 <nirik> #meetingname fesco
17:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:02 <nirik> #topic init process
17:30:02 <zodbot> The meeting name has been set to 'fesco'
17:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:24 <nirik> morning folks. ;)
17:30:38 <DiscordianUK> hi de hi
17:31:30 * nirik waits for fesco folks to show up.
17:31:36 <mmaslano> good evening ;-)
17:31:39 * mclasen present
17:31:49 * cwickert is here
17:31:51 * notting is here
17:32:05 <mjg59> Hi
17:32:56 <nirik> SMParrish, ajax, kylem? :)
17:32:57 <ajax> hidey-ho, neighborinos
17:33:20 <nirik> ok, I guess lets go ahead and dive in then...
17:33:28 <nirik> #topic #516 Updates policy adjustments/changes
17:33:29 <nirik> .fesco 516
17:33:30 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516
17:33:35 <kylem> hi.
17:33:52 <nirik> I talked with lmacken about the anon karma entries and what it would take to verify emails or limit ip's.
17:34:08 <nirik> he said it's possible, but would be a lot of work with the current version. He can add it as a wishlist for 2.0.
17:34:37 <nirik> so, what would we like to do with the 'allow anon folks karma to count' issue?
17:34:56 <mjg59> I think leave to 2.0 in that case
17:35:04 <mmaslano> fine with me
17:35:05 <mjg59> Unless anyone wants to volunteer to implement it
17:35:13 <nirik> yeah, I would be fine to defer/not do this at this time.
17:35:18 <ajax> same
17:35:30 <notting> aye
17:35:38 * mclasen concurs
17:35:54 <nirik> #agreed will defer anon karma counting until 2.0/later.
17:36:02 <nirik> #topic #515 Investigate a "features" repo for stable releases
17:36:03 <nirik> .fesco 515
17:36:04 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
17:36:07 <nirik> Any news on this?
17:36:17 <nirik> cwickert: I know you have been traveling a ton, so likely haven't had a chance to look at it.
17:36:24 <cwickert> I have been talking with lmacken about this
17:36:41 <cwickert> he said that it only requires minor changes in bodhi
17:36:50 <cwickert> basically we only need 2 more tags in koji
17:37:02 <cwickert> and bodhi relies on the info from koji
17:37:12 <nirik> would this be another branch or ?
17:37:25 <nirik> ie, how do I make a stable vs feature build/commit?
17:37:38 <cwickert> like if you select "enhancement" and "testing", it will end up in updates-features-testing
17:37:45 <cwickert> yes, in git we need a new branch
17:38:04 <cwickert> I haven't found the time to write all this up yet
17:38:11 <cwickert> I have just come hone yesterday
17:38:17 <dgilmore> cwickert: would this also need a extra set of branches in git and fedpkg work to send the build to the right place?
17:38:26 * nirik nods. Yeah, a write up would be good... but I understand travel being draining. ;)
17:38:35 <cwickert> nirik: I will, I promise
17:39:03 <cwickert> dgilmore: as mentioned it will require new branches in git, not sure about the impact on fedpkg
17:39:06 <nirik> would it also be seperate in pkgdb?
17:39:09 <dgilmore> cwickert: along with extra pushes by releng and some minor fedora-release update to ship a .repo file that could be enabled
17:39:31 * nirik nods. Lots of details on this kind of thing... we would need to weigh if they would be worth it.
17:39:33 <dgilmore> nirik: i would think so
17:39:50 <mjg59> What would koji build against?
17:39:53 <dgilmore> unless we created the git branch automatically
17:39:55 <mjg59> The contents of the enhancement repo?
17:39:58 <cwickert> I don't think it needs a new 'release' in packagedb
17:40:07 <cwickert> mjg59: yes
17:40:10 <dgilmore> mjg59: it would need new targets in koji
17:40:11 <mjg59> Ok
17:40:31 <nirik> yeah, I would guess it would have to... or we would only allow leaf applications to be in the feature repo.
17:40:36 <cwickert> erm, right, targets, not tags as I said
17:40:46 <dgilmore> cwickert: it would unless we just created 2 branches at mass branching
17:40:55 <dgilmore> wether the second is used or not wont matter
17:40:57 <mjg59> So the way I see it, we have the choice of this approach (generic enhancements repo) or a large number of individual per package/package set repos
17:41:19 <nirik> mjg59: yeah, repos.fedorapeople.org / etc.
17:41:19 <dgilmore> mjg59: plusses and minuses to both
17:41:25 <cwickert> the latter seems way more work
17:41:36 <mclasen> of course, the mess starts once you need to build stuff against each other...
17:41:38 <cwickert> both for users and maintainers
17:41:55 <mjg59> The latter approach would let people opt-in to invidual packages, but does hit combinatorial problems
17:42:19 <mjg59> I guess since we know what the issues are in doing it through koji, we should probably take it to devel@?
17:42:27 <nirik> also there will likely still be a case for repos.fp.o even if there is a features repo.
17:42:33 <mjg59> Right
17:42:37 <cwickert> indeed
17:42:48 <nirik> mjg59: I'd like to see a write up with all the details spelled out...
17:43:07 <nirik> then we can take that to devel@ and see what folks think of it, to rel-eng to see if there are resources, etc.
17:43:14 <cwickert> mjg59: before we take this to devel@ I'd like to discuss it here
17:43:34 <cwickert> so suggestion: write everything up in the wiki and discuss it next week, then go to devel@
17:43:41 <mjg59> Ok, that works for me
17:43:50 <notting> sounds good.
17:44:01 * nirik nods.
17:44:18 <nirik> any objections?
17:44:38 <nirik> #agreed will get a proposal in the wiki and discuss next week before opening for wider feedback.
17:44:56 <nirik> thanks for working on this cwickert
17:45:00 <nirik> #topic #517 Updates Metrics
17:45:00 <nirik> .fesco 517
17:45:01 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517
17:45:12 <nirik> anything on this? I think SMParrish was going to try to, but he's not here today.
17:45:56 <nirik> ok, lets move on then...
17:46:09 <nirik> #topic #544 List of services that may start by default
17:46:09 <nirik> .fesco 544
17:46:10 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544
17:46:30 <notting> so, i went through the list in the ticket and sorted them into the buckets from spot's proposal
17:46:51 <nirik> notting: by 'not network enabled' you mean, not listening on external interfaces? because some of the ones in that bucket are listening on localhost by default I think...
17:47:06 <notting> right
17:47:32 <nirik> ie, quagga doesn't seem like it would be very usefull with just localhost. ;)
17:48:04 <ajax> unless you're doing something very weird with virtual machines i guess
17:48:05 <nirik> hum. exim and sendmail are in there, but postfix isn't set to start by default?
17:48:15 <notting> the quagga service that starts by default is just a monitor for the quagga daemon. the daemon itself doesn't
17:48:57 <kylem> would hope routing daemons don't start without configuration. ;-)
17:49:01 <nirik> doesn't udev start a udevd that keeps running?
17:49:19 <nirik> perhaps we should go over this by group? or ?
17:49:34 <notting> udev is started in rc.sysinit/systemd; the udev init script is for saving persistent rules, etc.
17:49:51 <notting> we certainly can go through it by group if people want
17:50:10 <mclasen> if udev kept running it would go in the next group... (exception to make things work)
17:51:08 <notting> any other comments on the first group?
17:51:57 * nirik still wishes pcsc-lite didn't start on machines without the hardware, but thats another bug I think.
17:52:09 <nirik> that group seems ok
17:52:16 <mmaslano> same with bluez
17:53:35 <kylem> nirik, indeed
17:53:45 <nirik> ok, second group?
17:53:49 <notting> i thought bluez *was* fixed these days
17:53:52 <nirik> One-shot service on boot
17:54:57 <nirik> all those seem ok to me.
17:55:59 <ajax> yeah, i can't see anything obviously wrong with that list
17:56:07 <kylem> they look fine to me
17:56:28 <nirik> ok, on to "Permitted via exception/requirement for operation"
17:57:00 <notting> i was a little liberal here for 1) things required to bring up networking 2) things required to mount filesystems
17:57:03 <nirik> I have a few questions here... coda-client and rp-pppoe ?
17:57:13 * nirik installs to look.
17:57:55 <ajax> coda's a network filesystem
17:58:11 <notting> oh wait
17:58:13 <nirik> yeah, just wondering what the init script does... mounts them?
17:58:24 <notting> the rp-pppoe is the server side, so that should probably be moved
17:59:12 <notting> unless i'm misunderstanding it
17:59:32 <nirik> coda-client init script starts a cache manager?
18:00:00 <kylem> brb.
18:01:05 <nirik> so, not sure on that one, I suppose it might be ok.
18:01:18 <nirik> yes, rp-pppoe should go in the 'should be fixed' IMHO
18:01:51 <nirik> also, xinetd out of the box has no services at all enabled, so perhaps it should also go to 'should be fixed'
18:02:32 <mmaslano> notting: what about dnsmasq, shouldn't it run with libvirtd?
18:02:47 <notting> libvirtd starts dnsmasq itself if it needs to
18:03:03 <mmaslano> ok
18:03:39 <notting> nirik: hm... i could see that, but i don't know that we want xinetd-using services to have to have a two-stage process for enabllement
18:04:42 <nirik> bonus idea: chkconfig on a xinetd service chkconfig's xinetd on if you enable a xinetd service.
18:04:50 <nirik> (no, I'm not saying I will implement that. ;)
18:05:21 <nirik> I suppose it could stay... it's not installed by default anymore anyhow, right?
18:05:47 <notting> no
18:07:00 <nirik> so, rp-ppoe -> fixit... what do folks think of coda-client? should we try and find out more, or just leave it for now?
18:09:12 * nirik waits for everyone to finish installing and looking at it. ;)
18:10:06 <ajax> i'm fine with leaving it for now
18:10:15 <nirik> ok.
18:10:21 * mclasen has no problem with it
18:10:29 * nirik doesn't feel too strongly either way.
18:10:46 <nirik> any other comments/changes for the "Permitted via exception/requirement for operation" section?
18:11:14 <nirik> ok, anything for "Looks like they need disabled" ?
18:11:40 * nirik thinks those look fine to diable.
18:11:43 <nirik> disable even
18:11:58 <mmaslano> could we sent proposal to devel list before vote?
18:12:13 <mmaslano> maybe developers will have valid arguments
18:12:35 <nirik> sure, we could...
18:13:03 * mclasen notes that the iscsi-initiator-utils package has both client and server bits, it seems ?
18:13:09 <DiscordianUK> that'd go on and on and on
18:13:18 <mjg59> Probably easier just to file bugs
18:13:28 <notting> mclasen: no, the iscsi server is in... isns-utils? some other package
18:13:30 <mjg59> Anyone who disagrees knows where to find us
18:13:39 <DiscordianUK> FESCo can and should decide
18:14:01 <mmaslano> mjg59: bugzilla looks also ok
18:14:29 <nirik> that leads to the next question: After we populate this list, shall we ask FPC to review and approve exceptions (provided they are willing to), or handle them ourselves?
18:15:19 <ajax> fpc i think
18:15:57 <notting> i'm ok with either
18:16:10 <nirik> I don't expect there to be too many, but yeah...
18:16:51 <nirik> how about this: We codify the list we have + spot's proposed guideline. I'll ask FPC if they would be ok with handling exceptions or not, and ask them to add this into packaging guidelines?
18:17:06 <ajax> sure
18:17:32 <mmaslano> ok
18:17:36 <mclasen> having the proposed guideline accepted and worked into the packaging guidelines would be best, imo
18:17:49 <notting> nirik: wfm
18:17:57 <nirik> mclasen: you mean ask FPC to ok what we have now?
18:18:47 <nirik> would anyone care to write up exactly what we have now on the wiki?
18:18:49 <mclasen> no, I wanted to reinforce niriks earlier comment ("how about hthis:...)
18:20:17 <nirik> ok, not sure where we are, so:
18:20:59 <nirik> proposal: We write up what we have now on the wiki. We run that by FPC and ask if they would like to handle exceptions or want us to.
18:21:10 <ajax> +1
18:21:19 <mjg59> +1
18:21:19 <nirik> +1 from me. (although if someone will step up to write up on the wiki that would be great to me. :)
18:21:24 <mmaslano> +1
18:21:27 <mclasen> +1
18:21:32 <cwickert> +1
18:21:39 <nirik> #agreed We write up what we have now on the wiki. We run that by FPC and ask if they would like to handle exceptions or want us to.
18:21:41 <notting> +1
18:21:52 <nirik> Anyone want to write it up? If not, I can get to it at some point. ;)
18:22:20 <nirik> #topic #518 Abrt
18:22:21 <nirik> .fesco 518
18:22:22 <zodbot> nirik: #518 (Abrt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/518
18:22:29 <nirik> ok, so they have a roadmap link for us...
18:22:38 <kylem> ugh, sorry, not feeling so great today. back now.
18:22:49 <nirik> https://fedorahosted.org/abrt/wiki/Features
18:22:53 <nirik> kylem: no worries.
18:22:59 <ajax> ooh, a roadmap
18:23:31 <nirik> well, a collection of features they would like to implement at some point.
18:23:37 * cwickert wonders why they don't use tickets and the roadmap feature provided by trac
18:24:12 <nirik> yeah, not sure.
18:25:00 <nirik> so, what action do we want to take here (if any).
18:25:11 * nirik is happy the abrt folks are listening and working to improve things.
18:25:24 <ajax> looks like a reasonable roadmap.  i don't agree with the prioritization completely, but i'm also not about to micromanage it
18:26:45 <ajax> (i still don't understand how anyone can not understand why we need difs, but hey)
18:27:48 <nirik> I think the "Provide a way for maintainers to blacklist their packages without changes into abrt package?" might get lots of the folks who dislike/don't want to deal with abrt reports happier.
18:28:03 <nirik> of course then there are a bunch of crashes our users get that aren't dealt with either.
18:28:30 <cwickert> I don't like this idea, at least not if the rationale is just "I don't care"
18:28:50 <nirik> yeah, better dup handling would also help that case.
18:28:57 <cwickert> if it is "gnash has way too many crashes", this is ok for me
18:29:04 <ajax> could do a pseudocomponent in bz for unowned crashes?
18:29:19 <ajax> not a great idea really
18:29:36 <cwickert> I mean, how do *we* want to deal with exceptions? is it just that any packager can opt out or we want to have a list of packages?
18:29:50 <ajax> though, again: maybe reporting to bz isn't the best idea.
18:30:08 * nirik for example looks at the 473 bugs at https://admin.fedoraproject.org/pkgdb/acls/bugs/rhythmbox (almost all of which are abrt)
18:30:32 <nirik> cwickert: good question.
18:30:34 <cwickert> I guess with proper duplicate detection it comes down to a reasonable list
18:31:24 <nirik> the thing is: if there's no one dealing with the reports (due to overwork, or lack of info in them, or whatever), it's likely better to not have abrt report them and give people false hope that it will get looked at.
18:32:09 <ajax> i kind of feel like the thing to do now is see how much of these have been addressed in 3-6 months
18:32:25 <cwickert> or report it to upstream directly
18:32:30 <notting> yes. although i'd like to figure out how to fix it so that crash reports can at least be somewhat addressed
18:32:59 <nirik> when they improve the dup detection, is there a way for them to run thru the existing reports and dedup?
18:33:51 <nirik> that might be nice if possible.
18:34:14 <nirik> anyhow, I'm ok with waiting a while and see how much things improve. We are at least used to the current status quo.
18:35:56 <nirik> Any other ideas? Should we keep this ticket and revisit in 3 months? or close it? or can we address anything else here.
18:36:13 <notting> i like the idea of doing a de-duplication cycle in bz, if possible
18:36:39 <cwickert> +1
18:37:01 <nirik> I can ask them to look into that. ;)
18:37:09 <cwickert> I think all we can do at this point is provide some more whishes in their trac
18:37:19 <cwickert> and then look at things again in X months
18:37:59 <ajax> that's pretty much where i'm at
18:38:01 <cwickert> noteworthy wishes: de-duplication, blacklist, direct submissions to upstream
18:38:07 <cwickert> anything more?
18:38:39 <nirik> ok, sounds good to me. Any objections to that plan?
18:39:00 <nirik> #agreed will make more suggestions, revisit in a few months to check on progress or ideas to improve.
18:39:09 <nirik> #topic #556 Need to access all packages that only use the deprecated and now removed V4L1 API
18:39:09 <nirik> .fesco 556
18:39:10 <zodbot> nirik: #556 (Need to access all packages that only use the deprecated and now removed V4L1 API) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/556
18:39:16 <nirik> This is a provenpackger request.
18:39:18 <cwickert> -1 to this request
18:39:28 <nirik> I sent it to sponsors as per our process, and there were -1's there, so it comes to us.
18:39:52 * cwickert notes there was not a single +1 but only -1
18:40:07 <cwickert> s/-1/-1's
18:40:39 <nirik> yeah.
18:40:48 <cwickert> IMHO he should 1) file bugs and provide patches and 2) become co-maintainer for the packages in question
18:40:49 <ajax> i don't really have a problem with this, beyond that when he patched the v4l X driver he didn't bother to make sure it stayed MIT-licensed
18:40:59 <cwickert> ouch
18:40:59 <ajax> which, actually, is a pretty big problem.
18:41:22 <nirik> so, I am also -1, I'd like to see them work with existing maintainers first and see if there is some widespread need for provenpackager. It's not clear to me right now that there is.
18:41:27 <nirik> ajax: :(
18:41:35 * notting is -1 as well
18:41:38 <mmaslano> looks like he doesn't have enough packaging experience, so -1
18:42:30 <ajax> yeah, leaning -1 on this as well
18:42:40 <ajax> i mean i appreciate the effort, but.
18:43:03 <cwickert> the goal is noble, the process is not
18:43:19 <kylem> well, everything broken is going to ftbfs with the mass rebuild anyway.
18:43:24 <kylem> so the maintainers will have to fix it. ;-)
18:43:41 <cwickert> we have 5 -1's so far
18:43:43 <nirik> #agreed request is denied at this time. Please work with existing maintainers to get changes in and be comaintainer on those packages.
18:44:01 <nirik> #topic #557 Drop CloudFS as an F15 feature
18:44:01 <nirik> .fesco 557
18:44:02 <zodbot> nirik: #557 (Drop CloudFS as an F15 feature) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/557
18:44:24 <nirik> I'm fine with this, but if we can do it as a 'tech preview' I think that might be nice too.
18:44:26 * cwickert is fine with declaring it a "tech preview"
18:44:35 <ajax> same
18:44:39 <mjg59> +1
18:44:41 <nirik> perhaps we could ping marketing and docs folks and see if thats acceptable.
18:44:52 <kylem> +1.
18:44:57 <cwickert> I think the final word should be on the feature owner
18:45:00 * notting is +1 to Whatever The Maintainer Wants
18:45:16 <mmaslano> +1
18:45:20 <cwickert> but from my side I am +1 for "tech preview" or what ever maintainer wishes
18:45:21 <nirik> I think they are ok with it, but we don't have much process for "tech preview" I don't think.
18:45:47 * nirik notes revamping the features process would be a great project for someone interested with time to do it. ;)
18:45:58 * cwickert hides
18:46:16 <nirik> #agreed we are fine with tech preview or whatever the feature owner prefers.
18:46:24 <nirik> #topic #555 Requesting Fedora 15 Feature Exception for FreeIPA v2
18:46:24 <nirik> see also: #558 F15Feature: FreeIPA 2.0 - https://fedoraproject.org/wiki/Features/FreeIPAv2
18:46:25 <nirik> .fesco 558
18:46:26 <zodbot> nirik: #558 (F15Feature: FreeIPA 2.0 - https://fedoraproject.org/wiki/Features/FreeIPAv2) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/558
18:46:38 <nirik> so this was a late feature after the deadline.
18:46:49 <nirik> it's already pretty much done.
18:47:09 <mjg59> +1
18:47:25 <nirik> although they have a ton of tickets... https://fedorahosted.org/freeipa/milestone/2.0.1 Bug fixing
18:47:30 * kylem wonders what the point of deadlines is if we vote on them one way or another. ;-)
18:47:53 <DiscordianUK> goal posts
18:47:56 <mmaslano> but it's almost done +1
18:48:04 <nirik> kylem: yeah, see 'someone should revamp the feature process' :)
18:48:08 <kylem> hehe
18:48:13 <nirik> anyhow, I'm +1 for this.
18:48:32 <ajax> +1
18:48:43 <mclasen> +1
18:48:53 <nirik> #agreed Feature is approved.
18:49:06 * notting is +1. sorry
18:49:16 <nirik> #topic #559 lorax commit access for anaconda folks
18:49:21 <nirik> .fesco 559
18:49:22 <zodbot> nirik: #559 (lorax commit access for anaconda folks) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/559
18:49:29 <nirik> This wasn't on the agenda, just came in this morning.
18:49:48 <kylem> +1 to dcantrell.
18:49:52 * nirik is fine with this.
18:49:59 <mmaslano> +1
18:50:08 * mclasen has no idea what lorax is
18:50:10 <mjg59> +1
18:50:13 <ajax> +1
18:50:23 <nirik> Lorax is a tool for creating anaconda install images
18:50:27 <mclasen> oh, +1 then
18:50:28 <nirik> (so says pkgdb)
18:50:53 <nirik> #agreed will grant dcantrell acls on lorax
18:50:58 <nirik> #topic Open Floor
18:51:05 <nirik> Anyone have anything for open floor?
18:51:58 * nirik will close out the meeting in a minute if nothing else comes up
18:52:03 <rbergeron> I am all for revamping the feature process if someone wants to join me. ;D
18:52:21 <cwickert> rbergeron: you just want to have less work with it ;)
18:52:34 <DiscordianUK> i was gonna ask about fpaste in f15
18:52:45 <cwickert> good one
18:52:46 <nirik> DiscordianUK: I already added it this morning to the live media. ;)
18:52:51 <nirik> (and got flamed for it)
18:52:54 <DiscordianUK> but I gather it's been sorted
18:52:56 <rbergeron> I just don't want there to be a process that is meaningless, or a process that people avoid or get nothing out of.
18:53:03 <cwickert> nirik: I think it should not be in base
18:53:12 <nirik> cwickert: why not?
18:53:12 <DiscordianUK> aye nirik I know
18:53:22 <rbergeron> If it's a filter for marketing, then let's make it that. if it's a filter for quality, let's make sure that people are getting out of it what they have to put into it.
18:53:27 <cwickert> nirik: because it is not really 'base'
18:53:29 * nirik notes we can sort fpaste after the meeting, doesn't need to be now. ;)
18:53:40 <DiscordianUK> sorry
18:53:41 <rbergeron> As it is - I hear too many people say that they aren't going to file something as a feature because they get nothing out of it, and that depresses me.
18:53:44 <rbergeron> eof ;)
18:53:51 <mmaslano> rbergeron: imho it should be for quality, for marketing could be used some sort of technical notes
18:54:11 <nirik> rbergeron: sure, I'd welcome a revamp, I just don't have time to commit to working on it. I welcome proposals.
18:54:26 * rbergeron nods
18:55:09 <nirik> Anything else before we close?
18:55:20 <Southern_Gentlem> cwickert,  but fpaste in the livecds makes live better when troubleshooting problems
18:55:51 <cwickert> Southern_Gentlem: agreed, it's just not 'base' I think
18:57:02 <DiscordianUK> if it's in all media I'm done
18:57:09 <nirik> ok, thanks for coming everyone!
18:57:13 <kylem> thanks nirik
18:57:21 <nirik> #endmeeting