17:00:48 <geppetto> #startmeeting fpc
17:00:48 <zodbot> Meeting started Thu Feb 25 17:00:48 2021 UTC.
17:00:48 <zodbot> This meeting is logged and archived in a public location.
17:00:48 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:48 <zodbot> The meeting name has been set to 'fpc'
17:00:48 <geppetto> #meetingname fpc
17:00:48 <zodbot> The meeting name has been set to 'fpc'
17:00:48 <geppetto> #topic Roll Call
17:00:57 <tibbs> Hello.
17:01:09 <carlwgeorge> howdy
17:01:11 <geppetto> #chair tibbs
17:01:11 <zodbot> Current chairs: geppetto tibbs
17:01:14 <geppetto> #chair carlwgeorge
17:01:14 <zodbot> Current chairs: carlwgeorge geppetto tibbs
17:01:30 <tibbs> Now unfrozen and with power.
17:01:45 <geppetto> always a bonus :)
17:02:17 <mhroncok> .hello churchyard
17:02:18 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:02:31 <limburgher> Nice!
17:02:33 * limburgher here
17:02:49 <geppetto> #chair limburgher
17:02:49 <zodbot> Current chairs: carlwgeorge geppetto limburgher tibbs
17:02:57 <geppetto> #chair mhroncok
17:02:57 <zodbot> Current chairs: carlwgeorge geppetto limburgher mhroncok tibbs
17:04:08 <decathorpe> hey y'all
17:04:08 <geppetto> #chair decathorpe
17:04:08 <zodbot> Current chairs: carlwgeorge decathorpe geppetto limburgher mhroncok tibbs
17:05:25 <geppetto> #topic Schedule
17:05:28 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/CZVRDTC7H6BHK4YGJ32H3KMM2J7IUIJJ/
17:05:37 <geppetto> So … nothing new again
17:05:58 <geppetto> Which is fine by me
17:06:15 <geppetto> #topic Open floor
17:06:19 <geppetto> Anyone have anything?
17:06:26 <mhroncok> not me
17:06:33 <decathorpe> there are probably two tickets we should look at
17:06:45 <tibbs> I can't say that I've had a whole lot of time to look into things lately.  Last week was something of a mess.
17:06:54 <geppetto> tibbs: yeh
17:07:02 <geppetto> decathorpe: New ones?
17:07:16 <decathorpe> not-tagged-with-meeting-ones
17:07:34 <decathorpe> .fpc 1018
17:07:35 <zodbot> decathorpe: Issue #1018: Review exception request: Xorg utility deaggregation - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1018
17:07:37 <decathorpe> .fpc 1053
17:07:39 <zodbot> decathorpe: Issue #1053: gnome-software switched from libappstream-glib to appstream - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1053
17:08:01 <geppetto> #topic #1018 Review exception request: Xorg utility deaggregation
17:09:10 * King_InuYasha waves
17:09:13 <King_InuYasha> .hello ngompa
17:09:13 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:09:13 <decathorpe> FESCo moved deadline for this to f34-beta
17:09:45 <decathorpe> and it would make things a lot easier if there wouldn't need to be dozens of package reviews (though some are already reviewed now)
17:10:07 <geppetto> #chair King_InuYasha
17:10:07 <zodbot> Current chairs: King_InuYasha carlwgeorge decathorpe geppetto limburgher mhroncok tibbs
17:10:31 <King_InuYasha> well, it turned out to be a good idea when Xwayland was being split out
17:10:34 <King_InuYasha> that package was a mess
17:11:10 <decathorpe> true, but different person :)
17:11:20 <geppetto> I +1d to Xorg
17:11:29 <geppetto> Also mentioned we should probably have a general rule
17:12:35 * mhroncok was +1 to handle everything in one bugzilla
17:13:15 <carlwgeorge> i also +1-ed it
17:13:26 <geppetto> the gnome-software thing seems like if someone just did a PR I'd happily merge it
17:13:40 <geppetto> or anyone else could
17:13:53 <decathorpe> the problem is that somebody should probably do a spec mass-change for this as well
17:13:57 <mhroncok> +1 to anybody just doing it :D
17:14:15 <mhroncok> decathorpe: well, I don't think it's super necessary
17:14:29 <decathorpe> it would be nice-to-have though ...
17:14:35 <decathorpe> and the next problem is that gnome-software with this change got pushed to Fedora without notifying anybody :shrug:
17:14:48 <mhroncok> that is the first problem, not the next one
17:14:51 <geppetto> decathorpe: If we held up all policy changes on doing that … it would not be a good time
17:14:53 <King_InuYasha> well, that's pretty normal
17:15:16 <King_InuYasha> the more worrying issue is that appstream-builder will be deprecated/retired soon
17:15:32 <King_InuYasha> that's what we use to create appstream repodata
17:15:45 <geppetto> cool
17:15:57 <King_InuYasha> the other option is appstream-generator, but nobody has done any work on making it possible for us to switch
17:16:05 <King_InuYasha> (and I'm struggling to fix the FTBFS for it too)
17:16:07 <decathorpe> if createrepo_c were written in Rust, I'd gladly work on appstream data support ;) but it's GObject-C
17:16:20 <King_InuYasha> decathorpe: dude, D is not better
17:16:34 <King_InuYasha> appstream-generator is written in D, and every Fedora release glibd and gir-to-d break
17:16:35 <decathorpe> I didn't say it was :D
17:16:41 <mhroncok> createrepo_d
17:16:46 * King_InuYasha dies
17:17:02 <carlwgeorge> lol
17:17:05 <King_InuYasha> I'd personally like createrepo to be C++ but I didn't make those choices
17:17:20 <mhroncok> good that it isnt haskell
17:17:22 <King_InuYasha> but getting createrepo_c to support appstream repodata generation is going to be a lot more important
17:17:35 <King_InuYasha> or switching over to appstream-generator
17:18:25 <decathorpe> well I didn't want to start the language wars in FPC meeting :) just make sure we're all aware that the default appstream implementation in Fedora is now a different one
17:18:27 <geppetto> I mean, sure, but this isn't our problem
17:18:51 <tibbs> All we need to do is make sure the guidelines language matches reality.
17:18:54 <King_InuYasha> yep
17:18:58 <decathorpe> question: who even decided that all appdata MUST be validated?
17:18:58 <King_InuYasha> that part is easy enough
17:19:03 <King_InuYasha> decathorpe: hughsie
17:19:05 <tibbs> Which is often tough when reality changes and nobody tells us.
17:19:11 <geppetto> It wouldn't be the first time we've kept really old compat. code around because nobody converted the non-fun parts
17:19:14 <decathorpe> tibbs: yeah that's it ...
17:19:55 <geppetto> True, worst case we could replace the validate step with /bin/true … and if whoever wants it to be better can convert the old code.
17:20:28 <mhroncok> pity it isn't macronized :/
17:20:46 <King_InuYasha> we should just macroize it this time
17:20:52 <King_InuYasha> I expect we'll change this again and again
17:20:56 <decathorpe> make it a brp script
17:20:59 <King_InuYasha> or that even
17:21:07 <King_InuYasha> we had one for desktop files a long time ago
17:21:14 <geppetto> Can ya'll stop signing up for work ;)
17:21:15 <decathorpe> and make it fail the build if validation fails >:-)
17:21:35 <geppetto> Or I'm going to start doing #action commands :p
17:21:39 <tibbs> Yeah, every time we add a block of code as a MUST step somewhere, we should ask whether it can just be done automatically.
17:22:09 <King_InuYasha> I think one thing that changed from before to now is that redhat-rpm-config controls brp scripts run in package builds
17:23:13 <King_InuYasha> the whole post-build stage is controlled by a macro in there that can be extended
17:23:13 <King_InuYasha> it's not as clean as some other distros do it, but at least the hook is there now
17:23:26 <decathorpe> geppetto: stop pointing out my flaws :)
17:23:30 <tibbs> There's also a standard method for disabling each brp script.
17:24:11 <mhroncok> the problem with brp for this
17:24:20 <mhroncok> is that you still need to BR the tool
17:24:38 <mhroncok> or redhat-rpm-config needs to pull it in
17:24:58 <mhroncok> I guess the BRP could fail with an actionable message when the tool is missing
17:24:58 <tibbs> Yes, which does somewhat conflict with the "minimal buildroot" goal.
17:25:26 <mhroncok> aka "an appstream file found, but foobar is not installed, ass BuildRequires: foobar and restart the build
17:25:32 <mhroncok> omg
17:25:33 <mhroncok> add
17:25:35 <mhroncok> not ass
17:25:52 <tibbs> If the tools + deps are minimal then it's not a huge deal to just have them there always but if not then....
17:26:23 <tibbs> Probably can't leverage the auto-buildrequires stuff for this, either.
17:26:24 <limburgher> !nick limburgher
17:26:35 <King_InuYasha> well, we _could_
17:26:51 <King_InuYasha> if we can override the %generate_buildrequires section like we can for %prep, %build, and %install
17:26:56 <mhroncok> an additional %generate_buildrequires step from %os_install_post, I love it
17:27:23 <mhroncok> King_InuYasha: but you need to know the content of %{buildroot} to detect the need
17:27:48 <King_InuYasha> well, you could also detect the presence of appdata/metainfo files in the sources
17:28:01 <mhroncok> I can help design the brp script, so geppetto doesn't need to action anybody
17:28:14 <mhroncok> but I lack the mental energy to push it trough
17:28:36 * mhroncok is tired from all the "mass changes should be avoided" pushbacks
17:28:42 <King_InuYasha> I know the feeling
17:28:46 <King_InuYasha> the cmake thing burned me out
17:28:47 <geppetto> #action mhroncok will help design the brp script
17:28:52 <geppetto> mhroncok: :)
17:29:08 <mhroncok> geppetto: than you very much indeed
17:29:14 <mhroncok> *thank
17:32:06 <geppetto> 👍
17:32:19 <geppetto> #topic Open Floor
17:32:43 <geppetto> .fpc 1054
17:32:44 <zodbot> geppetto: Issue #1054: DT_RPATH/DT_RUNPATH policies - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1054
17:33:29 <geppetto> So this seems mostly informational, at least atm
17:33:31 <tibbs> I admit I don't understand this besides to ask why they have added more RPATH-type things.
17:34:06 <geppetto> shared libraries are like pokemon, they everywhere now and you gotta catchem all
17:34:45 <tibbs> Except that the world seems to prefer static linking now.  Because it has forgotten everything learned the last many times that has caused problems.
17:35:04 <limburgher> Predictable, sadly.
17:35:23 <geppetto> So, anyway I'll close in a minute and you can all go read 1054
17:35:43 <geppetto> tibbs: Ahh, but now we'll put them in a container … so the entire OS support is also static
17:36:21 <King_InuYasha> over and over and over
17:36:39 <King_InuYasha> I wonder what will be this generation's "zlib" that shocks them out of this?
17:37:11 <limburgher> Something in go or rust.
17:37:30 <geppetto> Nothing, everyone will just shrug
17:38:15 <limburgher> And statically link or bundle more stuff....
17:39:08 <geppetto> limburgher: It might be a losing strategy, but we'll make it up in volume!
17:40:20 <geppetto> #endmeeting