17:00:21 #startmeeting Stewardship SIG Meeting (2019-04-17) 17:00:21 Meeting started Wed Apr 17 17:00:21 2019 UTC. 17:00:21 This meeting is logged and archived in a public location. 17:00:21 The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:21 The meeting name has been set to 'stewardship_sig_meeting_(2019-04-17)' 17:00:30 #meetingname stewardship-sig 17:00:30 The meeting name has been set to 'stewardship-sig' 17:00:36 #chair mhroncok 17:00:36 Current chairs: decathorpe mhroncok 17:00:43 hey 17:01:24 .hello2 17:01:25 mizdebsk: mizdebsk 'Mikolaj Izdebski' 17:01:39 mizdebsk: hey. thanks for coming! 17:01:41 hey, glad you could make it! 17:02:11 * nirik waves. Somewhat here, but also trying to catch up on things after a full morning of meetings. 17:02:41 no pressure ;) 17:03:18 should we start? anybody who shows up "late" should be able to catch up 17:03:46 also, I don't think more people were planning to attend today 17:03:55 right 17:04:29 #topic Review package build status 17:04:38 #link https://apps.fedoraproject.org/koschei/groups/stewardship-sig? 17:04:47 I see aqute-bnd, gradle and maven 17:04:56 * mizdebsk looks 17:05:28 maven has been broken since December 17:05:38 I don't really know what aqute-bnd is, but gradle FTBFsing blocks other things, like dropping checkstyle and CVEs of sorts 17:05:58 aqute-bnd and maven have fixes available 17:06:08 I think all missing build dependencies have been restored at least 17:06:17 fixing gradle requires developing a patch, see my comment in bugzilla 17:06:43 patch for aqute-bnd: https://src.fedoraproject.org/fork/mbi/rpms/aqute-bnd/c/9dc6e1b 17:06:46 mizdebsk: so aqute-bnd and maven have patches in your arbitrarily-named branches? 17:06:48 I've seen it, but I have no capacity of doing that 17:07:09 patch for maven: https://src.fedoraproject.org/fork/mbi/rpms/maven/c/512a4dd 17:07:19 decathorpe, no, they are in forks in dist-git, not merged yet 17:07:30 I see, thanks 17:07:53 #link https://src.fedoraproject.org/fork/mbi/rpms/aqute-bnd/c/9dc6e1b aqute-bnd patch 17:08:01 #link https://src.fedoraproject.org/fork/mbi/rpms/maven/c/512a4dd maven patch 17:08:15 https://src.fedoraproject.org/rpms/aqute-bnd/pull-request/1 17:08:20 I should have some time over the Easter holidays to check this 17:09:12 https://src.fedoraproject.org/rpms/maven/pull-request/1 17:09:15 untested 17:09:59 simple-koji-ci might not even srpm, due to undefined macros in java packages (not required by redhat-rpm-config) 17:10:29 java srpms should not be using any custom macros 17:10:48 building binary rpms does, but these macros are pulled by BuildRequires 17:11:48 oh, it was prep that didn't work 17:12:00 sorry about that 17:12:29 well, at least now we have something to work with 17:13:07 the other issue: non-64bit builds for some packages are broken on f30+ 17:13:15 because eclipse dropped 32bit arch support 17:13:45 I suppose we should just do the same 17:14:20 * mhroncok would only solve FTBFS bugz when it blocks other things, such as CVE fixes 17:15:01 I'm not sure that's a good idea since it will cause a huge cascade of packages which will have to drop 32bit versions 17:15:59 not that many packages require eclipse; most of java packages are noarch and should continue to work on 32-bit arches 17:16:16 those that do require eclipse can be patched to use alternative components instead 17:16:27 (osgi api, jpa api etc.) 17:16:30 yes, most things that broke were due to osgi components 17:16:33 I'm not sure we have the capacity to do so 17:16:34 and jpa 17:17:00 how did you solve this for your modules? 17:17:06 I mean, I'm happy to backport upstream commits, but I forgot all Java years ago 17:17:17 my modules don't have any dependency on eclipse 17:17:36 several packages have "%bcond_without eclipse" that can be toggled to disable features that depend on eclipse 17:17:58 #action mhroncok to grep sig packages for eclipse bcond 17:18:03 that's easy at least 17:18:40 decathorpe: let's go trough bzs? 17:18:52 just a sec 17:19:04 I added x86_64 arch overrides to koschei for the following packages: 17:19:21 avalon-framework, avalon-logkit, log4j, xbean 17:19:28 but there are probably more that are affected 17:20:01 what does an x86_64 arch override do in koschei? 17:20:30 it makes sure noarch packages don't hit i686 builders AFAICT 17:20:51 mhroncok, scratch builds will be done on x86_64 builders only 17:20:59 you can provide more than one arch, separeted by space 17:21:15 or you can exclude arches - build on all arches except some 17:21:38 decathorpe, due to koji bug builds can be still ran in i686 chroots 17:21:52 https://pagure.io/koji/issue/789 17:22:02 okay 😂️ 17:22:06 well, at least I tried 17:22:12 moving on? 17:22:28 yes 17:22:39 #topic Review Open RHBZ issues 17:22:53 #link https://bugzilla.redhat.com/buglist.cgi?email1=stewardship-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=substring&list_id=10107571&product=Fedora&query_format=advanced 17:23:28 so... all CVEs are handled for now, thanks to mizdebsk I guess. except gradle, becasue that's blocked by the FTBFS 17:23:33 yes 17:23:41 I'd say that we ignore new version bugs for now, unless they fix other issues as well 17:23:45 gradle can be fixed by using a buildroot override 17:24:09 add an older build to override and submit a build fixing cve 17:24:10 mizdebsk: you mean by rebuilding it with older gradle? 17:24:17 yes 17:24:28 interesting 🤔️ 17:24:38 wow, I got that idea, but I considered it cheeting 17:24:39 :D 17:24:43 do buildroot overrides work in rawhide? 17:24:49 do I just tag it, or can I use bodhi for rawhide? 17:25:00 just tag a build to f31 17:25:04 that works as override 17:25:11 magic 17:25:13 f31-pending* 17:25:17 ok, can do 17:25:21 (autosign will move it to f31) 17:25:39 #action mhroncok to chaat grdle FTBFS to fix the CVE and remove checkstyle dependency 17:25:44 #undo 17:25:44 Removing item from minutes: ACTION by mhroncok at 17:25:39 : mhroncok to chaat grdle FTBFS to fix the CVE and remove checkstyle dependency 17:26:09 #action mhroncok to cheat gradle FTBFS to fix the CVE and remove checkstyle dependency by tagging older version of gradle to build new gradle 17:26:20 with that I think there are no more CVEs left? 17:26:28 yes 17:26:32 perfect 17:26:39 decathorpe: should we set priority: low to the version bumps? 17:26:50 yeah, I can do that later 17:27:10 #action decathorpe will set priority for version updates to "low" 17:27:29 any other noteworthy bugs? 17:27:42 that bz query may not include all bugs 17:27:57 I know, only those the SIG is either CCd or assigned 17:27:59 the script that syncs pagure owners to bugzilla is broken 17:28:17 i've re-assigned some bugs to the sig, but others may remain assigned to wrong people 17:28:30 I don't know enough BugZilla voodoo to query all our packages 17:28:39 and xmlrpc is horrible 17:28:50 i can provide a query for you 17:29:10 🙇️ that would be appreciated 17:29:18 basically, query for components matching regex 17:29:37 oh 17:30:02 decathorpe: I've set the priority, had it open in browser before I read your action item 17:30:06 i think i can actually include the query in koschei 17:30:17 well 17:30:20 koschei could have a link to bugzilla query for given package group 17:30:23 #undo 17:30:23 Removing item from minutes: ACTION by decathorpe at 17:27:10 : decathorpe will set priority for version updates to "low" 17:30:27 ;) 17:31:03 any other bugs we should talk about? 17:31:19 * mhroncok doesn't know any 17:31:53 alright, lets move on then? 17:32:58 sure 17:33:01 #topic Review Open Pull Requests 17:33:03 #link https://decathorpe.fedorapeople.org/stewardship-sig-prs.html 17:34:11 I merged some minor version updates already, but only where we were sure nothing would break 17:35:14 also, I was thinking we could try to reduce the number of our packages by giving them to the people who already submit PRs? 17:35:54 decathorpe: I've tried to ask everybody who sent a PR 17:35:56 no luck so far 17:36:08 yeah, me too 17:36:17 I'll continue to try ;) 17:36:19 * mhroncok goes outside with the laptop, the wifi should be there, but will check 17:37:42 do you need any feedback from me regarding these PRs? 17:38:08 it'd be interesting to know if any version updates are expected to cause issues or not 17:38:42 but that's probably hard to tell 17:38:58 out of these PRs only maven-plugin-tools will break other packages 17:39:14 (i'm talking about issues that can't be trivially patched) 17:39:28 some of these updates must happen together, like maven-archiver and plexus-archiver 17:39:41 ok, can I quote you on that? ;) 17:40:16 well, you can check my koschei instance where i merged most of them and there was no breakage 17:40:19 except for maven-plugin-tools 17:40:39 that's good to know 17:40:57 https://koschei.kjnet.xyz/ - this is where all packages from mbi forks are integrated together 17:41:18 oooh nice 17:41:30 whoops, guess the WiFi didn't work outside 17:41:41 #info maven-plugin-tools update will cause non-trivial issues 17:42:03 #info maven-archiver and plexus-archiver PRs need to be coordinated 17:42:10 google-guice should be updated together with maven 3.6.x 17:42:17 * mhroncok is back, that didn't work 17:42:30 #info google-guide and maven 3.6.x PRs need to be coordinated 17:43:09 okay, that's really valuable (and actionable) information. thanks! 17:43:28 i don't see any PR for maven 3.6, but it's been updated in mbi fork 17:43:38 I thought so 17:43:47 https://src.fedoraproject.org/rpms/maven/pull-request/1 17:44:21 ah right, but that one dependns on a few other updates, hence the failure due to missing deps 17:44:52 sure. it was a blind shot 17:45:14 maven FTBFS can be fixed by applying the topmost commit "Update to Mockito 2" 17:45:54 good to know 17:45:55 which basically removes a patch that causes it to fail to compile 17:46:22 any other things about those PRs we need to talk about? I'd like to move on, time is moving faster than I thought it would 17:46:47 * mizdebsk has nothing 17:47:45 #topic Review SIG leaf packages 17:47:58 #link https://decathorpe.fedorapeople.org/stewardship-sig.html 17:48:13 (you'll need to scroll down past the table and the dependency ranking) 17:48:27 (TODO: I need to add some html anchors to that page) 17:48:58 basically, no other packages from our group depend on these 5 packages right now: 17:49:14 apache-commons-discovery, json_simple, nodejs-array-union, nodejs-arrify, nodejs-set-immediate-shim 17:50:27 my thoughts were: I'll regularly ask packagers who need these packages to take them from us 17:50:42 (so we can reduce our package set bit by bit, hopefully) 17:53:35 what happens if we just orphan them? 17:53:55 we have the same problem we had before we took them 17:54:12 I think addressing owners of dependent packages is more likely to help 17:54:50 we should at least try 17:55:20 I don't mind sending a few e-mails every 2 weeks or so ... 17:55:39 note that many maintainers of java packages are de facto unresponsive 17:56:10 right - but there are also other packages that depend on this stuff 17:56:11 i would even say that majority of java packages have de facto unresponsive maintainers 17:56:28 (which is a sad state of affairs, I agree) 17:56:53 sure, i'm just saying 17:57:03 well, we can try at least 17:57:38 * mhroncok will have to leave in couple minutes 17:57:50 I'd say let's discuss the future meeting schedule in a ticket on pagure 17:57:57 and end the meeting here, unless there's something else 17:58:02 better to include those who didn't make it 17:58:34 right. this week was sub-optimal, I know 17:59:04 #topic Meeting Schedule 17:59:16 decathorpe: thanks for organizing this 17:59:17 #action to be discussed in a ticket in pagure 17:59:19 decathorpe++ 17:59:20 mhroncok: Karma for decathorpe changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:59:25 mizdebsk: thanks for your help 17:59:26 sure :) 17:59:30 mizdebsk++ 17:59:32 bye 17:59:35 right, thanks a lot, mizdebsk 17:59:37 thanks to you too 17:59:40 bye! 18:00:03 right, lets close this meeting then 18:00:30 #endmeeting