15:01:10 #startmeeting Stewardship SIG Meeting (2019-08-06) 15:01:10 Meeting started Tue Aug 6 15:01:10 2019 UTC. 15:01:10 This meeting is logged and archived in a public location. 15:01:10 The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:10 The meeting name has been set to 'stewardship_sig_meeting_(2019-08-06)' 15:01:15 #meetingname stewardship-sig 15:01:15 The meeting name has been set to 'stewardship-sig' 15:01:23 hey guys :) 15:13:32 \o 15:13:44 decathorpe: Did I miss the pagure issue or was that not sent out with the email yesterday? 15:14:07 decathorpe: Ah never mind, found it. 15:14:24 hi! 15:14:27 #chair cipherboy 15:14:27 Current chairs: cipherboy decathorpe 15:14:47 sorry, I was pretty busy, I created the pagure ticket only a short time ago 15:15:32 decathorpe: Not a problem. I'll try to spend some time today reviewing the open PRs. 15:15:37 #link https://pagure.io/stewardship-sig/issue/44 Agenda 15:16:08 that would be great! they should be fine, as I did test rebuilds for all of them 15:16:09 decathorpe: I think the one I want to deal with that's not there yet is jackson-databind. There's been a few CVEs against it, so I *hope* rebasing to the newest upstream release will address that. 15:16:45 oof okay that one is still orphaned 15:16:54 jackson-databind is? 15:16:58 yes 15:17:02 I thought we previously claimed it a while back. 15:17:12 nope 15:17:13 https://src.fedoraproject.org/rpms/jackson-databind 15:17:51 decathorpe: So what's the difference between jackson and jackson-databind? 15:18:27 looks like databind is an extension of jackson 15:18:34 Yeah, looks like it. 15:18:58 I was confused, jackson mentions "data binding" so it sounded like jackson package might include core jackson + jackson-databind, but I guess not. 15:19:00 hello! \o 15:19:00 also, it's on the list of orphans we depend on. so we'll probably pick it up soon 15:19:08 hi! :) 15:19:25 decathorpe: Yeah, we (RHCS) maintain/depend on it in RHEL, so we should pick it up in Fedora as well. 15:19:31 #chair sillebille 15:19:31 Current chairs: cipherboy decathorpe sillebille 15:19:49 I apologize for being been sloppy for past couple of meetings. I have reserved some cycles to get into SIG work this month. 15:20:16 no problem, I'm glad for any help I get :) 15:20:51 cipherboy: do you see any other packages on the "orphans list" that you know we will need anyway? 15:21:10 we can request ownership of these right away and don't have to wait for further cleanups 15:22:10 decathorpe: Give me a sec to pull up the doc, I had a list at one point.. 15:23:13 cipherboy, is this the list that you were looking for? https://paste.fedoraproject.org/paste/7X70X4D3D~uTW-qQvF6LVA 15:23:47 decathorpe: Not sure this is the right list, but I have jackson-databind, glassfish-fastinfoset, glassfish-jaxb, istack-commons, jackson, javassist, jboss-annotations-1.2-api, jboss-logging, slf4j, xalan-j2, and xsom? 15:24:19 ok, we akready have some of these, but some are missing 15:24:33 Right, I need to intersect that with our packages already. 15:25:37 can you comment on this ticket once you have the list? it's where we're tracking which orphans we need to adopt. 15:25:39 https://pagure.io/stewardship-sig/issue/40 15:25:45 decathorpe: Sure, will do. 15:25:50 thanks! 15:26:11 decathorpe: I think I had wanted to see if jboss-annotations-1.2-api and jboss-logging could be dropped, but I haven't had time to look into that yet. 15:26:21 I think I decided it wasn't an easy conditional flag in the spec file, but. 15:26:55 yeah not every optional feature is already switchable with a spec flag 15:28:28 Agreed. 15:28:34 I'll take a look at that sometime. 15:29:02 👍 15:29:18 * cipherboy files tickets so I remember to look at it 15:29:58 that's my strategy as well ;) 15:30:37 with everything that's going on, it's hard to keep on top of things as it is 15:30:48 decathorpe: Agreed. 15:31:34 also I don't know how productive the next few days will be for me, since I'm at flock till Sunday 15:32:07 Cool! Good luck on your presentation! 15:33:16 thanks :) I hope it'll be interesting 15:34:26 ah, there's one topic I wanted to bring up as well. 15:35:30 #link https://pagure.io/releng/issue/8522 F30: Retire FTBFS packages on 2019-08-06 15:36:23 this will probably happen in a few days, or after flock 15:36:45 so just a heads-up that some Java packages might start to FTBFS because of this 15:37:10 Are any of our packages besides potentially gradle affected by it? 15:37:11 once we know which packages we need, we can start to un-retiring them 15:37:24 I don't know ... that's the thing 15:37:30 :D 15:38:37 it's not really easy to tell which packages are affected 15:39:26 Yeah, gradle is the only obvious one. 15:39:26 so my thoughts were ... let's see which things break and fix them afterwards. 15:39:31 heh, works for me. 15:39:41 Will this cause the packages to get removed from F30? 15:40:13 no, they will only get removed from rawhide and what will become f31, since it should happen before the branch point 15:40:38 Good, so nothing stable will be affected. 15:40:43 yes 15:40:59 my goal was that we should keep things working as best as we can in F31 15:41:07 and start to really mess with things for F32 ;) 15:41:32 I should update CI to start testing on the newer images when they're available so we'll catch failures sooner too. 15:41:51 jss builds on rawhide, but I don't think we do pki-core images. sillebille could correct me if I'm wrong though. 15:42:16 you can also look at koschei, it tells you which packages have missing dependencies or fail to build 15:42:17 we do with pki-core 15:42:23 and it passes. 15:42:29 sillebille: \o/ cool 15:42:48 https://travis-ci.org/dogtagpki/pki/builds/568172768 15:42:53 cipherboy: you know about this page right? https://apps.fedoraproject.org/koschei/user/cipherboy 15:43:10 decathorpe: Yeah, I think I signed up to get notifications, but I get so many that they all get filtered :? 15:43:22 oof 15:43:26 decathorpe: I need to unfilter some :D 15:43:33 yeah notifications really are a firehose 15:43:46 hmmm. pki-core fails started to fail in rawhide, recently. ugh. I'll take a look in a while... 15:43:48 but right now everything's green 15:44:15 decathorpe: Yeah. \o/ 15:45:30 I hope that after all the non-responsive maintainer processes I went through we can make sure the remaining Java stack will be in better shape 15:45:53 I just worry we'll be stuck with most all of the stack. 15:46:32 well ... I'm still hoping that Modularity will be abandoned ;) 15:46:46 and people maintaining the modules will take their old packages back 15:47:26 I keep wondering what will happen if modularity gets abandoned in Fedora (or, defacto abandoned)... RHEL will have to support it at least through RHEL 8... 15:47:36 yeh 15:47:37 I know 15:47:46 it's all a huge mess 15:48:01 * cipherboy wonders what will happen if he asks for a few ursine versions of modular packages... 15:48:21 you can always ask. which packages are you thinking of? 15:49:26 Well, the obvious one would be the rest of the Java ones (maven, ant, and javapackages-tools). I think we have most of the dependencies we care about though, so the difference should be minimal. 15:50:03 we basically maintain "ursine" branches of these three already 15:50:11 decathorpe: What really annoys me is that we spend time maintaining usrine versions of some of these and they only get used in the BUILDROOT since the default module stream wins. 15:50:34 yeah that's an obvious design flaw in my opinion 15:50:45 (which is why I disable modular repos on all my systems) 15:51:04 Oh! I can disable just the modular repos? 15:51:07 yep 15:51:16 \o/ cool, I'll have to look at that and see what breaks. 15:51:41 this way I also wasn't affected by the libgit2 mess 15:51:51 Hm, I never saw that. 15:52:09 I guess I am on f30 anyways. 15:52:21 yeah, that's where the problem was 15:53:37 but to come back to an earlier point: the goal of most of the package updates I've been working on is to try to keep rawhide and Java modules from diverging too far (which will only lead to issues) 15:54:07 Yeah, it'd be nice if we could automatically pull in updates from the java module streams. 15:54:34 pull in == open a PR, sorry. 15:54:57 it won't be that easy since there's stuff specific to modularity happening there, but backporting the major changes is pretty straightforward 15:55:41 decathorpe: The other thing we're missing is a .spec file rountripper. Something to let us programatically change them in a little safer way than sed. 15:56:07 ugh don't get me started 15:56:16 programmatically modifying .spec files is a nightmare 15:56:17 :D 15:56:38 What do you think of something like https://packit.dev/ ? 15:56:50 It feels like we'd need to push those to the upstream though to take advantage of it. 15:56:59 yes 15:57:09 my thoughts are: interesting, but not what we really need 15:57:39 (I've been trying to work on something in my spare time, but got sidetracked with Stewardship stuff) 15:57:43 And we really want to do as little upstream work as we can. We don't really have the resources to do more than file issues I guess. 15:57:55 absolutely :( 15:58:01 :/ 15:58:21 which is why I'm trying to reduce our package set every way I possibly can 15:58:50 so we can focus the little resources we have on the stuff we really need 15:59:38 Yeah agreed. And thanks for all your work :) 15:59:59 heh. thanks for your help :) 16:00:08 That's all I really have. I'll check out the open PRs now and see what I can approve. 16:00:23 awesome 16:00:32 do you want a list of PRs with successful test rebuilds? 16:00:32 1 question before we break: can't we just steal stuff from the stream branches 16:00:46 sillebille: we can, and I've started to do exactly that 16:01:00 sillebille: See about 30 messages ago, but the answer is "we can, just not in an automated fashion" 16:01:12 exactly 16:01:13 so, we just rebase f30, f29 and master to 16:01:34 I'd stick to branched and rawhide for now 16:01:56 everything else would be risky 16:01:59 i think I worked on a script to automatically do builds. I have the design somewhere in my local but I hadn't had the chance to implement the design 16:02:03 decathorpe: So with a lot of these, I see you're reordering the spec file. Is this for your later automation? 16:02:31 automatically == minimize the manual effort. Not complete automation. 16:02:51 I can share the design with the SIG once I get consultation from cipherboy ;) 16:02:52 not really ... I'm just used to the standard formatting / style 16:03:02 decathorpe: ACK 16:03:15 decathorpe: If we have a standard, makes it easier to automate though, so I'm all for it. 16:03:26 cipherboy: I know, it's probably a bad habit to mix formatting changes in :( 16:03:43 but I don't want to "pollute" commits with "formatted spec file" commits either 16:04:09 decathorpe: Eh, commits will get polluted either way tbh. 16:04:48 right. I just try to keep my garbabe contributions low ;) 16:04:50 I've had my share of 4 commit "forgot to do this, forgot to do that, this doesn't actually build, oh here we go" when it could've been a single version bump commit. 16:05:01 :D sure. we've all been there 16:06:03 by the way - before we close the meeting - I've started collecting some data about our packages (it's in the /data/ folder in our pagure project) 16:06:54 how do I acces that? 16:07:04 pagure.io/stewardship-sig 16:07:26 oh! ~facepalm~ yeah. That! Thank you! :) 16:07:50 I've collected package adoption and removal dates, upstream releases, and downstream updates. 16:07:57 decathorpe: :o wow! Cool 16:08:13 that way I can generate statistics about update delays, update backlogs, etc. 16:08:38 output in textual format is here: https://decathorpe.fedorapeople.org/stewardship-sig-stats.html 16:09:20 decathorpe: Cool, I'll have to take a look at that some more. 16:09:39 don't look too long, it gets rather depressing 16:09:43 :D 16:09:51 that's a quite a cool collection of info. I'd be handy 16:09:52 :) 16:09:59 well, that's everything from my side 16:11:57 decathorpe: Thanks! 16:12:24 thanks for showing up! 16:12:27 #endmeeting