15:01:00 #startmeeting FESCO (2018-12-10) 15:01:00 Meeting started Mon Dec 10 15:01:00 2018 UTC. 15:01:00 This meeting is logged and archived in a public location. 15:01:00 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:00 The meeting name has been set to 'fesco_(2018-12-10)' 15:01:00 #meetingname fesco 15:01:00 The meeting name has been set to 'fesco' 15:01:00 #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:01:00 Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek 15:01:03 #topic init process 15:01:05 .hello2 15:01:05 bowlofeggs: bowlofeggs 'Randy Barlow' 15:01:10 .hello2 15:01:11 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:17 morning 15:01:46 afternoon ;) 15:01:51 .hello2 15:01:52 sgallagh: sgallagh 'Stephen Gallagher' 15:01:54 .hello2 15:01:55 jforbes: jforbes 'Justin M. Forbes' 15:02:01 .hello psabata 15:02:02 contyk: psabata 'Petr Šabata' 15:02:17 Tha's 6, quorum 15:02:22 * contyk will be very distracted for a bit 15:02:47 #topic #2023 Allow untagging of module builds from rawhide 15:02:50 .fesco 2023 15:02:51 zbyszek: Issue #2023: Allow untagging of module builds from rawhide - fesco - Pagure.io - https://pagure.io/fesco/issue/2023 15:02:53 https://pagure.io/fesco/issue/2023 15:03:26 .hello2 15:03:27 maxamillion: maxamillion 'Adam Miller' 15:03:45 I admit I have no idea about this topic, so I'll just follow what others say 15:03:58 I think this happens because of a suboptimal tagging behavior in MBS 15:04:02 yeah i also don't really get what's going on here 15:04:10 I'm +1, but would like to get the base cause fixed 15:04:26 there's a plan to make it more flexible and put it in an external service (in dev) 15:04:39 so if what Igor said in ticket is true, then yes I'm +1 because if it's an uninstallable artifact, it shouldn't matter 15:04:47 yes 15:04:57 +1 as well, in those cases 15:05:00 Right, +1 then too 15:05:18 i'm +1 to removing uninstallable things 15:05:24 this particular case was caused by our relase scripts I think... not mbs... but yeah 15:05:25 I am +1 as well 15:05:29 I think the short-term is that we want rel-eng to have permission to do this as they see fit until we have a better technical solution 15:05:31 I'm +1 15:05:35 s/release/branching/ 15:05:55 hmm 15:06:34 wait ... releng doesn't have permissions to take action on build artifacts that need to be released? 15:06:35 would love to learn more about that, nirik 15:06:36 i'm with maxamillion, i'd think releng already has this authority 15:06:59 there's a rule that we never untag artifacts after they have shipped out in rawhide. 15:08:09 #agreed: Untagging of the builds is allowed until a longer-term solution is implemented (+6, 0, 0) 15:08:11 #info: There's a plan to make it more flexible and put it in an external service (in development) 15:08:12 contyk: when branching we clone the tag so the branch has everything... right now that includes modules... 15:08:15 OK? 15:08:41 zbyszek: LGTM 15:08:43 #agree Untagging of the builds is allowed until a longer-term solution is implemented (+6, 0, 0) 15:08:47 #info There's a plan to make it more flexible and put it in an external service (in development) 15:08:50 Did I get the syntax right? 15:08:53 nirik: yeah, let's look into that together latet 15:09:19 I hope so, I'll just fixup the meeting notes ;) 15:09:20 contyk: sure. I think sgallagh and mboddu were going to poke at it, but yeah, it needs likely some more logic or something. 15:09:21 zbyszek: i think the #agreed one works 15:09:44 There's no feedback unfortunately. 15:09:52 Anyway, let's move on. 15:09:53 #topic #2020 Firefox is switching from gcc to clang/2020 15:09:53 .fesco 2020 15:09:53 https://pagure.io/fesco/issue/2020 15:09:53 nirik: Yeah, I'm going to look into that with mboddu after the New Year 15:09:54 zbyszek: Issue #2020: Firefox is switching from gcc to clang/llvm - fesco - Pagure.io - https://pagure.io/fesco/issue/2020 15:09:58 my dance card is full until then 15:10:17 zbyszek: It's agreed, not agree 15:10:46 I already commented on the ticket that sgallagh and I will look into it after Dec 31 15:11:11 great 15:11:27 sgallagh: i still kinda feel like FPC should get to decide on this before escalating to fesco 15:12:08 I would disagree. The policy doesn't need to change, they are simply asking for an exception. Though I don't really have a problem with them chiming in first 15:12:11 i'm fine with clang personally, but FPC oversees the guidelines and i think they should have a shot at considering this issue first 15:12:37 here is the old ticket: https://pagure.io/fesco/issue/847 15:12:38 bowlofeggs: The ticket with FESCo is just about untagging the modules 15:12:40 We don't really need to have a custody battle over this, do we? 15:13:27 bowlofeggs: FPC doesn't *set* policy, they *implement* policy. 15:13:34 the thought was that lots of things would switch and llvm would have poor/no support for many things and we would be in a bind 15:13:35 How to handle the the issue is a different case 15:13:39 ah so it look slike this was a fesco policy to begin with, as linked by nirik 15:14:12 bowlofeggs: where was it linked? 15:14:21 zbyszek: https://pagure.io/fesco/issue/847 15:14:35 apparently this policy was a fesco decision 6 years ago 15:14:37 nirik: Right, and there's some argument to be made that, six years and endless corporate sponsors later, we might even consider revisiting this. 15:14:55 perhaps. 15:15:05 But I'm not proposing that today :) 15:15:18 we could say something like "packages can use compilers supported by upstream" 15:15:40 I'd be inclined to just allow this for firefox. If this starts coming up more, we can always ask FPC to change the guidelines. 15:15:41 bowlofeggs: I actually disagree with that, but it's not the topic on the table today. 15:16:02 bowlofeggs: I concur with sgallagh here 15:16:04 Today we just have a specific exception to consider. As I noted in the ticket, I'm +1 15:16:11 +1 too 15:16:14 i can be +1 to the exception 15:16:22 +1 here 15:16:22 * nirik is +1 to allow firefox and if folks want to revisit, we should/can do that with another ticket. 15:16:31 nirik++ 15:16:31 sgallagh: Karma for kevin changed to 20 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:17:07 +1 here 15:17:26 contyk? 15:17:53 oh ... BZ got an upgrade 15:17:54 I abstain 15:17:55 huh 15:18:37 #agreed The exception for firefox is granted (+6, +1, 0) 15:18:54 #topic #2003 Ursa Major (modules in buildroot) enablement 15:18:54 .fesco 2003 15:18:54 https://pagure.io/fesco/issue/2003 15:18:56 zbyszek: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003 15:19:42 I think we should go with the proposal as stated by contyk in the ticket 15:20:16 When an implementation is ready, there'll probably be more details to figure out 15:20:23 https://pagure.io/fesco/issue/2003#comment-544193 15:20:42 * sgallagh agrees 15:21:21 * nirik doesnt like telling everyone to hit koji 15:21:37 yeah, a compose would be better 15:21:53 I don't like it, I'm inclined to propose to reject ursa-major entirely until it can be implemented correctly 15:21:55 or just mirror the Koji repos 15:22:01 contyk: not an option 15:22:01 Wait, "I think the only workable option here are buildroot composes." 15:22:03 but would be vast 15:22:23 maxamillion: can you define correctly? 15:22:30 contyk: which statement? 15:22:48 maxamillion: the one just now 15:23:24 contyk, nirik: I don't understand nirik's comment. My reading of contyk's proposal was that a compose would be created, and koji would not be hit. 15:23:41 zbyszek: the compose wouldn't be mirrored aiui 15:23:47 if thats the case... I think our mirrors might be unhappy. 15:23:54 zbyszek: that would indeed be my proposal 15:24:01 I suppose everything would be hardlinkable... 15:24:05 contyk: please clarify "that" 15:24:17 zbyszek: creating a buildroot compose 15:24:30 also it would increase compose time 15:24:31 apologies, just getting off a plane 15:24:31 contyk: this needs to be handled in a way that doesn't introduce undue burden on packagers, releng, or the infra team ... right now it's just passing the buck because the solution doesn't satisfy the requirements 15:25:47 maxamillion: Do you have a (general) proposal how this would be handled better? 15:26:13 maxamillion: so you refuse a, I think, a workable proposal as incorrect without having anything specific in mind as a replacement 15:27:05 zbyszek: I don't know enough about the implementation to really offer technical architecture change suggestions, I only know the impact that's being outlined in the proposal and I don't consider them acceptable 15:27:09 I agree that dumping more on releng isn't a workable proposal 15:27:11 i also think having packagers use the koji server could be a problem, fwiw 15:27:38 contyk: I don't agree that creating more work for others is a "workable proposal" 15:27:44 bowlofeggs: +1 15:27:46 jforbes: +1 15:28:25 I'm not sure this is much more work for releng... the aspect I am not sure about is the buildroot compose and other resources it would consume... time, disk, mirror space, etc. 15:28:32 * contyk doesn't consider setting up one more variant as a huge burden in terms of work 15:28:40 nirik: and you think that mirroring these buildroot repos would not be "popular" among mirror admins? 15:28:57 well, it's Everything + (some) modules 15:29:12 I think nirik suggested we could point to artifacts in the other variants last time 15:29:20 but maybe I misunderstood 15:29:34 yeah, if we can do that I am ok with this. I thought that wasn't workable? 15:29:36 nirik: is "Everything" required? I thought it'd be just the "+ some modules" part. 15:30:00 nirik: you just need to make it look like a flat repo 15:30:04 zbyszek: perhaps. would need pungi work though? 15:30:23 So the question is who would be implementing this? 15:31:08 we could ask pungi developers... 15:32:02 if we can solve the resource issues around the buildroot repo(s), I'd be in... 15:32:16 proposal: talk to pungi devs, revisit next week? 15:32:39 Also, can we get an impact assessment from infra? 15:32:44 if we can just point at the right rpms in the other variants (most in everything, some in modular), it would be mostly empty a provide an environment similar to koji 15:32:51 zbyszek: +1 15:32:58 zbyszek: in what sense? 15:33:34 nirik: in the sense if the additional repo would be a burder to distribute 15:33:35 It depends on how it's implemented how much disk/etc it would use 15:33:59 nirik: well, it'd be just a bunch of symlinks, so probably not that much actual disk space 15:34:08 if it was just repodata, thats nothing... if it was just modules that are in the buildroot, thats not much more, if it's everything... thats a burden 15:34:19 we cannot use symlinks. 15:34:28 it would be hardlinks or copies 15:34:40 Right, hardlinks. 15:35:18 But actually no new data, right? By defininition all those rpms must already be visible somewhere else. 15:35:36 sure, but they would take up 100,000 inodes or whatever. 15:35:49 it could be new data 15:36:29 but very little of it if any - that's the buildroot only modules that would require FESCo ack 15:37:00 OK, so who can talk to pungi devs (and whoever else should be included)? 15:37:15 nirik, contyk? 15:37:17 I can file a ticket... and everyone can watch/add to it? 15:37:40 Works for me. 15:37:45 +1 15:38:04 +1 15:38:14 +1 15:38:26 +1 15:38:41 +1 15:39:03 +1 too 15:39:07 #action nirik to file a ticket with pungi 15:39:07 #agreed We'll gather more information about the required changed to pungi and additional resources required for this and revisit next week (+7, 0, 0) 15:39:34 #topic Next week's chair 15:39:57 I'll be free 15:40:14 This is my last FESCo meeting of 2018 15:40:41 Is this the last meeting before after the elections? 15:41:02 next week 15:41:42 So, contyk or sgallagh, who wants to chair the next meeting less? 15:41:53 I can 15:41:59 sgallagh can't 15:42:03 #action contyk will chair next meeting 15:42:24 * zbyszek has trouble figuring out if "this" is this, or "the one beeing discussed" 15:42:26 * contyk nods 15:42:28 Right, sorry. 15:42:38 s/this/today/ 15:42:41 it's this 15:42:42 Thanks contyk. 15:42:44 clearly 15:42:49 #topic Open Floor 15:43:09 I suspect we won't have quorum anyway 15:43:47 Anyone? 15:43:50 One item for open floor, the koji outage next month 15:43:59 It's pretty long, no? 15:44:34 More of an infra thing, but the concern is, what if there is a critical security update during that long window? Is there a way to force a build/exclude s390? 15:44:44 #info OUTAGE: Koji system 2019-01-11 -> 2019-01-14 15:45:16 #info https://pagure.io/fedora-infrastructure/issue/7429 15:45:45 jforbes: ExcludeArch ? 15:46:01 https://pagure.io/pungi/issue/1095 <- pungi ticket 15:46:07 I am certainly not proposing that we just keep things going, it would be a nightmare to catch up S390, but there should be an exception process 15:46:15 please expand on anything I got wrong. ;) 15:46:17 zbyszek: Yes, but the way it read, koji as a whole would be down 15:46:31 koji will not be down, only s390x builders. 15:46:53 Okay, that alleviates my concern 15:46:57 Hmm, but does this mean that we should discourage non-noarch builds? 15:47:09 zbyszek: They should fail 15:47:19 Ah, OK. 15:47:19 unless you ExcludeArch 15:47:26 they would queue up... waiting 15:47:37 well, until they hit the 2 day timeout probibly. 15:48:31 OK, anything else to mention here? 15:48:41 No, that addresses my concern 15:48:41 If not, I'll close in a minute. 15:48:42 it's a super computer so it should be able to do a super amount of builds when it comes back online 15:49:09 bowlofeggs: I think by legal definition, an iPhone is a super computer these days 15:49:18 ha 15:49:39 proposal: replace s390x by an iphone, call it quits 15:49:57 * sgallagh is not entirely sure if zbyszek is joking 15:50:02 zbyszek: It should at least be android 15:50:39 #endmeeting