16:00:07 <geppetto> #startmeeting fpc
16:00:07 <zodbot> Meeting started Thu Mar 14 16:00:07 2019 UTC.
16:00:07 <zodbot> This meeting is logged and archived in a public location.
16:00:07 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:07 <zodbot> The meeting name has been set to 'fpc'
16:00:07 <geppetto> #meetingname fpc
16:00:07 <geppetto> #topic Roll Call
16:00:07 <zodbot> The meeting name has been set to 'fpc'
16:00:09 <mhroncok> hey
16:00:14 <geppetto> #chair mhroncok
16:00:14 <zodbot> Current chairs: geppetto mhroncok
16:00:19 <tibbs> Hey, folks.
16:00:23 <geppetto> mhroncok: hey, how do you feel about running it this week?
16:00:23 * limburgher hi
16:00:28 <geppetto> #chair tibbs
16:00:28 <zodbot> Current chairs: geppetto mhroncok tibbs
16:00:31 <geppetto> #chair limburgher
16:00:31 <zodbot> Current chairs: geppetto limburgher mhroncok tibbs
16:00:31 <ignatenkobrain> .hello2
16:00:32 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:00:36 <geppetto> #chair ignatenkobrain
16:00:36 <zodbot> Current chairs: geppetto ignatenkobrain limburgher mhroncok tibbs
16:00:39 <mhroncok> geppetto: as in now?
16:00:44 <geppetto> mhroncok: yeh
16:01:10 <mhroncok> geppetto: I guess I can. do we have a schedule?
16:01:31 <geppetto> Nothing's changed since last week or so … didn't mail anything out, no.
16:01:37 <tibbs> Another terrible week for me.  Might be getting better in a couple of weeks.
16:01:55 <tibbs> Haven't seen much packaging-related stuff going on besides the fedora-review work (which is great).
16:02:16 <geppetto> yeh, I'm stuck in internal stuff … and on holiday next week
16:02:57 <mhroncok> #topic Schedule
16:03:02 <mhroncok> #link https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
16:03:11 <tibbs> I need to spend ten minutes re-tagging the issue list and then just need to fix some broken links and formatting and such.
16:03:30 <mhroncok> #info Nothing has changed since last week
16:03:54 <geppetto> tibbs: you think there are new tickets which you can move to meeting?
16:04:08 <mhroncok> anyone want to discuss  859 Scriptlet to replace a directory: try delete first? / or 845 Wiki deprecation status?
16:04:09 <tibbs> To be fair I haven't spent the ten minutes to see.
16:04:20 <tibbs> I did ask RPM upstream about 859.
16:04:42 <tibbs> Basically what we have is still the "recommended way".
16:05:03 <tibbs> But I think that was more as in "you still have to use that method" instead of "that's exactly the code that you should use".
16:05:46 * geppetto nods
16:05:58 <mhroncok> on a side topic, slighly relevant: should we recommend using trailing / for directories in %files?
16:06:05 <tibbs> The situation is rare enough that the questions seem closer to theoretical, but I don't think it would hurt anything if they were implemented.
16:06:16 <tibbs> Thing is, do we want to touch this and risk screwing it up?
16:06:16 <mhroncok> so they don't accidentally become a file?
16:06:37 <geppetto> mhroncok: dos that affect picking up all the files inside the dir.
16:06:46 <mhroncok> geppetto: it changes nothing
16:06:50 <tibbs> mhroncok: I do that myself and would think a recommendation would be good.  I think all of our examples already do that but if they don't then we should fix them.
16:06:51 <mhroncok> except it fails if it is not a dir
16:06:54 <geppetto> Ok, I'm fine with it then
16:07:06 <mhroncok> I'll open a ticket
16:07:19 <mhroncok> so we can do both (recommend and check examples)
16:07:25 * geppetto nods
16:07:37 <mhroncok> ok...
16:07:41 <mhroncok> #topic Open Floor
16:08:11 <mhroncok> I don't think we have anything else to discuss, but please do if you have
16:08:35 <ignatenkobrain> I'll need to update Rust guidelines since we changed them a bit
16:08:44 <ignatenkobrain> I'll submit PR as soon as I have it
16:08:47 <ignatenkobrain> just FYI
16:09:21 <ignatenkobrain> also I heard that FedoraReview is getting Python 3 port and is being fixed to work with latest guidelines changes
16:09:22 <ignatenkobrain> also FYI
16:09:45 <tibbs> I wonder how much would break if check-rpaths was in %__arch_install_post by default.
16:10:20 <tibbs> The the advice in the Beware of Rpath section is weird because most people just use mock so your personal .rpmmacros file doesn't make any difference.
16:10:22 <ignatenkobrain> oh, isn't it there by default? !
16:10:47 <tibbs> Not as far as I can tell.
16:11:00 <tibbs> Unless check-buildroot performs that check itself.
16:11:52 <tibbs> The guidelines also say that check-rpaths is in rpmdevtools, but it's in rpm-build.
16:12:11 <tibbs> This is what happens when I start reading guidelines at the random place where I stop scrolling.
16:12:25 <geppetto> obv. stop doing that then ;)
16:12:32 <ignatenkobrain> I would vote to move it ot arch_install_post :)
16:12:52 <tibbs> I would, too, but I am concerned about how much it would break.
16:13:12 <ignatenkobrain> submit F31 change and we will see :)
16:13:12 <mhroncok> I think we should add more enforcing to brp scripts
16:13:17 <mhroncok> generally
16:13:34 <tibbs> Yes, though this isn't actually a brp script.
16:13:45 <mhroncok> it is still easy to opt-out in case you have an exceptional case
16:14:15 <tibbs> I'm not entirely sure how things run from %__arch_install_post differ from things run in %__os_install_post.
16:14:22 <mhroncok> tibbs: right what i really mean is add stuff to "happens automatically"
16:16:03 <mhroncok> ok. if that's it, I'll end in 5 minutes
16:16:30 <tibbs> Yes, if we have enough "local" information to do a check (i.e. just by looking at the stuff in the buildroot) then we should definitely be doing that check.
16:17:08 <ignatenkobrain> one thing if you get some time during a week
16:17:10 <tibbs> The disablement mechanism for brp scripts we have works well and is easier than messing with some external system to disable checks.
16:17:15 <ignatenkobrain> https://pagure.io/fedora-rust/rust2rpm/issue/70
16:17:50 <ignatenkobrain> tl;dr there is a problem that (a >= 2.0.0 with a < 3.0.0) are matching 3.0.0~beta versions
16:18:00 <ignatenkobrain> so I proposed some workaround work it, probably you have some input on that
16:18:29 <tibbs> I mean, that's not a problem according to the definitions of "<" and "~".
16:19:00 <tibbs> I would expect it to work that way, but I guess some could be confused by it.
16:19:00 <ignatenkobrain> yes, definitely. but it is a problem for us :)
16:19:14 <mhroncok> just stick in the ~ I guess, as proposed
16:19:43 <ignatenkobrain> mhroncok: welp, 3.0.0~~~beta is valid too
16:19:48 <tibbs> That is the only logical solution, again given the definitions of "<" and "~".
16:19:56 <geppetto> a < 3.0.0~~~~~~~ ;)
16:20:08 <ignatenkobrain> geppetto: a < 3.0~~~~~~~~~~~~~~~~~~~~~~~~`
16:20:08 <ignatenkobrain> :)
16:20:14 <geppetto> indeed
16:20:17 <tibbs> I think that if someone does that, they get to keep the pieces.
16:20:21 <mhroncok> ignatenkobrain: valid yes, but reasonable to support?
16:20:28 <mhroncok> tibbs: exactly
16:20:40 <tibbs> It's the kind of theoretical question that is more annoying than practical.
16:21:41 <mhroncok> ignatenkobrain: that reminded me https://github.com/rpm-software-management/rpm/issues/639
16:21:46 <redi> hi - I've got something else in my calendar now, so can't attend the meeting sorry
16:21:47 <tibbs> I wonder how close upstream RPM is to a release.
16:21:48 <ignatenkobrain> in future we can come up with Requires(semver): ^1.0.0
16:21:48 <redi> same next week too
16:22:31 <tibbs> And caret version is exactly why I'm asking.
16:22:33 <mhroncok> redi: but not forever, tight? do we need to reschedule?
16:22:34 <ignatenkobrain> tibbs: I hope there will be one for f31
16:22:36 <ignatenkobrain> because I planned 2 changes for it
16:22:48 <ignatenkobrain> automatic BuildRequires and automatic inter-package dependencies
16:22:49 <tibbs> Yeah, those changes were kind of premature.
16:22:56 <ignatenkobrain> though still need to write code for it
16:23:12 <redi> mhroncok: not forever, just this week and next
16:23:17 <mhroncok> redi: ok
16:23:46 <tibbs> I'm generally dismayed by the attitude that we don't patch Fedora's RPM and we have to wait for a release when there are no defined criteria for such a thing.
16:23:58 <ignatenkobrain> tibbs: otherwise it won't happen in next few years if you don't push people 🤷
16:24:07 <ignatenkobrain> yes, I also disagree with this
16:24:11 <ignatenkobrain> it doesn't make sense for me
16:24:36 <mhroncok> bring that to fesco?
16:24:43 <tibbs> It makes sense as long as releases come quickly or regularly.
16:25:05 <tibbs> But Fedora does need to be able to plan and right now when RPM is involved that can't really happen.
16:26:58 <ignatenkobrain> mhroncok: once I find some annoying bug and RPM maintainers will refuse to backport it, I'll open a FESCo ticket
16:27:10 <mhroncok> good
16:27:17 <tibbs> Anyway, I'm done.  Will bring the check-rpaths thing to RPM upstream before thinking about filing a feature.
16:27:39 <ignatenkobrain> for example this one https://github.com/rpm-software-management/rpm/commit/ef422951aeb328c3274bc7b355bf8387306590f3
16:28:00 <ignatenkobrain> rpm2archive on source rpms is basically broken (it prepends '.' before each file)
16:29:24 <mhroncok> ok, another 5 minutes to the end
16:30:03 <tibbs> I'm done.
16:30:08 <ignatenkobrain> I think we can just close this and discuss it over email :)
16:30:41 <geppetto> sounds good
16:30:49 <limburgher> Ditto.
16:32:25 <ignatenkobrain> have a nice rest of the day, folks! see ya next week.
16:32:41 <mhroncok> you too
16:32:48 <tibbs> Thanks!
16:33:13 <geppetto> yeh, thanks for running the meeting mhroncok++
16:33:24 <mhroncok> not much to run really
16:34:04 <ignatenkobrain> mhroncok++
16:34:26 <mhroncok> #endmeeting