15:01:10 #startmeeting FESCO (2018-10-29) 15:01:10 Meeting started Mon Oct 29 15:01:10 2018 UTC. 15:01:10 This meeting is logged and archived in a public location. 15:01:10 The chair is jforbes. 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 'fesco_(2018-10-29)' 15:01:10 #meetingname fesco 15:01:10 #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:01:10 #topic init process 15:01:11 The meeting name has been set to 'fesco' 15:01:11 Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek 15:01:18 morning 15:01:19 .hello2 15:01:20 maxamillion: maxamillion 'Adam Miller' 15:01:32 I'm in two meetings but will do my best 15:04:23 .hello2 15:04:24 sgallagh: sgallagh 'Stephen Gallagher' 15:04:28 .hello2 15:04:29 bowlofeggs: bowlofeggs 'Randy Barlow' 15:05:10 Well, that at least gives us quorum 15:05:21 i'm only in this meeting but will do my worst 15:05:52 #topic #2003 Ursa Major (modules in buildroot) enablement 15:05:52 .fesco 2003 15:05:52 https://pagure.io/fesco/issue/2003 15:05:54 jforbes: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003 15:07:52 * nirik wonders if this needs more discussion on list or something... 15:07:56 Do we have any more detail on the buildroot repo? I don't see anything in the releng ticket new either. 15:08:07 or a prototype of the repo... 15:08:19 nirik: so the concern is that it will be hard to build locally? 15:08:27 yeah. 15:08:42 i do regularly build my packages locally before trying it in koji 15:08:47 so that would be unfun for me 15:09:20 adn this would not just affect module packages right? 15:09:28 because the point is that RPMs will be able to depend on modules now? 15:09:41 it would affect anything that built against modular content I think. 15:10:42 I think it's important to do this, but we should try and minimize the problem as best we can for local rebuilding. 15:10:53 same, I always build locally in mock before attempting in koji 15:11:04 i actually don't even use mock 15:11:09 Yes, local building is important 15:11:09 i just use rpmbuild directly 15:11:16 wait, so things built against modular content can't be built locally? 15:11:19 * jsmith is finally here 15:11:41 (in a data center with spotty wifi, but I'm here) 15:12:24 maxamillion: if there are modules enabled in the buildroot, rpm has no way to reflect that in src.rpms 15:13:05 maxamillion: They can be built locally, assuming you have that module enabled in your local installation 15:13:15 ah 15:13:17 so if you build against say openjdk-21 and thats in a module, we could build it by adding that module to our koji buildroot, but a local user would have to try and figure out where to get that 15:13:19 alright 15:13:26 This is about making that content available in the buildroot for mock/koji 15:13:39 So, what I am gathering here is we do not have enough data to really do anything. Perhaps a list discussion would be more helpful? 15:13:40 also mock would have no way to know to enable that 15:14:53 jforbes: +1 15:15:29 So proposal: Send email to devel list for further discussion and review in 1 week 15:15:36 yeah list discussion seems good 15:15:36 +1 15:15:44 +1 15:15:48 i think we do need a way to build locally, but i don't know what that would be 15:16:03 otherwise debugging is far more difficult 15:16:45 if we can make this buildroot repo work, we could enable it in mock at least... 15:17:00 bowlofeggs: Build a Koji container and install it with `fedora-packager`? *ducks* 15:17:08 hahaha 15:17:37 nirik: requiring mock would not be my fav, but it would be a reasonable solution if we can't think of anything else 15:17:45 i do really like being able to just run rpmbuild directly 15:18:07 bowlofeggs: Which remains an option if you have the necessary packages installed locally already. 15:18:08 bowlofeggs: still not required as long as you have the build dep installed 15:18:18 sgallagh: oh i guess that's a good point 15:18:26 not sure why i didn't thin of that 15:18:27 It's just that we have no easy way right now to help you get the deps automatically 15:18:28 haha 15:18:38 yeah so just dnf builddep won't work 15:18:40 `dnf builddep *.spec` won't work 15:18:42 perhaps dnf builddep could be extended too 15:18:56 if we could make dnf builddep work that would be rad 15:19:08 When the dnf team might have cycles again 15:19:18 That would be the best case, but we have to find some way to inform it what is needed. 15:19:23 yeah they are already overwhelmed it sounds like 15:20:09 So the proposal has 3 votes, bowlofeggs maxamillion jsmith want to vote? 15:20:47 dnf builddep won't do the thing it's supposed to do? 15:20:54 jforbes: +1 15:21:06 maxamillion: It won't *right now* 15:21:12 ... 15:21:24 Because it doesn't know it has to look for deps in what are effectively disabled repos 15:21:39 alright 15:21:42 +1 15:22:00 It can only find deps in standard repos or modules streams marked as the default stream' 15:22:41 it would be tricky to implement without something like the buildroot repo 15:23:17 #agreed an email will be sent to the devel list for further discussion and we will review it again in 1 week (+5,0,0) 15:23:27 Anyone want to send that email? 15:24:11 I will send it then 15:24:20 #topic #2004 Enabling pm_request in fedoraproject koji 15:24:20 .fesco 2004 15:24:20 https://pagure.io/fesco/issue/2004 15:24:22 jforbes: Issue #2004: Enabling pm_request in fedoraproject koji - fesco - Pagure.io - https://pagure.io/fesco/issue/2004 15:24:35 Similar request, though there has been more discussion on this one 15:24:47 this one sounds maybe scary but i don't know enough about it to have an informed opinion 15:25:25 puiterwijk, nirik: you both know a lot about koji - do you have comments on this issue? 15:25:56 my inclination is to say no. but I have been on PTO this last week, so I haven't had time to read the latest comments. 15:26:24 mizdebsk does seem to know a lot about koji based on my past interactions, and he seems to think it's unsafe 15:27:06 the idea of packagers being able to set buildrequires based on the %prep step does sound like a good feature, but this implementation of that feature may be unsafe 15:27:09 Yeah, I'm leaning towards "no" at this point, reserving the right to revisit it if someone comes up with mitigation plans 15:27:28 so perhaps this could also use another week... 15:27:29 perhaps there could be another implementation that doesn't have the security concerns? 15:27:45 there's a proposed rpm change, but it's not been merged... 15:28:07 i'm not opposed to the feature itself, i'm just concerned about the noted security issues with this particular implementation 15:28:28 yeah another week could be good 15:28:57 and https://github.com/rpm-software-management/rpm/issues/104#issuecomment-433248114 15:29:33 So it appears that it might not be needed for Fedora though, epel would still need it. Discussion is at least happening though 15:30:27 Proposal: pm_request discussion is still happening in ticket and should be given another week before we address it. 15:30:35 jforbes: +1 15:31:00 +1 15:32:28 sgallagh maxamillion jsmith? 15:32:39 +1, I suppose 15:32:48 +1 15:32:56 sorry, I'm joining a third meeting ... because of course I am 15:33:03 i do want this feature, but i want it to not be risky to the build infra 15:33:24 i would use it (i package a rust thing too) 15:33:36 #agreed pm_request discussion is still happening in ticket and should be given another week before we address it. (+5,0,-0) 15:34:00 #topic #2006 No Xfce and LXQT lIve isos in Fedora 29 RC 1.2 15:34:00 .fesco 2006 15:34:00 https://pagure.io/fesco/issue/2006 15:34:02 jforbes: Issue #2006: No Xfce and LXQT lIve isos in Fedora 29 RC 1.2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2006 15:34:23 Really, this and 2007 could probably be addressed together. Similar issues. 15:34:34 I'm sorry about the Xfce one... I usually test those, but I was on PTO and didn't specifically hand that off to anyone. ;( 15:35:10 proposal: spin these (and astronomy) with fixes needed to compose and make accessable for release tomorrow 15:35:37 nirik: +1 15:35:51 +1 15:36:02 patch 15:36:04 is that something releng will do? 15:36:20 for xfce thats 1 package I think, for lxqt it's a kickstart change, for astronomy I am not sure as it was just hanging and we didn't figure out why 15:36:42 Proposal: Perform a new spin that can be shipped for release. Ideally ship them alongside the release tomorrow, but a slip of a few days is acceptable if needed. 15:36:43 I think it's do-able... perhaps mboddu could chime in if he thinks it's not 15:37:36 sgallagh: If a slip is acceptable then we can do it, but definitely they cannot be ready by the release time tomorrow 15:37:41 * mboddu can try but no promises 15:38:08 * nirik is happy to help 15:38:15 I think a slip is acceptable. The alternative is to skip shipping those spins for this release, which seems much less desirable 15:38:32 I think if they aren't there tomorrow we will get a ton of questions about it. 15:38:38 i think a slip has to be acceptable 15:38:40 +1 15:38:40 haha 15:38:57 sgallagh: +1 15:39:19 Serious question: could we do Oct 31? If so, I'd suggest actually slipping the standard release to that date as well 15:39:36 As discussed in Go/No-Go, that would have a good synergy with RHL's original release 15:39:49 nirik: sure, but if they can't be done by tomorrow, better late than never 15:39:50 I think that would be pretty hard. 15:39:50 maybe this should be a council decision? 15:40:15 because there's a ton of people involved in release and telling them all to change with 1 days notice could be difficult. 15:40:33 without council approval, i'd opt to ship tomorrow as planned, and ship these whent hey are ready even if those are different dates 15:40:40 and I think the news cycle is already on.. something else. :) 15:40:42 nirik: Well, I basically mean "put everything in place as normal, but not send the announcement until a day later" 15:40:50 Right, I would love to have seen an Oct 31 release, but it doesn't seem like something we could change today 15:40:52 Also remember, we wont be syncing them to the place where they should have been, so websites people might have to do some work as well 15:40:56 Even better; we'll pick up the flagging news cycle in another day 15:41:14 mattdm: Are you around? 15:41:43 * nirik isn't sure, we might get a lot of questions about that too... since we announced tuesdayas the release date. 15:41:43 sgallagh: Pretty sure that even by Wed, it will be little more than a footnote in the current news cycle 15:41:54 jforbes: Fair 15:42:19 mboddu: yeah. ;( 15:42:32 OK, then I suppose we Common Bugs the lack of those Spins and send out a separate announcement when they're ready. 15:42:47 sgallagh: yeah that sounds good to me 15:43:09 Or, lets redirect the people to a page "not ready, come back soon" whenever they are ready, people will be able to access them 15:43:52 There are two teams involved, releng and websites 15:43:56 if we cannot get them in place sure. 15:44:05 I am +1 if there is a slip, but we need to check with websites as well 15:44:06 * nirik would really like to try and do that. 15:44:30 I would try to get them ready by tomorrow, but as said, no promises 15:44:35 OK, so there are two different questions here. 15:44:42 what about QA time on the images? 15:44:42 So proposal: If they can't be ready by tomorrow, common Bugs the lack of Xfce, LXQT, and Astronomy Spins and send out a separate announcement when they're ready. 15:45:01 bowlofeggs: Well, they are non blocking, so QA doesn't really matter 15:45:04 sure, +1 15:45:18 jforbes: Implicitly agreeing that, yes, we are shipping them. +1 15:45:22 it would be good to do some basic testing on them too yes 15:45:39 sgallagh: yes 15:45:41 nirik: Bare minimum: someone can successfully boot them in a VM 15:45:48 nirik: Yeah, definitely, whether they are booting or not and then basic dnf tests and stuff like that 15:46:07 sure.... 15:46:49 jforbes: +1 15:46:58 maxamillion jsmith? 15:47:02 Has anyone talked to websites and see if they can do this? 15:47:10 +1 15:47:21 mboddu: oh, good point of note 15:47:26 not yet, but I can. 15:47:46 #agreed If they can't be ready by tomorrow, common Bugs the lack of Xfce, LXQT, and Astronomy Spins and send out a separate announcement when they're ready. (+5,0,-0) 15:48:05 sgallagh: I am around but need to go in a few minutes 15:48:13 As I said, they wont be syncing to the place where they generally would be, so people might not be able to find them easily, so websites should definitely have the right link 15:48:13 #action nirik will talk to websites 15:48:30 mattdm: See current topic; we have an issue with some Spins, we're going to ship them, possibly late. 15:49:06 And that covers 2007 which was the last item on the agenda 15:49:53 sgallagh: +1 shipping them however we can 15:50:05 thanks y'all 15:50:13 jforbes: Hold up 15:50:23 We forgot to include the NFS topic on the agenda 15:51:25 sgallagh: right, it was opened 3 days ago, and getting votes in ticket 15:51:40 The only reason I added the spins was because of release timing 15:51:44 jforbes: Right, but with the level of chatter on it, I'd like us to discuss it today. 15:51:59 I meant to add the keyword and forgot. 15:52:01 Okay 15:52:06 (Had other things on my mind this weekend...) 15:52:33 #topic #2005 F30 System-Wide Change: Deprecating /etc/sysconfig/nfs 15:52:40 .fesco 2005 15:52:42 jforbes: Issue #2005: F30 System-Wide Change: Deprecating /etc/sysconfig/nfs - fesco - Pagure.io - https://pagure.io/fesco/issue/2005 15:53:08 So, I'm slightly of two minds on this topic. I'm firmly in favor of getting this done in F30, however I don't necessarily feel that the current migration approach is correct. 15:53:36 So I'd like to propose that we accept the Change, but that I'll volunteer to help the Change Owners find a better migration path. 15:53:54 +1 from me 15:54:02 sgallagh: I agree with you on the migration strategy 15:54:06 +1 15:54:31 +1 for change and yeah on migration 15:55:13 maxamillion jsmith? 15:56:34 +1 to my own proposal, to be clear. 15:56:37 +1 15:57:25 #agreed we accept the Change, but that sgallagh will volunteer to help the Change Owners find a better migration path. (+5,0,-0) 15:57:34 #topic next week's chair 15:57:55 last week zbyszek volunteered to take next week 15:58:36 #action zbyszek will chair next week's meeting 15:58:42 * steved thanks the board and looks forward working with sgallagh on a migration path 15:58:52 #topic Open Floor 15:59:46 Anyone have anything? 16:00:09 * sgallagh sings the blues 16:01:15 If nothing else, I will close in 1 minute 16:01:26 jforbes: Thanks for chairing 16:02:15 #endmeeting