17:00:17 <jwboyer> #startmeeting FESCO (2016-02-19)
17:00:17 <zodbot> Meeting started Fri Feb 19 17:00:17 2016 UTC.  The chair is jwboyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:17 <zodbot> The meeting name has been set to 'fesco_(2016-02-19)'
17:00:17 <jwboyer> #meetingname fesco
17:00:17 <zodbot> The meeting name has been set to 'fesco'
17:00:17 <jwboyer> #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh
17:00:17 <zodbot> Current chairs: dgilmore jsmith jwb jwboyer kalev maxamillion nirik number80 paragan sgallagh
17:00:20 <jwboyer> #topic init process
17:00:30 <jsmith> .hello jsmith
17:00:31 <maxamillion> .hello maxamillion
17:00:32 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
17:00:35 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:00:37 <kalev> .hello kalev
17:00:41 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
17:00:57 <paragan> .hello pnemade
17:01:00 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
17:01:02 <nirik> .hello kevin
17:01:03 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:01:39 <number80> .hello hguemar
17:01:40 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com>
17:01:51 <jwboyer> missing sgallagh dgilmore ?
17:02:12 <dgilmore> hey
17:02:31 <jwboyer> ok.  let's get rolling.
17:02:33 <jwboyer> #topic #1541 F24 System Wide Change: LiveUSBCreator as Primary Downloadable
17:02:36 <jwboyer> .fesco 1541
17:02:38 <jwboyer> https://fedorahosted.org/fesco/ticket/1541
17:02:40 <zodbot> jwboyer: #1541 (F24 System Wide Change: LiveUSBCreator as Primary Downloadable) – FESCo - https://fedorahosted.org/fesco/ticket/1541
17:02:47 <jwboyer> i think (?) all the questions were answered for the most part
17:02:59 <number80> Yes, Martin was quick to answer me
17:03:05 <jsmith> Did the warning get implemented, or is that still on the to-do list?
17:03:20 <number80> jsmith: it's currently discussed with the designer but it's planned for GA
17:03:26 <jwboyer> not sure.  personally, i don't think it's a blocker
17:03:36 <jsmith> OK, I was just curious more than anything
17:03:48 <jsmith> As long as it's being addressed, I'm OK
17:04:01 <number80> the same, and it's actively worked on
17:04:09 <jwboyer> proposal: #agreed LiveUSBCreator as Primary Downloadable is accepted for F24
17:04:15 <number80> except if releng has objections => +1
17:04:15 <dgilmore> Not sure it effects releng at all
17:04:33 <dgilmore> but I am still catching up from the last 3 weeks
17:04:43 <nirik> dgilmore: they need to sign the win/macos builds somehow
17:05:15 <maxamillion> just sign a checksum file or something more integrated?
17:05:32 <dgilmore> nirik: we have no way of signing anything windows
17:05:32 <number80> maxamillion: signing the binary itself
17:05:33 <jsmith> I think it's signing the actual binary, but I could be mistaken
17:05:33 <nirik> I'm fine with the proposal (I assume cloud and docker and things that make no sense for this will just stay as links to download images)
17:05:39 <maxamillion> number80: ah
17:05:49 <dgilmore> and we would have to scope out entirely how to do it
17:05:51 <nirik> dgilmore: yeah, it may be out of scope...
17:05:58 <dgilmore> nirik: so if that is a must then we can not do it
17:06:15 <dgilmore> same goes for OSX
17:06:40 <nirik> well, the alternative is that they just do it some other way... which would be less controlled, but may be ok since we likely also aren't building the macos one anyhow.
17:06:43 <jwboyer> confused why signing is a requirement
17:06:47 <maxamillion> I'm not even sure how to sign a OS X or windows binary ... I'm pretty ignorant when it comes to either of those topic areas
17:06:48 <number80> How did we do for the windows version of LUC?
17:06:54 <dgilmore> jwboyer: I am not sure, nirik brought it up
17:06:57 <number80> (I mean the current one)
17:06:58 <kalev> I think the Windows / OS X builds and having them signed are pretty much a must for making this a primary download
17:07:04 <nirik> jwboyer: I think otheroses won't run things that aren't signed or put up a nasty warning?
17:07:04 <dgilmore> nirik: we did not afaik
17:07:21 <number80> kalev: they will be signed, Jiri will be getting a signing key
17:07:27 <nirik> not what?
17:07:35 <jwboyer> we've had windows binaries before.  i don't remember them being signed
17:07:40 <jsmith> Alternate Proposal: We punt this for a week to discuss signing and if it's a possibility
17:07:51 <nirik> lmacken may have signed them somehow...
17:07:51 <dgilmore> we have never signed non linux deliverables
17:07:54 <maxamillion> what imposes the requirement of the binary being signed? is that a OSX/Windows platform restriction or something else?
17:08:05 <jsmith> (I'm not sure we need to actually solve the technical problem in this meeting)
17:08:22 <jwboyer> we're not trying to.  we're trying to understand why it's required
17:08:38 * nirik has no idea. I have not used either of those OSes in many many years. ;)
17:08:49 <number80> As long as the binary is signed by someone trusted, I'm fine
17:08:57 <jwboyer> number80, why is that required
17:09:12 <kalev> yeah, it doesn't necessarily have to come out of koji as signed, could very well be signed manually by someone before putting it up
17:09:22 <number80> jwboyer: this is not requirement from us but for people to run it on recent OS X and windows
17:09:26 <nirik> kalev: koji is unlikely to build macos binaries. ;)
17:09:26 <dgilmore> I have used osx a couple of times over the last 5 or so years, last I used it you had to jump hoops to get unsigned binaries to work. but signed have to go through apples appstore
17:09:35 <dgilmore> at least something like that
17:09:43 <nirik> win binaries might be possible with mingw...
17:09:44 <maxamillion> dgilmore: oh, interesting
17:10:12 <dgilmore> if I remember correctly
17:10:22 <dgilmore> I had to do odd things to get libreoffice to work
17:10:34 <jwboyer> so the choices are to either approve and trust that Jiri is going to get it solved, or defer and trust that jiri is going to get it solved.
17:10:39 <dgilmore> though I th~ink firefox came from mozilla
17:11:26 <dgilmore> I am not sure how we intend to deliver the software and get updtaes out if at all.
17:12:15 <dgilmore> do we want to put it on the mirrors and use mirrormanager redirects? or just serve it entirely ourselves
17:12:48 <nirik> well, it's likely to be pretty small, we could put it in/near websites...
17:12:52 <number80> jwboyer: I trust Jiri to solve this
17:13:10 <dgilmore> do we want Jiri to do it all, or do we want releng to step in and be the gate keepers making sure its all done correctly and put in place?
17:13:21 <nirik> I'm fine approving it, but would be good to work out non linux build process sooner rather than later.
17:13:32 <dgilmore> nirik: indeed
17:13:50 <dgilmore> I think we could do windows in koji with mingw. well maybe
17:14:08 <dgilmore> but osx is going to need someone with a mac to build it
17:14:19 <jwboyer> coming up on 15min.  my proposal still stands
17:14:25 <nirik> as a datapoint:
17:14:45 <nirik> currently win versions are built by lmacken and distributed from fedorahosted.org: https://fedorahosted.org/releases/l/i/liveusb-creator/
17:15:25 <dgilmore> I am fine approving, but would like to understand the build and release process for non rpm delivered content
17:15:40 <nirik> jwboyer: +1 (and we can ask juri to talk to releng and work out an acceptable workflow)
17:15:49 <maxamillion> I'm +0 on this, my level of ignorance on the topic space makes me worried to vote in either directioin comfortably
17:16:50 <jsmith> +0 -- would prefer to have more discussion (outside of IRC) before making a definitive vote
17:16:53 <number80> +1
17:17:07 <jwboyer> i've got +1:3, -1:0, 0:1 so far
17:17:32 <number80> I agree that we need to sort the windows/OS X builds in koji but this is a long term action
17:17:51 <number80> and we've shipped windows builds of LUC without such requirements for long time
17:18:00 <kalev> I don't think OS X is going to be possible in koji, as OS X headers required for building aren't open source
17:18:07 <jwboyer> more votes?
17:18:32 <paragan> +1 to jwboyer proposal and remaining things can be discussed with change owners
17:18:47 <kalev> MinGW builds may be possible in koji, but AFAIK we don't have python support in the mingw toolchain so it may be more like a theoretical possibility
17:18:59 <kalev> +1 from me as well
17:19:03 <jwboyer> that's 5
17:19:20 <jwboyer> #agreed LiveUSBCreator as Primary Downloadable is accepted for F24 (+5, -0, 1)
17:19:20 <number80> kalev: we can circumvent that, but I think that providing a way to OS X users to deploy Fedora on usb sticks is more important
17:19:32 * kalev agrees.
17:19:38 <jwboyer> #info Change owners need to follow up with rel-eng on signing and hosting requriements
17:19:43 <jwboyer> time to move on
17:19:50 <jwboyer> #topic #1478 F24 Self Contained Changes
17:19:50 <jwboyer> .fesco 1478
17:19:51 <jwboyer> https://fedorahosted.org/fesco/ticket/1478
17:19:52 <zodbot> jwboyer: #1478 (F24 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1478
17:20:07 <number80> ok, I don't get the rationale for system-python split
17:20:14 <mhroncok> .hello churchyard
17:20:15 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:20:26 <number80> excellent :)
17:20:29 <mhroncok> number80: what part of it?
17:20:29 <jwboyer> hi mhroncok.  thanks for joining
17:20:41 <mhroncok> hi, np
17:20:43 <jsmith> Yeah, I'm inclined to vote for the PHP one, but I"m still hesitant about the python one
17:20:59 <pviktori> .hello pviktori
17:21:00 <zodbot> pviktori: pviktori 'Petr Viktorin' <pviktori@redhat.com>
17:21:06 <maxamillion> is "System Python" really a self contained change?
17:21:09 <number80> mhroncok: I don't see the use, I'd like explaination (I'm +0 for now)
17:21:26 <number80> and how the libs will be splitted
17:21:28 <mhroncok> maxamillion: yes, it is, it doesn't require anything from any toher package
17:21:28 <jwboyer> maxamillion, as suggested, yes.
17:21:35 <maxamillion> hrmmm... alright
17:21:39 * nirik is +1 to both
17:21:49 <maxamillion> I'm +1 on the change, but I just kind of considered it to be larger in scope
17:21:50 <number80> (+1 to the PHP one)
17:21:56 * maxamillion is +1 to both
17:22:11 <mhroncok> the complete list of what's going to be in what package is not yet clear and the decision is tha part of scope
17:22:49 <paragan> +1 to both
17:23:04 * kalev is +1 to both as well.
17:23:34 <jwboyer> i'm +1 to both
17:23:36 <jwboyer> which is 5
17:23:43 <jwboyer> does anyone wish to vote negatively?
17:23:44 <kalev> seems fairly trivial to roll back the python changes if they blow up in some way
17:23:53 <mhroncok> kalev: exactly
17:23:56 <jsmith> Put me down as +1 for the PHP, and -1 for the Python split -- I guess I still don't get it
17:23:56 <dgilmore> I am +1 to php
17:24:07 <number80> nope, I'm just thinking it's not yet ripe for F24
17:24:15 <dgilmore> I am not really sure of the python one
17:24:18 <number80> but no breakage expected so +0
17:25:19 <jwboyer> #agreed System Python is approved (+5, -1, 1)
17:25:33 <mhroncok> thank you, bye
17:25:43 <kalev> thanks mhroncok
17:25:48 <jwboyer> #agreed Drop php-pear dependency for pecl modules is approved (+8, -0, 0)
17:26:09 <jwboyer> moving on
17:26:15 <jwboyer> #topic #1542 backintime - nonresponsive maintainer
17:26:16 <jwboyer> .fesco 1542
17:26:16 <jwboyer> https://fedorahosted.org/fesco/ticket/1542
17:26:17 <zodbot> jwboyer: #1542 (backintime - nonresponsive maintainer) – FESCo - https://fedorahosted.org/fesco/ticket/1542
17:27:20 <jwboyer> proposal: #agreed Orphan backintime immediately and orphan the remainder of cicku's packages in one week's time if there is no further contact
17:27:31 <jwboyer> NOTE: that is a lot of packages
17:27:31 <jsmith> +1
17:27:34 <paragan> +1
17:27:45 <nirik> yeah, he's been collecting packages other people have orphaned for a long time.
17:27:46 <number80> *sigh*
17:27:58 <number80> +1
17:28:08 <kalev> I'd like to see this go through a proper nonresponsive maintainer process
17:28:10 <nirik> 230 packages
17:28:15 <kalev> is ciscu even in CC there in the ticket?
17:28:18 <jwboyer> kalev, backintime did
17:28:19 <number80> if we can't get hold of him, this is the best thing to do
17:28:38 <jwboyer> kalev, and this is the second or third package he's involved with where he's been unresponsive
17:28:46 <nirik> yeah, he is.
17:28:56 <nirik> so, sadly +1 here as well...
17:28:57 <jwboyer> kalev, so are you suggesting we go through the process for all 230 packages?
17:29:02 <dgilmore> +1
17:29:04 <paragan> I too have sent cicku personal email to respond else soon someone will ask to orphan his all packages but have not got any reply from him
17:29:05 <number80> I just don't like the new trend of not following the unresponsive process
17:29:21 <maxamillion> number80: +1
17:29:28 <maxamillion> also, cicku pushed an update to libpsl 18 days ago according to datagrepper
17:29:30 <kalev> jwboyer: no, I am suggesting that we have a process for marking maintainers nonresponsive: email devel list and CC the maintainer etc
17:29:37 <jwboyer> we did that
17:29:39 <jwboyer> for backintime
17:29:45 <kalev> ok, great :)
17:29:46 <jwboyer> how many more times would you like to repeat it?
17:29:54 <dgilmore> jwboyer: none
17:30:08 <dgilmore> at least not for this maintainer
17:30:09 <kalev> no, it's fine if it's done once; I think the process is for marking a _maintainer_ nonresponsive, not just taking one package
17:30:12 <number80> considering cicku history, giving hime one week to hear from him is fair
17:30:13 <kalev> if it was done, that's good :)
17:30:21 <dgilmore> and certainly not on a package by package case
17:30:27 * kalev agrees.
17:30:38 <number80> sponsors did ask him to focus on a smaller set of packages
17:30:42 <maxamillion> ah, alright
17:30:50 * maxamillion is +1 to the proposal
17:30:52 <kalev> anyhow, +1 to the proposal from me as well
17:31:07 <jwboyer> #agreed Orphan backintime immediately and orphan the remainder of cicku's packages in one week's time if there is no further contact (+8, 0, 0)
17:31:26 <jwboyer> nirik, can you help with the orphanings now and in one week?
17:31:41 <jwboyer> nirik, i'll send an email to devel and cicku about the mass orphaning next friday
17:31:42 <nirik> yep
17:31:54 <jwboyer> thanks
17:32:04 <jwboyer> #info nirik to orphan backintime
17:32:13 <jwboyer> #info jwb to email devel list about the remainder of the packages
17:32:23 <number80> thank you nirik
17:32:28 <jwboyer> ok, moving on
17:32:30 <jwboyer> #topic #1517 Can coprs depend on third part repositories to be usable at runtime
17:32:33 <jwboyer> .fesco 1517
17:32:34 <zodbot> jwboyer: #1517 (Can coprs depend on third part repositories to be usable at runtime) – FESCo - https://fedorahosted.org/fesco/ticket/1517
17:32:35 <jwboyer> https://fedorahosted.org/fesco/ticket/1517
17:32:47 <number80> phun topic
17:32:58 <jwboyer> this one is 2 months old.  we never tackled it.  that's kind of poor response
17:33:03 <jwboyer> let's work it out
17:33:32 <number80> if it's requires => no, weak dependencies => ok-ish
17:33:34 <nirik> I thought we mostly answered it, but sure, we should be more clear
17:33:35 <jwboyer> the immediate package in question was determined to be using BuildRequires on rpmfusion stuff.  that's not allowed
17:33:54 <jwboyer> but the question around Recommends and Suggests remains
17:33:57 <dgilmore> I am okay if weak deps are used to potentially pull something in at run time
17:34:05 <jsmith> number80: +1
17:34:13 <kalev> I would be inclined to say that it's not excellent user experience if copr's start requiring stuff outside of fedora
17:34:14 <dgilmore> but there can be no BuildRequires from something forbidden
17:34:16 <jwboyer> number80, want to craft that into a proposal we can vote on?
17:34:16 <nirik> I guess I am ok with that too, we never heard back from legal if that was ok...
17:34:39 <dgilmore> but I would want legal to say it is okay
17:34:41 <jwboyer> nirik, spot said in the initial comment that there was no legal reason to disallow that
17:34:42 <kalev> I wouldn't mind a soft dep though, but not sure about a hard library dep
17:34:44 <jsmith> I'd even go so far as to allow Suggests but not Recommends...
17:34:49 <nirik> ah, missed that, ok
17:34:58 <jwboyer> "There is, however, no legal reason that I am aware of that a Copr could not include a package which has a purely runtime dependency on something in a third party repository."
17:35:26 <nirik> right.
17:35:40 <number80> proposal: package build in copr must be functional with requirements complying w/ Fedora licensing policies. Dependencies using third-party repositories are ok if they are non-essential at runtime (e.g Recommends/Suggest)
17:36:00 <dgilmore> jwboyer: is it okay then to say you have to enable rpmfusion, or some other repo of things we can not ship in order to install the software
17:36:01 <nirik> +1
17:36:14 <dgilmore> number80: +1
17:36:15 <jsmith> +1
17:36:16 <maxamillion> +1 to number80's proposal
17:36:24 <number80> (formal +1)
17:36:30 <jwboyer> dgilmore, that isn't how recommends and suggests works
17:36:35 <jwboyer> number80, +1
17:36:39 <kalev> from a high level point of view, I think it would be great if the dnf plugin for enabling coprs would universally work and wouldn't require any additional manual steps, such as enabling rpmfusion
17:36:43 <kalev> number80: +1
17:36:45 <paragan> number80, +1
17:37:23 <number80> the hard part will checking it in practice
17:37:41 <number80> *be
17:37:43 <jwboyer> no harder than any other checks we do
17:37:47 <jwboyer> (which is none)
17:38:30 <jwboyer> #agreed package build in copr must be functional with requirements complying w/ Fedora licensing policies. Dependencies using third-party repositories are ok if they are non-essential at runtime (e.g Recommends/Suggest) (+8, -0, 0)
17:38:45 <jwboyer> ok, next week's chair
17:38:52 <jwboyer> #topic next week's chair
17:39:01 <dgilmore> I can
17:39:01 <jwboyer> who wants the hot seat?
17:39:04 <jwboyer> yay dgilmore
17:39:09 <jwboyer> #info dgilmore to chair next week's meeting
17:39:15 <jwboyer> #topic Open Floor
17:39:39 <jwboyer> anything?
17:40:05 <dgilmore> wanted to give a quick heads up, we are really close now to changing how we build and ship rawhide in prep of f24
17:40:19 <dgilmore> I will be asking for people to look things over early next week
17:40:25 <jwboyer> dgilmore, as in composes are composes and no more TC/RC?
17:40:25 * jsmith listens intently to dgilmore
17:40:39 <dgilmore> jwboyer: there will be RC but no more TC
17:40:43 <maxamillion> dgilmore++
17:40:46 <jwboyer> neat!
17:40:49 <number80> dgilmore++
17:40:49 <zodbot> number80: Karma for ausil changed to 21 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:41:12 <jwboyer> dgilmore, throw a #info with however is best to explain that
17:41:15 <jsmith> Sounds great...
17:41:24 * nirik looks forward to our pungi4 overlords
17:41:30 <dgilmore> it is looking a bit different to what we have previously had
17:42:29 <dgilmore> #info the pungi change is close to completion, next week we will be seeking feedback on teh composes as we prepare to switch rawhide over
17:42:30 <paragan> Is there any wiki documentation on coming new changes to read?
17:42:48 <dgilmore> paragan: on which part of it?
17:43:02 <dgilmore> I have yet to write up the docs on how to do composes
17:43:07 <paragan> okay
17:43:23 <dgilmore> pungi has some docs on how to configure it all
17:43:28 <jwboyer> i have something of a small heads up when dgilmore is all set with his topic
17:43:42 <dgilmore> jwboyer: I am done unless there is more questions
17:44:22 <jwboyer> so at DevConf there was much discussion in many talks about modularity and how to do it in a distro
17:44:42 <jwboyer> and with my Council hat on, we have an Objective for modularity in Fedora
17:44:56 <jwboyer> the discussions got people excited and ready to work
17:45:16 <dgilmore> not sure we fully understand what that means.
17:45:31 <jwboyer> over the next few weeks, there will likely be increased activity around what modularity means to Fedora and how groups are going to start looking at it
17:45:34 <nirik> is this something for f25? so, after branching?
17:45:42 <dgilmore> I think we do need to figure that out and see what we need to do to enable the changes
17:45:48 <jwboyer> believe f25 is the earliest target, yes
17:46:00 <nirik> cool.
17:46:04 <dgilmore> nirik: I would say f25 probably f26
17:46:13 <jwboyer> there is no set target, but to do any of this for f24 would be way too soon in my personal opinion
17:46:36 <dgilmore> jwboyer: I agree
17:46:52 <nirik> yeah, but after f24 branches, rawhide is there ready to go
17:47:01 <jwboyer> some of the activity might come from a revamped Base or Env & Stacks WG, some might come from individuals or small groups
17:47:39 <jwboyer> the point of me bringing it up is that there will be more activity around it, and FESCo should probably pay attention so we can address technical aspects with good understanding while we work through things
17:48:02 * nirik nods
17:48:13 <dgilmore> jwboyer: thanks
17:48:32 <jwboyer> for those that don't know langdon is the Objective lead.  i'm sure he'll be joined by mattdm and myself regularly in this
17:48:55 <jwboyer> anyway, that's all i wanted to bring up today
17:49:04 <number80> ack
17:49:11 <jwboyer> anything else?
17:49:12 <jsmith> Thanks for the heads up, jwboyer
17:49:19 * jsmith has nothing to add
17:49:20 <number80> you may follow the council list if you already don't
17:50:19 <maxamillion> jwboyer++
17:50:19 <zodbot> maxamillion: Karma for jwboyer changed to 5 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:50:31 <jwboyer> ok, going close the meeting out in 2 min if there is nothing further
17:51:06 <jwboyer> 1min
17:52:19 <jwboyer> thanks all
17:52:21 <jwboyer> #endmeeting