17:30:01 #startmeeting FESCO (2011-05-11) 17:30:01 Meeting started Wed May 11 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 #meetingname fesco 17:30:01 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 #topic init process 17:30:01 The meeting name has been set to 'fesco' 17:30:01 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:25 Afternoon 17:30:36 yo. 17:30:46 * nirik waves. 17:31:10 * j_dulaney is here 17:31:13 Sort of 17:31:17 * mmaslano here 17:31:46 * notting is here, although i have to leave at 2M 17:32:06 * mclasen is here 17:32:07 hello, sports fans 17:32:22 ok, lets go ahead and dive in... hopefully another reasonably short meeting. 17:32:32 #topic #515 Investigate a "features" repo for stable releases 17:32:32 .fesco 515 17:32:33 nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:32:45 cwickert isn't here, so no news on this that I can see. 17:33:00 are there any other folks who would like to try and move it forward? 17:33:29 I'm a bit overwhelmed with other stuff at the moment, so can't really take that on 17:33:54 To an extent I think this is the kind of thing that's probably better thrashed out in person 17:34:07 yeah, perhaps so. 17:34:07 At least as far as making sure we have an understanding of the problems 17:34:50 well, it also doesn't seem to be that urgent/wanted if no one can work on it... 17:34:56 but I guess time will tell. 17:35:15 #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:35:15 .fesco 563 17:35:16 nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:35:19 kylem: any news here? 17:35:37 no, i haven't had a chance to rebuild the chroot of base/x/gnome yet with the flags. 17:35:49 i think we should just enable it and see who screams. 17:36:03 sounds like an ok approach for f16, if we do it now 17:36:05 both of them? 17:36:17 do we have a mass rebuild this cycle ? 17:36:27 relro definitely, pie is the one that adds cost, but yeah, i think if we do a mass rebuild for f16 we might as well. 17:36:29 to early to tell. 17:37:21 pull the trigger already 17:37:22 why would an app care? 17:37:23 fine with me. 17:37:29 So can we just add them to the build flags now and schedule a mass rebuild reasonably early if we don't have one first? 17:37:32 not to bad to have it enabled on important damones anywa. 17:37:37 daemons 17:38:08 so, +1 here to just enabling them in f16 by default and see if we run into any bad blockers/issues... 17:38:35 yeah, i mean, they seem safe enough in the limited testing i've done. 17:38:38 * notting is +1 to taht 17:38:55 +1 17:39:04 +1 17:39:08 +1 17:39:22 +1 17:39:23 +1 17:39:26 #agreed will enable them both by default in rawhide and see if we run into issues. 17:39:37 so, who would be willing to add them in and announce this? ;) 17:39:38 i mean, one way or another, apache, sshd, etc., should really have them, no matter what. 17:39:55 nirik: i know where to poke in the rpm macros 17:40:15 ajax: cool. Can you make that change and also announce it to devel-announce? :) 17:40:26 aye cap'n 17:40:33 Pie in rawhide? Sweet! 17:40:41 * gholms apologizes for the terrible joke 17:40:46 mmm pie 17:40:50 #action ajax to make change and announce it. 17:40:52 cool. 17:41:04 #topic Upcoming Elections 17:41:12 So, with the end of a cycle, elections are coming up. 17:41:24 Nominations are now open. 17:41:26 https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations 17:41:56 and nominations close 2011-05-15 at 23:59:59 17:42:22 Expiring Seats are currently held by: Kevin Fenzi (nirik) (Chair), Bill Nottingham (notting), Kyle McMartin (kyle), Steven M. Parrish (tuxbrewr) and Matthias Clasen (mclasen) 17:42:31 nirik: that's just-before-midnight... UTC? 17:42:36 yep 17:42:45 i'm not on the list? huh. thought i would be. 17:42:50 notting, if you're agonizing about it for that long... ;-) 17:42:53 ajax: No, we did it 6 months ago 17:43:05 ajax: you can coast until next cycle. ;) 17:43:28 anyhow, encourage your friends and/or foes to nominating. 17:43:40 Are any of you folks going to re-run? 17:43:55 i'm undecided as yet. 17:44:03 kylem: nah, jost wondering how long i can put off procrastinating 17:44:08 * mclasen is probably going to take a break 17:44:17 gholms: i probably will 17:44:19 i have been pretty rubbish at attending and getting things done, i don't want to be a drag on fesco by running again. 17:46:00 * nirik isn't sure yet... might be good to get new blood 17:46:18 #topic F15 release coming up 17:46:25 so, f15 is right around the corner. 17:46:31 how many more glibc updates can we fit in before release? 17:46:32 ;-P 17:46:41 Any issues or thoughts we have? things we should look at? 17:46:59 * gholms raises hand 17:47:22 gholms: go for it. 17:47:32 Is this glibc fight going to carry over into the release? Is that something fesco should offer input upon? 17:47:45 the rpc lib thing? 17:47:48 Yeah 17:48:11 Some people are pushing to get it re-added but I have seen no indication that the maintainers have any intention of doing so. 17:48:28 yeah. Sigh. Do we have any reliable way to communicate with the glibc maintainers? 17:48:41 gholms: reference? (bug #, thread, whatever) 17:48:51 * gholms digs one out 17:49:00 https://admin.fedoraproject.org/updates/glibc-2.13.90-11 17:49:35 basically they dropped the rpclib in glibc... then readded just one of the headers back... 17:49:38 The last five comments are the most useful. 17:49:51 they want people to go use libtirpc 17:49:56 which is fine. 17:50:07 but a few days before a release freezes is... not the time for that. 17:50:09 Which is fine at an earlier point in a release cycle 17:50:28 Do we have an explicitly stated policy that it's unacceptable to create FTBFS in a stable update? 17:50:35 so, the issue here is that to 'fix' this we have to deviate from the exported upstream ABI/API? 17:50:45 mjg59: almost certainly not 17:51:02 Should we? 17:51:16 notting: it's unclear to me if this was an upstream or local change. 17:51:31 nirik: it's upstream (came from uli, iirc) 17:51:32 mjg59: seems like a question of scale and circumstances 17:51:34 It's difficult to autoqa, but I'd hope that anything along those lines should be an immediate disqualification 17:51:46 mjg59: well, given we do allow ABI changes... 17:51:58 it seems like there should be a linker script one could come up with to pull in tirpc automagically at link time 17:51:59 notting: That's kind of another screaming nightmare 17:52:05 mjg59: if there's an isolated package failing to rebuild because it was relying of bug compatibility, thats one thing, but breaking everthing using rpc is something else.... 17:52:17 ajax: that still changes the implementation in use on rebuild 17:52:32 mclasen: I'd argue that the push should be delayed until that package has been fixed 17:52:39 Which shouldn't be difficult 17:52:54 notting: yeah, well. 17:53:02 would read more logs, but sourceware seems to have shot itself 17:53:14 Will people be able to reliably -1 every subsequent update until they push one with RPC back in place? 17:53:31 DOS by karma 17:53:33 gholms: ... enforcing stalemate via protest seems impractical 17:53:40 That could also prevent other bugfixes. 17:53:46 notting: Yeah, exactly 17:53:47 eventually there will need to be a security fix, or something 17:54:13 Does anyone want to argue that this change should be permitted in stable? 17:54:15 * adamw reads the updates policyu 17:54:24 "During this time maintainers MUST: Avoid Major version updates, ABI breakage or API changes if at all possible." 17:54:27 (post-beta, pre-final) 17:54:41 i'd say it's 'at all possible' to avoid this change. 17:54:43 personally, i think it's time glibc had actual package maintainers, instead ofjust shoving git snapshots into fedora and letting us beta test for the rest of the world. but that's just me. 17:54:47 mjg59: i would not make that argument. 17:55:14 kylem: likely not just you. ;) 17:55:39 i mean, i don't mean it as a slight to the glibc folks, but they're developers, not packagers, and it shows. 17:55:47 we should free them to develop. 17:56:04 I don't mind the beta testing so much as the no communication... and no way to ask them to revert or change something. 17:56:23 * kylem nods. 17:56:52 the same text applies in post-release. i think the intent is that we allow api/abi changes but only in really exceptional circumstances. 17:56:54 ...? it's the same way you ask any other maintainers 17:57:08 or are you referring to the efficacy of that way in this case? 17:58:23 I assume everyone here knows that getting a response from the glibc package maintainers can be difficult at times. 17:58:29 in my ideal world we would ask them to carry the rpc implementation in f15, and remove it in f16/rawhide and they would do it. ;) 17:59:22 right. it's a matter of setting precedent, though (kicking upstreams that break things) 18:00:09 i.e., what happens if we ask, and they say no? 18:00:35 tgl maintains mysql and postresql. He didn't say which packages couldn't be built... 18:00:36 well, if past history is any guide, we can ask and they will just ignore us. 18:00:48 but I don't know the way forward here. 18:01:02 the way forward is someone nmu's glibc and we move on with our lives 18:01:05 Well, we can ask 18:01:17 And if nothing happens then we can swear 18:01:20 we could find someone else interested in maintaining it, and add them as maintainer. (not it) 18:01:24 But we might as well ask first 18:01:36 have we not asked yet ? 18:02:00 You need to decide whether or not to allow the API-breaking change before you can ask. 18:02:02 well, if we is fesco as a body, no. not that I know of. 18:02:07 (AFAICT) 18:02:29 if we is several maintainers, we have asked in the update with -1 karmas 18:02:41 nirik: that's not exactly official 18:03:02 fwiw, i was/am going to send mail to an internal contact about this, unless someone thinks that's bad? 18:03:10 notting: I've no problem with that 18:03:11 I'm fine with trying to officially ask... but I suspect not much will come of it. 18:03:20 notting: do it. 18:03:28 +1 to asking them officically to revert the rpc thing for f15. 18:03:38 +1. 18:03:45 +1 18:03:45 +1 18:03:54 +1 18:04:07 +1 18:04:28 #agreed will ask glibc maintainers to revert the rpc change in f15 18:04:45 Ok, anything else on that and/or general f15 issues? 18:05:16 The KDE spin has 1337 packages at the moment. :P 18:05:35 nirik: who is doing this asking? 18:05:37 Sounds good to me 18:05:40 we're having mysterious problems with f15 live composes, so if anyone thinks they can help with that, that'd be great. 18:05:45 notting: I'm fine with you doing that 18:05:47 notting: you? ;) 18:05:52 mjg59: ok, that's two mails then 18:06:07 will do 18:06:23 #action notting will contact glibc folks. 18:06:46 #topic Open Floor 18:06:50 ok, anything for open floor? 18:07:07 shouldn't we talk abou proposal about man-pages? 18:07:18 oh shoot, I forgot about that one. 18:07:19 sure. 18:07:36 #topic #587: Check if localized manual pages are up to date 18:07:39 .ticket 587 18:07:41 nirik: #587 (Hosting request for python-augeas) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/587 18:07:55 Thanks, zodbot 18:08:03 Not sure everyone has had a chance to look at this, but thought I would bring it up. 18:08:06 oops. 18:08:08 .fesco 587 18:08:11 mjg59: #587 (Check if localized manual pages are up to date) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/587 18:08:12 yeah, that. 18:08:15 sorry. 18:08:49 I agree it's a problem 18:09:28 But when we say "out of date" do we mean "hasn't been cleaned up as much", "lacks documentation of new features" or "contains lies"? 18:09:36 older version ? 18:09:41 Because the first two still sound better than nothing 18:09:53 And in some circumstances even the third might be 18:10:01 it's problem when you are missing options or can't read warnings about deprecations 18:10:19 patching all man pages as suggesting in part of the propsal seems a non-starter 18:10:21 so all three could br true 18:10:35 mmaslano: Would you prefer a manpage with missing options or no manpage? 18:10:44 (sorry, dropping off now) 18:10:50 so, to be clear, these are man pages shipped in all the various packages? 18:10:56 mjg59: the problem is when the english version contains lies too... 18:10:58 notting: no worries. thanks. 18:11:05 mjg59: I stopped using localized man page because they are missleading 18:11:18 mjg59: I prefer warning on the top of the page 18:12:13 I don't know that we can mandate a reasonable thing to do here 18:12:20 so, these are as shipped by upstreams for each of the package? or are we talking about base manpages like man-pages-fr ? 18:12:33 probably both 18:12:49 Doing it automatically isn't practical - fixing a typo in the english text shouldn't invalidate the others 18:12:51 I suppose it could be handled as feature if anyone is willing to take it 18:13:03 well, ideally the maintainer would tell upstream that the man pages need updating... 18:13:24 and/or carry a local patch until upstream does do so. 18:13:34 doing a check based on version information in the man page might work for a manpages vs manpages-fr situation 18:13:46 but probably not if the translated manpages are shipped in the same package 18:13:48 some of man-pages-* upstreams are dead, so they could have only the warning 18:13:51 because the version information is likely generated 18:13:58 regardless if the content is actually in sync 18:14:49 anyway I can't see how we could force it 18:15:19 yeah, this looks like a maintainer/upstream issue to me... so it will vary from package to package.... 18:15:28 I think its a two step process: 18:15:39 1. implement that warning feature in the man reader itself 18:15:52 2. write lots and lots of patches for all the man pages out there 18:16:50 so what does the warning say? 18:19:05 that's up to maintainer of man-db 18:19:40 "This localized man page may be out of date, see the english one" ? 18:19:53 I'm fine with someone working on this as a feature, but I don't know if we're really in a position to mandate a specific technical solution 18:20:04 yeah. 18:20:22 proposal: ask submittor to work with man-db maintainer/upstream to come up with a good solution. 18:20:40 ok, I could do it 18:22:33 any objections? votes? other ideas? 18:23:58 * nirik listens to the wind 18:24:18 * mmaslano would like to see end of meeting, that's all ;-) 18:24:27 * gholms rings the 15 minute bell 18:24:40 +1 to just pushing it to the proposer 18:25:00 sounds fine to me. 18:25:01 +1. 18:25:12 ok. Sounds like thats a winner. ;) 18:25:35 #topic Open Floor again 18:25:50 anything for another open floor? or shall we stick a fork in this meeting? 18:26:04 So much for another short meeting. :( 18:26:14 ah well. ;) 18:26:19 ok, thanks for coming everyone. 18:26:23 pfah, you nancies wouldn't make it through 10% of a release blocker review ;) 18:26:27 thanks again nirik 18:26:40 #endmeeting