14:03:43 <langdon> #startmeeting modularity_wg
14:03:43 <zodbot> Meeting started Tue Sep 19 14:03:43 2017 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:43 <zodbot> The meeting name has been set to 'modularity_wg'
14:03:56 <langdon> #meetingtopic Meeting of the Modularity Working Group (once every two weeks)
14:04:02 <langdon> #chair cydrobolt dgilmore haraldh langdon mikedep333 sct tflink
14:04:02 <zodbot> Current chairs: cydrobolt dgilmore haraldh langdon mikedep333 sct tflink
14:04:07 <asamalik> .hello2
14:04:08 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:04:10 <langdon> #topic Roll Call
14:04:15 <langdon> .hello2
14:04:16 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:04:24 <langdon> do i have to do that if i start the meeting?
14:04:43 * asamalik will be back in 2 minutes
14:04:56 <contyk> .hello psabata
14:04:57 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:05:07 <tflink> .hello tflink
14:05:07 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
14:05:15 <geppetto> .hello james
14:05:16 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
14:06:20 <langdon> #agenda
14:06:27 <langdon> #topic agenda
14:06:28 <langdon> oops
14:06:40 <langdon> ok.. nothing in the etherpad.. but i was planning on giving a status update
14:06:46 <langdon> anyone else have stuff?
14:06:47 * asamalik is back
14:07:07 * langdon waves at asamalik
14:07:24 * asamalik waves back at langdon
14:07:51 <langdon> tick tock
14:07:53 <asamalik> langdon: we have discovered a new issue preventing us build modules that build-require bootstrap and something else.. do we want to talk bout that?
14:08:05 <langdon> asamalik: sure
14:08:21 <langdon> i am not sure there is much to say though ;)
14:08:45 <jkaluza> what issue?
14:08:54 <langdon> let's hold for a min
14:08:58 * contyk thinks it's a non-issue
14:09:08 <langdon> ok.. let's starts with asamalik's topic.. then stat rep
14:09:11 <asamalik> langdon: we could temporarily revert that change.. let's talk about it at least.. we can decide it's a non issue for sure
14:09:45 <langdon> #topic when build-requireing bootstrap, nothing else can cascade to build-require anything that conflicts
14:09:48 <langdon> hows that?
14:10:24 <asamalik> langdon: I think that fine
14:10:25 <langdon> one comment i have on this is, would be nice if we could make this a "warn" rather than an error
14:10:48 <contyk> that's not really possible, it fails on rpm level
14:10:50 <asamalik> langdon: it's not a check, it's an actual error
14:10:54 <langdon> like find a way for mbs to do the "right" thing.. and just notify that it may not be the result you want
14:11:03 <asamalik> so is that topic active, or is it just added to the agenda?
14:11:08 * asamalik is not slow, he's just taking a while
14:11:09 <langdon> active
14:11:11 <asamalik> ha
14:11:14 <asamalik> so let me introduce
14:11:15 <langdon> well.. it could just ignore the request to include it again
14:11:25 <langdon> ok.. you go asamalik
14:11:56 <asamalik> it's a useful fix we have been waiting for.. when I require (or build-require) a module, I had to list all its dependencies as well which was annoying
14:12:10 <asamalik> now I can just add the modules I need and their deps get pulled in automagically
14:12:13 <asamalik> which is good, but
14:12:27 <contyk> ^ this is only about build deps
14:12:36 <asamalik> contyk: ok, thanks
14:12:38 <asamalik> everything depends on platform, and platform conflicts with bootstrap
14:13:05 <asamalik> so if I build-require i.e. perl and bootstrap, platform gets pulled in as well because perl needs it, and it conflicts
14:13:13 <contyk> correct
14:13:22 <contyk> question: why do you buildrequire perl and bootstrap?
14:13:56 <asamalik> so while this is better in many cases, it prevents us from doing some builds that build-require bootstrap and something else
14:14:15 <asamalik> karsten: ^^
14:15:06 <contyk> so far it sounds like you would to revert an MBS bugfix that reveals a bug in your packaging
14:15:17 <langdon> i guess my point here is, you are relying on a human to keep very careful track of deps and all when the computer could do it better
14:15:22 <jkaluza> contyk: How does it conflict? I mean which rpm conflicts with which? shouldn't it get the latest available into buildroot? Or there are some rpm-level conflicts defined "somehow" between packages in platform and bootstrap?
14:15:38 <contyk> jkaluza: fedora-release / fedora-modular-release
14:15:42 <jkaluza> contyk: By a bugfix you mean transitive deps?
14:15:43 <jkaluza> contyk: thanks
14:16:15 <contyk> jkaluza: bootstrap has the standard fedora-release tagged from f27; platform has a custom-built fedora-modular-release
14:16:18 <langdon> ohh.. but don't we have this problem in general? or is this specifically to deal with bootstrap which is wonky
14:16:22 * asamalik can't find any modules in https://github.com/fedora-modularity/dependency-report that would build-require something else than bootstrap
14:16:29 <jkaluza> contyk: yeah, I see know what you mean
14:16:53 <jkaluza> contyk: by reverting bugfix, you mean that transitive deps fix, right?
14:17:11 <contyk> jkaluza: yes
14:17:23 <asamalik> jkaluza: that's what I meant yes..
14:17:26 <langdon> jkaluza: we don't want to do that.. the packaging is "wrong"  but I just wonder if we could have the build system figure it out
14:17:46 <asamalik> but I can't actually see any real example of this... karsten came up by one, but I'm not sure what or why was that
14:17:59 <contyk> asamalik: I think it was a bug
14:18:07 <asamalik> contyk: in the module?
14:18:09 <asamalik> maybe
14:18:10 <contyk> yes
14:18:23 <contyk> I remember people doing this for f26 boltron, a lot
14:18:26 <contyk> I never understood why
14:18:39 <langdon> contyk: doing what exactly?
14:18:47 <contyk> this = buildrequiring bootstrap + five other modules that provide stuff that is already in bootstrap
14:18:59 <langdon> probably to make the module more "correct"
14:19:02 <asamalik> I just wanted to make sure we won't have our builds broken.. but since I can't fine any single one needing this at the moment, I'm tempted to apologize and shut up :)
14:19:11 <asamalik> *find
14:19:12 <langdon> like bootstrap should be special cased..
14:19:52 <contyk> langdon: to answer your question whether the buildsystem could detect this -- it's a nontrivial problem due to the nature of rpm packaging
14:19:58 <karsten> python3-bootstrap was where I run into this issue, it buildrequires bootstrap and perl
14:20:05 <jkaluza> contyk: what pulls both fedora-release and fedora-modular-release in?
14:20:15 <contyk> langdon: you would need to run the rpm transaction for every rpm in every module you're pulling in and compare them against each other
14:20:30 <contyk> karsten: basically anything via a virtual provide
14:20:38 <asamalik> karsten: I can't see that https://github.com/fedora-modularity/dependency-report/tree/master/modules/python3-bootstrap
14:20:57 <contyk> jkaluza: ^^ not for karsten
14:21:56 <jkaluza> contyk: can't  you filter it out from on bootstrap level?
14:22:25 <contyk> jkaluza: if I drop it from bootstrap, nobody who buildrequires just bootstrap will be able to build their module
14:22:51 <jkaluza> contyk: can't you include fedora-modular-release in bootstrap?
14:23:02 <jkaluza> sorry if I'm asking dumb questions
14:23:14 <contyk> jkaluza: I could, but it's a workaround for something I don't consider broken
14:23:26 <contyk> and it would need additional special hacks in our tools
14:23:27 <karsten> asamalik:  http://pkgs.fedoraproject.org/cgit/modules/python3-bootstrap.git/tree/python3-bootstrap.yaml
14:24:08 <langdon> karsten: is that a bug? why does the gen'd version not have it?
14:24:11 <jkaluza> contyk: sure, just trying to find out solution which won't result in removing features from MBS in case people here decides it is broken :)
14:24:28 <asamalik> karsten: but perl is in bootstrap, right contyk? so it's a bug
14:24:29 <langdon> jkaluza: i don't think that is up for discussion..
14:24:35 <jkaluza> langdon: good :)
14:24:43 <contyk> asamalik: yes, it is, both
14:24:49 <jkaluza> langdon: We've done enough MBS updates recently
14:24:52 <langdon> jkaluza: i would just like mbs to "handle" this problem..  :)
14:25:01 <langdon> but contyk tells me im crazy
14:25:09 <karsten> langdon:  I think the yaml file either was heavily edited or not genereated from the README that Adam parses for his report
14:26:07 <asamalik> yeah the only modulemd which has this problem is wrong.. so can we agree it's a non issue?
14:26:27 <langdon> ahh .. could this be the python team & nickc being discoordinated with the rest of modularity
14:26:31 <langdon> ??
14:26:43 <langdon> coghlan... not the other nickc :)
14:26:56 <asamalik> langdon: maybe :) they don't even use that module, because they use bootstrap
14:27:17 <langdon> ok.. so, let's call this a mistake and move on?
14:27:25 <asamalik> I would do that yeah
14:27:25 <contyk> and until recently they were actually using random rpms depending on the order koji inherited from them
14:27:36 <langdon> i think we all agree this is the correct operation..  just bugs
14:27:42 <karsten> asamalik:  no, python3 buildrequires python3-bootstrap
14:28:19 <langdon> both :)
14:28:22 <langdon> http://pkgs.fedoraproject.org/cgit/modules/python3.git/tree/python3.yaml
14:28:28 <asamalik> karsten: they should either only need bootstrap or things other than bootstrap
14:28:43 <karsten> right
14:28:46 <asamalik> according to the report https://github.com/fedora-modularity/dependency-report/blob/master/global_reports/README.md
14:29:03 <asamalik> python3 can build only with bootstrap and is not missing anything in the buildroot
14:29:06 <langdon> yeah.. so .. i think we need to stomp on a bunch of ones in dist-git?
14:29:37 <langdon> actually.. i would rather adam writes a long email to nick and explains whats up
14:29:42 <langdon> and let him make the change
14:29:57 <asamalik> we might want to state somewhere that packagers should use either only bootstrap, or anything other than bootstrap.. and never mix it
14:30:04 <langdon> just so we don't a) accidentally revert when he "fixes" it b) we don't have this problem again
14:30:24 <langdon> asamalik: we can add that guidance to the guidelines
14:30:30 <contyk> what we could do is to add a test that warns you when you push a modulemd which buildrequires bootstrap and something else
14:30:34 <langdon> along with the selector thing we talked about the other day
14:30:42 <asamalik> contyk: that would be nice
14:30:42 <langdon> contyk: ahh.. i like that idea
14:30:43 <contyk> we already have a test that runs on dist-git pushes
14:30:57 <contyk> it reports to resultsdb which nobody watches
14:31:07 <contyk> even the notifications are opt-in so nobody has them enabled
14:31:08 <langdon> geppetto, karsten think either of you could whip that up?
14:31:17 <langdon> contyk: the perfect test environment
14:31:38 <langdon> #action langdon to get bootstrap guidance added to guidelines
14:31:42 <contyk> https://github.com/fedora-modularity/check_modulemd/
14:32:05 <langdon> #action langdon to get someone to write a module check for using bootstrap + anything and issuing a warning
14:32:54 <tflink> contyk: are you suggesting that the notifications not be opt-in?
14:33:00 <asamalik> contyk: could be worth to spread that info.. people might not know about that
14:33:05 <langdon> tflink: that is my opinion ;)
14:33:55 <tflink> that'd likely require some change to fmn config but assuming I understand what you're asking, I don't think that'd be impossible
14:33:55 <langdon> ok.... can we close this topic?
14:34:04 <contyk> tflink: the last tiem we talked about it your said your reason for the current state was not to overwhelm people
14:34:07 <langdon> tflink: you might have riots
14:34:27 <tflink> hrm, I might be misremembering and/or misunderstanding
14:34:55 <contyk> tflink: I don't mind getting notifications about every little thing but I guess some people would just ignore them if they were getting dozens for every build
14:35:20 <contyk> tflink: it was just the default fedora notifications config, wasn't it?
14:35:22 <langdon> tflink: the fedora community is notorious about not getting more email about stuff.. so i would assume "opt-out for errors in resultsdb" would cause much consternation
14:35:22 <tflink> IIRC, package owners get notifications that aren't opt-in WRT failing tests
14:36:00 <tflink> langdon: that's not what I'm talking about, though
14:36:18 <tflink> I'm talking about opt-out for modulemd
14:36:24 <langdon> ahh i see
14:36:28 <tflink> assuming that it's reliable enough to be doing that for
14:36:34 <langdon> i would say, yes, let's make it opt out
14:36:44 <langdon> well.. i don't think it tests much
14:36:52 <langdon> but what it does test should be noticed
14:37:36 <langdon> i don't know.. ill have irina look in to it and come back with a recommendation/plan
14:37:53 <tflink> if it's critical and reliable, I don't see an issue with making error notification opt-out for folks responsible for the module in question
14:38:10 <contyk> +1
14:38:22 <langdon> tflink: right.. so, I'll have her look at that and if it is, we will ask you to switch it?
14:38:49 <langdon> and if it isn't, we will fix it, then ask you to switch it :)
14:39:51 <tflink> sounds good
14:39:55 <langdon> ok.. so.. next topic?
14:40:30 <langdon> ill take that as a "yes"
14:40:35 <langdon> #topic status report
14:40:55 <langdon> as you all probbaly know, modular server and tradition fedora have been having some challenges :)
14:41:28 <langdon> in an effort to better track everything, i put in depends on the fedora change tracker in bz..
14:41:32 <langdon> https://bugzilla.redhat.com/show_bug.cgi?id=1474931
14:42:03 <langdon> so now you can get a pretty graph of our headaches: https://bugzilla.redhat.com/showdependencygraph.cgi?id=1474931&display=tree&rankdir=TB
14:42:32 <langdon> we are proposing moving the Fedora Modular Server release out by about a month.. we will be discussing in the server sig meeting later today
14:42:44 <langdon> here is my proposal: https://fedoraproject.org/wiki/User:Langdon/Proposed_Modular_Server_Release
14:42:49 <langdon> but it is largely unreviewed
14:43:01 <langdon> being tracked in this ticket: https://pagure.io/fesco/issue/1775
14:43:31 <langdon> questions? comments?
14:43:33 <sgallagh> It is on the agenda for today's Server SIG meeting
14:43:39 <langdon> sgallagh: woot
14:44:13 <sgallagh> langdon: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/N4BXITJUX4N6LO5B2ZZZB4TEP2FFYBNH/
14:44:18 <sgallagh> Oops, wrong link
14:44:48 <sgallagh> Hmm, my email to the server list didn't hit the archives
14:44:53 * sgallagh goes to figure out why
14:46:36 <langdon> ok.. i think we are all stupid busy.. moving to a brief open floor
14:46:41 <langdon> #topic open floor
14:46:45 <langdon> anyone have anything else?
14:46:54 <langdon> 963 done yet?
14:47:06 <sgallagh> Looks like mailman was broken. Email should be going out soon.
14:47:12 <langdon> :(
14:47:14 <contyk> done
14:47:20 <sgallagh> langdon: Platform build completed successfully
14:47:27 * contyk submits another build with the modular dnf
14:47:40 <langdon> ohhh.. ha.. mailman is NOT in platform ;)
14:47:42 <sgallagh> contyk: of platform?
14:47:47 <contyk> sgallagh: yes
14:47:54 <sgallagh> ok
14:48:02 <sgallagh> langdon: I meant why my email to server@ didn't go out
14:48:11 <sgallagh> Sorry for the confusion.
14:48:12 <langdon> sgallagh: yeah.. got it now.. took me a minute :)
14:48:28 <sgallagh> IRC needs threaded responses... somehow
14:48:46 * langdon moves to nntp
14:48:49 <tflink> sounds like a job for slack?
14:48:51 * tflink ducks
14:48:53 <langdon> ha
14:49:07 <langdon> ok.. closing down in 60s?
14:49:54 <sgallagh> tflink: Please don't encourage pingou to reinvent Slack...
14:50:12 <tflink> sgallagh: you're the one who mentioned it ...
14:50:13 <langdon> ok.. closing
14:50:19 <langdon> #endmeeting