16:00:11 <geppetto> #startmeeting fpc
16:00:11 <zodbot> Meeting started Thu Jun  7 16:00:11 2018 UTC.
16:00:11 <zodbot> This meeting is logged and archived in a public location.
16:00:11 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:11 <zodbot> The meeting name has been set to 'fpc'
16:00:11 <geppetto> #meetingname fpc
16:00:11 <geppetto> #topic Roll Call
16:00:11 <zodbot> The meeting name has been set to 'fpc'
16:00:17 <tibbs> Howdy.
16:00:20 * limburgher here
16:00:21 <mhroncok_phone> Hi
16:00:21 <geppetto> #chair tibbs
16:00:21 <zodbot> Current chairs: geppetto tibbs
16:00:23 <geppetto> #chair limburgher
16:00:23 <zodbot> Current chairs: geppetto limburgher tibbs
16:00:30 <geppetto> #chair mhroncok_phone
16:00:30 <zodbot> Current chairs: geppetto limburgher mhroncok_phone tibbs
16:01:53 * mhroncok_phone is on Fedora Release Party, will get to a computer soon
16:01:59 <decathorpe> hi everybody
16:02:04 <geppetto> #chair decathorpe
16:02:04 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok_phone tibbs
16:02:56 <tibbs> I was going to say that we had no new tickets besides the one I filed to track the webextension draft, but I see one appeared this morning.
16:02:58 <geppetto> Anyone know if churchyard is around today?
16:03:03 <geppetto> yeh
16:03:08 <mhroncok_phone> Here
16:03:12 <tibbs> On his phone, I assume.
16:03:24 <geppetto> oh, bah
16:05:04 <geppetto> #chair mhroncok
16:05:04 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok mhroncok_phone tibbs
16:05:04 <mhroncok> I'm here
16:05:21 <geppetto> #topic Schedule
16:05:24 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/RQ3PUFXH7TJV7MO4TVV5MVGGBPPGVLNN/
16:05:42 <geppetto> I've no idea what my email client decided to do to my email this week
16:05:58 <decathorpe> I just thought, that's interesting formatting this week
16:06:04 <geppetto> indeed
16:06:22 <geppetto> it looked perfect when I just send … but what is in my sent folder looks like what hit the list :(
16:06:44 <geppetto> anyway … ignoring that in multiple ways … 772
16:06:58 <geppetto> #topic  #772 Manual Python byte compilation change
16:07:01 <geppetto> .fpc 772
16:07:03 <zodbot> geppetto: Issue #772: Manual Python byte compilation change - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/772
16:07:26 <tibbs> So I read it, and... I'm afraid there's one thing I just don't get.
16:07:45 <tibbs> There's this thing which, if it would do anything at all, must always be disabled.
16:07:51 <tibbs> So... why don't we just disable it by default?
16:08:18 <geppetto> yeh
16:08:26 <tibbs> (The thing happens to be automatic byte compilation of anything named *.py outside of /usr/lib*/python*.
16:08:35 <tibbs> )
16:08:53 <geppetto> the wording is weird, but I'm not 100% sure it does byte compilation outside of the dirs.
16:09:13 <geppetto> but if it does, that seems bad
16:09:18 <mhroncok1> Got discinnected, sorry
16:09:19 <tibbs> It does.  Always has, actually.
16:09:41 <mhroncok1> should be on a better wifi now
16:10:05 <tibbs> This feature is about turning that off, but right now (as of recent rawhide) what's there is the ability to turn it off.  It's still done by default.
16:10:34 <tibbs> I don't understand why we would have something which is on by default, but which we require that packagers disable.
16:10:45 <mhroncok> tibbs: ok, so let me try to explain
16:10:53 <mhroncok> we want to get rid of it
16:11:03 <mhroncok> but we don't want to break everything
16:11:14 <tibbs> Where "everything" is what, exactly?
16:11:18 <mhroncok> so we say you must disbale it now, so we don't bring in new packages that use it
16:11:35 <mhroncok> later, in 2 or 3 releaes, when this is adapted a bit more, we say it's disabled by default
16:11:56 <tibbs> What would actually break?  At worst some packages wouldn't build due to missing __pycache__ directories, maybe.
16:11:58 <mhroncok> tibbs: packages that rely on the current badly designed bahaviour
16:12:00 <geppetto> do we have a rough list/count of packages that put *.py files outside of /usr/lib/*/python*.*?
16:12:31 <tibbs> There may be plenty, but how does anything rely on it?  Python still runs if files aren't byte compiled.
16:12:38 <mhroncok> it was a couple hundreds IIRC
16:12:49 <geppetto> uh
16:12:51 <mhroncok> ok, iw we turn it of by default, it works for me
16:12:56 <mhroncok> this was the compromise
16:13:13 <tibbs> The context would have been nice, I guess.
16:13:16 <mhroncok> as approved by fesco. I think if we want to switch it of now, we need to get it reapproved
16:13:31 <geppetto> ok
16:13:39 <tibbs> Wish we had had a chance to comment on the fesco discussion, since this is... dumb.
16:13:51 <mhroncok> ok, sorry for not bringing you in
16:14:00 <geppetto> I'm fine with it … just assumed it would only be < 50 packages and it would be easier to just switch it off
16:14:09 <mhroncok> I'm not saying it's fesco who made us do it this way
16:14:15 <mhroncok> I'm just saying it's how it got approved
16:14:35 <tibbs> This is sort of an illustration of a sad point.  We pass this draft and all of those packages still build but are out of compliance with the guidelines.
16:15:00 <mhroncok> tibbs: the packages will stop building it anyway with the other chnage
16:15:02 <mhroncok> ...
16:15:10 <mhroncok> https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package
16:15:24 <mhroncok> trying to get pviktori in
16:15:36 <geppetto> tibbs: what would you prefer?
16:15:42 <mhroncok> he had some list of packages that ship pyc files outside of python dirs
16:15:59 <mhroncok> we can get the list and make a decision next week I guess
16:16:15 <geppetto> I'm mostly fine to +1 now.
16:16:30 <mhroncok> pviktori: just if we have the list of packages
16:16:35 <tibbs> Basically I'm bemoaning an attitude that it's better to have all of these packages in random states of guidelines compliance rather than just break them.
16:16:38 <mhroncok> pviktori: that rely on automagic bytecompilation
16:16:43 <mhroncok> pviktori: or count at least
16:17:23 <tibbs> Obviously there's a tradeoff here, but we could fix those packages with one line instead of adding this weird "on by default but you MUST turn it off" thing to the guidelines.
16:17:36 <tibbs> Which then forces... how many packages to add that?
16:17:37 <geppetto> I would change "compilation, and compile them" to "compilation. You can then compile them"
16:17:46 <geppetto> which I think is easier to read.
16:18:00 <mhroncok> geppetto: feel free to adjust th wording
16:18:03 <mhroncok> in place
16:18:16 <pviktori> I don't have the list ready :(
16:18:19 <mhroncok> tibbs: the one liner would need to know what to bytecompile exactly I guess
16:18:27 <mhroncok> pviktori: np, thnaks
16:18:52 <mhroncok> our idea was to fix all the pythno3 packages
16:18:54 <tibbs> mhroncok: The one liner would just turn the automatic bytecompilation back on.
16:18:58 <mhroncok> and let the python2 packages die
16:19:03 <mhroncok> without fixing them
16:19:20 <mhroncok> tibbs: oh, got it
16:19:23 <tibbs> Just the other day I had to help someone in #fedora-devel to deal with the automatic bytecomp thing because it broke his package.
16:19:36 <mhroncok> right
16:20:12 <mhroncok> se the preffered way is to - get the list - add the onliner to turn this on - make it off y default?
16:20:18 <tibbs> Anyway, I guess we can add this unnecessary complication into the guidelines for now and then rip it out in a year, but that seems to be completely backwards from the right way to do it.
16:20:54 <geppetto> mhroncok: Ok, I've altered it … I'm +1
16:22:25 <geppetto> tibbs: Would you prefer some kind of config. to get the new behaviour?
16:22:30 <tibbs> Current diff is https://fedoraproject.org/w/index.php?title=User%3AChurchyard%2FManual_byte_compilation&type=revision&diff=latest&oldid=520118
16:22:42 <tibbs> geppetto: Exactly the opposite, actually.
16:23:02 <geppetto> Just make the change and have some kind of config. to get the old behaviour?
16:23:15 <tibbs> My point is that it is just bizarre to tell someone "X is on by default; you MUST disable it".
16:23:36 <tibbs> "f you have <code>*.py</code> files outside of the <code>/usr/lib(64)?/pythonX.Y/</code> directories, you '''MUST''' disable their automatic compilation."
16:23:44 <mhroncok> it is bizarre, yes
16:23:59 <geppetto> I mean it's more like "you must disable FOO, if you do weird things"
16:24:14 <tibbs> And the reason for that is that currently %_python_bytecompile_extra is 1.
16:24:34 <geppetto> but, yeh, I understand … but assuming we don't want to break 100s of packages tomorrow … I'm not sure what other option there is
16:24:54 <tibbs> geppetto: I don't see it that way, because the only case FOO _ever_ does anything is when you do those exact weird things.
16:25:36 <tibbs> Anyway, I don't see much point in my arguing about it further since this is the plan that FESCo has approved.
16:25:43 <decathorpe> I quickly generated a list of packages that contain *.pyc files in /usr/share, and which files they are. it's *really* long
16:25:43 <mhroncok> pviktori: are we OK to idenitfy the packages, and push one line to them in an automated fashion?
16:26:14 <mhroncok> we can maybe ask fesco for a change
16:26:27 <tibbs> I don't think it's worth delaying movement on this for that.
16:26:51 <geppetto> That might be less work overall though
16:27:01 <tibbs> When I originally objected I didn't realize that the FESCo part of the process had existed.
16:27:06 <geppetto> But, as I said, I'm +1 on the current draft too.
16:28:20 <tibbs> One thing I might change is to explicitly say "on <= F28, if you need to change the python interpreter which is used for byte compilation of these files, add %global __python %__python3"
16:28:43 <tibbs> Currently it just says "This defaults to <code>/usr/bin/python</code> (that's Python 2.7 on Fedora). If you need to compile the modules for python3, set it to <code>/usr/bin/python3</code> instead"
16:29:28 <tibbs> I.e. tell them the line to add instead of leaving it to them to understand how to set it properly.
16:29:48 <geppetto> Might as well tweak the draft
16:29:56 <mhroncok> tibbs: it's in the fedora <= 28 section
16:30:18 <tibbs> Oh, there it is.
16:30:24 <tibbs> Sorry, I was looking at the diff and not the draft.
16:30:56 <tibbs> Also, ther's this added: "Note that this does disable the compilation of files in /usr/lib(64)?/pythonX.Y/. "
16:31:09 <tibbs> Never mind, I see what it's doing.
16:32:03 <tibbs> It's been too long since I looked at the Python_Appendix document, I think.
16:33:05 <geppetto> limburgher: decathorpe Any comments?
16:33:18 * decathorpe shrugs
16:33:47 <limburgher> Not really. Given the FESCO sitch, +1.
16:34:01 <geppetto> #chair
16:34:01 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok mhroncok_phone tibbs
16:34:08 <decathorpe> yeah, +1 for now, even though the approach is strange
16:34:12 <geppetto> #unchair mhroncok_phone
16:34:12 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok tibbs
16:34:26 <tibbs> +1 and we'll fix this in a year or so.
16:34:28 <geppetto> tibbs: Ok, I think that just leaves you
16:34:35 <geppetto> I'm assuming mhroncok is +1
16:35:19 <geppetto> #action Manual Python byte compilation change (+1:5, 0:0, -1:0)
16:35:21 <geppetto> Ok
16:35:41 <mhroncok> yes, I'm +1
16:36:29 <geppetto> #topic #691 noarch *sub*packages with arch-specific dependencies
16:36:31 <geppetto> .fpc 691
16:36:33 <zodbot> geppetto: Issue #691: guidelines change: noarch *sub*packages with arch-specific dependencies - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/691
16:37:02 <geppetto> mhroncok: opened the releng ticket
16:37:20 <tibbs> Should probably drop this out of meeting state until we get info.
16:37:21 <mhroncok> finally
16:37:29 <mhroncok> sorry for the dealy
16:37:33 <geppetto> no problem
16:37:45 <geppetto> ticket has been open since way before you got here
16:37:46 <mhroncok> updated the tags
16:38:29 <geppetto> cool
16:38:40 <geppetto> ok, I thik that's it for updates …
16:38:45 <geppetto> #topic Open Floor
16:38:52 <geppetto> Anyone have anything they want to talk about?
16:38:59 <limburgher> Not I.
16:39:17 <tibbs> I decided it would be good to have webextension guidelines, so I figured I would start trying to draft some.
16:39:40 <tibbs> But I kind of realize that I don't know a lot about how chrome does them.
16:39:44 <mhroncok> tibbs: I've seen it. but I really don't have any opinions there
16:39:50 <mhroncok> exactly
16:40:30 <tibbs> Or rather, the way it seems to do it is bizarre, where the files aren't actually in the package.  Instead there's a pointer to some internal bit of the chrome store and chrome fetches the files from there.
16:40:46 <mhroncok> tibbs: that's rather horrible
16:40:59 <tibbs> But I don't have a lot of examples to follow.
16:41:13 <decathorpe> web browsers seem to be special kind of horrible, yeah
16:41:16 <geppetto> tibbs: so if the bits go away upstream the package is worthless?
16:42:00 <tibbs> I guess that would be a side effect, yes.
16:42:24 <geppetto> smh
16:43:11 <tibbs> For example, the current webextension-token-signing package has /usr/share/chromium/extensions/(random-crap).json
16:43:23 <tibbs> That only contains "external_update_url": "https://clients2.google.com/service/update2/crx"
16:43:50 <tibbs> The firefox xpi file is just a zip of the actual javascript and content.
16:44:07 <geppetto> That's kind of what I expected
16:44:29 <geppetto> just pointing to an external url seems bad
16:44:44 <tibbs> Anyway, I'll have to look at it further but if anyone knows more about Chrome than the tiny bit I know, feel free to chime in.
16:44:53 <limburgher> geppetto, when has that ever stopped anyone?
16:44:55 <mhroncok> tibbs: maybe spot would know
16:45:03 <limburgher> mhroncok, great point.
16:45:06 <geppetto> yeh, spot is the only person I can think of
16:45:26 <geppetto> although I'm not even sure how much he knows about the extensions
16:45:37 <geppetto> Anyway...
16:45:43 <geppetto> I'll give you all 15 minutes of your day back
16:45:47 <geppetto> #endmeeting