16:00:39 <geppetto> #startmeeting fpc
16:00:39 <zodbot> Meeting started Thu Jul 30 16:00:39 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:39 <geppetto> #meetingname fpc
16:00:39 <geppetto> #topic Roll Call
16:00:39 <zodbot> The meeting name has been set to 'fpc'
16:00:57 <gbcox> Good morning... sitting in the back row again... ;-)
16:01:21 <geppetto> We are going to mistake you for furniture soon ;)
16:01:23 * tomspur waves gbcox :)
16:01:28 <geppetto> #chair tomspur
16:01:28 <zodbot> Current chairs: geppetto tomspur
16:01:30 <gbcox> ROFL
16:02:29 <mbooth> Hi
16:02:34 <geppetto> #chair mbooth
16:02:34 <zodbot> Current chairs: geppetto mbooth tomspur
16:04:51 <geppetto> tibbs: FPC ping
16:04:53 <tibbs|w> Howdy.
16:05:00 <geppetto> #chair tibbs
16:05:00 <zodbot> Current chairs: geppetto mbooth tibbs tomspur
16:05:07 <tibbs|w> Damn it, 11AM already.
16:05:12 <geppetto> orionp: FPC ping
16:06:33 <geppetto> we seem to have a small/simple Schedule today, so I'll wait another few minutes to see if we can get one more.
16:07:59 <tomspur> yeha :)
16:08:07 <Rathann> hi, sorry for being late
16:09:24 <geppetto> #chair Rathann
16:09:24 <zodbot> Current chairs: Rathann geppetto mbooth tibbs tomspur
16:09:32 <geppetto> Cool, now have 5
16:09:40 <geppetto> #topic Schedule
16:09:45 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-July/010893.html
16:09:55 <geppetto> #topic #553 	Spec file naming
16:09:55 <geppetto> .fpc 553
16:09:55 <geppetto> https://fedorahosted.org/fpc/ticket/553
16:09:57 <zodbot> geppetto: #553 (Spec file naming) – fpc - https://fedorahosted.org/fpc/ticket/553
16:10:43 <tibbs|w> Not a big deal, but the current situation is kind of bizarre.
16:11:07 <geppetto> Yeh, I had a look … and almost no packages seem to disobey this anyway
16:12:01 <geppetto> big offenders were compat. packages
16:12:13 <tibbs|w> I remember fighting over gcc at one point, but that was years ago.
16:12:14 <Rathann> +1 from me, this is kind of obvious
16:12:17 <geppetto> Eg. libfooXX having a specfile of libfoo.spec
16:12:19 <tibbs|w> +1
16:12:24 <geppetto> +1
16:12:59 <tibbs|w> Really, if you're importing  something into a compat package you can just rename the spec.  This shouldn't be really painful.
16:13:12 <geppetto> yeh
16:13:28 <tibbs|w> But I guess it's no huge deal; standardization just helps the tooling quite a bit.
16:13:29 <tomspur> Is there something in the guidelines that say: Only one spec per git pkg is allowed?
16:13:39 <geppetto> I'm just guessing that those are "we did the minimal thing and it worked, so we didn't do anything else"
16:13:41 <tibbs|w> I don't think so.
16:13:43 <orionp> Sorry afk for a bit
16:14:00 <tibbs|w> I don't really see a problem with a package having multiple files that happen to end in .spec.
16:14:15 <tibbs|w> Sometimes that might be simpler than making a branch to do a big cleanup.
16:14:22 * tomspur nods
16:14:32 <geppetto> Was just making sure that no packages had a differently named spec for a specific reason
16:14:44 <tibbs|w> But the current pyrpkg behavior of picking a file essentially at random is ungood.
16:14:53 <geppetto> yeh
16:14:54 <tomspur> +1
16:14:56 <tibbs|w> Well, it's ungood in the case that you do have multiple specs.
16:15:12 <tibbs|w> Also, there's something about SCLs having multiple specs.
16:15:41 <tibbs|w> But in our universe, we wanted SCLs to be in different packages so that wouldn't be an issue.
16:15:57 <tibbs|w> (And it was that demand that made the SCL folks give up.)
16:16:11 <orionp> I don't see a good reason to allow multiple specs
16:16:52 <geppetto> I saw soemthing recently that implied SCLs would be coming back for F23/F24
16:16:58 <orionp> I think people managed to have unified specs for SCLs and non-scls
16:17:13 <tibbs|w> Well, coming back to us.
16:17:18 <geppetto> yeh
16:17:24 * mbooth just keeps scl-ised versions of packages in a separate branch
16:17:39 <tibbs|w> FESCo gave us the power to let them opt out of the review process which I think was their main objection.
16:17:54 <tibbs|w> But enough about SCLs; my brain hurts enough already.
16:17:55 <orionp> mbooth -  I do the same but it could be unified I think
16:18:36 <mbooth> orionp: Oh yeah is it a unified spec file in the branch, but scl macros are forbidden in main branches -- hence the separate branch
16:18:50 * mbooth shrugs
16:19:01 <mbooth> +1 to the proposed language in the ticket though
16:19:04 <orionp> Right, I'm just saying it's not an argument for multiple specs
16:19:27 <tibbs|w> But really, I'd like to clean up the cyrus-imapd package.  I could do it in a branch, or I could just copy the spec, check in the new file and clean that up.
16:19:36 <tibbs|w> Since it's just one file.
16:20:02 <tibbs|w> But I guess there's no specific reason for me to call it whatever.spec.  If the tooling were better, though, I would.
16:20:03 <geppetto> Ok, I think that's everyone
16:20:16 <orionp> +1 from me
16:20:30 <geppetto> #action Spec file naming must match package (+1:5, 0:0, -1:0)
16:21:06 <geppetto> #undo
16:21:06 <zodbot> Removing item from minutes: ACTION by geppetto at 16:20:30 : Spec file naming must match package (+1:5, 0:0, -1:0)
16:21:10 <geppetto> #action Spec file naming must match package (+1:6, 0:0, -1:0)
16:21:14 <tibbs|w> Thanks.
16:21:24 <geppetto> #chair orionp
16:21:24 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs tomspur
16:21:46 <geppetto> Spec file naming
16:21:53 <geppetto> #topic #550 	Darktable and Rawspeed internal library
16:21:53 <geppetto> .fpc 550
16:21:53 <geppetto> https://fedorahosted.org/fpc/ticket/550
16:21:56 <zodbot> geppetto: #550 (Darktable and Rawspeed internal library) – fpc - https://fedorahosted.org/fpc/ticket/550
16:22:03 <Rathann> yeah, I'd like to bring that up again
16:22:31 <Rathann> upstream is a bit touchy, but I think we started off with miscommunication
16:22:54 <Rathann> now that they've explained how things work I think a bundling exception for all rawspeed consumers is in order
16:23:17 <Rathann> there seems to be a healthy and active ecosystem around rawspeed
16:23:24 <geppetto> for a release or two … or longer term?
16:23:28 <Rathann> with all consumers contributing back to upstream actively
16:23:44 <Rathann> I'd say at least two releases
16:23:59 <Rathann> they don't have even a long term plan to unbundle right now
16:24:18 <Rathann> but some developers said they would review patches allowing that
16:25:45 <geppetto> Hmmm
16:25:46 <tomspur> Actually, I only see arguments against unbundling...
16:26:19 <tomspur> see the github issue, you linked to in the last comment
16:27:07 <geppetto> what about the pugixml bundling?
16:28:28 <Rathann> pugixml is unbundled in latest release
16:28:42 <Rathann> at least that's what they said
16:30:27 <tibbs|w> I would generally (not just for this package) be in favor of temporary exceptions if they actually meant something.
16:30:54 <geppetto> Yeh, I could go for a longish tmp. exception if they were working on the problem
16:31:37 <tibbs|w> But unless people are OK with me retiring packages when their exemptions expire then it becomes kind of pointless.
16:31:55 <Rathann> so... a permanent one?
16:32:16 <tibbs|w> This seems pretty much the wrong kind of package for a permanent exemption.
16:32:17 <Rathann> as things stand, unbundling might break stuff
16:32:26 <tomspur> As you still seem to be discussing with upsteam, maybe look at it again next week?
16:32:30 <tibbs|w> Big, processes untrusted data.
16:32:50 <orionp> Is there any reason why DT's rawspeed modifications couldn't just be applied to an unbundled rawspeed in Fedora?
16:32:52 <tibbs|w> But I will admit to not being fully informed as I'm absorbed in the Python stuff.
16:33:10 <Rathann> orionp: no, but then other consumers of rawspeed will break
16:33:19 <geppetto> Rathann: Even moving to a static lib. would be too hard?
16:33:33 <orionp> Why does modifying it break everything
16:34:04 <Rathann> the way they describe it (I haven't looked at the actual code) is that only parts of functionality are implemented in rawspeed
16:34:20 <Rathann> other parts are implemented in the consumers (DT, rawstudio, etc)
16:34:37 <Rathann> it looks like code duplication but they seem to be happy with it for now
16:35:04 <Rathann> and if the parts are not in sync, things break, they say
16:35:42 <Rathann> also, the latest comment says this
16:35:51 <geppetto> yeh, I mean I'm sure they are happy with it … I'm just not sure we should be
16:36:02 <Rathann> the different libs mentionned here should not be considered "a bunch of code" but more like "hardware descriptors that happen to be described in C" from a packaging point of view.
16:36:02 <Rathann> there are new lenses/cameras every month and they need synchronized updates to both rawspeed and darktable/rawstudio. That means that a given version of darktable will only work with a given version of rawspeed.
16:36:38 <tomspur> I don't see why adding a new camera breaks stuff...
16:37:01 <tomspur> That camera just doesn't work then, or are the list of supported cameras hardcoded somewhere?
16:37:05 <tomspur> Sounds like it...
16:37:22 <geppetto> Rathann: But they get that from a static lib., right?
16:38:22 <Rathann> well but it would have to be one git snapshot for each consumer
16:38:31 <Rathann> as they are not all using the same one
16:38:44 <geppetto> nice
16:38:59 <orionp> I wonder if darktable would just need to ship its own cameras.xml/showcameras.xsl...
16:39:40 <Rathann> well they did say this: "most issues preventing this are surpassable but there is no one available to do the work and I doubt there will be in the near future."
16:40:10 <orionp> I'm fine with a temporary exception so they can work on it
16:40:15 <Rathann> that's why I think a temp exception is in order
16:40:30 * orionp wonders if we have list of expired exceptions....
16:40:40 <geppetto> Yeh, I would be fine witha temp. sexception … _if_ they were going to work on it
16:40:59 <geppetto> but it sounds a lot more like … lol, it's not going to happen give us a temp. exception and we'll get another in 2 years
16:41:01 <Rathann> well all of our temps have a Fedora release number at which they expire
16:41:01 <tibbs|w> I did put the trac stuff in place to handle the exemption case.
16:41:17 <tibbs|w> Just resolve things as temporary exception and then we can query those.
16:41:17 <Rathann> geppetto: actually I'm the one pushing for temp exception
16:41:40 <tibbs|w> But I don't know how many tickets were actually resolved that way.
16:42:17 <tibbs|w> Again, I'm in favor of a temporary exemption _if_ someone's working on fixing the issues _and_ the package is actually going to get pulled if nothing happens.
16:42:34 <Rathann> tibbs|w: we'd need to sync the wiki with the trac ticket resolution statuses
16:42:54 <tibbs|w> Rathann: Yes, but I guess it's not too much work if someone wants to do it.
16:43:28 <orionp> So are the Fedora packagers interested in driving this?
16:43:39 <orionp> I think it's going to be up to them.
16:43:41 <Rathann> tibbs|w: the package is too valuable to be pulled and the maintainer is not a developer so unless someone steps in and helps upstream nothing will change I'm afraid
16:44:02 <tibbs|w> Then what's the point of a temporary exemption?
16:44:27 <Rathann> to give the maintainer time to find someone? or do we just drop it from Fedora?
16:44:58 <geppetto> Is it so bad to just drop it until they fix it?
16:45:00 * Rathann remembers something about not trying to make people happy against their will
16:45:00 <tibbs|w> Well, "too valuable to be pulled" is an important thing.
16:45:09 <tibbs|w> We have guidelines around that already.
16:45:13 <geppetto> I mean that's the most likely to give them some incentive, right?
16:45:20 <tibbs|w> Do they have a designated security team, for example.
16:45:58 <tibbs|w> Firefox gets a huge exemption, on the "too important but has active security team" basis.
16:46:23 <Rathann> it looks like all consumers are actively pushing bugfixes upstream
16:46:34 <Rathann> at least that's what was claimed in that github issue
16:47:33 <geppetto> why is it important?
16:48:17 <geppetto> Are all the consumers important?
16:48:43 <tibbs|w> geppetto: are you asking that of me?
16:48:58 <geppetto> Of Rathann mainly, as he's the one that said it's important
16:49:22 <geppetto> But if anyone knows … I don't mind :)
16:49:25 <tibbs|w> I was just pointing out that "too important to remove" is one of our exemption criteria.
16:49:34 <geppetto> Oh, yeh
16:49:38 <tibbs|w> I have no idea if this package meets that criterion.
16:49:58 <tibbs|w> But Rathann said it, so maybe he can qualify his statement.
16:50:05 <geppetto> yeh
16:50:06 <Rathann> it's just my impression, nothing else
16:50:16 <Rathann> I haven't actually used it
16:50:47 <geppetto> ok, it's not like all camera integration in gnome is going to stop is we drop it?
16:51:10 <Rathann> I guess not
16:51:24 <Rathann> this looks like it's targeted at professionals
16:51:28 * geppetto shrug … I'm happy to just drop it and see what happens then
16:51:36 <Rathann> or at least advanced amateurs
16:51:51 <geppetto> If someone complains then they can come back to us, and maybe try to help upstream
16:51:54 <Rathann> who know what RAW format is and why it's better than JPEG
16:52:03 <geppetto> RAW is lossless compression
16:52:19 <geppetto> Well, lossless format … not sure if there's compression
16:52:31 <Rathann> also, upstream said they don't want to deal with any breakage resulting from unbundling and will tell users not to use Fedora package
16:52:35 <Rathann> so that's a bit hostile
16:52:45 <geppetto> yeh, screw them then
16:52:56 <geppetto> they can always package up whatever mess they have upstream
16:52:57 <Rathann> *sigh*
16:53:24 <gbcox> Yeah, that is a big hostile
16:53:27 <tibbs|w> It sounds as if they don't want us to package it, then.
16:53:37 <tibbs|w> Which is fine; some projects are like that.
16:53:57 <geppetto> Kind of, when I've seen that reaction before they want the distro. to just ship whatever upstream gives them
16:54:31 <geppetto> All they want is the "distro-pm install foo" to work out of the box, but not have to do anything to comply
16:54:53 * geppetto has roughly 0 sympathy for that anymore
16:55:25 <Rathann> well I do have sympathy for having no time to work on fun stuff, let alone non-fun but necessary stuff
16:55:32 * geppetto nods
16:55:39 <tibbs|w> Someone will copr it anyway if it's really important.
16:55:54 <tibbs|w> We're getting to the point where that isn't much of a big deal.
16:55:54 <geppetto> sure
16:56:04 <Rathann> so when upstream says "yes, this could be done, patches welcome" then I'm at least glad
16:56:48 <Rathann> *sigh* I think I spent too much effort on an issue that doesn't even concern me personally
16:56:58 <Rathann> but I like it when people play nice with each other
16:57:30 <mbooth> Valiant effort all the same, Rathann :-)
16:57:37 * geppetto nods
16:57:55 <tibbs|w> It's always sad when this happens.
16:58:18 <tibbs|w> If upstream had even said "we'll try to work on it" I'd have a different attitude.
16:58:22 <geppetto> And I understand not having enough time … esp. for unfun stuff … but at some point when something needs to be done and you refuse to do it, but say patches would be fine you are just saying my time is more important than yours
16:58:45 <tibbs|w> "We'd accept patches, but aren't going to bother ourselves" just isn't positive.
16:58:54 <gbcox> yup
16:59:41 <Rathann> ok
17:00:12 <gbcox> well maybe the users can complain to upstream and that will get them to change their mind
17:00:39 <tibbs|w> Yes, it would be nice if that happened.
17:00:59 <tibbs|w> You know, it's probably worth an announcement to some list.
17:01:18 <geppetto> #action Without a timeline, or some other commitment from upstream we can't do much (too big to just ignore).
17:01:21 <tibbs|w> "We're forced to drop this package because XXX and upstream doesn't want to work on it."
17:01:23 <geppetto> #topic Open Floor
17:02:00 <orionp> tibbs|w - great work on the python stuff
17:02:10 <tibbs|w> Thanks.
17:02:13 <geppetto> Yeh, major kudos
17:02:20 <tibbs|w> I've fixed the things that people pointed out.
17:02:39 <tibbs|w> tomspur has just added an explanation of %python_provide which I think was needed.
17:03:08 <tomspur> tibbs++
17:03:08 <zodbot> tomspur: Karma for tibbs changed to 5:  https://badges.fedoraproject.org/tags/cookie/any
17:03:09 <tibbs|w> I need to document the new macros, but that should be a few one-liners.
17:03:21 <tibbs|w> There is one open question:
17:03:46 <tibbs|w> Currently my draft says that unversioned executables must be the py3 version.
17:03:54 <tibbs|w> assuming py3 is supported, of course.
17:04:27 <tibbs|w> I'm pretty sure that's what we voted before but I've gotten lost.
17:04:53 <tomspur> Hmm, for applications right?
17:04:56 <geppetto> yeh
17:04:56 <tibbs|w> Yes.
17:05:13 <tibbs|w> I mean, that's what the whole "py3 as default" thing actually means.
17:05:43 <tibbs|w> It's easy to get that confused with changing the /usr/bin/python link, but that's not part of the change at all.
17:05:46 <tomspur> pip probably doesn't count as application, so I guess that's not included...
17:06:06 <tibbs|w> Well, we can exempt very special things, of course.
17:06:22 <tibbs|w> Though, I guess "why not pip?" is a valid question.
17:06:40 <bochecha> you need both pip, though
17:06:46 <tibbs|w> Of course, and you'll get both.
17:06:56 <tibbs|w> Actually, you'd get five.
17:07:06 <tibbs|w> pip, pip-3, pip-3.4, pip-2 and pip-2.7.
17:07:16 <bochecha> imho, /usr/bin/pip needs to be for /usr/bin/python
17:07:17 <tibbs|w> The only question is which one just plain "pip" gives you.
17:07:26 <bochecha> anything else would be confusing
17:07:43 <tibbs|w> I'm sure there's a PEP on this.
17:07:51 <tibbs|w> Which we should of course follow.
17:08:34 <tibbs|w> Is there anything else which would need that as an exception?  Or should I change the draft to...
17:08:46 <tibbs|w> either tone down the "must" to a "should" or
17:08:56 <tibbs|w> revert to "should be the python2 version" or
17:09:14 <tibbs|w> go to  "must be the python2 version"?
17:09:32 <geppetto> why revert?
17:09:34 <tibbs|w> So, four choices.  If we can decide this I think the page is done.
17:09:54 <tibbs|w> Well, someone said that I changed that in my draft.  I don't recall changing that specifically but I could have done so.
17:10:10 <tibbs|w> So my draft would have to revert to... whatever it was before I changed it.
17:10:36 <geppetto> I thought we'd voted on it, with the py3 change to default
17:10:44 <tibbs|w> Though people are telling me I changed things incorrectly when I just pasted sections in, so who knows.
17:11:00 <tibbs|w> Let's see what the current guidelines say.
17:11:27 <tibbs|w> Man, they hurt my eyes....
17:12:00 <tibbs|w> "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. On releases up to and including F21, this was the python 2 implementation. Python3 should be used in F22 and later if supported by upstream. Be sure to test the new implementation. Transitioning from python2 to python3 is left to individual package maintainers except for
17:12:01 <tibbs|w> packages in Fedora's critical path. For these, we want to port to python3 versions in the same Fedora release if possible. "
17:12:06 <tibbs|w> (sorry).
17:12:19 <tibbs|w> So, they say "should".
17:12:47 * geppetto nods
17:12:47 <tibbs|w> Though if the new macros get into F21 I'll need to make sure that F21 is mentioned in that bit.
17:13:17 <tibbs|w> My draft says: "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. On releases up to and including F21, this was the python 2 implementation. Python3 should be used in F22 and later if supported by upstream. Be sure to test the new implementation. Transitioning from python2 to python3 is left to individual package
17:13:18 <tibbs|w> maintainers except for packages in Fedora's critical path. For these, we want to port to python3 versions in the same Fedora release if possible. "
17:13:55 <tibbs|w> But there's a "Naming" section, which in the original draft says:
17:14:00 <tibbs|w> " For example, the python 3 version of "coverage" must ship executables /usr/bin/coverage, /usr/bin/coverage-2 and /usr/bin/coverage-2.7, while the python 3 version must provide /usr/bin/coverage-3 and /usr/bin/coverage-3.4 (assuming python3 is Python 3.4). "
17:14:06 <tibbs|w> Which.... makes zero sense.
17:14:36 <tibbs|w> And before that it says: "The unversioned executable must be the python 3 version"
17:14:53 <Rathann> ok, that's inconsistent
17:15:08 <geppetto> maybe the example was written assuming coverage was a module and not an application?
17:15:14 <geppetto> Or not just an application?
17:15:30 <geppetto> but more likely just left over from various changes for py3
17:15:34 <tibbs|w> It's specifically talking about executables.
17:15:43 * geppetto nods
17:15:54 <tibbs|w> But yes, either I screwed up in writing something up or we missed this in one of the drafts I applied.
17:16:12 <tibbs|w> Either way, the question remains: What should these two bits actually say?
17:16:40 <tibbs|w> I would suggest "unversioned exe should be the py3 version"
17:16:47 <geppetto> I know we agreed somewhat recently that apps. should only ship one version
17:17:01 <tibbs|w> Shit, really?
17:17:02 <geppetto> And that stuff should move over to py3 if they could
17:17:03 <tibbs|w> I can't keep track.
17:17:41 <tibbs|w> There's something in there about what to do if the program has identical functionality.
17:17:49 <tibbs|w> between the py2 and py3 versions.
17:18:13 <tibbs|w> In my draft, "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. On releases up to and including F21, this was the python 2 implementation. Python3 should be used in F22 and later if supported by upstream. Be sure to test the new implementation. Transitioning from python2 to python3 is left to individual package maintainers
17:18:14 <tibbs|w> except for packages in Fedora's critical path. For these, we want to port to python3 versions in the same Fedora release if possible. "
17:18:36 <geppetto> yeh
17:18:41 <tibbs|w> Which is identical to the current guidelines.
17:19:15 <tomspur> coverage behaves differently for python2 and python3, so the unversioned one should be python2 still?
17:19:18 <tibbs|w> I don't like the grammar there, but whatever.
17:19:24 <geppetto> yeh, so we should change the example to only have either coverage-2 or coverage-3
17:19:34 <geppetto> tomspur: Oh, how so?
17:19:38 <tibbs|w> So, right, the answer is precisely what to do when the functionality is not identical.
17:19:39 <tomspur> Makes sense as long as /usr/bin/python is python2
17:19:53 <tibbs|w> tomspur: +1
17:20:11 <tomspur> This would be the same as the pip question above
17:20:21 <tibbs|w> Yes, I think that's it.
17:20:39 <tibbs|w> Which is exactly what ... someone... was trying to tell me in 281.
17:21:14 <tibbs|w> bkabrda in https://fedorahosted.org/fpc/ticket/281#comment:32
17:21:52 <tibbs|w> So, change things back to say that for things where functionality is not identical, unversioned should be py2.
17:22:24 <tibbs|w> Otherwise (if functionality is identical) we keep the existing guideline and you only package the py3 version in F22+.
17:22:39 <tibbs|w> I should ask the EPEL folks if they care, but that's orthogonal.
17:22:58 <geppetto> I can see wanting to package both if they aren't identical
17:23:05 <geppetto> But I don't see why you'd want to the default to be py2
17:23:24 <tibbs|w> Because that's going to be stuff like pip and coverage.
17:23:52 <tibbs|w> Where it would be pretty confusing to have /usr/bin/python as py2 and /usr/bin/pip as py3.
17:24:03 <tomspur> +1
17:24:04 <geppetto> Hmm
17:24:15 <tibbs|w> We're leaving out the case where there's an application with one feature disabled on py3 or something, of course.
17:24:26 <tibbs|w> But I'd prefer not to go that far down the rabbit hole.
17:24:43 <geppetto> python == python2 because upstream says that's the best thing to do, right?
17:24:48 <tibbs|w> Yes, currently.
17:24:50 <geppetto> What do they say about pip, anything?
17:25:04 <tomspur> Because upststream says that /usr/bin/python "should" be python2
17:25:09 <tibbs|w> There's a PEP on it /usr/bin/python but I don't know about pip.
17:25:20 <tibbs|w> Still, it does make sense to me.
17:25:34 <tomspur> The /usr/bin/python PEP is https://www.python.org/dev/peps/pep-0394/
17:25:37 <tibbs|w> Look at https://fedorahosted.org/fpc/ticket/475#comment:11
17:26:42 <tibbs|w> From the PEP:  The Python 2.x idle , pydoc , and python-config commands should likewise be available as idle2 , pydoc2 , and python2-config , with the original commands invoking these versions by default, but possibly invoking the Python 3.x versions instead if configured to do so by the system administrator.
17:27:23 <tibbs|w> As far as I can tell, that's it.
17:27:28 <mbooth> 6666666666
17:27:43 <tibbs|w> Indeed, this is Satan's work.
17:28:01 <mbooth> Sorry -- inadvertent pet/keyboard interaction
17:28:31 <tibbs|w> So, WTF to do?
17:29:16 <tibbs|w> And the changes to the current guidelines came in with my last writeup.
17:29:38 <tibbs|w> So this screw up, including the inconsistency in the Naming section, is my fault.
17:30:17 <tibbs|w> I need to just put it back the way it was (py2 is default for exes where functionality differs) and then if we want to change that in the future, we can.
17:30:25 <geppetto> so … python-sig wants all unversioned applications to be py2?
17:30:47 <tibbs|w> I think the easiest question to answer is "should I have changed this in the first place".
17:30:56 <geppetto> So … presumable dnf would have to be renamed to dnf3, if it wanted to be py3 as default?
17:31:00 <tibbs|w> And the answer is no, I screwed up.
17:31:02 <geppetto> which is insane
17:31:12 <tibbs|w> dnf doesn't differ functionally between py2 and py3 versions.
17:31:23 <tibbs|w> So it's not within the scope of what we're discussing.
17:31:26 <geppetto> ok
17:31:56 <tibbs|w> It's only for stuff like idle, ipython, pydoc, python-config, pip, and coverage.
17:32:02 <tomspur> I think this only affects exes that do something with python modules itself
17:32:20 <tibbs|w> In fact, did I just list all of the examples?  Probably not, but there can't be many more.
17:32:23 <tomspur> Either testing/using interpreters directly
17:32:26 <geppetto> Right, I guess I'd prefer language like "applications that are tied to /usr/bin/python"
17:32:49 <tibbs|w> How about this: I put this back the way it was.
17:32:53 <geppetto> Or "applications that have functionality tied to the version of python they are running under"
17:32:57 <geppetto> :-o
17:33:06 <tibbs|w> I push my onto the current guidelines.
17:33:13 <tibbs|w> And then we can vote on this as a separate change?
17:33:43 <geppetto> sure, although it seems someone obvious after talking about it for a bit … and I'm not sure it will be next week, for me ;)
17:33:58 <geppetto> *somewhat
17:34:10 <tomspur> We can vote on it again, I thought we voted on this as just described
17:34:31 <tibbs|w> tomspur: Sorry, just as described where?
17:35:10 <tibbs|w> In my draft, or in the guidelines before I screwed them up?
17:35:23 <tomspur> e.g. "applications that are tied to /usr/bin/python" or your "differ functionally between py2 and py3 versions" over here
17:36:22 <tibbs|w> I guess I still don't know which version you're preferring.
17:36:38 <tibbs|w> Thing is, I really, really want to get this big rewrite out of my head and off my plate for the time being.
17:37:16 <tibbs|w> So if this is something that needs a vote, I'd rather just make sure I'm not changing anything functionally and vote on the functional change later.
17:38:54 <geppetto> Well the text is the same, right?
17:39:08 <geppetto> in the draft and what is policy?
17:39:21 <tibbs|w> The problem is that the current policy is broken.
17:39:23 <geppetto> And we understand what it is saying?
17:39:25 <tibbs|w> Because I screwed it up.
17:39:33 <tibbs|w> So I need to revert that.
17:39:43 <tibbs|w> And then make my draft match so I'm not actually changing anything there.
17:39:45 <tomspur> I'd move in https://fedoraproject.org/wiki/User:Tibbs/PythonCleanup2#Naming the /usr/bin/coverage from python3 to python2 and it should be consistent, isn't it?
17:39:57 <geppetto> yes
17:40:19 <tibbs|w> Well, one line above that, the 3 needs to change to 2.
17:40:34 <tibbs|w> That's what I screwed up, basically.
17:40:37 <geppetto> There's maybe some confusion there over what the default to install should be vs. what /usr/bin/coverage should be
17:40:39 <tibbs|w> I changed it when I should not have.
17:40:41 <geppetto> As with python itself
17:43:18 <geppetto> ok, so you good?
17:43:33 <tibbs|w> Yes.
17:43:53 <geppetto> ok, cool
17:43:57 <geppetto> Anyone else have anything?
17:44:01 <tibbs|w> OK, I've undone my mistake in the current guidelines.
17:44:17 <tibbs|w> Will make my draft match (since I didn't intend to change that) and then push it into place.
17:45:48 <geppetto> ok
17:45:52 <tibbs|w> I'm all out.  Still have some writeups to do but hopefully will be completely caught up with FPC work today.
17:46:01 <geppetto> cool
17:46:11 <tomspur> Great.
17:46:19 <tibbs|w> BTW, what are we actually going to do about rawwhatever?
17:46:31 <tibbs|w> As in, do I need to do anything?
17:46:39 <geppetto> No
17:46:44 <geppetto> I'll update the ticket, and close it
17:47:08 <tibbs|w> Will someone take care of retiring the package or whatever needs to happen?
17:48:10 <geppetto> Has it got through review?
17:48:21 <geppetto> I can do that if I knew how :)
17:48:31 <tibbs|w> yum list raw\*
17:48:43 <tibbs|w> Or dnf or whatever.
17:49:31 <tibbs|w> So it's darktable, sorry, and that's in the distro currently.
17:49:49 <tibbs|w> https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review&list_id=3682666&query_format=advanced&short_desc=darktable&short_desc_type=allwordssubstr
17:50:03 * geppetto sighs
17:50:13 <tibbs|w> Somehow it was submitted three times.
17:50:18 <Rathann> we have all three main rawspeed consumers in Fedora
17:50:32 <Rathann> I'm filing bugs against the other two
17:50:38 <Rathann> rawstudio and rawtherapee
17:51:54 * tomspur needs so leave, sorry
17:52:01 <geppetto> ok
17:52:20 <geppetto> tomspur: ok, see ya
17:52:29 <geppetto> tomspur: We are almost over anyway, I think
17:52:46 <tomspur> good, see you then
17:53:17 <tibbs|w> Thanks.
17:53:26 <tibbs|w> Hopefully no more two hour meetings for a while.
17:53:43 <Rathann> yeah, sorry for taking so much time with rawspeed thing
17:54:09 <tibbs|w> It was worthy of discussion, so I see no reason to apologize.
17:54:27 <geppetto> no problem, we all wanted it to work out better
17:58:30 <geppetto> ok, I'll close in a couple of minutes
17:58:36 <geppetto> let everyone get some lunch ;)
17:58:41 <tibbs|w> Thanks.
18:00:19 <geppetto> #endmeeting