17:01:18 <geppetto> #startmeeting fpc
17:01:18 <zodbot> Meeting started Thu Jan 29 17:01:18 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:18 <geppetto> #meetingname fpc
17:01:18 <zodbot> The meeting name has been set to 'fpc'
17:01:18 <geppetto> #topic Roll Call
17:01:42 <geppetto> geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ spot tibbs|w tomspur: FPC ping
17:01:52 * tomspur is here
17:01:56 <geppetto> #chair tomspur
17:01:57 <zodbot> Current chairs: geppetto tomspur
17:02:05 <orionp> morning
17:02:15 <geppetto> #chair orionp
17:02:15 <zodbot> Current chairs: geppetto orionp tomspur
17:02:21 <geppetto> #chair racor
17:02:21 <zodbot> Current chairs: geppetto orionp racor tomspur
17:04:01 <tibbs|w> Howdy.
17:04:08 <tomspur> tibbs|w: Can I adjust your pycache draft wrt to the double usage of site-packages?
17:04:16 <tibbs|w> I extricated myself from the line of people at the door.
17:04:24 <geppetto> #chair tibbs|w
17:04:25 <zodbot> Current chairs: geppetto orionp racor tibbs|w tomspur
17:04:32 <tibbs|w> Feel free to edit draft as needed; I was mostly talking out of my ass anyway.
17:05:32 <geppetto> #chair Rathann
17:05:32 <zodbot> Current chairs: Rathann geppetto orionp racor tibbs|w tomspur
17:05:58 <geppetto> mbooth away today?
17:06:03 <tibbs|w> Note that we have a small office party for someone who is leaving (in disgust, it happens) in 25 minutes, so I may will have to step away.  But after that I should be able to be in and out.
17:06:11 <Rathann> hi
17:06:44 <mbooth> Hi
17:06:47 <geppetto> #chair mbooth
17:06:47 <zodbot> Current chairs: Rathann geppetto mbooth orionp racor tibbs|w tomspur
17:07:25 <geppetto> ok, looks like we have everyone we'll be getting
17:07:33 <geppetto> #topic #495 	Proposal: Package Guidelines: PreupgradeAssistant contents packages
17:07:38 <geppetto> https://fedorahosted.org/fpc/ticket/495
17:08:59 <tibbs|w> This looks mostly OK to me, although, man, preupgrade-assistant-contents-*.  I'm going to need to add another monitor off the side for the massive package names.
17:09:08 <geppetto> yeh
17:09:15 <geppetto> I was thinking the prefix was a little onthe big side
17:10:00 <tibbs|w> Also, mnariadb... isn't the best example for a spec.
17:10:06 <Rathann> maybe without "-contents"?
17:10:16 <mbooth> Rathann: I thought the same thing
17:10:55 <tibbs|w> Really I don't want to care about the name; if we have to ask for changes, maybe ask them to consider something shorter but I can't see how that's the biggest issue we'd have.
17:11:40 <orionp> why must be noarch?
17:11:53 <tomspur> Why is there "fedora_" in the macro? Wouldn't %{preupgrade_name} be enough? That would save quite a few characters on that page
17:12:05 <tibbs|w> tomspur: +1
17:12:23 <Rathann> right
17:12:31 <tibbs|w> But they might have a reason.  This could quite possibly be a cross-distro thing.  But even then we shouldn't care about that in our packaging.
17:12:49 <geppetto> does anyone understand where group.xml comes from?
17:13:09 <tibbs|w> I assume all of the assistant packages will have one.
17:13:12 <orionp> what about packages in epel then?
17:13:19 <Rathann> presumably, the preupgrade_build generates it?
17:13:27 <geppetto> yeh, that was my best guess
17:13:34 <geppetto> it's just a weird name for a generated file
17:13:37 <tibbs|w> EPEL (really RHEL) doesn't support cross-version upgrades.
17:13:43 <tomspur> Yeah, I don't know if it makes sense to support going from Fedora to rhel back and forth
17:13:49 <tibbs|w> orionp: Oh, I see your question.
17:14:03 <tibbs|w> There is no point packaging this stuff for epel at all.
17:14:23 <tibbs|w> So if you _insist_ on having the same spec for EPEL, maybe you'd have to conditionalize the subpackage.
17:14:25 <orionp> tibbs|w - you can upgrade from RHEL6 to RHEL7 now using this stuff
17:14:37 <tibbs|w> I thought that wasn't supported.
17:14:41 <Rathann> I wonder what are these .sh, .py, .xml and .txt files
17:14:51 <geppetto> tibbs|w: el7 was the first one where they tried
17:15:07 <tibbs|w> So most of the questions I'm seeing would probably be answered by looking at one of the packages.
17:15:10 <geppetto> tibbs|w: there's a list of exceptions though, AIUI
17:15:42 <tibbs|w> So is this something that Red Hat just went and did, and now is being submitted for Fedora?
17:15:55 <geppetto> kind of
17:16:03 <tibbs|w> Not that I care, but when that happens we tend to see resistance to changes in the proposal.
17:16:06 <geppetto> it grew from fedup, which started in Fedora
17:16:51 <geppetto> Basically el6 => el7 tried to use fedup … hit a big wall, and then did this as a fix/workaround
17:16:53 <Rathann> the draft is technically fine, but doesn't explain what all the various files are and what they're used/needed for
17:16:59 <tibbs|w> In any case, I guess it's obvious that we aren't going to approve this as is without some questions answered.  Maybe everyone post yours in the ticket?
17:17:27 <geppetto> yeh, or maybe someone wants to volunteer to work with the submitter?
17:17:28 <tibbs|w> Trying to do as much as I can before i have to run out in ten minutes....
17:17:33 <tomspur> Sounds like it will install always the same files to the same place, now about a %{preupgrade_install} then?
17:17:54 <tibbs|w> Maybe.
17:18:14 <racor> i think the submitter should provide a real world example.
17:18:17 <tibbs|w> I'll volunteer to condense our questions into a list inthe ticket.
17:18:48 <tibbs|w> racor: I guess they did, in mariadb, but that's an overly complicated example.
17:18:50 <geppetto> racor: isn't that what the mariadb specfile is supposed to be?
17:19:29 <tibbs|w> I think I can rewrite the example spec to be more generic (preupgrade-assistant-contents-foo and leave out the mariadb specifics.
17:19:30 <racor> Is there one in mariadb?
17:19:35 <geppetto> #action tibbs|w Condense questions/concerns into manageable list for the submitter, in the ticket.
17:19:53 <tibbs|w> And once I've done that, everyone feel free to pile on.
17:19:57 <tibbs|w> And we lost mbooth.
17:20:20 <geppetto> #topic #481 	static uids systemd-network, systemd-timesync, systemd-resolve
17:20:20 <tibbs|w> Man our git server is slow.
17:20:27 <geppetto> https://fedorahosted.org/fpc/ticket/481
17:20:39 <Rathann> thanks, tibbs|w, will do
17:20:50 <tibbs|w> And mariadb does not currently have any preupgrade-assistant stuff.
17:22:01 <tibbs|w> So on 481, I'm still mostly +1 because I think they've justified it, but I can understand the objections.
17:22:06 <racor> I am asking for some real world example (and/or docs), because the request seems pretty much a content-free placeholder to me.
17:22:12 <tibbs|w> And that ticket has mostly degraded into a discussion of the policy.
17:22:27 <tibbs|w> racor: I'll add that to my summary in 495.
17:23:35 <tibbs|w> Maybe FESCo wants to change the policy on how hard it is to get a static UID.  I don't know.  But I don't think the bar is too high currently.
17:24:37 <geppetto> I'm reluctant … but I guess I'll +1 -network and -resolve getting a uid
17:25:01 <geppetto> Those are fairly generic anyway, and likely to be wanted for a long time
17:25:25 <geppetto> It feels like they could work around it if they wanted to, but meh.
17:26:13 <geppetto> tibbs|w: I assume that's a +1 for all three?
17:26:33 <tibbs|w> Yes, if we're going to vote separately.
17:26:48 <tibbs|w> Don't construe that to mean that I'm happy about it, though.
17:26:53 <geppetto> Well, I'd rather not give one to timesync as that really doesn't need it
17:27:20 <tibbs|w> I understand.
17:27:32 <tibbs|w> I not sure we'll cross +5 on any of them, though
17:27:51 <tibbs|w> I have to step out now.  I hope to be back soon.
17:29:41 <tibbs|w> Well that was quick.
17:30:03 <tibbs|w> The guy isn't even on campus yet, so I'll have to run out when he gets here.  They're hoping to surprise him.
17:30:28 <tibbs|w> So, maybe set this to voting, or is everyone else reading?
17:30:46 <geppetto> orionp tomspur Rathann racor: vote?
17:31:11 * orionp reading..
17:31:22 <Rathann> I'm +1, after reading the Zbyszek's rationale
17:31:42 <tibbs|w> Rathann: To all three?
17:31:59 <Rathann> yes
17:33:11 <tomspur> +1 to both, I'll read again about the last one..
17:33:13 <tibbs|w> So we're at +3 for all but timesyncd, which has +2.
17:33:19 <geppetto> So ATM: network+resolve+timesync:+2, network+resolve:+4
17:33:24 <tibbs|w> Ninjad.
17:33:28 <geppetto> :)
17:35:04 <racor> +1 I am giving in for the sake of peace, but I am not at all convinced ...
17:35:23 <geppetto> racor: for all three?
17:35:25 <tibbs|w> We should avoid trying to make piece if we're not convinced.
17:35:29 <tibbs|w> peace.
17:35:44 <tibbs|w> If this devolves into a useful discussion of the policy, then so be it.
17:36:38 <geppetto> So ATM: network+resolve+timesync:+3, network+resolve:+5
17:36:43 <geppetto> I think
17:36:51 <tomspur> tibbs|w: I don't know why it is such important to save one more or less uid. Shouldn't it be fine to reallocate it to some other meaning, once it had some ban time?
17:37:00 <tibbs|w> Nope.
17:37:24 <tibbs|w> Because people can upgrade their OS continually, and we can't rewrite the password file.
17:38:48 <geppetto> orionp: vote?
17:40:16 <geppetto> #action static uids systemd-network, systemd-resolve (+1:5, 0:0, -1:0)
17:40:30 <geppetto> #action static uids systemd-timesync (+1:3, 0:0, -1:2)
17:40:34 <tibbs|w> Need people to stop coming to my office.
17:40:38 <geppetto> :)
17:40:53 <orionp> +1 network +1 resolve -1 timesync  fwiw
17:40:59 <racor> geppetto: yes, I don't want to block the systemd folks, no matter how controversial it may be (I am very sure *-networkd etc will be).
17:41:24 * geppetto nods
17:41:26 <geppetto> #undo
17:41:26 <zodbot> Removing item from minutes: ACTION by geppetto at 17:40:30 : static uids systemd-timesync (+1:3, 0:0, -1:2)
17:41:30 <geppetto> #undo
17:41:30 <zodbot> Removing item from minutes: ACTION by geppetto at 17:40:16 : static uids systemd-network, systemd-resolve (+1:5, 0:0, -1:0)
17:41:36 <geppetto> #action static uids systemd-network, systemd-resolve (+1:6, 0:0, -1:0)
17:41:46 <geppetto> #action static uids systemd-timesync (+1:3, 0:0, -1:3)
17:41:55 <geppetto> #topic #493 	Bundling exception: python-execnet bundles python-apipkg
17:41:56 <zbyszek> thanks
17:42:01 <geppetto> https://fedorahosted.org/fpc/ticket/493
17:42:23 <geppetto> tomspur: Did people speak to you?
17:42:43 <tomspur> thm wanted to have a look at it again, but apparently didn't yet
17:43:40 <geppetto> ok
17:44:15 <geppetto> #topic #399 	request for bundled library exception - clustal omega
17:44:20 <geppetto> https://fedorahosted.org/fpc/ticket/399
17:44:29 <geppetto> this looks like it just needs a vote or two from new people
17:44:36 <geppetto> might not even be needed anymore
17:45:25 <Rathann> looks like upstream is considering this to be fixable in the future
17:45:42 <Rathann> ah that was about #493
17:46:21 <mbooth> Do we know if #399 is still relev
17:46:30 <mbooth> ant?
17:46:58 <geppetto> it probably is, given it's not been over a year
17:47:05 <Rathann> hm
17:47:06 <tibbs|w> I've no idea (which is why I asked).
17:47:07 <Rathann> Overview of the security ramifications of bundling
17:47:07 <Rathann> Considering this library is used for a single purpose (taking input), I believe the security ramifications are minimal. But, my expertise in this area is minimal.
17:47:11 <geppetto> but no word from the last 7 weeks :(
17:47:18 <Rathann> taking input is high-risk application
17:47:49 <tibbs|w> I propose to close it and they can reopen if they still need it.
17:48:02 <tibbs|w> It's just sad that it made it to +4 with the old committee and didn't make it further.
17:48:48 <geppetto> I'm fine with that, given they didn't say anything for last 7 weeks
17:49:28 <geppetto> #action Reopen ticket if you still need this.
17:49:29 <tibbs|w> I guess in the future it would be really nice if people recorded their opposition in voting tickets as well, so we can know whether people are opposed or just not voting.
17:49:56 <geppetto> I would bet a decent amount that people just weren't around to vote
17:50:23 <geppetto> #topic #346 	Bundling exception request for Eclipse Sisu
17:50:28 <geppetto> https://fedorahosted.org/fpc/ticket/346
17:51:39 <tibbs|w> Another old one.  Sorry about all of these.
17:51:48 <geppetto> no problem
17:51:49 <tibbs|w> At least this one is still relevant.
17:52:37 <geppetto> Yeh, and ASM looks huge
17:52:48 <tibbs|w> It is.  But.... Java.
17:52:59 <geppetto> When your user guide is a PDF … that's a pretty strong guide that I'm not going to let you bundle it.
17:53:54 <geppetto> tibbs|w: Yeh, but someone needs to tell them to stop smoking crack. And we are probably that person.
17:54:10 * mbooth puts down the crack pipe
17:54:32 <tibbs|w> I odn't know.  They say they have a valid reason, but there's not a whole lot of technical discussion in the upstream bug lin.
17:54:36 <tibbs|w> k.
17:55:28 <tibbs|w> From what I gather it seems like an issue they can't get around; simply requiring ASM means it pollutes the namespace which breaks compatibility with.. something.
17:55:50 <tibbs|w> Proposal: they package a separate ASM which has been namespace namgled.
17:55:53 <geppetto> And from what I can see on http://asm.ow2.org/doc/developer-guide.html#overview … they mean for asm to be distributed on it's own, as a library
17:56:06 <tibbs|w> I simply cannot type today.
17:56:14 <tomspur> Do symlinks work instead of copying it over? (I avoid Java were possible usually...)
17:56:25 <tibbs|w> tomspur: I do not believe so.
17:56:43 <mbooth> tomspur: No, this is about classpath pollution AIUI
17:56:50 <tibbs|w> The bundled ASM has to be mangled in some way so that it will coesist with other ASM versions.
17:57:00 <tibbs|w> So, they must be able to do this programmatically.
17:57:02 <geppetto> *facepalm*
17:57:21 <tibbs|w> So, do that in the spec, and supply the mangled ASM, hopefully as a subpackage of the real ADM.
17:57:39 <tibbs|w> If they could do that, would that be remotely acceptable to anyone here?
17:57:46 <geppetto> yeh
17:57:54 <Rathann> wait
17:58:27 <Rathann> why can't the upstream ASM be modified to co-exist with older incompatible release?
17:58:55 <tomspur> mbooth: It sounds like they are just copying binary files to a new namespace, so why not linking in the new namespace
18:02:08 <tibbs|w> Now the guy is here, so I'm going to step out.  But I guess I have nothing else to add to 346.
18:02:17 <geppetto> #action Work with the ASM packager/upstream and create an API/ABI mangled version, instead of bundling.
18:02:24 <geppetto> no problem … enjoy the party :)
18:02:36 <geppetto> #topic #381 	Bundling exception for python-matplotlib fonts
18:02:40 <geppetto> https://fedorahosted.org/fpc/ticket/381
18:03:07 <geppetto> Hmm, I thought there was something to say here
18:03:35 <mbooth> tomspur: Erm, the bundled source is in a different namespace, not binary files (as far as I can from looking at the source)
18:04:14 <geppetto> #topic #304 	asking for bundling exception for the package "rubygem-rdiscount"
18:04:18 <geppetto> https://fedorahosted.org/fpc/ticket/304
18:04:46 <geppetto> I believe this is fixed/notneeded now.
18:05:12 <racor> sorry, folks, my time's up for today. I have to quit
18:05:17 <geppetto> no problem
18:05:27 <geppetto> I should leave soon too, today
18:05:56 <mbooth> I guess #304 can be closed then?
18:06:09 <geppetto> #action Leaving F20 is fine, as long as the next update can rebase to the F21/F22.
18:06:16 <geppetto> Yeh
18:06:25 <geppetto> #topic Open Floor
18:06:54 <geppetto> Anything to bring up?
18:08:04 <Rathann> nothing from me
18:08:19 <geppetto> Ok, thanks for coming … see you next week.
18:08:21 <geppetto> #endmeeting