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