=================================== #fedora-meeting: FESCO (2011-02-02) =================================== Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-02/fesco.2011-02-02-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:01) * #516 Updates policy adjustments/changes (nirik, 17:32:26) * LINK: https://fedorahosted.org/bodhi/ticket/182 (nirik, 17:39:08) * LINK: https://fedorahosted.org/bodhi/ticket/470 (nirik, 17:39:59) * LINK: https://fedorahosted.org/bodhi/ticket/158 (nirik, 17:40:06) * ACTION: nirik to talk to lmacken about this and provide more info for next week. (nirik, 17:53:45) * AGREED: will not implement this suggestion at this time. (nirik, 18:05:11) * #515 Investigate a "features" repo for stable releases (nirik, 18:05:24) * #517 Updates Metrics (nirik, 18:06:58) * #518 Abrt (nirik, 18:08:06) * ACTION: nirik will ask for roadmap/more info in ticket, will revisit next week. (nirik, 18:12:32) * #544 List of services that may start by default (nirik, 18:12:54) * LINK: http://fpaste.org/B18Y/ (nirik, 18:15:55) * ACTION: mjg59 and notting will work on the list and sort thru it for next time. (nirik, 18:36:33) * AGREED: we mostly like spot's draft and will look at the list next time for exceptions that are needed. (nirik, 18:36:55) * #550 F15Feature: Indic Typing Booster - http://fedoraproject.org/wiki/Features/IndicTypingBooster (nirik, 18:37:05) * AGREED: Feature is approved (nirik, 18:49:40) * Open Floor (nirik, 18:49:48) Meeting ended at 18:52:51 UTC. Action Items ------------ * nirik to talk to lmacken about this and provide more info for next week. * nirik will ask for roadmap/more info in ticket, will revisit next week. * mjg59 and notting will work on the list and sort thru it for next time. Action Items, by person ----------------------- * mjg59 * mjg59 and notting will work on the list and sort thru it for next time. * nirik * nirik to talk to lmacken about this and provide more info for next week. * nirik will ask for roadmap/more info in ticket, will revisit next week. * notting * mjg59 and notting will work on the list and sort thru it for next time. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (125) * mjg59 (64) * notting (22) * mclasen (18) * skvidal (15) * zodbot (12) * mmaslano (12) * SMParrish (9) * tibbs (3) * ajax (0) * kylem (0) * cwickert (0) -- 17:30:01 <nirik> #startmeeting FESCO (2011-02-02) 17:30:01 <zodbot> Meeting started Wed Feb 2 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 <nirik> #meetingname fesco 17:30:01 <zodbot> The meeting name has been set to 'fesco' 17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 <nirik> #topic init process 17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:06 * notting is here 17:30:10 * mclasen too 17:30:12 <mjg59> Afternoon 17:30:24 * mmaslano is here 17:30:49 <nirik> SMParrish should be here in a few... 17:31:32 <mjg59> ajax is still away 17:32:10 <nirik> I guess we have 5 so we could go ahead and dive in. 17:32:26 <nirik> #topic #516 Updates policy adjustments/changes 17:32:26 <nirik> .fesco 516 17:32:27 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:32:54 <nirik> ok, so this week I pulled two more ideas from the ideas container. 17:32:59 <nirik> 1) allow anon karma to count. Or allow it to count less (.5). 17:33:19 <nirik> The idea here is that we would allow non logged in people to influence karma. They currently don't. 17:33:30 <nirik> Of course it's not very hard to get an account. 17:33:38 <mclasen> wouldn't that open the door to voter fraud ? 17:34:16 <nirik> it could, as you could vote anon a bunch of times from different places, etc. 17:34:34 <mclasen> oh, you can't vote repeatedly from the same place ? 17:34:41 <mjg59> I think we do have to assume good faith on the part of contributors 17:34:49 <mjg59> To a certain extent 17:34:57 <mclasen> but with anon votes we don't know they are contributors... 17:35:00 <nirik> I'm not sure if it does anything for preventing multiple votes from the same ip or the like. 17:35:01 <mjg59> I've no problem with permitting it unless it turns out to cause problems 17:35:23 <mjg59> But it ought to block obvious duplicates, and we probably need to talk to luke to make sure that happens? 17:35:38 <mmaslano> I would try it, it could be reverted if it turn to be bad 17:35:50 <mmaslano> but we should be able to track these changes somehow 17:35:53 <nirik> I think we did have it enabled at first... but then later disabled it. 17:36:03 <mmaslano> why? 17:36:51 <nirik> I can't recall. Let me see if I can dig up details. 17:37:21 <notting> i wouldn't enable it until we know if it catches obvious fraud (repeated spamming from same IP, etc.) 17:37:55 <mjg59> Yes, conditional on that 17:39:08 <nirik> https://fedorahosted.org/bodhi/ticket/182 17:39:59 <nirik> https://fedorahosted.org/bodhi/ticket/470 17:40:06 <nirik> https://fedorahosted.org/bodhi/ticket/158 17:40:28 <nirik> so, currently it should use a captcha and require an email address (but I don't think there's any way to make sure it's a valid address) 17:41:56 <nirik> I guess personally I would say to not do this at this time, and revisit with bodhi 2.0 with the newer karma setup. 17:43:12 * SMParrish here sorry about that 17:43:26 <nirik> I could ask luke how hard it would be to keep track of per ip anon submissions... that could be complicated tho 17:43:46 <mjg59> If we can limit it to one per IP, sure 17:43:54 <mjg59> Or if we can require that the email address be confirmed 17:44:15 <mjg59> But that's some additional complexity 17:44:28 <nirik> yeah. 17:44:37 <notting> but given that e-mail address confirmation is basically all that's required to get a real account... 17:45:02 <nirik> right. There's no requirement for any group, etc to add karma, just a FAS account at all. 17:46:26 <nirik> so, I am -1 at this time, other votes or discussion? 17:47:06 <mjg59> +1 conditional on some mechanism for encouraging uniqueness 17:48:22 <SMParrish> -1 I don't think it is much to ask that some be cla_done to add karma 17:49:03 * nirik isn't sure you even need cla_done. 17:49:07 <mmaslano> +1 with fixes in bodhi (migt wait for 2.0) 17:49:34 <mjg59> I think cla_done is way too far 17:49:55 <mjg59> I don't think we should be requiring people to provide a real world address in order to test our packages 17:50:11 <mjg59> But we don't require that at present anyway, so 17:50:45 <SMParrish> I just want some way to make sure it isn't gamed. 17:50:58 <nirik> I wonder how clear it is that their karma doesn't count if they are anonymous. 17:51:03 <nirik> it doesn't seem to really say that 17:51:17 <notting> +1 with the same conditions as others... can revisit if it becomes an issue 17:52:38 <nirik> ok, how about I talk with Luke and see what it would take to add stuff for uniqness and we revisit next week? 17:53:03 <mmaslano> fine with me 17:53:13 <SMParrish> works for me 17:53:45 <nirik> #action nirik to talk to lmacken about this and provide more info for next week. 17:53:50 <nirik> The other one I had was: 17:53:53 <nirik> 2) enforced min number of days in testing for some updates? 17:54:20 <nirik> The thing here is that some updates that are in high demand get karma quickly and never even go to testing or get mirrored out. 17:54:46 <nirik> The thought was that rushing testing like that could result in less through testing overall. 17:55:00 <nirik> so, the idea was to require some small number of days in testing... 2-3 or so. 17:55:11 <mclasen> how do they get karma without ending up in testing ? people test koji builds directly ? 17:55:13 <notting> yes 17:55:35 <notting> i'm against this, generally... if the karma/testing being done isn't good enough, we should fix that 17:56:15 <nirik> yeah, grab the builds directly. 17:56:36 <mclasen> as long as we allow updates to trickle, it seems ok to me...testing is testing 17:56:37 <SMParrish> Bodhi should inhibit karma until the build is pushed to the testing repo 17:56:47 <SMParrish> and maybe even for 24 hours after that 17:56:49 <nirik> yeah, I would agree. If someone rushes their testing and says +1, when it's broken, we need them to test better/more. 17:56:51 <mclasen> when we get to actually batch updates in some form, it will solve itself 17:57:50 <mmaslano> it's very handy for broken things which I need to see fix asap e.g fedpkg few weeks back 17:58:08 <nirik> well, going out to testing does mean more people will see it/test it, but if 2-3 people grab the build and test it and say it's ok, we should trust them unless they prove they are not trustworthy. 17:58:13 <mjg59> When we first introduced this I seem to remember us explicitly saying that people could effectively go straight to updates if they had enough karma 17:58:22 <mjg59> So as far as I'm concerned, this is working as we designed it 17:58:24 <nirik> mjg59: yep 17:58:49 <mjg59> And without any evidence that packages falling into this state are going out broken, I don't see any reason to change it 17:59:51 <nirik> There was an example I think from the person who submitted this idea... but I can't recall what package it was. 18:00:02 <nirik> (and it really doesn't seem like it's widespread) 18:00:23 <mjg59> So I'm -1 for now 18:00:29 <mclasen> nirik: so you are saying that having the package out in testing gives some implicit confidence that it is not entirely busted, through the absence of negative karma, even if we don't get positive karma ? 18:01:00 <nirik> thats what the submittor of this idea was supposing I think, yes. 18:01:14 * nirik notes he's just passing these ideas along and trying to get them a fair hearing. 18:02:02 <nirik> I am -1 to this at this time. I think if we run accross updates having problems due to no testing time, we should look at who is doing the testing and help them test better. 18:02:14 <mmaslano> -1 18:03:21 <nirik> ok, so where are we. -4 ? 18:03:35 <mjg59> Think so 18:04:31 <nirik> anyone else? mclasen ? 18:04:33 <nirik> SMParrish: ? 18:04:34 <mclasen> -1 18:04:41 <SMParrish> Y'all changed my mind I'll go -1 18:05:11 <nirik> #agreed will not implement this suggestion at this time. 18:05:24 <nirik> #topic #515 Investigate a "features" repo for stable releases 18:05:25 <nirik> .fesco 515 18:05:26 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 18:05:39 <nirik> I think cwickert was going to work on this, but I expect he is still traveling right now. 18:05:58 * nirik will move on unless someone has something to add on this topic. 18:06:16 <mclasen> did this get discussed at fudcon ? 18:06:25 <nirik> not that I recall. 18:06:58 <nirik> #topic #517 Updates Metrics 18:06:58 <nirik> .fesco 517 18:06:58 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517 18:07:10 <nirik> same deal for this one... kylem was going to work on it... 18:07:37 * nirik will move on in a minute if nothing else on this from anyone. 18:08:06 <nirik> #topic #518 Abrt 18:08:06 <nirik> .fesco 518 18:08:06 <zodbot> nirik: #518 (Abrt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/518 18:08:23 <nirik> we were hoping to talk to abrt folks at fudcon, but not sure that happened either. ;) 18:08:33 <nirik> So, failing that, we should ask them for a roadmap or the like. 18:08:35 <notting> i saw jiri 18:09:00 <mmaslano> he has a presentation there 18:09:25 <nirik> yeah, too many things to be in at once. ;( 18:09:31 <mmaslano> not sure if he met someone, he's still traveling 18:10:35 <notting> yeah, just talked to him about generalities 18:11:06 <nirik> ok, so shall we ask in the ticket for a roadmap update and go from there next week? I think maintainers will be happier knowing which improvements are coming when... 18:12:06 <mjg59> Sure 18:12:15 <SMParrish> yes 18:12:32 <nirik> #action nirik will ask for roadmap/more info in ticket, will revisit next week. 18:12:51 <nirik> ok, on to the fun one for today... 18:12:54 <nirik> #topic #544 List of services that may start by default 18:12:54 <nirik> .fesco 544 18:12:56 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544 18:13:12 <nirik> we have a list of 68 services that currently start by default. 18:13:50 <nirik> we have spot's page as a guideline start: https://fedoraproject.org/wiki/User:Spot/DefaultServices 18:14:29 <notting> yeah, i was going to work on this, but got distracted with fudcon and other fires 18:14:30 <nirik> how do we want to approach this? 18:14:59 * nirik looked at the list... got confused about the dbus type services in the systemd world 18:15:31 <mclasen> nirik: where's the list of 68 ? 18:15:42 <nirik> it's in the ticket. I can paste it in a better form... 18:15:42 <mmaslano> in ticket ;-) 18:15:55 <nirik> http://fpaste.org/B18Y/ 18:16:12 <mjg59> For many of these applications, if the service doesn't start by default then the binaries installed by the package simply won't work 18:16:25 <mjg59> I... don't see how that would be a useful configuration 18:16:55 <mjg59> There's a few counterexamples 18:17:49 * mclasen notes that bluez installs a dbus service file with Exec=/bin/false 18:17:53 <mjg59> But hal, for instance? It's not network enabled, so it doesn't seem to be relevant to this policy at all 18:18:11 <mjg59> And ifplugd? 18:18:34 <nirik> in spot's proposal non network services could choose to start or not if they wanted. 18:18:41 <mclasen> a few other services do the same, that seems the semi-official way to turn off autostart 18:18:43 <mmaslano> shouldn't maintainers reviewed if it's ok or not? 18:18:48 <mjg59> So is this list of 68 the list of packages that are chkconfiged on by default, rather than the list of packages that may require exceptions? 18:19:07 <nirik> mjg59: well, it depends. Do we agree to: 18:19:19 <nirik> "If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so). In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away") and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of "runs once then goes away" services include iptables and udev" 18:19:40 <nirik> if we agree with that, we can remove a number from this list on that basis. 18:19:46 <mjg59> I would say I agree to that, but further I would agree to network daemons that only bind to localhost by default 18:19:58 * nirik notes you can't disable bluez except by removing it. 18:20:26 <mjg59> nirik: You can disable bluetooth 18:20:42 <mjg59> Difficult to present an attack surface if there's no radio listening... 18:20:59 <nirik> I'd love to hear how in the rawhide systemd world. ;) 18:20:59 <mclasen> I wonder how much sense it makes to have a guideline entirely on a package basis, without looking at whats installed by default or not 18:21:33 <mjg59> Anyway, as I said, I broadly agree with spot's guidelines 18:21:40 <mjg59> I think we could easily go further than that 18:21:51 <nirik> systemd has no way I can find to disable/enable dbus based services, they are just there and will be enabled when something wants them. 18:21:53 <mjg59> Our default configuration right now is that everything's firewalled unless explicitly not firewalled 18:22:13 <mjg59> So if I have to chkconfig something on, and *also* unblock the firewall, that's a technological failure 18:22:28 <notting> right, but that's being worked 18:22:30 <mjg59> Either we don't need off by default or we don't need blocked by default 18:22:53 <mjg59> notting: Yeah. Just noting that right now the objectives of this seem to be achieved even without changing anything. 18:23:12 <mjg59> What's our feeling on "network enabled and only bound to loopback"? 18:23:36 <skvidal> mjg59: isn't there room for wanting something installed on the system but off and not going to run automatically when something wants it? 18:23:47 <nirik> it could represent a local vulnerability if it needs config to secure/set it up. 18:23:48 <mjg59> skvidal: No 18:23:55 <mjg59> Uninstall it 18:23:58 <skvidal> mjg59: I can think of a fair number of things that I want off until I explicitly need them, - not just when something happens to probe a port 18:24:09 <mjg59> skvidal: So either don't install, or turn it off 18:24:32 * nirik has httpd on his laptop, but off most of the time. Only start it when I need to test something or have someone hit something here. 18:24:35 <skvidal> is that fesco's decision? 18:24:47 <skvidal> ie: has that decision been made as policy for the distro? 18:24:52 <nirik> skvidal: no. 18:24:53 <mjg59> skvidal: No 18:25:09 <mjg59> It's also not clear whether that should be fesco's role, or whether it falls to the packaging committee 18:25:28 * skvidal will be eager to learn whose decision it is. 18:25:30 <nirik> well, we asked packaging to look at what services should start by default, but they pushed it back to us. ;) 18:26:00 <mjg59> nirik: If a non-network daemon (local sockets, for instance) starts by default then it still presents a potential security issue 18:26:01 <nirik> They said: "Decide whether FPC or FESCo makes the list (b/c some thought this was an expansion of fpc's charter while others thought that it was within FPCs charter and additionally FESCo had agreed to hand it to FPC several meetings back)." 18:26:23 <mjg59> nirik: So really I'm not convinced that it's an issue if it only binds to loopback 18:26:29 <mjg59> But this is probably a fairly niche case 18:26:32 <notting> should we just task ourselves with evaluating the list of current start-by-default things in light of spot's draft? 18:26:39 <nirik> in the interests of avoiding a back and forth, I think fesco should decide. 18:26:59 <mjg59> notting: I guess, but we need to start by discarding everything on that list that doesn't listen to the network - which looks to be most of them 18:27:07 <tibbs> I wanted to point out that "network enabled and only bound to loopback" exposes still exposes those daemons to attack by local users or by exploitable code run by local users. 18:27:19 <nirik> I like spot's draft in general... perhaps we could sort the list into things that we need to look at and things that are excepted by the proposed policy 18:27:20 <skvidal> mjg59: it's not just about security - it can also be about resource and power use 18:27:34 <mjg59> tibbs: Yes, as is also the case with anything that's running but not network-enabled 18:27:37 <skvidal> mjg59: I may want something installed for the handful of times i need it but never to come on unless I explicitly want it on 18:27:44 <skvidal> mjg59: for power use cases and for memory-use 18:27:56 <mjg59> skvidal: That's what swap's for 18:28:04 <skvidal> mjg59: not all systems have swap 18:28:05 <mclasen> but you can easily turn them off after installing them... 18:28:08 <skvidal> mjg59: olpc comes ot mind 18:28:14 <nirik> mclasen: in some cases. ;) 18:28:15 <mclasen> since you are willing to turn them on and off all the time anyway 18:28:29 <skvidal> mclasen: how do you turn off dbus-using services? 18:28:46 <mclasen> if you can't turn them off, there's no point discussing if they should be initially turned off, I'd say ... 18:28:59 <mjg59> skvidal: Daemons that consume power when not being actively used are buggy, and the answer there is "Fix the software", not "Mandate that software not start" 18:29:22 <nirik> there are lots of corner cases... 18:29:29 <skvidal> mjg59: so by not loading bluetooth, for example, I don't pull that module in 18:29:34 <skvidal> mjg59: that module burns power for me 18:29:44 <skvidal> ditto with various other components 18:29:47 <nirik> but lots of obvious things we shouldn't allow either. 18:29:49 <mjg59> skvidal: Uh. I think you're misunderstanding hardware here, to a large extent. 18:30:02 <mjg59> skvidal: If you want bluetooth powered down fully then you need to load the module 18:30:06 * nirik points to freenx-server. Which you need to setup a bunch to work. 18:30:08 <mjg59> skvidal: Then you disable bluetooth 18:30:13 <skvidal> mjg59: I'm going by powertops estimate 18:30:23 <mjg59> skvidal: I understand this better than powertop does 18:31:19 <nirik> so, how about we get 1-2 people to sort thu the list and present us with the ones we need to decide on based on the proposed policy? 18:31:22 <notting> <15 minutes ding> 18:31:35 <mjg59> nirik: Sure 18:31:40 <notting> is the proposed policy we're referring to the one spot has in the ticket? 18:31:46 <mjg59> notting: Yes 18:31:48 <nirik> notting: yeah, I was at least. 18:31:52 <notting> as what FPC actually ratified wasn't a policy at all 18:32:05 <nirik> they didn't ratify anything I don't think... 18:32:12 <nirik> just passed what they had back to us. 18:32:13 <mjg59> I'll pull out anything that isn't permitted by spot's proposal and I'll group them by different categories 18:32:15 <notting> they ratified a SEP field 18:32:26 <mjg59> I think everything that's permitted by spot's proposal makes sense 18:32:46 <notting> mjg59: i can help with the weeding if you'd like 18:32:47 <mjg59> Does anyone think that's unreasonable? 18:32:55 <mjg59> notting: Yeah, it's not a big list 18:33:02 <mjg59> I'll let you know 18:33:39 <nirik> it might be good to keep those items in a seperate list... ie "here are things that are one-shot or etc, so don't need an exception" 18:34:20 * nirik is happy with that plan. Any other thoughts? or should we move on for now? 18:34:35 <notting> i.e., sort the permitted things by why they're permitted? 18:34:53 <nirik> yeah. 18:35:12 <nirik> or sort the things which are set to start by default into why they are allowed to do that. 18:36:33 <nirik> #action mjg59 and notting will work on the list and sort thru it for next time. 18:36:55 <nirik> #agreed we mostly like spot's draft and will look at the list next time for exceptions that are needed. 18:37:05 <nirik> #topic #550 F15Feature: Indic Typing Booster - http://fedoraproject.org/wiki/Features/IndicTypingBooster 18:37:05 <nirik> .fesco 550 18:37:06 <zodbot> nirik: #550 (F15Feature: Indic Typing Booster - http://fedoraproject.org/wiki/Features/IndicTypingBooster) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/550 18:37:16 <nirik> This was deferred from last time. 18:37:38 <nirik> answers on the talk page: http://fedoraproject.org/wiki/Talk:Features/IndicTypingBooster 18:38:23 <notting> forks. whee. 18:38:52 <nirik> yeah, thats not great. ;( 18:39:41 <notting> although it seems reasonable why they'd fork if they're going to end up breaking chinese support 18:39:43 <nirik> other than that I guess I am +1... I wish they would have found a non forky way. 18:40:23 <tibbs> Does that mean you can't have both Chinese and Indic ibus installed at the same time? 18:40:34 <mjg59> I think that would need to be checked 18:40:46 <tibbs> Because I can't imagine that would be acceptable. 18:40:48 <nirik> I would hope thats not the case. 18:40:56 <mjg59> Guess we should ask that 18:41:09 <notting> tibbs: the implication is that chinese and indic used to both use ibus-tables; they're forking ibus-tables for indic. 18:41:20 <notting> the appearance is that you could have both installed 18:41:45 <nirik> it's not already a approved package tho it seems 18:42:48 <nirik> or I am looking in the wrong named. 18:42:50 <nirik> names 18:44:41 <notting> in any case, +1 18:44:42 <nirik> so whats the name of that forked package? is it in the same package as the feature? 18:45:38 <nirik> so: 18:45:42 <nirik> .bug 666517 18:45:43 <zodbot> nirik: Bug 666517 Review Request: scim-typing-booster - Indic Typing Booster Table IMEngine for SCIM - https://bugzilla.redhat.com/show_bug.cgi?id=666517 18:45:51 <nirik> .bug 666520 18:45:53 <zodbot> nirik: Bug 666520 Review Request: ibus-typing-booster - Indic Typing Booster Table IMEngine for ibus - https://bugzilla.redhat.com/show_bug.cgi?id=666520 18:46:01 <nirik> both approved, but they forgot to set fedora-cvs. 18:46:15 <mjg59> Ah, ok 18:47:16 <nirik> so, anyhow, +1, but we should make sure there's no conflicts with packages. 18:47:59 <nirik> any other votes/comments? 18:48:23 <mjg59> +1 assuming no conflicts 18:49:09 <SMParrish> +1 18:49:12 <mclasen> +1 18:49:40 <nirik> #agreed Feature is approved 18:49:48 <nirik> #topic Open Floor 18:49:54 <nirik> Anyone have anything for open floor? 18:51:07 <mjg59> Not me 18:51:14 * nirik doesn't. 18:52:16 * nirik will close out in a minute if nothing else comes along. 18:52:46 <nirik> ok, thanks for coming everyone! 18:52:51 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
