17:02:05 #startmeeting RELENG (2018-05-10) 17:02:05 Meeting started Thu May 10 17:02:05 2018 UTC. 17:02:05 This meeting is logged and archived in a public location. 17:02:05 The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:05 The meeting name has been set to 'releng_(2018-05-10)' 17:02:05 #meetingname releng 17:02:05 The meeting name has been set to 'releng' 17:02:05 #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe 17:02:05 Current chairs: Kellin dustymabe masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 17:02:05 #topic init process 17:03:07 misc: doh, I misread the timestamp :) 17:03:08 kparal, misc : Not sure what you guys are talking about, but rel-eng meeting just started now and scheduled for next 1 hr 17:03:22 .hello 17:03:22 Kellin: (hello ) -- Alias for "hellomynameis $1". 17:03:28 morning 17:03:29 .hello kellin 17:03:30 Kellin: kellin 'Kellin' 17:03:44 .hello2 17:03:46 kparal: kparal 'Kamil Páral' 17:03:47 nirik: How is it going? Long time no see ;) 17:05:02 just peachy 17:05:36 nirik: keen too? 17:05:49 not very keen, but oh well. ;) 17:06:07 Okay, lets get started, I have 3 topic to discuss today and 1 to get a status on 17:06:22 #topic #7488 Released Fedora .composeinfo 17:06:28 #link https://pagure.io/releng/issue/7488 17:07:15 So, this is a request from internal, which until yesterday they were not able to import our composes in beaker, so they wanted to change the .composeinfo file 17:07:44 From Rel-Eng side of things, the only thing that I know is that .composeinfo is used for just beaker imports 17:08:00 So, two things, 1. are we using it anywhere else? 17:08:42 2. Currently its seems to work for them(automagically), but in future they see something wrong and want to change it to something that beaker can understand, can we modify it? 17:09:22 I don't think anything else is using them... 17:09:41 does pungi make those? 17:10:14 nirik: Nope, there is a script we run in nightly.sh 17:11:19 ah. 17:11:49 So, lets see how it goes now and if they find something, we can modify it for their requirements then 17:11:53 Does that sound okay? 17:11:58 we might check if internal uses them and stay in sync with them, but otherwise I don't see any problem adjusting 17:12:08 sure 17:14:14 nirik: Yeah, definitely 17:15:05 #info It seems to be working now and we will leave it at that for now. When we find any issues, we will adjust it accordingly for beaker requirements 17:15:12 Moving on 17:15:41 #topic #7485 rust-quickcheck0.4 is in composes 17:15:47 #link https://pagure.io/releng/issue/7485 17:16:21 So, the problem is sometimes when a package gets retired, its not properly updating pdc and hence not getting blocked in koji and with that its getting included in to the compose 17:17:00 There were 1 or 2 instances before but seems like they are getting increased in number in recent times 17:17:07 So, I want to bring this up and fix it 17:17:18 * mboddu can find the tickets if needed 17:17:36 ok, sounds like the listener to do this isn't working right/all the time... 17:18:27 nirik: yes 17:19:04 I guess file an infra ticket and we will see if we can get someone to investigate. 17:19:07 nirik: AFAIR, its not on ansible, its running as a service on one of boxes, do you know where is it? 17:21:03 #info mboddu will file a infra ticket with the recent issue tickets 17:21:04 it's on pdc-backend02 IIRC 17:22:32 nirik: Okay, I will create a ticket in infra with the recent issues with it 17:22:48 The problem is we dont know until someone reports about it 17:23:17 hum... perhaps rust-quickcheck0.4 wasn't retired properly? 17:23:29 they said it was retired manually... 17:24:59 nirik: May be but there were other instances when f29 retired updated pdc but not f28 17:25:01 like 17:25:11 https://pagure.io/releng/issue/7436 17:25:25 .https://pagure.io/releng/issue/7420 17:27:02 ok 17:27:07 well, we can try and look into it 17:27:30 Okay, I will create a infra ticket 17:27:36 Moving on 17:27:51 #7445 [RFE][PATCH] make $releasever return "rawhide" on Rawhide 17:27:56 #link https://pagure.io/releng/issue/7445 17:28:12 kparal: I guess you are here for this particular ticket :) 17:28:51 yes, I have a wall of text prepared as a conversation starter (sorry!) 17:29:03 I guess I'll dump it right in? 17:29:16 Sure :) 17:29:23 The background is that Rawhide is treated in a very special way for seemingly little reason and I'd like to make it closer to other releases in order to simplify automation tasks. The area I'm trying to improve is $releasever handling in Rawhide. We use the variable everyone, except Rawhide. It doesn't really make sense to me to ignore the variable - either let's use it, or if the value is not to our liking, let's change it and 17:29:23 then use it, just like in all other releases. 17:29:32 I have to say that RelEng already made a major improvement in supporting rawhide-as-number in mirrormanager. If this support stays in future, it's a big win for our use cases. Still, I'd like to make the behavior consistent between main Fedora repos and third-party repos (COPR being the most visible player here). 17:29:44 The easiest solution would be to "simply use $releasever as a number everywhere". Fedora fixed that in MM, and COPR could use it as well in their baseurls. But they haven't in the past (probably becaused they emulated the approach of Fedora Releng), and now they don't want to break existing people's repos. In order to keep compatibility, they would have to maintain rawhide->number symlinks in their repos, and according to clime 17:29:45 they really don't want to. I find that very unfortunate, because it's the simplest solution in my eyes, but I understand it's an extra bother for them. 17:29:56 The other solution (the proposed solution 1 in the ticket) is to make $releasever return 'rawhide' instead of a number. Then it can be directly used in Fedora repo files (if you wish) and the same COPR repo file/baseurl will work on all releases including Rawhide. The downside is that PackageKit would still consider $releasever as a number, because it doesn't use the same logic as DNF does. PackageKit would need to get patched, I 17:29:57 haven't discussed the issue with its maintainers yet. First I wanted to hear your opinion on this matter. 17:30:01 (done) 17:30:52 oh, and sorry for very long tickets, the idea is simple but the implications can get complex 17:31:35 * nirik really likes the idea of all numbers... but might be I missed some other places it would have an effect (like copr) 17:32:20 couldn't copr convert things? I guess that would be a lot of work too. 17:32:50 there's nothing stopping them using 29/ for rawhide, and then 30/ and so on. but their current repo files have 'rawhide/' hardcoded in baseurl, fedora-style 17:32:58 so existing users would get a broken link 17:33:04 existing rawhide users 17:33:18 yeah. ok 17:33:28 and they seem opposed to maintaining rawhide->number symlinks 17:34:55 the downside to 'rawhide' instead of 29 or whatever is that we still then need special rawhide repos... we can't collapse it all into normal ones. ;( 17:35:22 also, clime says that many users see 'rawhide' as an immutable target, so if they build something when rawhide=29, they expect it to be there once rawhide=30. they could solve this by copying the repo contents while branching, but it adds some tasks 17:36:06 nirik: well, you do and don't. you want special repos because of metadata_expire, probably. perhaps some gpg 17:36:23 yeah, IMHO the way to think of it is that if you build something now in rawhide and f29 branches, it's probibly a lot more like f29 than it is rawhide after a while. 17:36:31 but if $releasever returns rawhide on rawhide, you can use $releasever in repo files 17:37:05 yeah, I suppose... but they would look weird... 17:37:13 frawhide-updates-released 17:37:48 well, you want to support both in MM anyway, right? 17:38:10 at least that's what you did for this cycle, when I asked in the other releng ticket, iiuic 17:38:32 yeah, thats true... 17:38:53 so copr is using download.fedoraproject.org/ or metalinks or hard coded? 17:39:09 example: https://copr.fedorainfracloud.org/coprs/kparal/taskotron-dev/repo/fedora-rawhide/kparal-taskotron-dev-fedora-rawhide.repo 17:39:20 rawhide is hardcoded there 17:39:27 but: https://copr.fedorainfracloud.org/coprs/kparal/taskotron-dev/repo/fedora-28/kparal-taskotron-dev-fedora-28.repo 17:39:32 $releasever is used 17:39:38 it's exactly fedora releng style 17:40:07 but we have no control over those... those don't hit mm or anything... 17:40:31 no, I'm simply trying to make the behavior consistent across fedora releng + copr 17:41:04 that's why I created tickets for both, asking opinions 17:41:26 unfortunately they haven't met in a single solution 17:41:55 right. I don't think I am prepared to make some final decision today. I need some time to look at it more closely and see if there are any issues I missed. 17:42:09 sure 17:42:36 and I was hoping we could come to something that would simplify everything... but it's looking like it's not with copr in the mix 17:42:43 do you think you intend to keep both number and keyword support in MM for Rawhide in the future? that would be the first important thing 17:42:44 (what is iiuic) 17:43:07 Kellin: if I understand it correctly 17:43:34 kparal: What is COPR using to get the repos from? 17:43:51 mboddu: sorry, I don't understand 17:43:51 yeah, I think it should be easy to keep both... 17:44:09 kparal: baseurl=https://copr-be.cloud.fedoraproject.org/results/kparal/taskotron-dev/fedora-rawhide-$basearch/ in the .repo file you pointed 17:44:55 and the second, whether you prefer using numbers as a primary ID (and will you support that both in MM and in baseurls, or just in MM?), or whether you think it's better to make $releasever return rawhide on Rawhide (breaking PK support, but allowing universal URLs for both Fedora and COPR) 17:45:02 but if we drop fedora-repos-rawhide and depend on the number, then copr repos are going to diverge... you could have a f27 box with a rawhide copr repo... 17:45:46 nirik: you have the same problem now, if you install a rawhide copr repo, it's always a rawhide copr repo 17:45:54 we cannot support numbers in baseurls unless we moved rawhide to 29 and when branching made 30 17:46:22 kparal: yeah, I guess I don't understand that anything we do changes copr rawhide repos..they are hard coded right? 17:47:46 if nothing changed on copr side, and we made $releasever=rawhide, they could have a universal repo file using $releasever, and thus automatically follow the release (once it gets branched, it no longer pulls from rawhide dir from copr, but the correct number dir) 17:48:57 alternatively, they could get rid of rawhide/ dir, use numbers every time, and again have a universal repo file. this wouldn't require changes in fedora. but they are reluctant because compatibility with existing users 17:49:00 yeah, but they would still have to change all the repo files for that 17:49:33 in the first case, they could change what they offer (or not), but existing repos would not be affected, would still work 17:49:53 * nirik nods. 17:50:30 nirik: Cant we just make a symlink of rawhide/ to XX/ dir (not sure if MM understands it or not) 17:50:41 nope. 17:50:52 mirrors may or may not support symlinks 17:50:53 sadly 17:50:58 :/ 17:51:06 Yeah, thought so 17:51:08 copr is in a better place here 17:51:32 we could hardlink rawhide to XX/ but then if someone isn't using hardlinks they get everything twice. 17:51:32 they can afford symlinks, but don't really want to maintain them 17:51:48 nirik: Yes 17:52:08 it's really only one link, but they would have to change it every 6 months. ;( 17:53:26 it's a pickle. I'll be happy to hear better ideas than I had. or if you decide to do no changes, but at least keep the MM support for number-and-keyword for rawhide, it's still very helpful. it wouldn't work with copr, sadly, but I might try to convince them once again 17:54:00 my goal is to have a single repo file that works everywhere. either using mirrormanager (fedora) or baseurl (copr, third-party) 17:54:35 well, baseurl is a tough one. 17:54:43 mirrormanager is much easier 17:54:52 nirik: baseurl is not needed for fedora main repos, as long as MM works 17:55:21 I'm not really asking releng that 17:55:48 oh I see... right. 17:56:24 what I would like to do is have fedora / fedora-updates /fedora-testing repos, all using metalink as now and working for any release... 17:56:41 and for baseurls comment heavily and default to the stable release ones. 17:57:23 that should be doable right now. but if you want to make baseurls correct as well, we must make $releasever=rawhide 17:57:40 because of no symlinks on mirrors 17:57:45 even that would not work would it? 17:57:49 or you'd have to have 30/ instead of rawhide/ 17:57:53 development vs releases 17:57:58 oh 17:58:08 right, that's another issue with baseurls 17:58:24 and again hard to solve without symlinks :/ 17:58:38 and without changing the layout completely 17:58:46 right. I would just say to comment the repo file heavily and explain them all and when you might use one, etc 17:58:53 so I take it back, baseurls wouldn't be correct on rawhide, just MM 17:59:25 should we take this to a wider audience? ie, devel list or the like? 17:59:26 you could hardcode the baseurl on rawhide, and use variables in MM url 18:00:12 nirik: +1 on devel list 18:00:15 I don't know, you tell me :) if should not impact workflows of other people, I hope. except the affect on PackageKit, depending on the solution 18:00:15 nirik: I don't know about just yet, but eventually. I personally need more time to absorb this - can we table it for a week so mboddu and I can work through the implications and then come back? 18:00:52 there is always "something" out there, it would be wise before any final decision is made to throw a wider net 18:01:09 yeah, more pondering is good... I'd like to ping devel before we make any changes tho... it might affect someone we havent considered. 18:01:18 sounds good 18:01:20 at the same time, we have at least 1 (maybe 2) other topics to hit today, so if we can adjourn it for now and come back, we can keep going 18:01:34 kparal: btw has metalink been working well for you lately? 18:01:47 nirik: I still haven't converted our infra to use metalinks :/ 18:02:04 ah well, ok. ;) 18:02:07 still in my queue 18:02:45 should I send an email to devel list then? 18:03:16 I think we should work it down a bit 18:03:23 lets wait and send after next meeting? 18:03:28 ok 18:03:43 I'll be happy to help in the ticket or over irc 18:03:48 we want to be sure we as owners have a clear unified understanding before we add X people where X is all fedora developers 18:04:31 it's sometimes difficult to grasp it all, so feel free to ping me if you feel like missing something 18:04:45 even I had to have a refresher before the meeting 18:05:18 yeah, it's a lot of moving parts 18:05:23 damn compatibility concerns, without them this would be trivial :) 18:05:46 alright, thanks for your time, very appreciated 18:06:05 mboddu: so let's hit those last two things real quick? 18:06:27 kparal: Thanks for the info and its a lot to take in 18:07:04 Kellin: I dont have anything else other than checking status on https://pagure.io/releng/issue/7457 18:07:34 nirik: ^ Any update on it? 18:07:43 * nirik clicks 18:08:00 And thanks nirik for helping us solve the MM issues until we get a better understanding of it 18:08:02 nirik++ 18:08:13 ah, I think thats done? let's test 18:09:03 mboddu: did I miss us covering https://pagure.io/releng/issue/6676 ? 18:09:17 so, yeah, I think this is done... it's sort of like the last one tho... if we want a special rawhide repo or not. 18:09:56 nirik: Yeah 18:10:10 Kellin: Oh sorry, I didn't got to it, can we take it next week? 18:10:24 Its way past our scheduled time 18:10:25 so, I'd say lets close that one and note that it's end fate may be decided by the last ticket... 18:10:49 nirik: Okay 18:11:08 nirik: 7457 or 6676? 18:11:33 7457... 18:12:30 7457 end fate depends on 7445 18:12:39 yeah 18:13:52 Kellin: We will start our next meeting with 6676, sorry we couldn't make it this time 18:14:09 Thank you all for joining 18:14:18 #endmeeting