16:00:01 <geppetto> #startmeeting fpc
16:00:01 <zodbot> Meeting started Thu Jul 19 16:00:01 2018 UTC.
16:00:01 <zodbot> This meeting is logged and archived in a public location.
16:00:01 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:01 <zodbot> The meeting name has been set to 'fpc'
16:00:02 <geppetto> #meetingname fpc
16:00:02 <geppetto> #topic Roll Call
16:00:02 <zodbot> The meeting name has been set to 'fpc'
16:00:10 <tibbs> Hey, folks.
16:00:11 <redi> hi
16:00:12 <geppetto> #chair redi
16:00:12 <zodbot> Current chairs: geppetto redi
16:00:15 <geppetto> #chair tibbs
16:00:15 <zodbot> Current chairs: geppetto redi tibbs
16:00:18 <ignatenkobrain> .hello2
16:00:19 <geppetto> Hey
16:00:19 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:00:22 <geppetto> #chair ignatenkobrain
16:00:22 <zodbot> Current chairs: geppetto ignatenkobrain redi tibbs
16:00:25 <decathorpe> .hello2
16:00:26 <zodbot> decathorpe: decathorpe 'None' <decathorpe@gmail.com>
16:00:30 <geppetto> #chair decathorpe
16:00:30 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain redi tibbs
16:00:40 <geppetto> woo, 5 ftw :)
16:00:48 <orionp> .hello2
16:00:51 <zodbot> orionp: Sorry, but you don't exist
16:00:54 <geppetto> #chair orionp
16:00:54 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain orionp redi tibbs
16:00:58 <orionp> hah!
16:01:00 <redi> :)
16:01:23 <decathorpe> hi everybody! I'm really sorry for meeting the last few meetings, I've spent three weeks in hospital ... but I'm back now
16:01:33 <mhroncok> hi
16:01:39 <geppetto> #chair mhroncok
16:01:39 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok orionp redi tibbs
16:01:49 <geppetto> decathorpe: You doing better?!?
16:02:06 <decathorpe> gepetto: yeah, I am. thanks :)
16:02:20 <decathorpe> oops, typo.
16:03:11 <geppetto> no problem :)
16:03:15 <ignatenkobrain> so many ppl today
16:03:33 * mhroncok would need to bail out in ~1 hour
16:03:47 <geppetto> mhroncok: we only have the meeting for 1 hour
16:03:59 <mhroncok> geppetto: well, but it could go into 2 hours
16:04:29 <geppetto> Maybe, I think we've run into go/no-go meetings before … but that's probably not on atm.
16:04:51 <geppetto> #topic Schedule
16:04:53 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/GSUKP4G7KFIJAH2DYHMI5H6VOJTEEVYJ/
16:05:03 <geppetto> #topic #759 Don't require editing of Source0 in Python spec template
16:05:06 <geppetto> .fpc 759
16:05:08 <zodbot> geppetto: Issue #759: Don't require editing of Source0 in Python spec template - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/759
16:05:34 <geppetto> There were a couple of votes in the ticket here already
16:06:00 <mhroncok> +1 (already on the ticket)
16:06:18 <ignatenkobrain> +1 from me
16:06:36 <tibbs> I was +1 in the ticket
16:06:51 <orionp> +1
16:06:59 <decathorpe> +1 from me too
16:07:39 <geppetto> redi: Ok, just you left to vote
16:08:06 <redi> +1 !
16:08:08 <geppetto> #action Don't require editing of Source0 in Python spec template (+1:7, 0:0, -1:0)
16:08:12 <mhroncok> (for the logs) geppetto was +1 on the ticket
16:08:19 <tibbs> I'll write that up now.
16:08:27 <geppetto> #topic #774 Reword "Addon Packages" a bit
16:08:31 <geppetto> .fpc 774
16:08:32 <zodbot> geppetto: Issue #774: Reword "Addon Packages" a bit - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/774
16:09:12 <geppetto> tibbs: we talked a little about this withou quorum … do you have anything to say for everyone?
16:09:56 <tibbs> Not really.  I'm still not sure if removing the "new" was the only change requested.
16:10:04 <tibbs> If so, I think I would have just done it.
16:10:15 <geppetto> #topic #775 Allow to have %{?suse_version} condition in spec file
16:10:19 <geppetto> .fpc 775
16:10:20 <zodbot> geppetto: Issue #775: Allow to have %{?suse_version} condition in spec file - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/775
16:10:30 <redi> eurgh
16:11:51 <tibbs> I'm still -1 to any "official" acceptance of this kind of thing.
16:12:01 <redi> down with this sort of thing
16:12:09 <geppetto> I mostly agree with tibbs in the ticket … it's fine in small doses, but don't really want to encourage it.
16:12:21 <geppetto> Adding a few extra provides should be a lot easier, and cleaner.
16:13:07 <tibbs> I'd rather just say that "we can't stop you, but will try to avoid automatic cleanup which would interfere with that stuff"
16:13:31 <redi> yeah. If somebody wants to do it, I don't think we should go around ripping that stuff out of their spec, but also don't want to see it officially blessed or encouraged
16:14:07 <geppetto> Might be worth saying something about adding provides as a better/cleaner workaround
16:14:45 <ignatenkobrain> agree with tibbs
16:14:59 <tibbs> Adding dependencies won't be a complete workaround in any case.
16:15:05 <tibbs> But it would certainly help.
16:15:11 * geppetto nods
16:15:47 <tibbs> And if maintainers don't want to do that, we can always add stub packages like I do for python2-* in EPEL.
16:16:38 <geppetto> Hmm
16:16:49 <geppetto> Not sure we want to encourage that either :p
16:16:56 <tibbs> Of course you could balk at going through all that effort to avoid just having someone use some suse-specific macro, but I think saving packagers from having to care is better.
16:17:47 <tibbs> And, sure, no point in thinking about stub packages until after the relevant maintainers have nixed the idea of adding the Provides: to the relevant packages.
16:18:00 * geppetto nods
16:18:02 <tibbs> Anyway, it's just a PR away.
16:18:22 <geppetto> So, do we want to vote on anything here?
16:19:10 <tibbs> I don't really think anything would pass.
16:19:40 <geppetto> #topic #777 Improved text for default services page
16:19:42 <geppetto> .fpc 777
16:19:43 <zodbot> geppetto: Issue #777: Improved text for default services page - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/777
16:19:45 <tibbs> But there seems to be some agreement that we shouldn't blanket allow such things, so I don't think any guidelines change would happen.
16:20:02 <tibbs> OK, I put together a draft.
16:20:20 <tibbs> I think it says what was requested.
16:21:11 <tibbs> If anyone understands the "optionally failing" thing, feel free to tell me WTF it's supposed to be allowing.
16:22:28 <tibbs> Seems like we go to lengths to say that services can't fail if they're enabled by default, and then.... it's OK for them to fail if they have an opt-in mechanism.
16:22:47 <redi> "for example, when hardware which is expected to be present is removed or stops functioning" could do with clarification
16:22:49 <tibbs> But I thought the opt-in mechanism would be "systemctl enable" so I guess I just don't get it.
16:23:02 <redi> not much point in an example if it doesn't tell us what it's saying
16:23:06 <tibbs> redi: I don't disagree, but that is their text.
16:23:16 <redi> yeah, I'm not criticising your draft :)
16:23:28 <tibbs> And as I've said, I don't understand at all what is wanted, so I don't know how to make it better.
16:24:28 <tibbs> Maybe they have in mind some tool to control these things which somehow doesn't end up doing 'systemctl enable' when it wants to turn them on.
16:24:38 <tibbs> That seems utterly bizarre to me.
16:24:58 <tibbs> There must be some example someone had in mind; I just don't know what it is.
16:25:20 <tibbs> And I don't understand why saving state matters at all.
16:25:35 <orionp> I wonder if rngd is compliant these days - it exits with an error on EL7 on hardware that doesn't support it - not sure about current Fedora....
16:26:03 <redi> I think I get it
16:27:03 <redi> lets say you have a fancy fpga board installed. you enable a service that's meant to talk to it. if it melts, you don't want the service to just silently exit without error. you want it to be marked as "failed"
16:27:16 <redi> the current rule doesn't allow that
16:28:14 <redi> if it saves state in permanent storage it can record that it worked on the last boot, and therefore its failure now is unexpected, so mark as failed
16:28:23 <redi> if it never worked previously, it was probably never installed.
16:28:52 <redi> I'm not sure what the "An opt-in mechanism involving a userspace tool with proper documentation." means though. If you have to opt-in then the service isn't enabled by default anyway, and isn't covered by these rules
16:29:22 <tibbs> The current rule does allow that, though.
16:30:29 <tibbs> Hmm, OK, maybe that was true of one of the three versions of this that I lost because of the wiki being a wiki.
16:30:40 <redi> :)
16:31:04 <tibbs> At one point there was a phrase saying that things had to start without error under normal conditions.
16:31:49 <geppetto> redi: I think it's saying an opt in mechanism that makes the service fail when HW doesn't exist
16:31:49 <tibbs> They could still fail under exceptional conditions, like "you have the random number generator but... somehow we are erroring out when talking to it because your motherboard is fried".
16:32:39 <redi> geppetto: yeah, I was going to say something like that. so normally if it doesn't exist, it exits silently, but there's a way to say "be noisy if it stops working"
16:32:49 * geppetto nods
16:33:34 <geppetto> FWIW this is the diff. from current: https://fedoraproject.org/w/index.php?title=Tibbs%3ADefaultServices&type=revision&diff=522564&oldid=522327
16:33:38 <geppetto> I think I'm +1
16:33:52 <redi> tibbs: yeah, h/w that is expected to be present (because it's been configured to be expected) not being present is exceptional.
16:34:14 <redi> the bullet about saving state in permanent storage says "to aid in detecting the failure" which seems to suggest it only stores some info about the failure for debugging, rather than my guess of remembering if it worked last boot
16:34:28 <redi> I might be reading too much between the lines.
16:34:51 <tibbs> How about if I add a fourth condition "Must not fail under normal conditions".
16:35:02 <redi> works for me
16:35:04 <tibbs> In the text, define what "fail" means.
16:36:17 <redi> I still think a concrete example (from sgallagh or zbyszek) could clarify things
16:36:28 * sgallagh looks up
16:36:58 <redi> sgallagh: https://pagure.io/packaging-committee/issue/777 the "such as if hardware that is expected to be present disappears or stops functioning" case
16:37:01 <sgallagh> Could someone summarize the question? there's a lot of scrollback
16:37:17 <redi> sgallagh: https://pagure.io/packaging-committee/issue/777#comment-522407
16:37:25 <redi> "And then that weird section about value in optionally failing comes along and contradicts all of the other rules and confuses things"
16:38:02 <sgallagh> redi: I mean that there may be services for which we *want* to know if they stopped working when they previously worked fine.
16:38:37 <sgallagh> For example, we installed a hardware RNG device to provide entropy to the system, but later it malfunctioned or someone knocked it out of the machine.
16:39:03 <sgallagh> It should't fail in the pristine case where we assume that people don't have hardware RNG devices normally
16:39:17 <sgallagh> But it probably SHOULD fail if one had been detected and used previously and suddenly isn't there anymore
16:39:36 <redi> but if it was working on last boot, or if the admin has somehow said "this machine expects this h/w" then it should be marked "failed" if absent
16:39:36 <sgallagh> So we need to be able to store that information and make decisions from it
16:39:49 <tibbs> Right, that's why I'm adding this text as an additional prerequisite for something starting by default: The service must not under normal operating conditions exit with an error causing systemd to mark the unit as failed.  A service which is started by default is permitted to fail under exceptional conditions.
16:40:11 <sgallagh> redi: Yes
16:40:23 <tibbs> That is now in the current draft.
16:40:34 <sgallagh> That clause is to allow for those decisions to be made automatically if sensible and not necessarily require the admin to say "we expect this"
16:41:13 <tibbs> If that is the whole point of that extra section, then simply saying "yes, you can fail when you see that something is broken" should cover it, I think.
16:41:26 <redi> yeah
16:41:26 <sgallagh> tibbs: Works for me.
16:42:13 <tibbs> OK, I added that text and removed the more confusing text.
16:42:17 <sgallagh> Thanks
16:42:24 <tibbs> So reload and have a look.
16:42:44 <tibbs> If folks need time to read, we can move on and collect votes in the ticket.  But we should try to get this done soon.
16:43:03 <redi> tibbs: would "The service must not under normal operating conditions exit with an error causing systemd to mark the unit as failed" read better with commas around the "under normal operating conditions" clause?
16:43:27 <redi> i.e. The service must not, under normal operating conditions, exit with an error causing systemd to mark the unit as failed.
16:43:57 <tibbs> That's a tricky grammatical question.  The sentence doesn't have dependent clauses so it wouldn't cause comma overload.
16:44:11 <sgallagh> parens might be more clear
16:44:31 <redi> or "Under normal operating conditions, the service must not exit with an error causing systemd to mark the unit as failed." but I see the value in starting each requirement with "The service must not ..."
16:44:35 <sgallagh> Should we perhaps provide a non-exhaustive example of "exceptional conditions" (such as "hardware present but malfunctioning")?
16:44:50 <tibbs> An example certainly wouldn't hurt.
16:44:53 <redi> yes, that's kind of what I was getting at with concrete examples.
16:45:21 <tibbs> Parentheses tend to be over-inserted in English text by programmers, I think.
16:45:32 <redi> I know I'm guilty (of that)
16:45:38 <sgallagh> heh
16:45:49 <tibbs> Adding an example.
16:46:13 <geppetto> (•‿•)
16:47:02 <sgallagh> .fire geppetto
16:47:03 <zodbot> adamw fires geppetto
16:48:00 <geppetto> ha
16:48:15 <tibbs> OK, two examples have been added.
16:48:55 <geppetto> +1
16:48:58 <redi> "Or a server could fail to start "  s/server/service/ ?
16:49:31 <redi> or do you mean a service that runs a server? I guess either is right :)
16:49:56 <mhroncok> I'd rather say service
16:49:59 <sgallagh> I think "service" is more correct there.
16:49:59 <tibbs> "service" is what I intended.  Fixed.
16:50:02 <mhroncok> if server was intentional
16:50:05 <sgallagh> Otherwise, that looks good to me
16:50:06 <mhroncok> ok
16:50:07 <redi> when I first read it I thought "server" meant a machine
16:50:15 <redi> but it could be a web server, or NFS server etc
16:50:31 <redi> LGTM
16:50:33 <sgallagh> redi: Which are actually just "machines running the web service"
16:50:49 <redi> :)
16:51:33 <tibbs> +1 in case it isn't obvious.
16:51:40 <redi> +1
16:51:41 <mhroncok> +1
16:51:51 <redi> the latest draft clarifies all the bits that gave me pause
16:52:04 <redi> sgallagh: thanks for jumping in
16:52:43 <sgallagh> Happy to help
16:53:03 <decathorpe> if you need another vote, it's +1 from me since I think you fixed all the issues while I wasn't looking ;)
16:54:26 <geppetto> yeh, that's +5 now … but mhroncok or ignatenkobrain can still vote
16:54:38 <mhroncok> geppetto: I voted
16:54:49 <mhroncok> orionp can vote i guess
16:55:02 <geppetto> yeh, ignatenkobrain or orionp
16:55:20 <orionp> +1
16:55:31 <tibbs> OK, so one more down.
16:55:39 <tibbs> Still have a couple of minutes.
16:55:43 <ignatenkobrain> yeah, +1
16:55:43 * geppetto nods
16:55:48 <ignatenkobrain> had to re-read
16:55:49 <geppetto> #action Improved text for default services page (+1:7, 0:0, -1:0)
16:55:59 <geppetto> #topic #781 Wiki:Packaging:Java Guidelines Update (one-liner)
16:56:01 <geppetto> .fpc 781
16:56:02 <zodbot> geppetto: Issue #781: Wiki:Packaging:Java Guidelines Update (one-liner) - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/781
16:56:06 <geppetto> looks like we should be able to do this
16:57:05 <mhroncok> can we +1 it conditionally?
16:57:22 <tibbs> Well we can accept it but not write it up until it's ready.
16:57:35 <decathorpe> mhroncok: I thought we hate conditionals ;)
16:57:40 <ignatenkobrain> yep, agreed
16:58:05 <mhroncok> decathorpe: :D
16:58:08 <mhroncok> ok, +1
16:58:37 <mhroncok> I will have to go
16:58:38 <tibbs> I'm still +1 with the assumption that someone's actually going to fix what breaks.
16:58:45 <redi> +1 - seems to make sense
16:58:52 <mhroncok> consider me +1 on the python_sitearch/lib one
16:58:55 <mhroncok> bye
16:58:58 <tibbs> take care.
16:58:59 <decathorpe> +1
16:59:03 <geppetto> +1
16:59:27 <ignatenkobrain> +1
16:59:55 <tibbs> I do still agree that this should be filed as a change, but if we approve this then that portion of the change process is complete.
17:01:01 <tibbs> We still do have quorum.
17:01:58 <geppetto> orionp: vote?
17:03:06 <geppetto> #action Wiki:Packaging:Java Guidelines Update (+1:6, 0:0, -1:0)
17:03:09 <orionp> I'll just note that javapackages-filesystem is not (yet?) in EL7
17:03:18 <geppetto> #topic #782 Forbid %{pythonX_site(lib|arch)}/* in %files
17:03:25 <geppetto> .fpc 782
17:03:26 <zodbot> geppetto: Issue #782: Forbid %{pythonX_site(lib|arch)}/* in %files - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/782
17:03:58 <geppetto> So mhroncok already voted +1
17:04:35 <tibbs> So the guidelines already say what you should use in https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
17:04:49 <tibbs> And already say this:
17:04:55 <tibbs> You should not include the directories %{python3_sitearch}/__pycache__ or %{python3_sitelib}/__pycache__ because they are already owned by the python3-libs package.
17:05:09 <tibbs> So... this ticket is kind of redundant.
17:05:20 <tibbs> Will capitalize that should, though.
17:05:56 <tibbs> I made that change.
17:06:16 <decathorpe> Is there anything else?
17:06:21 <tibbs> So... this ticket seems to come down to changing the SHOULD NOT to a MUST NOT.
17:07:01 <redi> looks that way
17:07:02 <tibbs> I'm personally OK with MUST but I'm still struggling to figure out what difference it really makes.
17:07:25 <redi> same here
17:07:33 <ignatenkobrain> tibbs: just directory ownership?
17:07:51 <tibbs> Yes, it just leads to multiple ownership of the __pycache__ directory.
17:07:58 <ignatenkobrain> it's like we could do /*
17:08:25 <tibbs> Right, though most would get it wrong and hit conflicts due to permissions on /usr being 555.
17:08:42 <tibbs> Sorry, not /usr, /usr/bin.
17:08:51 <tibbs> No idea why that's the case, but it is.
17:09:27 <tibbs> The ticket linked to a bugzilla ticket, but it turned out to be unrelated.
17:10:16 <ignatenkobrain> FWIW, we could automatically generate .python3-files.list  and use %files -f
17:10:43 <ignatenkobrain> shouldn't it be better? ;0
17:10:52 <ignatenkobrain> but I would vote +1 for changing SHOULD NOT to MUST NOT
17:11:16 <decathorpe> yeah, that change from SHOULD to MUST won't hurt, so +1 from me too
17:11:19 <tibbs> We could, technically, as part of %python3_install.
17:11:40 <tibbs> I can +1 it; it's really just a cleanliness issue.
17:12:39 <redi> +1 but I'm mostly just going along with peer pressure to look cool, because I don't really get it ;)
17:13:31 <geppetto> :)
17:13:33 <tibbs> It's OK to just leave the votes tallied in the ticket and let Miro comment on whether he thinks things still need to change.
17:13:39 <redi> if somebody has a good reason they want to do it we can change back to SHOULD NOT, but until then MUST NOT seems good
17:13:43 <tibbs> I mean, it doesn't have a real draft.
17:14:29 <tibbs> Unless my proposal of "s/SHOULD/MUST/ in one place" counts....
17:15:34 <tibbs> I think we should move on, really.
17:15:59 <geppetto> Ok, that's way over an hour and al the new tickets
17:16:20 <geppetto> We have +3 for this … and I'm mostly happy to +1 it making it +4
17:16:33 <geppetto> Oh, ignatenkobrain was +1 too
17:16:39 <geppetto> So that's +5
17:17:46 <geppetto> orionp: or decathorpe want to vote?
17:18:14 <tibbs> He may still have changes in mind, but I may hoist that bit out of the "Byte compilation" section into some place where it's more obvious that we're indicating how your %files section should look.
17:18:23 * geppetto nods
17:18:24 <decathorpe> I already voted +1
17:19:03 <orionp> +1
17:19:18 <geppetto> #action Forbid %{pythonX_site(lib|arch)}/* in %files (+7, 0:0, -1:0)
17:19:24 <geppetto> #topic Open Floor
17:19:36 <geppetto> Ok, anything quick to talk about?
17:19:41 <tibbs> Might be worth taliking about 784 even though it's really new.
17:20:57 <decathorpe> well, I finally got around to formalize my thoughts about this, we don't have to talk about it today
17:21:16 <decathorpe> it just frustrates me that the number of "accidental soname bumps" seems to grow
17:22:08 <tibbs> You're right, but if this is really to help it would be good to have an idea of how to find packages which don't do the right thing.
17:22:24 <ignatenkobrain> even I understand the motivation, this will complicate CI systems for instance where you use one spec to build git versions of a package. also people will get annoyed for this
17:22:27 <ignatenkobrain> so I'm +0.1
17:22:28 <ignatenkobrain> ;)
17:22:48 <decathorpe> even when doing CI it's useful information that the soname has changed
17:23:21 <tibbs> It may even be more important in the context of a CI system.
17:23:22 <ignatenkobrain> tibbs: well, we can always patch build/files.c to make an error if /usr/lib*/*.so* is included by such regex after all
17:24:00 <decathorpe> (if it helps, I can hack up a script to check all specs and come back next week with more data)
17:24:06 <tibbs> Would rather find it by specfile inspection rather than another big bunch of FTBFS.
17:24:21 <tibbs> I'm just unclear on how you would handle it, though.
17:24:23 <geppetto> I'm mostly -1 … as I think it should be solved in a different way (like in bodhi or something)
17:24:42 <tibbs> Certainly bodhi doesn't help you for rawhide.
17:24:56 <geppetto> true, but does anyone care for rawhide?
17:25:00 <ignatenkobrain> well. gating + rawhide kinda didn't work out
17:25:13 <decathorpe> even for rawhide soname bumps have to be announced one week in advance
17:25:21 <decathorpe> which is hard if you do one accidentally
17:25:21 <ignatenkobrain> geppetto: well, I use it ;)
17:25:30 <tibbs> But you're right that this is a half-solution.
17:26:20 <tibbs> I mean, an unchanging so version does not really imply that a library update doesn't require rebuilds down the dependency tree.
17:26:30 <geppetto> sure, that too
17:26:39 <decathorpe> geppetto: bodhi didn't help in the soundtouch case, where an accidental soname bump was pushed to stable (without rebuilding dependencies, of course)
17:27:17 <geppetto> decathorpe: yeh, I'm just saying that something should trigger a giant warning in bodhi that says "This is an SO bump change, are you really sure etc. etc."
17:27:33 <tibbs> Still, we can only control packaging guidelines.
17:27:56 <geppetto> Yeh, it just feels like the wrong way to workaround the problem
17:28:07 <decathorpe> yes, that would help preventing pushed updates. we could still discourage usage of globs
17:28:34 <tibbs> Thing is, if we discourage it somehow then someone is justified in filing various reports about it.
17:29:05 <geppetto> decathorpe: Why do you want to discourage globs though?
17:29:30 <geppetto> decathorpe: apart from as a workaround for updates going out without testing
17:29:56 <decathorpe> because packagers actually would notice soname bumps, because the build would fail
17:30:19 <tibbs> I think the fundamental issue is that there are a number of cases where it would have helped maintainers to notice changing SO versions.
17:30:28 <decathorpe> tibbs: exactly
17:30:53 <tibbs> I thought there was some system which notified maintainers of ABI changes, but of course after you've done 'fedpkg build' it's too late.
17:31:13 <tibbs> The fact that we also don't have a broken deps report just exacerbates the problem.
17:31:25 <tibbs> But of course that's not FPC's issue to deal with.
17:32:10 <decathorpe> As I said, I'll check how many packages this "glob issue" affects until next week, so we have more data to base our discussion on.
17:32:40 <geppetto> Ok
17:33:13 <geppetto> Alright, I'll close in a minute
17:33:17 <geppetto> only 35 minutes over :)
17:33:50 <tibbs> It's not time wasted if something got done.
17:33:56 * geppetto nods
17:34:19 <tibbs> Besides, 35 over isn't bad for having missed quorum for the previous several meetings.
17:34:43 <geppetto> True
17:35:22 <geppetto> #endmeeting