14:00:54 <nils> #startmeeting modularity_wg
14:00:54 <zodbot> Meeting started Tue May 15 14:00:54 2018 UTC.
14:00:54 <zodbot> This meeting is logged and archived in a public location.
14:00:54 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:54 <zodbot> The meeting name has been set to 'modularity_wg'
14:00:54 <nils> #meetingtopic Meeting of the Modularity Working Group (once every two weeks)
14:00:54 <nils> #chair dgilmore mikedep333 tflink
14:00:54 <zodbot> Current chairs: dgilmore mikedep333 nils tflink
14:01:02 <nils> #topic Roll Call
14:01:11 <contyk> .hello psabata
14:01:12 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:01:22 <nils> I always need to find where to copy and paste that blurb from :)
14:01:27 <nils> .hello nphilipp
14:01:29 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:01:51 <contyk> add a macro to your client
14:02:03 <nils> mhm
14:02:10 <dgilmore> hi
14:02:10 <nils> the pain isn't strong enough yet :)
14:02:55 <tflink> .hello2
14:02:56 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
14:03:26 <nils> Does anybody have anything for the agenda? The issue tracker is empty.
14:03:30 <asamalik> .hello2
14:03:31 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:03:45 <bowlofeggs> .hello2
14:03:46 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
14:04:51 <nils> The sound of crickets can be soothing. :)
14:04:51 <langdon> weird.. i was connected but not connected :/
14:04:53 <langdon> .hello2
14:04:54 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:05:00 <nils> #chair langdon
14:05:00 <zodbot> Current chairs: dgilmore langdon mikedep333 nils tflink
14:05:28 <contyk> langdon: try connecting next time!
14:05:38 <langdon> contyk: thanks!
14:05:43 <nils> Schrödinger's Connection.
14:05:54 <langdon> nils: i looked in the box...
14:06:17 <langdon> do we have any agenda?
14:06:28 <nils> as of now it's empty
14:06:52 <contyk> I only have one little thing, probably for open floor
14:06:58 <langdon> oooo
14:07:01 <nils> Then let's start with that.
14:07:05 <nils> #topic Agenda
14:07:07 <langdon> anyone else have anything
14:07:08 <nils> #info Open Floor
14:07:12 <nils> #topic Open Floor
14:07:16 <nils> #chair contyk
14:07:16 <zodbot> Current chairs: contyk dgilmore langdon mikedep333 nils tflink
14:07:42 <contyk> so geppeto noticed that while we have a few modules in Fedora, we don't define defaults for almost any of them
14:07:46 <bowlofeggs> what is on the horizon for modularity that will require changes in fedora infra?
14:08:02 <nils> contyk, I noticed that I don't know how to define that, too
14:08:04 <contyk> defaults allow you to make packages in your module:stream available by default, without the need to explicitly enabled the module
14:08:15 <langdon> bowlofeggs: lets do that next?
14:08:21 <bowlofeggs> sure
14:08:25 <contyk> they also allow you to label certain installation profiles as default even when the module itself isn't enabled
14:08:26 <bowlofeggs> sorry i was typing at the same tim e;)
14:08:40 <langdon> contyk: did the docs for "new modules" get updated while i was at summit?
14:08:46 <langdon> bowlofeggs: i know the feeling
14:08:54 <contyk> langdon: nope, they were updated even before you left
14:09:03 <contyk> asamalik did that, I believe
14:09:20 <langdon> contyk: and defaults aren't a part of that?
14:09:24 <asamalik> langdon, they are
14:09:26 <contyk> they are
14:09:34 <asamalik> do we really have something that should be a default?
14:09:41 <nils> just to clarify, that includes default streams, right?
14:09:46 <asamalik> I'm under the impression that majority of the modules are just alternative versions
14:10:02 <contyk> it's a good idea to mark your profiles as default even if you don't want to mark any stream
14:10:13 <langdon> contyk: +1
14:10:13 <contyk> for the sake of ux
14:10:20 <asamalik> if my memory isn't betraying me, we decided not to modularize the default fedora packages some time ago?
14:10:34 <langdon> asamalik: well.. the maintainer can decide
14:10:34 <asamalik> contyk, ah profiles, not streams :)
14:10:58 * asamalik is confused
14:10:59 <contyk> it's all in one place
14:11:03 <langdon> would it make sense to consider an "empty module" indicating that the default is in regular rpms?
14:11:26 * asamalik read "defaults" and was thinking about streams automatically
14:11:36 <nils> asamalik, I think it would be good if say for two alternative streams one is marked as default so "dnf module install thatmodule" doesn't surprise you
14:11:37 <contyk> langdon: not sure I see the point there
14:11:41 <asamalik> langdon, even just for the UX? yes
14:11:42 <langdon> i would rather people were even doing their default rpms as default modules
14:11:48 <langdon> contyk: for UX
14:12:01 <contyk> langdon: you mean having an empty defaults doc, not an empty module?
14:12:12 <asamalik> like "what versions of $thing we have here?"
14:12:17 <asamalik> dnf module list shows 1
14:12:23 <contyk> langdon: in that case yes -- that's why the stream is optional and we have defaults for django that doesn't define any default stream, yet it still defines profiles
14:12:31 <asamalik> and dnf list | grep $think probably shows the other if I'm lucky
14:12:38 <langdon> contyk: no.. well.. maybe.. something like "dnf module list" would show "postgres 9.6 = rpms" and "postgres 10 = module"
14:12:41 <asamalik> think -> thing
14:12:42 <asamalik> :)
14:13:10 <langdon> i think dnf list lost modules somewhere
14:13:13 <contyk> there's no sensible way to achieve that
14:13:18 <nils> I don't think "dnf module list" reports anything about content outside modules
14:13:43 <langdon> contyk: you are sooooo limiting
14:13:59 <asamalik> so maybe without being too specific.. the question could be: can we come up with a mechanism to list alternative versions of stuff?
14:14:09 <langdon> asamalik: yeah
14:14:16 <langdon> dnf list used to have both
14:15:28 <asamalik> so do we want to make an action and move on?
14:15:43 <langdon> asamalik: sure
14:15:46 <praiskup> langdon, what did you mean by "postgres 9.6 = rpms" vs "postgres 10 = module"?
14:16:06 <nils> praiskup, I guess he means one postgres that comes from bare RPMs and one out of a module?
14:16:11 <langdon> praiskup: "dnf list *postgres*" would show two versions, one in rpms and one in a module
14:16:28 <nils> langdon, but it would still refer to the package, right?
14:16:32 <nils> in both cases
14:17:18 <langdon> nils: well.. it should list both
14:17:32 <langdon> and it used to
14:18:30 <asamalik> praiskup, I think we don't need to come up with a solution here... but the basic problems is: there is no easy way to ask "what versions of postgresql are available for me?"
14:18:34 <nils> langdon, so it should list both the package and the module if they have the same name, like postgresql:10 and postgresql-10.0-...?
14:18:57 <langdon> asamalik: exactly
14:19:06 <langdon> asamalik: want to write an action?
14:19:23 <langdon> nils: essentially, yes.. but the versions would likely be different
14:19:52 <contyk> I'm very limiting but again, there's no sensible way to do this :)
14:20:07 <contyk> you want to compare module names with package names, while modules are collections of things with potentially unrelated names
14:20:34 <contyk> yes, you could make those empty modules
14:20:40 <contyk> but that would just be confusing
14:20:48 <contyk> and adds extra maintainer overhead
14:21:43 <langdon> yeah.. i just go back to that stef mantra of "why would you keep doing rpms".. i wonder if the problem is cli.. in a sense.. we have too much information for a cli tool to usefully provide all the information you need
14:23:38 <contyk> if you want an action -- what would it be?
14:23:51 <asamalik> #action asamalik figure out how we could ask [dnf?] "what version of $thing is available on my system" when one version is standard RPMS and the other one is a module
14:24:03 * linuxmodder sneaks in late
14:24:23 <asamalik> nils, was that the right way to do it?
14:24:24 <nils> #chair asamalik
14:24:24 <zodbot> Current chairs: asamalik contyk dgilmore langdon mikedep333 nils tflink
14:24:28 <nils> now it would be
14:24:34 <nils> you need to be a chair AIUI
14:24:42 <langdon> asamalik: that would solve the simple problem.. i think contyk you are looking at the general answer..  which is also important.. but we might be able to get to an incremental improvement
14:24:49 <langdon> nils: correct
14:24:56 <nils> (so just re-send the line)
14:25:36 <linuxmodder> dnf list available does that
14:25:48 <linuxmodder> dnf list available | grep foo more specifically
14:25:52 <asamalik> langdon, can you elaborate? I'm not talking about nor hinting a solution.. just pointing out a problem
14:25:52 <asamalik> #action asamalik figure out how we could ask [dnf?] "what version of $thing is available on my system" when one version is standard RPMS and the other one is a module
14:25:54 <langdon> linuxmodder: doesn't include modules (to my knowledge)
14:26:19 <linuxmodder> langdon,  as in metapackages for modules?
14:26:33 <langdon> asamalik: so.. $thing in your sentence.. must be "postgres" not "random item in a module collection" (eg docker in container-tools)
14:26:36 <contyk> no idea what you'd show as an alternative to the upcoming javatools module that includes hundreds of generic java tooling components
14:26:43 <nils> langdon, linuxmodder: it looks as if it just filters out the modular or non-modular content depending on what is enabled
14:26:54 <contyk> I don't think having some partial package name-based solution makes sense
14:27:18 <nils> I have gimp:2.10 enabled on my system and can't see the gimp-2.8.22 packages from non-modular Fedora.
14:27:23 <asamalik> contyk, so I think this won't work for all or would be automatic
14:27:28 <linuxmodder> dnf --disablerepo=* --enablerepo=modular --enablerepo=modular-testing list available | grep docker should work
14:27:32 <asamalik> but we *know* that there are two versions of postgresql
14:27:38 <asamalik> we know what the versions are
14:27:58 <linuxmodder> or evne aliasing that to | dnf list installed
14:28:11 <asamalik> I believe we can somehow show them together
14:28:13 * langdon waits for fedora-repos-modular to install
14:29:21 <linuxmodder> so something like sudo dnf --disablerepo=* --enablerepo=modular --enablerepo=modular-testing list available | grep foo > modular.stdout | dnf list installed > installed-modules.txt
14:29:27 <langdon> maybe we just file an issue? or punt for the moment
14:30:06 <linuxmodder> or ideally create a metapackage or module that handles that in a module registry wide way
14:30:26 <langdon> dnf --disablerepo=* --enablerepo="fedora-modular" --enablerepo="updates-modular" list available | grep docker only works if container-tools is enabled
14:31:00 <langdon> probably because dnf is explicitly hiding rpms from not enabled modules
14:31:13 <contyk> it is, yes
14:31:29 <contyk> which, I think, was done on purpose
14:31:57 <contyk> otherwise you saw several builds of the same thing, if it was included in a number of modules and contexts
14:32:02 <contyk> that was consider bad ux
14:32:06 * asamalik senses a rat hole 🐀
14:32:08 <langdon> well.. to the earlier point.. i think we may just want to open the discussion of the problem
14:32:37 <asamalik> langdon, +1
14:32:52 <langdon> maybe we just file an issue.. against modularity
14:33:04 * asamalik wants to give some time to bowlofeggs as well
14:33:13 <bowlofeggs> \o/
14:33:56 <nils> asamalik, is this covered by your #action?
14:34:52 <langdon> nils: i think we should just file an issue..
14:34:55 <asamalik> nils, I believe it is.. we could make it more explicit that we want to discuss first, but I feel like that's not needed
14:35:16 <nils> cool, then we're done here and it's bowlofeggs' turn?
14:35:45 <bowlofeggs> ...?
14:35:54 <langdon> +1
14:35:58 <nils> good
14:36:02 <nils> bowlofeggs, you're on
14:36:04 <nils> #chair bowlofeggs
14:36:04 <zodbot> Current chairs: asamalik bowlofeggs contyk dgilmore langdon mikedep333 nils tflink
14:36:28 <bowlofeggs> cool. so we (infra) were talking and we thougth it'd be good for one of us to work with the modularity WG so we can know what's coming out way
14:36:41 <bowlofeggs> and so i volunteered to be the modularity infra bro
14:37:20 <bowlofeggs> my only question for today is whether there are more expected requirements from infrastructure on the horizon
14:37:25 <contyk> so this is mostly for the factory guys
14:37:38 <contyk> but there's this one project that has yet to be discussed
14:37:56 <contyk> it's a service that pulls modules into the non-modular buildroot, for a select, whitelisted few
14:38:22 <contyk> it allows people to modularize their content even if stuff that depends on them at build time isn't modular
14:38:31 <bowlofeggs> is this something factory 2 is building?
14:38:35 <contyk> yes
14:38:52 <langdon> how does fedora-infra connect with f2?
14:39:06 <bowlofeggs> so infrastructure will need to deploy it/maitain it/audit it/etc
14:39:12 <bowlofeggs> good to know - i wasn't aware of that
14:39:24 <contyk> they call it ursa major
14:39:26 <langdon> i wonder if it would be better for f2 & modularity to meet with infra perhaps at the infra meeting periodically
14:39:28 <bowlofeggs> langdon: i don't know that we have a formal connection with f2
14:39:44 <bowlofeggs> yeah that could be wise
14:39:51 <langdon> well.. 99% of "what is coming from modularity" will be through f2
14:40:09 <bowlofeggs> i seem to recall that there were going to be more bodhi changes
14:40:16 <langdon> so maybe add f2 and modularity to the infra agenda ~once a month?
14:40:22 <contyk> we're also working on a new solver for pungi + repoclosure
14:40:26 <bowlofeggs> langdon: +1
14:40:37 <contyk> it should be much faster and module-aware
14:40:51 <bowlofeggs> isn't there some kind of "stream expansion" thing that needs changes in bodhi?
14:41:15 <linuxmodder> stream or string ?
14:41:18 <contyk> possibly! though I thought bodhi has support for contexts already
14:41:18 <bowlofeggs> would f2 know about the bodhi/stream exapansion thing too?
14:41:24 <contyk> linuxmodder: stream
14:41:39 <contyk> bowlofeggs: they would
14:41:59 <contyk> bowlofeggs: stream expansion has two sides
14:42:03 <bowlofeggs> contyk: i think bodhi has some minimal knowledge of contexts, but i feeeel like something about the way it is doesn't meet the end goal that modularity wg has for stream expansion
14:42:08 <bowlofeggs> i don't nkow enough about it to say more than that :(
14:42:27 <contyk> one is at build, where you can build one module input multiple times against different buildroots, getting a number of different artifacts that either have the same runtime deps or differ in runtime deps
14:42:59 <contyk> another is runtime only -- build once and have a kind of a rich dependency that declares that the module is compatible with N of other modules in various combinations
14:43:36 <contyk> in structured data, context is name+stream+version+buildtime/runtime-deps
14:43:50 <contyk> stringified context is a hash of the deps
14:44:14 <bowlofeggs> is somethng about this not supported today due to bodhi?
14:44:30 <contyk> bowlofeggs: you probably know that better than I do :)
14:44:33 <bowlofeggs> hahah
14:44:43 <bowlofeggs> i think i know who i can talk to to find out more
14:44:46 <bowlofeggs> cool
14:45:04 <bowlofeggs> well i'm happy to try to link with with factory 2
14:45:05 <contyk> MBS is supposed to tag module builds into the updates-testing tags
14:45:24 <contyk> it understands these things and should distribute the artifacts accordingly
14:45:29 <bowlofeggs> contyk: are you sure about that? i woudl think only bodhi would do that?
14:46:06 <contyk> bowlofeggs: yes, this is definitely happening, at least partially; possibly still being developed to be smarter
14:46:23 <bowlofeggs> that is quite strange to me - what moves them to stable then?
14:46:42 <contyk> bowlofeggs: bodhi does but MBS should land them in some input tag for bodhi
14:47:04 <contyk> bowlofeggs: factory will tell you more, yeah
14:47:05 <bowlofeggs> contyk: ahhh - i think the input tag probably isn't updates-testing - it should be updates-candidate or something like that
14:47:09 <bowlofeggs> that's why i was confused
14:47:17 <bowlofeggs> updates-testing means bodhi has an update already
14:47:27 <contyk> bowlofeggs: apologies; yes, some candidate definitely
14:47:29 <bowlofeggs> cool
14:47:36 <bowlofeggs> yeah i'm with you now
14:47:52 * linuxmodder know wishes he didn't get so sidetracked from infra and modularity stuff months ago :(
14:47:53 <bowlofeggs> ok well i'm satisfied with the proposal to try to get involved with factory2 + modularity + infra
14:48:15 <contyk> linuxmodder: there there
14:48:22 <linuxmodder> contyk, ??
14:49:03 <linuxmodder> or even modular-testing ?
14:49:28 <contyk> yes, a modular testing candidate thingy
14:50:10 <langdon> contyk: now you sound like me :)
14:50:34 <contyk> I'm too lazy to look up the actual tag name :)
14:51:01 <asamalik> :)
14:51:43 <bowlofeggs> the actual tag name is f28-modular-updates-candidate: https://bodhi.fedoraproject.org/releases/F28M
14:52:28 <bowlofeggs> (bodhi's "input" tag, called a "candidate tag")
14:53:12 <langdon> more to discuss here? contyk, anything else you can think of in the pipe?
14:53:36 <contyk> just ursa major and the new solver coming in a few weeks
14:53:47 <bowlofeggs> nothing from me
14:53:48 <bowlofeggs> thanks!
14:54:07 <bowlofeggs> (ursa major is the new f2 service's name?)
14:54:08 <linuxmodder> solver is for pungi4 ?
14:54:12 <linuxmodder> or dnf
14:54:13 <asamalik> probably nothing from me either
14:54:39 <contyk> linuxmodder: it's for the currently existing pungi; not sure about the version
14:54:40 <langdon> bowlofeggs: no.. one of the apps
14:54:50 <bowlofeggs> ah
14:54:50 <contyk> the plan is to allow a configuration switch to choose the old or the new solver
14:54:56 <linuxmodder> in 27 and 28 that is pungi4 so cool
14:55:01 <langdon> bowlofeggs: iirc the thing that puts both a module and rpms in to the same compose
14:55:07 <asamalik> just maybe a positive feedback: I've been to RH Summit last week and people liked Modularity in F28 and I got much more positive response now when it's real than before, so yay I guess
14:55:14 <langdon> but now i am 2nd guessing myself
14:55:21 <langdon> summit broke my brain
14:55:24 <contyk> the new solver will be capable of properly solving hybrid repositories (modules and non-modular rpms on one pile), search dependencies in default streams and prioritize the modular content where applicable
14:55:29 <linuxmodder> contyk,  pls keep me updated on that progress, including any testing/bugzilla's feel free to add me
14:55:48 <contyk> linuxmodder: will keep that in mind
14:56:20 <linuxmodder> I ask partly as an infra ( passive ) and respins/freemedia SIG member
14:56:42 <nils> .oO(... 3 minutes and change left ...)
14:56:49 <langdon> contyk: ursa major does... ?
14:56:50 <linuxmodder> as in Respins we use pungi for the respins source images
14:57:12 <contyk> langdon: pulls modules into ursine buildroot
14:57:22 <langdon> contyk: ahh right.. i was close
14:58:02 <langdon> bowlofeggs: it makes it so you can dep on content in a module at build time.. so a "default module" can be the only version of  something even if other things in the rpm part of the distro depend on it to build
14:58:47 <bowlofeggs> cool
14:58:48 <bowlofeggs> thanks
14:59:20 <contyk> we haven't had a meeting like this in a while :)
14:59:27 <contyk> two minutes left
14:59:29 <nils> :)
14:59:33 <langdon> bare -> bear -> ursine/ursa/bruin/etc :)
14:59:40 <langdon> bowlofeggs: ^^
14:59:41 <contyk> medved
14:59:49 <nils> maybe next time we even have an agenda ahead of time! *hint*
14:59:51 <nils> :D
15:00:01 <langdon> contyk: ha.. i was gonna use that the other day but wasn't sure how much the accents mattered
15:00:06 <langdon> nils: pfft
15:00:16 <nils> :P
15:00:39 <nils> so are we done?
15:00:42 <langdon> i think so
15:00:46 <nils> good
15:00:51 <nils> thanks everybody!
15:00:54 <nils> #endmeeting