17:01:17 <mboddu> #startmeeting RELENG (2018-09-27)
17:01:17 <zodbot> Meeting started Thu Sep 27 17:01:17 2018 UTC.
17:01:17 <zodbot> This meeting is logged and archived in a public location.
17:01:17 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:17 <zodbot> The meeting name has been set to 'releng_(2018-09-27)'
17:01:17 <mboddu> #meetingname releng
17:01:17 <zodbot> The meeting name has been set to 'releng'
17:01:17 <mboddu> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe
17:01:17 <zodbot> Current chairs: Kellin dustymabe masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
17:01:17 <mboddu> #topic init process
17:01:23 <nirik> morning
17:01:36 <mboddu> nirik: morning, how is it going?
17:01:57 <nirik> not too bad...
17:02:04 * mboddu will get some tea, be back in 2 min
17:03:44 * threebean waves
17:04:52 * mboddu is back
17:04:57 * mboddu waves back at threebean
17:05:01 * nirik does the wave
17:05:56 <mboddu> I have two major issues and 1 minor issue(from nirik about torrents) to discuss today
17:06:11 <nirik> ok
17:06:19 <mboddu> Since threebean is here, lets start with his request
17:06:22 <mboddu> #topic #7840 Consider ursa-major
17:06:27 <mboddu> #link
17:06:30 <mboddu> #undo
17:06:30 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f56bbdb6950>
17:06:40 <mboddu> #link https://pagure.io/releng/issue/7840
17:06:50 <threebean> yeah, so I'm kind of proxying this request for others.
17:06:56 <nirik> I think this may be too big an issue for us to decide.
17:06:56 <threebean> sgallagh, mizdebsk: you guys around?
17:07:06 * mizdebsk is here
17:07:08 <sgallagh> .hello2
17:07:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:07:14 <mboddu> So, this is very concerning for me
17:07:21 <mboddu> I am not sure how much this break
17:07:29 <nirik> unless there's a way we can 'fix' other people building against fedora
17:07:31 <mboddu> threebean: Has it been deployed internally?
17:07:39 * threebean nods
17:08:20 <mboddu> What is the final goal for this?
17:09:10 <threebean> mboddu: to allow mizdebsk (and others) to make some of their packages module-only, so they don't have to maintain them twice.
17:09:12 <nirik> to allow things to become modular only and yet allow non modular packages to build against them
17:09:16 * threebean nods
17:09:20 <sgallagh> Can one or both of you enumerate your concerns in specific ways?
17:09:34 <threebean> yeah, they can't go all-modular today because some other things require them at buildtime.
17:09:48 <nirik> sgallagh: it means any external people cannot build some things anymore at all.
17:10:00 <nirik> or without a bunch of scripting and scraping and downloading
17:10:06 <sgallagh> hmm
17:10:29 <mizdebsk> the ticket brings this concern and i proposed some solutions
17:10:33 <nirik> including fedora users... you can't rpmbuild things anymore
17:10:46 <sgallagh> At the risk of asking Factory 2.0 for more enhancements... could they provide a service that produced "views" of buildroots for third-parties to consume?
17:11:01 * cverna is around
17:11:22 <sgallagh> nirik: Why do you think they cannot rpmbuild things?
17:11:32 <sgallagh> That's *always* been related to the set of packages installed locally
17:11:56 <nirik> you're right, I guess they can.
17:12:06 <threebean> mizdebsk: I think I liked your idea of the compose variant for buildroot only content the most.
17:12:18 <nirik> just anything that uses our repos cannot unless they somehow figure out when to use modular content
17:12:46 <nirik> thats going to be a large chud of content for mirrors. ;( All hardlinkable tho
17:13:59 <mboddu> Also, I wonder how the module solving might create issues
17:14:29 <threebean> mboddu: in koji? or, elsewhere?
17:14:40 <mizdebsk> "module solving"?
17:14:52 <sgallagh> nirik: What I meant by "views" above was whether we could perhaps create a service from Ursa Major that would allow a user to grab modified repodata
17:14:53 <nirik> heh. I suppose this is a way to get mattdm's rename of everything. ;)
17:14:56 <mboddu> threebean: elsewhere
17:15:19 <threebean> mboddu: ok - I guess I don't follow.
17:15:27 <mboddu> I guess koji can handle this (at least I hope it does)
17:15:28 <mizdebsk> neither do i
17:15:41 <sgallagh> So essentially, they would say to ursa major: "I want the buildroot, but with nodejs:6" and it would give back repo XML that provides the correct RPMs
17:16:13 <threebean> sgallagh: yeah, that's not what ursa-major's doing.  it's not something you can make runtime requests on.
17:16:16 <mboddu> threebean: People who are consuming out buildroot repos and using their tools to build anything on top of our stuff, I dont think their toolset is good enough to dep solve modules
17:16:33 <mboddu> Again, I am not sure if that is a concern of ours or not
17:16:40 <sgallagh> threebean: Yeah, I'm sure it isn't today. I'm trying to think of ways to solve the third-party problem
17:16:45 <threebean> sgallagh: it just manages some tag inheritance hierarchies in koji in an ongoing sort of way.
17:16:46 <mizdebsk> repos used in koji wouldn't be modular, they would not contain module metadata
17:17:04 <sgallagh> If we could just give information back to other tools to say "Get these RPMs from this repo, those ones from this other repo"...
17:17:10 <mizdebsk> (i am talking about this in more detail in the ticket)
17:17:29 <nirik> sure, but we don't want to tell everyone in the world... just hit our koji, it's fine, we have infinite bw.
17:17:36 <threebean> mizdebsk++ thanks for that.
17:17:36 <zodbot> threebean: Karma for mizdebsk changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:17:57 <mizdebsk> nirik, we can have a buildroot compose, with signed, mirrored packages
17:18:12 <threebean> nirik: yeah, that's why I liked mizdebsk buildroot compose.  yes.  :p
17:18:14 <mizdebsk> containing the same contant as koji build repos
17:18:23 <nirik> mizdebsk: sure, but thats a lot more content for mirrors... but perhaps it would work.
17:18:48 <mizdebsk> it could be in alt or somewhere not mirrored by most of mirrors
17:18:56 <smooge> mizdebsk, if mirrors want it.. mirrors are getting grumpy at how much we have loaded on them. We lost our biggest EU mirror because of the growth of Fedora in the last year
17:19:15 <smooge> mizdebsk, if it is on alt then it is as good as just going to koji
17:19:32 <mizdebsk> except that it is signed
17:19:36 <mizdebsk> but yes, i get the point
17:19:38 <nirik> hum, how to handle released fedoras?
17:20:02 <mboddu> nirik: released fedoras?
17:20:05 <nirik> would have to recompose that every updates push?
17:20:18 <mboddu> nirik: Ahh, right, good point
17:20:19 <mizdebsk> yes, every updates push
17:20:28 <nirik> ugh ,that would be a great pain.
17:20:53 <mizdebsk> i know... not saying this is a perfect solution, but some idea for further discussion
17:21:06 <smooge> what is the amount of time to do a compose? I have seen 12 hours
17:21:27 <mizdebsk> buildroot one? very short
17:21:35 <nirik> well, 8-10... but thats entire rawhide.
17:21:38 <nirik> with all images, etc.
17:21:43 <mboddu> threebean: How hard is it to get the tooling ready to make a runtime buildroot with particular modular builds?
17:21:51 <sgallagh> smooge: The compose wouldn't need to have ISOs, etc. So not AS long
17:22:18 <nirik> note: koji doesn't do multilib in buildroots, but these might need it?
17:22:23 <smooge> but does that mean rewriting parts of the compose to not do that because it has been assumed that they were needeD?
17:22:33 <mizdebsk> nirik, no, no multilib is needed
17:23:04 <mizdebsk> you want buildroot compose to be as close to koji as possible
17:23:05 <threebean> mboddu: a runtime buildroot?  i don't think its hard.  we would define a ursa-major config and give it a run with the list of module builds.
17:23:32 <nirik> so how can you build 32bit stuff with it?
17:24:12 <mizdebsk> use 32-bit compose
17:24:15 <nirik> also note that koji does them fast because it just updates and has all the packages handy/doesn't move them... copying around many hundreds of thousands of packages will take a bit.
17:24:51 <mizdebsk> i'm pretty sure pungi doesn't have to copy packages
17:25:19 <nirik> wel,l it hardlinks them, but that takes time.
17:25:39 <mizdebsk> hardlink or symlink
17:25:55 <nirik> no, we cannot use symlinks. all mirrors do not support them.
17:26:20 <mizdebsk> true, (i was thinking about pungi only)
17:27:33 <nirik> I wonder... could we make a 'virtual' repo?
17:27:34 <mizdebsk> then maybe we can create koji dist-repo and cache it?
17:27:51 <mizdebsk> content would be signed, and we would use koji ability to create repos fairly quickly
17:28:04 <nirik> has all the repodata, but just points to modular/nonmodular rpms already mirrored.
17:28:17 <sgallagh> nirik: Isn't that basically what I was proposing above?
17:28:22 <nirik> I do not want us to be a single point of failure for everyone building anything
17:28:25 * mboddu has no idea of virtual repo
17:28:37 <nirik> sgallagh: yeah, I guess so...
17:29:17 <nirik> will that work? I don't know for sure.
17:30:21 <nirik> I guess the path's might be a problem...
17:30:45 <mizdebsk> i think it should work, but requires new code development
17:31:12 <nirik> then it could just be a small thing at the end of composes and very little mirror space...
17:31:38 <mizdebsk> although no, some packages in koji buildroots are never pushed to mirrors
17:31:41 <mizdebsk> like buildroot overrides
17:31:54 <nirik> thats fine...
17:32:10 <sgallagh> nirik: That plan would assume that we have a single possible buildroot; it doesn't allow people to build against non-default streams without doing their own local work.
17:32:12 <nirik> I don't think people expect those
17:32:15 <mizdebsk> so it would have to be a compound repo, with some (most) of packages pointed to mirrors, and some to another place (koji, or alt space on mirrors etc)
17:32:22 <sgallagh> I think that's a perfectly reasonable constraint, but I wanted to point it out
17:32:45 <nirik> mizdebsk: they don't today have buildroot overrides... I don't think we need to enhance things for that
17:33:17 <nirik> sgallagh: perhaps whatever tool we make to do this could be flexable enough for people to adjust it for those cases?
17:33:18 <mizdebsk> then you can treat modules as buildroot overrides and be done with it :)
17:33:40 <sgallagh> nirik: I think that path is better solved by Weldr and we should remove it from consideration here.
17:33:47 <sgallagh> I just wanted it to be a conscious decision :)
17:33:54 <nirik> buildroot overrides assume the promise that you will have the thing in the main repo when you are done/stable. IMHO
17:34:18 <mizdebsk> not all overrides
17:34:32 <sgallagh> Actually, thinking through it, default-stream-only is the only sane approach
17:34:37 <mizdebsk> the ones used for bootstrapping should never reach mirrors
17:34:55 <sgallagh> We don't want anything ending up in the main repo with a runtime dep on a non-default stream
17:34:58 <mizdebsk> so you can't reproduce all fedora builds from mirrored content only
17:34:59 <nirik> sure, or glibc32, but thats nitpicking
17:36:19 <nirik> another alternative might be:
17:37:16 <nirik> have a tool / webthing / whatever that tells you what repo(s) you need to enable for BuildRequires. That would solve the copr/osbs case perhaps... just add more repos/remotes...
17:37:46 <mizdebsk> what repos would that be?
17:38:18 <sgallagh> nirik: Just adding repos doesn't necessarily work
17:38:38 <nirik> the modular ones... but yeah, if the repodata isn't the same there that won't work
17:38:39 <sgallagh> Actually... hmm
17:38:55 <sgallagh> I suppose we can kind of solve some of the problems with policy
17:39:14 <sgallagh> (If a module provides a default stream, none of its produced artifacts may also exist in the non-modular repos)
17:39:48 <nirik> then just dump them into Everything?
17:39:56 <nirik> (the rpms, not the modules)
17:40:20 <nirik> no, that would cause a lot of confusion...
17:40:48 <sgallagh> nirik: That's actually something I proposed a while back. I forget why it didn't end up happening.
17:41:31 <mizdebsk> that would not solve all the problems that ursa-major does
17:41:31 <nirik> and I guess dnf now would not install those, it would enable and install the module and ignore those?
17:42:21 <sgallagh> nirik: Right
17:42:28 <sgallagh> mizdebsk: Which problems does it miss?
17:42:46 <mizdebsk> modules in buildroot that don't have default streams
17:42:59 <mizdebsk> (or are not even shipped to users at all, like javapackages-tools module)
17:43:08 <sgallagh> mizdebsk: As I indicated above, I think we should take that off the table.
17:43:26 <nirik> well, mizdebsk needs that tho..
17:43:41 <mizdebsk> ack, but that solves nothing from my pov, just saying
17:43:53 <mboddu> I might be thinking out loud here, can we do a module build root override (kinda thing) and create the buildroot on the fly and use that buildroot to build the necessary modules and kill the buildroot once its done?
17:44:06 <sgallagh> mizdebsk: Maybe so, but I'm looking for where we can improve most with the least effort.
17:44:55 <sgallagh> I think if we constrain ourselves to "anything built against Fedora must run against the packages available in Fedora without having to activate any modules", then we can get something done relatively easily.
17:45:45 <sgallagh> mizdebsk: And I think we should be looking at ways to produce a default stream for those modules that make sense.
17:46:18 <sgallagh> mboddu: "build the necessary modules"?
17:46:34 <sgallagh> We're talking about doing non-modular builds that rely on modular buildrequires
17:47:39 <mboddu> sgallagh: Sorry, but we can build anything, modular or non modular
17:47:59 <sgallagh> mboddu: That's the spirit!
17:48:04 <sgallagh> ;-)
17:48:29 <nirik> ha. So, perhaps we should discuss this more and come up with a plan for next week/out of meeting?
17:48:40 <nirik> is there anyone who has cycles to work on tooling?
17:49:50 <sgallagh> Unclear from my end. My priority queue changes on an hourly basis :-/
17:49:57 <nirik> 🦗s
17:50:52 <sgallagh> If the first-pass solution we settle on is "dump default stream RPMs into Everything", I can probably talk Paul into giving me a few days to help with that.
17:51:01 <sgallagh> Much more complicated solutions will probably need an SME
17:51:02 <mboddu> threebean: ^ I saw tooling ;)
17:51:03 <mizdebsk> i think i can help with the tooling, as song as the design solves my needs as a packager - otherwise i have too much work maintaining packages
17:51:06 * mboddu hides from threebean
17:51:24 * nirik kinda likes the idea of a 'virtual' buildroot repo we make and publish
17:51:45 <sgallagh> nirik: Would you have the cycles to put together a straw-man proposal for how that might work?
17:51:47 <nirik> mizdebsk: fair
17:52:05 <mboddu> mizdebsk: Understandable
17:52:14 <mizdebsk> nirik, this one should be easy-enough to implement, if you don't want buildroot overrides in the repo, and i can work on this
17:52:19 <mizdebsk> it does solve my problem
17:52:21 <nirik> I can try and write something up sure... perhaps we can rope pungi folks into implementing. ;)
17:52:29 <nirik> or mizdebsk. ;)
17:52:42 <mboddu> Thanks nirik
17:53:20 <mizdebsk> nirik, it's just about figuring out packages in koji repo, using koji api calls only, at exact event when compose was ran (to make sure these packages are in compose)
17:54:14 <nirik> well, I was thinking it could be part of pungi and it could have most of that info already when it made repos... but yeah, I guess it could call koji at the end?
17:55:16 <sgallagh> mizdebsk, nirik: I'd be willing to help (with code review if nothing else).
17:55:32 <nirik> lets see first if everyone else agrees with the idea, but great
17:55:34 <sgallagh> I've been dabbling in Pungi a bit this last year, so I wouldn't be coming in totally fresh
17:55:45 <mboddu> I am happy to help with anything that is required
17:58:07 <mizdebsk> are there any other blockers for ursa-major, other than users being ably to easily rebuild packages?
17:58:35 <mboddu> mizdebsk: Not that I know off
17:58:56 <mboddu> #info nirik will write up a proposal on how to solve this and if everyone agrees then we will look into the tooling work
17:59:08 <mboddu> nirik: ^ Is that okay or you wanna reword it?
17:59:25 <nirik> sure.
18:00:24 <sgallagh> Thanks, nirik
18:00:31 <mboddu> nirik: Thanks
18:00:55 <mboddu> nirik: Also, sorry we were able to cover only one thing today, lets take the remaining to next week?
18:01:18 <nirik> https://pagure.io/releng/issue/7840#comment-533905 if anyone wants to correct me or whatever.
18:01:22 <nirik> mboddu: sure.
18:01:27 <nirik> unless it's super urgent
18:01:45 <mboddu> nirik: Well, I guess one is dnf and the other is torrent that can wait
18:02:10 <mboddu> nirik: https://pagure.io/releng/issue/7827 is the one that I wanted to bring up
18:02:13 <nirik> what did dnf do now? or do I even want to know. ;)
18:02:43 <mboddu> nirik: Its something that you already know
18:02:56 * mboddu wondering what we should do about it
18:03:38 <nirik> ah yeah, this. basically we need a way to tell these modules from the 'normal' ones and dont tag these into any shipping tag
18:05:11 <nirik> I guess we need to answer the questions in the last comment there
18:05:34 <mboddu> nirik: Yes, which is what I wanted to discuss
18:06:00 <nirik> might be we should get bowlofeggs to weigh in...
18:06:44 <nirik> right now I think they could be bodhi updates... but the problem is that eariler in the cycle they just go out before we enable bodhi.
18:07:36 <mboddu> nirik: Yeah, thats the problem until bodhi is enabled, we need a separate check for it, probably as part of compose (just before starting the compose)
18:08:04 <mizdebsk> i think the issue with flatpak vs non-flatpak modules could be solved by mbs change
18:08:29 <nirik> yeah, lets cc bowlofeggs and jkluza? and continue in ticket...
18:08:33 <mizdebsk> https://pagure.io/fm-orchestrator/issue/974
18:08:49 <mizdebsk> depending on runtime requires module would be tagged into different candidate tags
18:09:53 <mboddu> mizdebsk: But I thought that is on hold
18:10:06 <mboddu> nirik: Okay
18:10:44 <mizdebsk> perhaps it is, but it is one change that would fix several different issues
18:11:02 <mboddu> mizdebsk: Yeah, that is true
18:11:20 <mizdebsk> so instead of a flatpak-specific fix maybe this change should be pushed instead?
18:11:40 <mboddu> mizdebsk: +1, I can comment on the ticket, thanks
18:13:12 <mboddu> So, thanks everyone for joining
18:13:20 <mizdebsk> thank you
18:13:25 <mboddu> Sorry, it got a bit a late
18:13:41 <mboddu> Catch you all, if not some, next week
18:13:44 <mboddu> #endmeeting