17:00:15 #startmeeting 17:00:28 #meetingtopic FESCo Meeting - https://fedorahosted.org/fesco/report/9 17:00:38 nirik: you drive this meeting, I'm not sure how to operate this new-fangled thing :D 17:00:57 happy to. I was going to make that the first topic. ;) 17:01:10 * nirik thought jds2001 wasn't going to be around today. Moving done? 17:01:36 that was yesterday. 17:01:41 wait, what thing? 17:01:46 I still have boxes all around :( 17:01:51 jwb: fedbot 17:01:57 so we're not doing gobby? 17:02:00 * dgilmore is here 17:02:17 we could try each I guess. 17:02:21 well, lets go ahead and discuss which we want to do... 17:02:25 #topic ticket 158: Create new meeting summary procedure 17:02:28 fedbot 17:02:33 because i don't have gobby setup :) 17:02:49 so, this is a plugin to supybot, created by the fine debian folks. 17:03:10 it runs the meeting and produces a log and summary and such. 17:03:29 examples of the summaries? 17:03:30 nirik: i like the idea its something everyone can use and we can post all meetings logs to a common location 17:03:43 * nirik is digging up a example. 17:03:58 http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-04-16.33.html 17:04:06 this was the IRC Support sig meeting yesterday. 17:04:13 dgilmore: yeah, I would like that too. 17:04:27 we could still use both 17:04:29 currently it's running on my machine here, but we could easily add it to zodbot and get it on a fedora location. 17:04:43 so, it's all keyword based? 17:04:44 nirik, could have febot log to gobby 17:04:54 notting: yeah. 17:04:57 #commands 17:05:10 we need a #gobby 17:05:11 :) 17:05:18 nirik: is it packaged? 17:05:23 hm. it might be simpler, i'm not sure if it will end up more legible on the list/wiki 17:05:29 this does more than log, it does summary and such. 17:05:41 jds2001: not yet. I can do so. 17:05:49 notting, at this point i think we should just focus on getting something there consistently 17:05:54 notting, cleanup can happen later 17:06:04 jwb: right, but that can be done by just assigning someone :) 17:06:13 I would like all meetings to use the same format and go the same place and be searchable. ;) 17:06:13 notting: i could setup something like http://fp.o/meetings/ 17:06:22 to point to the right spot on noc1. 17:06:32 nirik: yep 17:06:42 notting, true. but robots are soo much cooler 17:06:48 we have a bunch in the wiki as well. 17:06:49 so that we dont have to put it on the wiki. 17:06:52 Meeting: space 17:07:10 jds2001: well, we'd still want them all (both before and after we change) in the same place 17:07:12 but the wiki search is... suboptimal 17:07:51 nirik: i google site:fedoraproject.org :( 17:08:13 so, I guess I think this is usable, but if we just want to assign a minutes taker, or try gobby, or whatever I am open to it if people feel its better. 17:08:43 * abadger1999 notes that we should make sure the logs get backed up. 17:08:46 perhaps ask for feedback from people who read logs after this meeting? 17:08:59 nirik: works for me 17:09:12 abadger1999: noc1 gets backed up, right? 17:09:14 * nirik nods. I backup the machine they are on here. ;) But yes, if they go to noc1 they should get backed up 17:09:20 if we add this plugin to zodbot? 17:09:43 jds2001: I don't know, thus: make sure ;-) 17:09:52 nirik: maybe take the log from this and post it on the wiki, get comments, and we can move everything together later? 17:10:29 well, not sure it would post right to the wiki. It expects to be it's own html/txt file. 17:10:37 but yes, I can ask for feedback from it. 17:10:51 it does allow logs to be posted right when the meeting is done, which is nice. 17:11:06 also links to the items in the logs, etc. 17:11:50 * nirik waits for any other votes/opinions. 17:12:05 i'm good with either 17:12:32 the bot looks good 17:12:38 i like the bot. 17:12:49 * j-rod happy w/the bot, knows nothing of gobby at all though 17:13:19 #action nirik will post the summary/logs from the meeting plugin for comment/feedback on fedora-devel. 17:13:24 ok, shall we move on? 17:14:07 #topic ticket 159: FPC report - 2009-06-02 17:14:11 .fesco 159 17:14:14 nirik: #159 (FPC report - 2009-06-02) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/159 17:14:30 +1 17:14:45 +1 17:14:58 +1 17:14:59 +1 17:14:59 seems reasonable to reduce the number of duplicate things in spec files... +1 here. 17:15:24 n+1 17:16:11 #agreed Approval for ticket 159 (phase out BuildRoot tag) from FPC. 17:16:32 #topic ticket 134: Approval needed - zsync needs to ship internal zlib for rsync compatibility 17:16:36 .fesco 134 17:16:42 nirik: #134 (Approval needed - zsync needs to ship internal zlib for rsync compatibility) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/134 17:17:01 -1, if at all technically possible 17:17:17 -1 17:17:23 -1 17:17:27 yeah, I don't want to allow an exception here if at all possible... I am wondering what rsync said upstream? 17:17:40 i think we should do everything we can to use the system zlib 17:18:13 -1 17:18:43 yeah. -1 here. Either someone needs to get it using system, the patches upstream, or just not package it. 17:18:56 hrm. so rsync is already in violation? 17:19:19 is it? I thought it used the system one? 17:19:38 I'm not sure... 17:19:51 If not, I don't understand the argument 17:20:11 it makes sense if rsync uses an internal and modified version that zsync needs to match 17:20:19 rsync does not link against system zlib 17:20:26 but if rsync uses the system zlib, I don't see why zsync can't do the same 17:20:31 j-rod: Yes, rsync is already in violation 17:20:34 aha 17:20:53 so why cant rsync use hte system zlib? 17:21:16 rsc was going to query upstream rsync about maintaining the forked zlib as a separate package but I don't know what happened to that. 17:21:21 * notting asks 17:21:46 hum, yeah, rsync should not use an internal zlib. ;( I thought that was fixed. 17:21:53 jds2001: Historicaly, rsync added some features to zlib to make it more efficient for what they do. 17:21:54 -1 for making another exception, and rsync needs fixage 17:22:16 or they can make rzlib or whatever. 17:22:21 bug 495310 17:22:23 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=495310 medium, low, ---, ssorce, NEW, rsync contains forked copy of zlib 17:22:28 jds2001: Unfortunately, they didn't push those upstream (might have tried and were rejected) and it changes the rsync on-wire format 17:22:34 such that both zsync and rsync may link to the same library. 17:22:56 abadger1999: yeah, i was talking about rsync yanking their port and shipping it separately. 17:23:04 17:23:16 so the on-wire format is preserved, and zsync 17:23:17 that's what I'm wishing for at the moment. 17:23:24 abadger1999: is the rsync forked one and the zsync forked one the same patches? or different? 17:23:34 we can just pull rsync from the distro, right? its not like anybody uses it... 17:23:39 :) 17:23:44 simo says it *could* use system, but upstream doesn't care enough to fix it 17:23:47 nirik: AFAIK, yes. 17:23:54 well, thats something at least. 17:24:04 If not, it's probably the usual desyncing that occurs when bundling libraries occurs, not something intentional. 17:24:38 notting: Hmm... If that's the case, we might need to just fix it. 17:25:14 I talked to spot and tibbs earlier this week and the three of us are in agreement that this particular Guideline should be a locker on any review. 17:25:26 Something that we'd fork from upstream over. 17:25:37 * nirik nods. 17:25:51 private copies of libraries are bad. 17:26:05 s/locaker/blocker/ 17:26:16 abadger1999: is there any way to identify this sort of thing over the collection? so we can see if there are others? 17:27:00 I guess for zlib a grep over the exploded source tree might show any more. 17:27:18 nirik: Not atm. dmalcolm had some code that could make it possible in his rpmgrok project. 17:27:34 Well yeah, grep over the source works. 17:27:53 in any case: -1 to exception, rsync (and anything else that does this) needs to be fixed. 17:28:03 so, we already have -5 to the exception for zsync 17:28:28 #agreed No exception for zsync. 17:28:44 #topic Open Floor 17:28:53 thats all we had for tickets. Anything for open floor? 17:29:12 did we agree that rsync should be fixed and that FPC should draft a guideline? 17:29:34 notting: Guideline is in place.... rsync just slipped through review with no one catching it. 17:29:45 notting: i think we agreed that rsync needs fixing 17:29:52 ok 17:30:04 https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries 17:30:11 #agreed rsync should be fixed in the same manner 17:30:14 odd. I don't see a merge review for it. 17:31:28 ah, there it is. 17:31:39 bug 226380 17:31:40 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226380 medium, medium, ---, redhat-bugzilla, CLOSED RAWHIDE, Merge Review: rsync 17:31:41 has it been done? 17:32:20 yeah, just got missed there. :( 17:32:50 anyhow, anything else? or shall we close up early? 17:34:29 were we getting a follow-up report on the flags stuff this week or next week? 17:35:00 not sure. ixs ? any news? can we assist any with info gathering? 17:36:23 would someone like to followup with ixs on that and see if there is anything we can do to assist? 17:37:56 * nirik listens to the crickets. 17:39:20 i can 17:39:26 cool. Thanks. 17:39:50 #action notting will contact ixs and check to see if we can assist/get status on Flags information gathering. 17:39:59 anything else? 17:41:17 possibly more rel-eng, but what has the f11 slip done to our f12 schedule? 17:42:51 nothing so far 17:43:30 ok, I'm sure it will be discussed. ;) 17:43:53 correct, F12 is currently on schedule, full speed ahead 17:44:00 no icebergs spotted yet. 17:44:04 ok, I guess I will close the meeting in 60 seconds if no new items come up. 17:44:24 i have nothing 17:45:05 #endmeeting