16:00:44 <geppetto> #startmeeting fpc
16:00:44 <zodbot> Meeting started Thu May 10 16:00:44 2018 UTC.
16:00:44 <zodbot> This meeting is logged and archived in a public location.
16:00:44 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:44 <zodbot> The meeting name has been set to 'fpc'
16:00:44 <geppetto> #meetingname fpc
16:00:44 <zodbot> The meeting name has been set to 'fpc'
16:00:45 <geppetto> #topic Roll Call
16:00:45 <zodbot> ignatenkobrain_: In #fedora-meeting is fesco (starting in a day)
16:00:48 <zodbot> ignatenkobrain_: In #fedora-commops is CommOps Hack Session (starting in 3 days)
16:00:50 <ignatenkobrain_> .hello2
16:00:55 <ignatenkobrain_> .hello ignatenkobrain
16:00:55 <zodbot> ignatenkobrain_: Sorry, but you don't exist
16:00:55 <tibbs> Howdy.
16:00:57 <zodbot> ignatenkobrain_: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:01:01 <geppetto> #chair ignatenkobrain
16:01:01 <zodbot> Current chairs: geppetto ignatenkobrain
16:01:06 <decathorpe> .hello2
16:01:07 <geppetto> #chair tibbs
16:01:07 <zodbot> Current chairs: geppetto ignatenkobrain tibbs
16:01:07 <zodbot> decathorpe: decathorpe 'None' <decathorpe@gmail.com>
16:01:09 <geppetto> #chair decathorpe
16:01:09 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain tibbs
16:02:11 <mhroncok> hi
16:02:15 <geppetto> #chair mhroncok
16:02:15 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok tibbs
16:03:52 <geppetto> I
16:03:59 <geppetto> I'll give it to 5 past
16:05:06 <ignatenkobrain_> here it is
16:05:33 <geppetto> indeed :)
16:05:37 <geppetto> #topic Schedule
16:05:39 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/JME57URI4GO2NJXFZDJG6I5RZLFGDT6D/
16:05:53 <geppetto> #topic #766 Not to using versioned Recommends (or any other weak deps)
16:05:57 <geppetto> .fpc 766
16:05:59 <zodbot> geppetto: Issue #766: Advise/Prohibit not to use versioned Recommends (or any other weak deps) - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/766
16:06:05 <ignatenkobrain_> that's mine ;)
16:07:24 <geppetto> Don't we want to say to use >= always?
16:07:27 <mhroncok> I still think that recommending a specific version is a legitimate use case
16:07:46 <ignatenkobrain_> geppetto, but what's the point?
16:07:51 <tibbs> It may be a legitimate use case, but I think the problem is that it doesn't work well.
16:07:55 <decathorpe> I'm not entirely sure what's the problem. doesn't the recommended package have an explicit versioned Requires on the recommending package?
16:08:07 <ignatenkobrain_> decathorpe, not necessarily
16:08:37 <decathorpe> that would solve the problem, I guess
16:08:46 <ignatenkobrain_> tibbs, it works as expected... but it's not very nice UX
16:08:52 <tibbs> Remember that some of our work is coming up with easy packaging, and some of it is documenting how other parts of the system don't work well.
16:08:55 <geppetto> mhroncok: I guess people are supposed to unversion recommend and conflict != version they want?
16:09:11 <mhroncok> dnf update just something should defaulty also update what's recommended if that's solves the recommendation
16:09:13 <geppetto> It kind of feels like dnf should be doing something else here
16:09:54 <geppetto> mhroncok: that seems like a bad default for the command line, although there was an option to do that in yum
16:10:03 * limburgher here late
16:10:10 <ignatenkobrain_> geppetto, if user asked to update just sssd, but not libsss, that doesn't mean that even there are Recommends: libsss >= new-version should update also deps
16:10:16 <geppetto> But, eh, after more than 5 seconds of thought you might be right.
16:10:41 <tibbs> If what we're running into here is just bad behavior on DNF's part then we also need to evaluate whether that can be fixed.  Patching poor behavior with guidelines is something we should avoid doing.
16:10:49 <geppetto> Esp. in the case of reocmmends = version … that should probably be updated
16:10:49 <mhroncok> if it requires the newer version, that get's updated, right?
16:10:59 <geppetto> mhroncok: yeh
16:11:01 <tibbs> But I would never use autoremove, because I think it's absolutely horrible in general, and so I can't offer much of an opinion.
16:11:03 <ignatenkobrain_> mhroncok, if requires/conflicts, then yes
16:11:14 <decathorpe> #chair limburgher
16:11:14 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok tibbs
16:11:22 <geppetto> decathorpe: thanks
16:11:32 <geppetto> limburgher: hey, welcome … didn't see you
16:11:43 <ignatenkobrain_> geppetto, why so? it's just weak dependency.. and they are weak because we should not force user to have it
16:12:06 <limburgher> geppetto, was getting lunch. Hangry. :)
16:12:08 <geppetto> ignatenkobrain: as mhroncok said … that's what happens for requires, and people think of them like requires.
16:12:17 <mhroncok> ignatenkobraindon't fore it, just make it the default
16:12:37 <mhroncok> don't update it if recommends are switched off
16:12:54 <ignatenkobrain_> mhroncok, what if libsss of newer version is not installable? you update just sssd and then dnf autoremove will still remove libsss
16:13:02 <geppetto> ignatenkobrain: like people think of the weak requires option as "should these act like requires or nothing" … but on update that's not what they do.
16:13:44 <geppetto> ignatenkobrain: that shouldn't happen (broken updates) … and if it does it's a super edge case.
16:13:44 <mhroncok> if recommends is resolvable, it shoudl act like requires unless explicitly turned off
16:14:07 <decathorpe> ^ I agree
16:14:12 * ignatenkobrain_ disagrees ;)
16:14:41 <mhroncok> so how shoudl a recommend behave then?
16:14:59 <ignatenkobrain_> as long as it's possible to satisfy weak dependency, it should be pulled in
16:15:10 <mhroncok> right
16:15:21 <mhroncok> and it is in this case possible to satisfy
16:15:35 <mhroncok> yet it is not pulled in
16:15:44 <ignatenkobrain_> yes, but if user doesn't update libsss, dependency is still satisfied
16:15:46 <ignatenkobrain_> because it is weak
16:16:01 <ignatenkobrain_> it's like "there is no package satisfying dependency"
16:16:02 <mhroncok> well that's playing with words
16:16:12 <ignatenkobrain_> because person excluded it from the update
16:16:43 <mhroncok> I think the behavior is weird, inconsistent with user expectations and shall be fixed. not something we should "fix" by guidelines
16:16:56 <mhroncok> user dind't exclude it
16:17:17 <ignatenkobrain_> in my example, I just updated half system (just sssd, but not libsss)
16:17:30 <decathorpe> I guess it comes down to different behavior between "not including sth." and "excluding sth."
16:17:31 <mhroncok> if what you say is true and requires would be used, than dnf update sssd* shoudl fail because libsssd in thta version is "not available"?
16:17:39 <mhroncok> decathorpe: exactly
16:18:14 <decathorpe> if I do "dnf upgrade -x recommended_package", I expect that package to not be pulled in
16:18:18 <mhroncok> it shoudl act like requires, but if that would not be solvable, it should be skipped
16:18:44 <mhroncok> explicitly excluding it shoudl exclude it
16:18:44 <decathorpe> which is what happens?
16:18:58 <mhroncok> but not including it should not skip it
16:18:59 <ignatenkobrain_> decathorpe, yes, it's not getting updated right now. because it's weak dep
16:19:12 <decathorpe> AFAICT only autoremove between updating parts of the system is problematic, yes?
16:19:45 <mhroncok> there might be more problematic situations
16:20:02 <geppetto> decathorpe: not if dnf did upgrade as expected.
16:20:02 <mhroncok> if A recommends B==1 and B recommends A==1
16:20:19 <ignatenkobrain_> decathorpe, autoremove is set for any "dnf remove"
16:20:23 <mhroncok> A and B both work just fine by their own, but gain more feature sif the other one is present
16:20:45 <mhroncok> than dnf update A should also update B (givven the reocmmendations changed to 1.1 in both for example)
16:20:47 <ignatenkobrain_> mhroncok, there are definitely some valid use-cases, but in sssd case it is just bad UX
16:20:56 <ignatenkobrain_> there is no weak update
16:21:08 <mhroncok> I'm not describing how it works
16:21:16 <mhroncok> I'm describing how it feels it should work
16:21:40 <mhroncok> am I the only one expecting this behavior?
16:21:54 <decathorpe> if there are version constraints on the two packages, they need to be declared, but using the "Recommends" field for that seems to cause problems
16:21:54 <geppetto> ignatenkobrain: ofc there is a weak update … if the recommends was a requires, it would update.
16:22:33 <mhroncok> decathorpe: it cause problems, but only becasue the bahaviour is weird
16:23:03 <mhroncok> that means the behavior should be changed, not the use cases banned
16:23:06 <decathorpe> I agree. this isn't doing what I would expect
16:23:49 <ignatenkobrain_> so what behavior do you expect?
16:23:51 <ignatenkobrain_> in case of sssd
16:23:56 <tibbs> So even if it can give a poor user experience, do we really need to ban it?  Why not just give a short explanation of the problem and leave it up to maintainers to decide whether that's an issue for them?
16:23:58 <geppetto> Yeh, I'm going to -1 this unless ignatenkobrain says dnf can't be fixed for some reason.
16:24:03 <mhroncok> dnf update sssd* to also update libsssd
16:24:13 <ignatenkobrain_> mhroncok, but I did -x libsss
16:24:21 <decathorpe> then it's your fault ;)
16:24:24 <geppetto> ignatenkobrain: when you update sssd libsssd should be upgraded too, as it would be if the recommends where a requires.
16:24:33 <mhroncok> oh sorry, if you did than the autoremove is just fine
16:24:42 <tibbs> I don't object to including something short, but it seems like there's nothing really "broken" here, only that autoremove is impossible to implement in a way that never surprises anyone.
16:24:57 <geppetto> ignatenkobrain: the -x libsssd case I put down to PEBAK … don't do that. Or if you do don't run autoremove until you've fixed it.
16:25:11 <mhroncok> agreed
16:25:50 <geppetto> tibbs: what would the short text be "try not to do XYZ because in weird usecases DNF will do weird things?"
16:26:05 <geppetto> Water also wet, news at 11.
16:27:28 <geppetto> ignatenkobrain: So does DNF need a change too, or were you using -x libssd all the time?
16:28:12 <ignatenkobrain_> geppetto, I did `dnf update sssd\*`
16:28:25 <ignatenkobrain_> and then ran `dnf autoremove` and it wanted to remove `libsss*`
16:28:31 <ignatenkobrain_> because they are unneeded anymore
16:28:34 <geppetto> ignatenkobrain: And that doesn't upgrade libsssd? … that should change then.
16:28:42 <ignatenkobrain_> https://paste.fedoraproject.org/paste/8UZqJzXGClqb4fhILf59BQ
16:28:47 <ignatenkobrain_> this is something what happened
16:28:50 <tibbs> geppetto: I don't know; I don't fully understand the problem because I always turn off autoremove.
16:28:54 <ignatenkobrain_> hopefully this is understandable testcase
16:28:57 <geppetto> #action DNF needs to upgrade recommends as it would requires, when they are enabled.
16:29:07 <geppetto> tibbs: indeed.
16:29:57 <ignatenkobrain_> +erase libsss-1-1.x86_64@@system
16:29:57 <ignatenkobrain_> +unneeded libsss-1-1.x86_64@@system
16:29:57 <ignatenkobrain_> +unneeded_filtered sssd-1-1.x86_64@@system
16:29:57 <ignatenkobrain_> +upgrade sssd-1-1.x86_64@@system sssd-2-1.x86_64@available
16:30:02 <mhroncok> so without -x this needs a dnf fix
16:30:06 <geppetto> tibbs: if only someone argued that it's a terrible feature to have on by default … ahh, well.
16:30:18 <ignatenkobrain_> this is what happens if you combine update+autoremove
16:30:20 <mhroncok> and with -x, this is a user doing stupid things, expecting nonstupid things to happen
16:30:30 <geppetto> ignatenkobrain: but update can be fixed.
16:31:15 <ignatenkobrain_> geppetto, I believe that libsolv author will reject this because it's really weak description of what should happen. But I can try to open a ticket
16:31:59 <geppetto> ignatenkobrain: It seems like an obvious flag, even if they won't want to do it all the time in libsolv.
16:32:25 <ignatenkobrain_> geppetto, this would complicate implementation quite a lot
16:32:35 <tibbs> geppetto: Well, I did make that argument a long time ago, but didn't get any traction.
16:32:47 <geppetto> tibbs: I also did, many times.
16:33:09 <geppetto> tibbs: response was always "well data will be perfect with DNF, so it'll be fine" /gg
16:33:11 <tibbs> True, and you have a better background in this kind of thing.
16:34:02 <geppetto> ignatenkobrain: Well you have obvious test case to take upstream, for the behaviour change.
16:34:03 <ignatenkobrain_> so what if we put advise not to do this unless sure?
16:34:12 <ignatenkobrain_> (meanwhile)
16:34:42 <mhroncok> -1 on changing/introducing a policy because of this
16:36:57 <geppetto> Yeh, unless we really can't fix dnf/etc. then I don't want to change anything
16:38:09 <geppetto> #topic #719 Simplify packaging of forge-hosted projects
16:38:13 <geppetto> .fpc 719
16:38:19 <zodbot> geppetto: Issue #719: Simplify packaging of forge-hosted projects - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/719
16:39:33 <tibbs> So is this just about the date thing now?  Or is there a draft to consider?
16:39:49 <geppetto> It looks like decathorpe did a draft
16:40:00 <decathorpe> the criticism I have right now is primarily about the date thing
16:40:07 <geppetto> but I'm less sure if that would close the ticket if accepted … I don't think so, but ¯\_(ツ)_/¯
16:40:10 <decathorpe> but yeah, I proposed something to fix it
16:42:09 <geppetto> I'm def. +1 on not using the current date.
16:42:26 <geppetto> but I'm less sure on what else there is to vote on :)
16:42:29 <tibbs> Yes, that seems terrible.
16:42:37 <tibbs> Unless I'm misunderstanding the implications.
16:42:49 <mhroncok> there is nothing  o vote on now I guess
16:42:58 <limburgher> Yeah current date is icky.
16:43:21 <limburgher> Remember which it was all tarballs? Those were the days. . .
16:43:23 <geppetto> decathorpe: anything you want to discuss or vote on?
16:43:25 <tibbs> In my head, using the "auto-date" thing would mean that if you do spectool -g *spec and build, you get a different build than you did yesterday.
16:43:26 <limburgher> s/which/when/
16:43:42 <geppetto> tibbs: yeh, that's one of the main problems.
16:43:44 <decathorpe> tibbs: that's exactly what happens
16:43:44 <tibbs> Which seems to be rather a negative for reproducibility.
16:43:47 <limburgher> tibbs: which sounds like something I can't imagine wanting.
16:44:12 <limburgher> Next, they'll want Release to be set to an MD5 of the spec.
16:44:37 <decathorpe> look at https://koji.fedoraproject.org/koji/buildinfo?buildID=1078636 for an example where the release tag doesn't match anymore
16:44:39 <geppetto> limburgher: after the md5 is in, right?
16:44:48 <limburgher> geppetto, Of course. :)
16:45:04 <geppetto> limburgher: ᕕ( ᐛ )ᕗ
16:45:34 <limburgher> geppetto: DYING
16:45:36 <tibbs> One important thing to note is that the macro magic might support something, but there's no reason we have to actually permit it to be used in the guidelines.
16:46:07 <limburgher> "You are allowed to implement stupid things, but this is optional."
16:46:31 <decathorpe> sure, it's just that the rest is nice, but this issue is really rubbing me the wrong way
16:46:39 <tibbs> Doing it all in lockstep (macros and guidelines allowing/supporting exactly the same things) would require a level of organization that we just don't have.  And Fedora isn't going to fly us and nim somewhere and lock us in a room until it's all done....
16:47:28 <limburgher> I bet if they did, they'd never do it again.
16:47:30 <geppetto> tibbs: indeed … implementing stuff in macors we can consider in the future is fine.
16:48:08 <geppetto> So do we know what we want to do with this ticket … the last meeting we had about it redi said he'd look at it, but I assume he's been busy
16:48:25 <redi> yeah very busy, sorry
16:48:31 <tibbs> Well, I think we've agreed that the current date thing is right out.
16:48:31 <geppetto> we all seem to agree on what we don't want :) … so maybe we can agree on what needs to change?
16:48:37 <redi> gcc is out now though so I can try testing it
16:48:37 <decathorpe> where / who do I have to ping to have this changed in the macros?
16:48:42 <geppetto> redi: Hey, you're here … didn't see you either.
16:48:44 <geppetto> #chair redi
16:48:44 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok redi tibbs
16:48:48 <tibbs> So it's just a matter of making sure the draft reflects that.
16:48:53 <redi> I missed the start :)
16:48:53 <tibbs> decathorpe: Me....
16:49:05 <decathorpe> ah, good, you're already here ;)
16:49:12 <geppetto> 👍
16:49:25 <tibbs> Basically any provenpackager can technically mess with redhat-rpm-config, but I wouldn't recommend it.
16:49:38 <tibbs> It's really, really easy to break the entire OS by touching that package.
16:49:40 <decathorpe> haha I wouldn't touch that package with a 10 foot pole
16:49:46 <limburgher> Oh HELL no.
16:49:46 <geppetto> So should I put an action item down for decathorpe to speak to tibbs about changing the macros?
16:50:08 <decathorpe> the change is really simple from what I can tell, I just have no clue about lua
16:50:17 <tibbs> To be fair, nim should be involved as well since he did all the work.
16:50:38 <tibbs> I can do lua stuff as well.  But testing the mess might be tougher for me so we'd have to work together.
16:50:44 <limburgher> decathorpe, clualess?
16:50:49 <geppetto> #action decathorpe to ping tibbs and nim about changing the macro
16:51:02 <geppetto> #topic Open floor
16:51:07 <decathorpe> limburgher: 🤯
16:51:16 <tibbs> I might be busy today but if you can document what needs to change in the ticket, that will give nim a chance to comment on it.
16:51:22 <geppetto> Ok, 10 minutes left … anything anyone wants to talk about?
16:51:23 <decathorpe> sure!
16:51:48 <tibbs> Also, if there's a draft, we should consider just editing the initial ticket message to reflect that and other status.  I think all FPC members can edit tickets.
16:52:04 <tibbs> Makes it easier to find things when there are a hundred comments.
16:52:14 <limburgher> I have nothing of substance to discuss.
16:53:27 <mhroncok> nothing to discuss on my part either
16:53:43 <decathorpe> me neither
16:54:13 <tibbs> So no new writeups this week?  I am actually caught up; just need to make an announcement but I was waiting for the ruby stuff to happen.
16:54:13 <geppetto> ok, I'll let you have 5 minutes of your day back
16:54:51 <geppetto> tibbs: yeh, might as well do it … will always be something else.
16:55:05 <geppetto> #endmeeting