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