15:01:16 #startmeeting Stewardship SIG Meeting (2020-05-05) 15:01:16 Meeting started Tue May 5 15:01:16 2020 UTC. 15:01:16 This meeting is logged and archived in a public location. 15:01:16 The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:16 The meeting name has been set to 'stewardship_sig_meeting_(2020-05-05)' 15:01:21 #meetingname stewardship-sig 15:01:21 The meeting name has been set to 'stewardship-sig' 15:01:26 #topic Knock Knock 15:01:37 who's there? 15:01:49 you got it :) 15:01:52 #chair mhroncok 15:01:52 Current chairs: decathorpe mhroncok 15:02:49 cipherboy, sillebille: meeting time 15:03:08 \o 15:03:20 hello! 15:03:23 #chair sillebille 15:03:23 Current chairs: decathorpe mhroncok sillebille 15:05:46 #topic Agenda 15:05:52 #link https://pagure.io/stewardship-sig/issue/87 15:06:04 I think we might want to start with the OpenJDK 11 Change? 15:07:19 decathorpe: I don't know where to start there actually 15:08:12 yeah it looks pretty bad :O 15:08:55 honestly I have no idea how other distros have dealt with this? I doubt it's our tooling alone that's responsible for all the failures 15:09:06 #topic OpenJDK 11 fedora 33 Change 15:09:42 #link https://fedoraproject.org/wiki/Changes/Java11 15:10:34 #link https://copr.fedorainfracloud.org/coprs/jvanek/java11/monitor/ 15:10:54 * mhroncok doesn't consider the results any good, it's Fedora 32 :/ 15:11:10 yeah I think they're starting to rebuild for rawhide now 15:11:59 I've looked at some of the failures, and enforcing a 1.6 or 1.8 target / source level should fix at least some packages 15:12:56 xmvn used to enforce a minimum of 1.6, but that has been dropped from xmvn 3.1.0 (which we dealt with when we updated it): https://github.com/fedora-java/xmvn/commit/c64c35a 15:13:04 I guess that's biting us again 15:14:50 the change owners recommend bumping to 1.8 for all packages ... which is probably a good idea anyway 15:14:50 this is the point where my knowledge seems not up to speed 15:15:06 the sources have hardcoded constraints to not use Java 11? 15:15:07 or? 15:15:28 no, some maven projects specify that their sources are Java 4 or something. OpenJDK does only support Java 8+ 15:15:57 decathorpe: I still don't follow, sorry :( 15:16:11 java-11-openjdk 15:16:19 is what we have now whenwe BR java 15:16:21 right? 15:16:25 yep 15:16:31 so what does that have to do with 1.6 -> 1.8? 15:16:58 some packages define in pom.xml that their sources are Java 5 or something. OpenJDK only supports building for Java 8+ 15:17:07 *OpenJDK 11 15:17:26 and instead of enforcing the newer version, it fails. 15:17:30 OpenJDK 11 isn't Java 11? 15:17:42 oh 15:17:49 it is, but it supports building sources for Java 8+ 15:18:02 so the soruces say: build me like I am one of the french girls 15:18:03 sorry 15:18:09 yeah 15:18:12 so the soruces say: build me like I am java 5 15:18:26 and the openjdk 8 said: sure, eneteryng my legacy mode or whatever 15:18:38 but openjdk 11 says: java 5? go home, you are drunk 15:18:58 as far as I understand, yes 15:19:25 so dropping those broken specifications from pom.xml files should fix those packages 15:19:31 and if we patch it to say: build me like I am java 8 it will either build (and therfore we assume it works) or we have an actinable error 15:19:39 yes. 15:20:13 decathorpe: is there some %magic for this, or it's plain old sed/patch game? 15:20:31 uh .. sed/patch. unless you want to use XPATH 15:20:38 which I hope you don't 15:21:02 haha 15:21:04 you bet 15:21:11 parsing xml by regex is better 15:21:24 but XML isn't a regular language, you say? ;) 15:21:35 #info it seems the java11 copr has automation set, so when we open a PR, it will build in it 15:21:56 oh, great. so we can start submitting PRs to proactively fix things? 15:22:08 decathorpe: we can try with one thing, to see if the above is true 15:22:24 but the header in https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ indicates that 15:22:28 yeah 15:22:46 #action decathorpe to try if PR automation for java 11 rebuilds works 15:23:29 Change owners also say if we encounter any packages that are really broken with Java 11 they will help 15:23:34 sorry, OpenJDK 11 15:24:00 decathorpe: try to PR, I'll copy pasta what you have and we can continue from there 15:24:18 decathorpe: do we know of any real failures? 15:24:33 there seem to be some ... 15:25:11 glassfish-jsp-api: https://download.copr.fedorainfracloud.org/results/jvanek/java11/fedora-32-x86_64/01355164-glassfish-jsp-api/build.log.gz 15:25:41 looks like this one fails in JavaDoc generation, because it references some missing / private symbols 15:25:58 I seem to remember that private symbols are now *really* private with OpenJDK 11 :) 15:27:14 decathorpe: as far as I am concerned, we can disbale the docs 15:27:21 mhroncok: exactly 15:27:34 javaparser is also broken, but newer versions support / need OpenJDK 11 15:27:59 yeah most of the failures I see are JavaDoc problems 15:28:38 if nothing else helps, we can just disable those 15:29:45 * decathorpe sighs at broken GCC on f32 15:30:27 decathorpe: I must admit, I won't have time to help with actual changes 15:30:32 sorry :( 15:30:38 no problem 15:30:43 I can help deciding things :D 15:30:54 well, it's something. :) 15:31:05 #action decathorpe to open TODO items for Stewardship SIG packages that are broken with OpenJDK 11 15:31:31 I think I can depend on jvanek's COPR from another COPR, right? 15:31:49 I might just start a rawhide rebuild of all stewardship SIG packages 15:33:22 decathorpe: we can depnd on their copr, yes 15:33:44 I'll see what I can do 15:33:55 fixing SIG packages is our priority anyway 15:34:27 getting rid of them is :/ 15:34:34 yeah ... 15:34:40 oh great. java-8-openjdk fails to build on rawhide because of missing oh great. java-8-openjdk fails to 15:34:52 copypasta #include 15:34:57 :D 15:35:10 * decathorpe sighs 15:35:55 I wanted to poke the Java SIG, and it looks like there's https://pagure.io/java-sig , but it's empty for 6 months 15:37:31 decathorpe: next topic? 15:37:44 yeah this is making me sad 15:38:01 #topic Review Open RHBZs 15:38:06 #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&email1=stewardship-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=substring&list_id=11039307&product=Fedora&query_format=advanced 15:38:19 there's a new CVE for log4j 15:38:30 other than that, I think the bugs are only anitya stuff 15:39:26 decathorpe: low prio CVEs? let's ignore them? 15:39:54 decathorpe: some of the anitya bgs are assigned to orphans, some for you 15:40:11 decathorpe: shoudl we drop the orphane dones and make stewardship sig default assignee for the rest? 15:40:37 This package is now maintained by the Stewardship SIG. 15:40:37 https://fedoraproject.org/wiki/SIGs/Stewardship 15:40:37 Any non-security updates will probably not be handled, if no volunteer steps up to do that. If you wish to volunteer assign this bug to you and reset the priority. 15:40:45 should I mass post that to the anitya ones? 15:41:27 I'm wondering why some bugs are assigned wrong 15:41:57 though with new pagure we can at least set default assignee now :) 15:42:01 decathorpe: the oprhaned ones are just listed becasue we are cced, I've fixed it now 15:42:13 decathorpe: for mass changes, the PR thing was easier 15:42:13 ah, good. thanks 15:42:33 true ... 15:43:14 I'll look through the bugs later, I think some of them might actually be fixed already 15:43:38 #action decathorpe to go through RHBZs with fine comb and close fixed ones 15:44:53 moving on? 15:46:18 yes 15:46:27 #topic Review Open PRs 15:46:32 #link https://fedora-stewardship.github.io/pr-report/ 15:46:51 junit 4.13 breaks some things, and there's no other PRs right now. so not much to talk about 15:47:23 thanks for the reviews on felix-* though :-) 15:47:41 sure. looks like we didn't break anything 15:47:53 yeah :-) 15:48:14 #topic Review (SIG) Leaf Packages 15:48:27 #link https://pagure.io/stewardship-sig/issue/84 15:48:46 cipherboy has not orphaned his packages yet, and I can't do it for him 15:49:16 decathorpe: I can 15:49:41 oh right. that would be great 15:49:44 decathorpe: is the stewardship sig removed? 15:49:48 yes 15:49:55 decathorpe: codemodel, glassfish-dtd-parser, glassfish-fastinfoset, istack-commons, and xsom? 15:50:00 codemodel, glassfish-dtd-parser, glassfish-fastinfoset, istack-commons, and xsom 15:51:09 mhroncok: many thanks :) 15:51:13 #link https://fedora-stewardship.github.io/report/#total-leaves 15:51:39 cipherboy wants us to keep jboss-el-3.0-api and jboss-servlet-3.1-api for now, since new resteasy versions will require them, I think 15:52:23 Giving rpms/codemodel to orphan 15:52:24 Giving rpms/glassfish-dtd-parser to orphan 15:52:24 Giving rpms/glassfish-fastinfoset to orphan 15:52:24 Giving rpms/istack-commons to orphan 15:52:24 Giving rpms/xsom to orphan 15:52:45 mhroncok++ 15:52:45 decathorpe: Karma for churchyard changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:53:03 with the latest felix-* updates, felix-framework is now a leaf, which will also free up felix-osgi-obr-resolver 15:53:22 so we should be able to drop those two packages with the next cleanup 15:56:39 good 15:56:52 #topic glassfish-jaxb subpackages 15:57:01 #link https://pagure.io/stewardship-sig/issue/85 15:57:37 the neuro SIG would like us to re-enable some subpackages we dropped, and they would be willing to help with maintenance 15:58:20 I'll work them to figure out a way to do that without pulling in ancient dependencies again 15:58:27 decathorpe++ thnaks 15:58:31 *thanks 15:59:02 #topic Dropping isorelax 15:59:06 #link https://pagure.io/stewardship-sig/issue/86 15:59:26 that's one of those ancient cruft packages, not touched upstream in 15 years or so 15:59:54 we should be able to drop it, since the only way we depend on it is because it's BRd in jdom2 (but not Required) 16:00:06 I'll see what I can do about that 16:01:32 #action decathorpe to work on dropping isorelax from jdom2 build 16:01:36 #topic Open Floor 16:04:52 I guess there's nothing else :) let's wrap up. 16:04:55 #endmeeting