17:00:02 #startmeeting FESCO (2016-04-22) 17:00:02 Meeting started Fri Apr 22 17:00:02 2016 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:02 The meeting name has been set to 'fesco_(2016-04-22)' 17:00:02 #meetingname fesco 17:00:02 #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh 17:00:02 #topic init process 17:00:02 The meeting name has been set to 'fesco' 17:00:02 Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh 17:00:52 .hello jkurik 17:00:53 jkurik: jkurik 'Jan Kurik' 17:00:57 jwb and jsmith were both out today... not sure we will have quorum. 17:01:02 .hello maxamillion 17:01:03 maxamillion: maxamillion 'Adam Miller' 17:01:05 .hello pnemade 17:01:09 paragan: pnemade 'Parag Nemade' 17:01:14 * kalev is here but typing on the phone. 17:01:38 .hello kalev 17:01:39 kalev: kalev 'Kalev Lember' 17:01:56 .fas eischmann 17:01:56 sesivany: eischmann 'Jiri Eischmann' 17:02:02 * dgilmore will be delayed 15 minutes or so 17:02:32 we have 5 with dgilmore if we wait for him. ;) 17:05:00 #topic #1444 Updates deliverables 17:05:00 .fesco 1444 17:05:00 https://fedorahosted.org/fesco/ticket/1444 17:05:01 nirik: #1444 (updates deliverables) – FESCo - https://fedorahosted.org/fesco/ticket/1444 17:06:05 so, I guess we need several things here... 17:06:33 input from dgilmore on what we are missing currently for updates deliverables, and then to decide the f24 ones (if we are adding/removing anything from them) 17:08:22 * paragan forgot, do we have wiki page for these deliverable list? 17:08:32 not sure 17:09:00 paragan: wiki pages do not work 17:09:01 * nirik looks 17:09:18 we need something better, ideally with an API 17:09:38 right, some thought was PDC could do this, but not sure if thats true 17:09:45 okay 17:09:56 PDC records what is built in composes 17:10:09 it does not define what is supposed to be 17:10:52 how can we review update deliverables for Fedora 24 now? 17:11:18 paragan: we have never had a list of updates deliverables 17:11:32 paragan: so its a whole net new thing 17:12:09 well, there's serveral things here. 17:12:36 what is built (PDC), what should be built (release blocking deliverables) and what should be updated after release (this ticket) 17:13:08 nirik: +1 17:13:20 nirik: right 17:13:41 there was a suggestion made for the second one we have a tool that gathers that from the pungi config (ie, the place where it would be set) 17:13:52 but not sure what we can do for updating things. 17:14:04 dgilmore: what do you think is missing from: ""updated RPM repos, atomic repos, atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image." 17:14:11 I imagine something that hooks into the pungi config pagure repo would be a good choice there 17:14:42 (for the second thing) 17:14:48 nirik: I think that is probably all we need 17:15:21 so where do we store that list? and does it change with f24? 17:15:35 no idea 17:16:01 the only new deliverables in f24 was a couple of new labs 17:16:08 I agree a wiki page sucks, but it would be something we could do now. 17:16:27 ok, I got to a keyboard now :) 17:16:40 I remember thinking about iso respins and thinking that it might make sense to change our repo structure to make this easier 17:17:01 right now F24 images get produced from the base "fedora" or Everything or however we call the repo and the repo is frozen after the images are cut 17:17:27 I was thinking that we may want to extend that to updated deliverables, so the when we cut an updated image we cut it from another frozen repo 17:17:30 let me explain: 17:18:12 right now we only have "fedora" and "updates" repos enabled in a regular fedora installation 17:18:18 kalev: today we do not update any isos 17:18:22 where fedora is the frozen base repo where images were cut from 17:18:26 śo doing so is something new 17:18:33 dgilmore: yea, but I understood that the ticket is about maybe starting doing it in the future 17:19:05 so if we start putting out updated images, we can't base it on the "fedora" repo because it's already frozen 17:19:06 kalev: it could be an option 17:19:25 and we can't easily base it on "fedora" + "updates" either because updates is constantly moving 17:19:31 the ticket was about being crystal clear what things are going to be updated post release 17:19:47 so I was thinking that whenever we have a new updated image coming up, we create a new frozen tree for it 17:19:54 right, I just wanted to get my amazing idea out :) 17:20:01 okay :) 17:20:21 right now the folks doing the live respins have been doing them everytime a kernel goes stable in updates... 17:20:44 nirik, yes 17:20:49 so when we have a F24.1 image update coming out, we'd also create a new "updates-24.1" repo that sits on top of "fedora" 17:21:22 but is different from the regular "updates" repo in the sense that while "updates" keeps on flowing, we can freeze "updates-24.1" and use it to cut a new updated image 17:21:37 wait, why are we creating a new repo? 17:21:40 anyhow, I think thats above the scope of this ticket. This is just asking for a list of what things we currently plan to do updates for. 17:22:05 and after that, we'll also have the nice side effect that "updates" would be much smaller since the delta to the frozen "updates-24.1" would be much smaller 17:22:09 anyway, EOF here :) 17:22:15 sorry for stealing the meeting! 17:22:20 how many such updates we plan to provide after a stable release? 17:22:34 that many repo trees will be needed then 17:22:38 kalev, then those imageswould have to go back QA again and they dont have time 17:22:48 kalev: I think I would like to see that drawn out. Just because I am not seeing how it makes updates smaller 17:22:56 Southern_Gentlem: yes of course; we'd need to QA all images we put out ... 17:23:18 dgilmore: yep, I can write it all up and put it in the ticket 17:23:27 please make a new ticket for it. 17:23:33 it's something new. ;) 17:23:34 ok 17:24:35 I think if possible we can start with wiki page for F24 update deliverable for this ticket. 17:24:58 proposal: for now, until we have something better, make a https://fedoraproject.org/wiki/Fedora_Program_Management/Updating_deliverables/Fedora24 with the currently agreed list 17:24:59 kalev: it is something different 17:25:25 nirik: missing is teh frequency of updates 17:25:48 Atomic deliverables are two weeks 17:25:55 repos are generally daily 17:26:01 yeah, that would need to be per updated thing right? 17:26:11 but docker, and cloud images, when do we want to do them? 17:26:22 maybe monthly or two weekly 17:26:30 right 17:26:41 cloud SIG wants the cloud base image to be monthly 17:27:15 there's a ticket in the cloud WG for it -> https://fedorahosted.org/cloud/ticket/138 17:27:20 ok, so perhaps we revisit this next week and gather input from groups? 17:27:35 nirik: +1 17:27:46 nirik, +1 17:27:54 I would volunteer to collect the data but I won't be here next Friday 17:28:03 well ... I'm probably not going to be here 17:28:15 I'll try to be pending connectivity while traveling 17:28:17 maxamillion: I can make a draft wiki page and you can talk to folks and fill it in? 17:28:25 nirik: +1 - let's do that 17:28:51 #action nirik to make draft wiki page, maxamillion will ask groups for feedback and we will revist next week. 17:28:55 any objections to that? 17:29:01 no 17:29:04 no 17:29:50 #topic #1555 Please clarify updates policy for security issues 17:29:50 .fesco 1555 17:29:50 https://fedorahosted.org/fesco/ticket/1555 17:29:51 nirik: #1555 (Please clarify updates policy for security issues) – FESCo - https://fedorahosted.org/fesco/ticket/1555 17:31:03 overall I don't mind the phrasing, but I am worried that it's overbroad... 17:32:26 I like the direction where this is going, as in reducing the updates firehose 17:32:29 it should apply when upgrading an older release is incompatible... if it's not, I don't see why you wouldn't just do it. 17:32:56 nirik: +1 17:33:04 right so the existing text looks good 17:33:15 yeah, I think so 17:33:53 * nirik looks at how to rephrase it so it doesn't seem overbroad 17:34:17 kalev: reducing the updates firehose will not happen with words 17:34:22 I guess it's better in context of the page it will be in. 17:35:42 so what do we want to do here? vote? wait a week? sgallagh had some feedback in ticket... 17:36:59 can we automate the checks 17:37:11 and filing of tickets 17:37:23 I'm happy with the wording, but others seem to have some feedback and since sgallagh is one of those people and isn't here, I'd vote to wait 17:37:36 not that I can see... 17:37:41 say have a check in bodhi that detects version bump, and files tickets, does some extra testing 17:37:57 the problem is there's no standard versioning. 17:38:07 I think we should wait until sgallagh is here, as he seems to think there was something not right 17:38:08 version 1.0 and 2.0 could be 100% compatible 17:38:14 does taskotron can do that testing? 17:38:23 nirik: maybe wait a week before voting, yes, so that jsmith is actually here and the edits that sgallagh wanted are done etc 17:38:28 and version 1.0.1 and 1.0.1.1 could be completely incompatibe. ;) 17:38:38 paragan: well we could do abi testing 17:38:48 nirik: right, 17:38:48 thats planned/almost in place now. 17:39:12 #info will wait another week for more feedback and others present 17:39:19 abi testing is in progress, the task is currently under review and will likely be in our dev instance in the next week or two 17:39:31 tflink: awesome 17:39:34 excellent 17:39:40 #topic #1566 Review of release blocking deliverables for F24 17:39:40 .fesco 1566 17:39:40 https://fedorahosted.org/fesco/ticket/1566 17:39:45 nirik: #1566 (Review of release blocking deliverables for F24) – FESCo - https://fedorahosted.org/fesco/ticket/1566 17:39:52 this is the second part of the other ticket... the what blocks release. 17:40:27 jkurik was the one not updating the list as new delieverables arrived 17:40:42 so, I guess here we should check the current list and see if we can think of anything missing? 17:41:14 https://fedoraproject.org/wiki/Changes/Astronomy_Spin 17:41:32 I do not think any of the new spins are release blocking 17:41:50 agreed 17:41:53 the change list has one spin 17:41:59 I thought there was two 17:42:05 CInnamon? 17:42:13 or was that added in f23? 17:42:33 Cinamon was in F23 17:42:37 I thought that was f24 17:42:39 errr 17:42:40 f23 17:42:42 * maxamillion can't type 17:45:25 proposal: add Astronomy spin, approve list 17:45:56 +1 17:45:58 +1 17:46:25 +1 17:46:29 Fedora-Cloud-Atomic was renamed to Fedora-Atomic 17:47:00 Atomic installer is missing 17:47:06 +1 17:47:14 we do not do Multi boot media any more 17:47:37 we added arm Docker base image 17:47:52 so -1 17:47:57 the list needs fixed 17:48:10 dgilmore: ok who is going to fix it? you? jkurik ? 17:48:25 it is jkurik's job afaik 17:48:30 nirik: I can fix the list 17:48:41 dgilmore: thanks for the input 17:48:45 ok, so do we want to wait and review it next week? or ? 17:48:52 we also moved a bunch of paths around 17:49:08 Spins became Labs 17:49:23 Live and Images became Spins 17:49:29 ok, then lets revist next week after all the fixes... that seems best 17:49:38 right 17:49:58 btw: to maintain the list, I need an input of these changes 17:50:16 jkurik: we really need something that has an API 17:50:23 these changes do to go through Change process 17:50:25 and can be used programatically 17:50:35 so I am typically not aware of it 17:50:47 jkurik: some of the changes went through the Change process 17:50:50 and some didnt 17:50:59 the ones that didn't are my fault 17:51:27 It would be nice to have a API, but not sure it would have helped with this unless someone was updating it... 17:51:50 nirik: well if we have an API, we validate the compsoe 17:51:59 and it yells when things are wrong 17:52:29 it will require writinga compose validation tool 17:52:31 hum, I guess. 17:52:55 ok, anyhow... 17:53:04 #info will revisit this next week after it's been updated. 17:53:21 nirik: the list ignores torrents also 17:53:23 OK, so moving the list from wiki to pagure (a CSV file ?) will help 17:53:28 ? 17:53:32 jkurik: maybe 17:53:40 jkurik: lets talk 17:53:42 dgilmore: we should add them. They are such an afterthought. ;) 17:53:53 nirik: indeed 17:54:13 perhaps pungi could make the .torrent files? anyhow, out of scope for this talk 17:54:30 #topic #1568 F25 Self Contained Changes 17:54:30 .fesco 1568 17:54:30 https://fedorahosted.org/fesco/ticket/1568 17:54:31 nirik: #1568 (F25 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1568 17:55:04 I am okay with using storaged 17:55:22 +1 17:55:26 +1 17:55:48 well, there was discussion on list where it was unclear if workstation wanted to use it or not 17:55:50 I am a bit disappointed that it's a different project instead of fixing udisks, but that's how it is I guess 17:55:55 +1 17:55:59 +1 17:56:17 "I don't think that Workstation wants to stray from upstream GNOME, which uses udisks2" 17:57:01 I thought that upstream GNOME was going to make the change also but is still using udisks2 today 17:57:15 I could be mistaken, but I thought that I read that somewehre 17:57:18 somewhere* 17:57:39 maxamillion: upstream gnome doesn't care about the features storaged brings... 17:58:14 is this change replacing udisks2 package completely? or just moving blivet/cockpit to using it? 17:58:26 the latter as I understand it 17:58:43 nirik: storaged says it is a drop in replacement extending on udisks 17:58:44 nirik: cockpit already uses storaged and blivet too afiak 17:58:53 so it should not really matter 17:59:07 I guess not... 17:59:11 ok, +1 then 17:59:26 #agreed Self contained changes approved (+5,0,0) 17:59:47 #topic #1570 F24 Changes not in ON_QA status (<100% completed) 17:59:47 .fesco 1570 17:59:47 https://fedorahosted.org/fesco/ticket/1570 17:59:48 nirik: #1570 (F24 Changes not in ON_QA status (<100% completed)) – FESCo - https://fedorahosted.org/fesco/ticket/1570 18:00:39 anything on the list that we should look at firing the contingency plan on? 18:01:28 cloud-motd looks like it should be done, and the bug has not been updated 18:01:40 dgilmore: yes, I think so as well 18:01:44 LiveUSBCreator as Primary Downloadable? 18:01:50 also "The GNU C Library version 2.23" seems to be done 18:01:57 nirik: what is the "contingency plan"? 18:02:14 I think golang is done also 18:02:19 maxamillion, its written in individual Change pages 18:02:27 paragan: ohhh ok 18:02:28 maxamillion: each change has to have one... in case they aren't ready 18:02:34 gotchya 18:03:21 maxamillion: didnt they enable atomic developer mode in the f23 builds about a month back? 18:04:02 dgilmore: I'd have to go check, I don't remember ... but I know it was being discussed 18:04:19 I just ping'd some folks asking if they know the status of the two Atomic related Changes 18:04:42 I think a lange number of these are done and people have just been bad at updating the bugs 18:05:27 yeah, seems so. 18:05:27 I have been trying to chase owners of these Changes, however not all I was able to catch 18:06:07 so, shall we just keep trying to update and wait a week? or ? 18:06:11 I can continue to chase owners till the next meeting 18:06:18 we can wait for a week 18:06:49 are tehre any that look like they are not done? 18:06:55 that we can go and punt 18:07:09 regarding the liveusb-creator, kalev asked me to come here today so i can answer your questions about its status if you want 18:07:11 Shenandoah 1.0 seems sketchy 18:07:18 I am not sure about the Erlang-18 18:07:30 jkurik: the packages are in 18:07:39 at least some of them 18:08:03 erlang-18.3.1-1.fc24 is in f24 18:08:05 dgilmore: yes, that was I was told; part of the Change is done, some packages are missing 18:08:15 this one needs to have a pull request merged for the atomic json input but it appears done https://bugzilla.redhat.com/show_bug.cgi?id=1303546 18:08:34 I don't see any obviously not done yet. 18:08:39 nirik: +1 18:08:44 not ssure where the removal of librtkaio from glibc is 18:08:45 mbriza: can you give us a quick update? how is it looking? 18:09:10 nirik: well we had a test day on tuesday which was the first day somebody except a few folks around me actually used the tool 18:09:17 so naturally there was quite a lot of bugs 18:09:22 (about 30) 18:09:39 i have fixed between 15-20 of them so far 18:09:46 thats actually good. ;) finding them now is much better than later.... 18:10:08 i think there are about 10 severe bugs left to fix which i'll do next week, nothing seems to complicated to do 18:10:16 *too 18:10:58 I think the tool itself will be ready, I'd worry about if we can make it on time in releng and websites. 18:11:01 other thing is we're working on setting things up for official windows builds in koji (with dgilmore and stickster] 18:11:15 yeah, thats our next topic actually. ;) 18:11:33 so, anymore on this? or wait a week and try and update things and revisit next meeting? 18:11:34 dgilmore: librtkaio should already be removed - https://bugzilla.redhat.com/show_bug.cgi?id=1308554#c3 18:11:45 for the websites... 18:12:06 jkurik: cool. so people suck at updating bugs :( 18:12:16 I'm currently arguing with them that the tool is really what we want to offer Windows users as primary downloadable. 18:12:17 dgilmore: no surprises there sadly. ;( 18:12:44 sesivany: lets cover that in teh next topic 18:12:52 ok 18:13:04 #info will wait for a week and try and update all non 100% changes 18:13:07 #topic #1571 need guideance of what exactly needs to be built from source for Fedora Media Writer 18:13:07 .fesco 1571 18:13:07 https://fedorahosted.org/fesco/ticket/1571 18:13:08 nirik: #1571 (need guideance of what exactly needs to be built from source for Fedora Media Writer) – FESCo - https://fedorahosted.org/fesco/ticket/1571 18:13:41 nirik: so I think at this point #proposal chase up change owners with baseball bats to update bugs and review next week, if bugs not updated change is punted to F25 18:13:53 too late :) 18:13:53 so, building windows binaries is just a new area to us... 18:14:00 dgilmore: indeed. ;) 18:14:04 it is a very new area 18:14:27 we have a mingw crosscompiler stack with a bunch of precompiled libraries 18:14:34 koji has long supported building windows binaries 18:14:35 but sadly it doesn't have python 18:14:47 upstream python can't be built using mingw 18:14:53 kalev: python seems to be the only missing thing 18:15:27 elmarco had a mingw-python package somewhere, let me see if I can find it 18:15:38 in arch, yes 18:15:41 aha, https://elmarco.fedorapeople.org/mingw/mingw-python-2.7.1-1.src.rpm 18:15:48 from 2011 :) 18:16:05 it shoudl be fine :P 18:16:23 probibly that has the big patch needed to make python build? 18:16:30 koji can build windows objects natively in windows 18:16:38 nirik: yep, it has that 18:17:23 https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2 this is a bit more up to date but still... ~80 patches 18:17:47 the maintainece cost of python in mingw seems high 18:17:48 thats a lot... but perhaps thats better than having to setup windows and deal wih binary stuff... 18:17:51 I could commit to reviwing the package if anyone wants to submit it to review and maintain it 18:18:03 * kalev has done a bunch of mingw related things in fedora. 18:18:20 the cost of building and maintaining python, qt, etc on windows natively seems high also 18:18:39 if we did get the mingw path working we would still need windows for signing ? or how does signing with mingw work? 18:18:43 kalev: I don't want to commit to it entirely, but I'm willing to look at it to see if I think that's something I'd be capable of doing 18:18:57 signing should work in linux using some tool from mono 18:19:06 didn't get it to work so far though 18:19:07 the cost of seting up and maintaining windows build environment in koji is afaik not that high 18:19:28 dgilmore: it's unpleasent tho. ;) 18:19:38 nirik: sure 18:19:40 * jsmith joins very very late 18:19:52 and means infrastructure can't say they are 100% open source anymore, which will make me sad. 18:20:04 we would need to decide if its okay to use upstream binaries of the things we want 18:20:31 nirik: sure: but the windows machines at least only run when doing builds 18:20:38 nirik: for f25, a mac port of the tool will (i hope) be ready and then you can't really use just opensource tools 18:20:47 so maybe 95% of the time we are 100% open 18:21:00 uh huh. 18:21:01 yeah, it's possible to set up a mac crosscompiler, but the libraries are non-free so we can't put them in fedora, sadly 18:21:33 kalev: can we build against darwin? 18:22:23 it is really useful to have a native windows tool to get people able to use Fedora easily 18:22:27 dgilmore: I don't remember the details, but I think it was possible to take most bits from darwin, but there was something else that was non-free that was required 18:22:42 but it comes with costs, which ones do we want to pay? 18:22:43 epienbro looked at this years ago, I wasn't involved with the mac crosscompiler stuff 18:22:45 at this point since kalev and maxamillion offered to help, I'd say we should try and get mingw working... if it becomes clear thats no go, we fallback to the windows stuff. 18:23:21 i think you have to use some parts of xcode which are not free 18:23:31 just to be clear, I don't want to sign up to being primary mingw-python package maintainer, but I'm more than happy to help drag this through the review process 18:24:22 and help clean it up so it actually builds after 5 years 18:25:09 mbriza: what do you think? willing to try that? or ? 18:25:14 kalev: yeah, if I spend some time looking at it and feel like I'm capable of doing so, I'll maintain it 18:25:27 awesome, thanks maxamillion 18:25:38 kalev: I appreciate you being willing to whip it into shape though :) 18:26:13 nirik: honestly, i'd rather go with the windows path... or wine... but still with a binary package from the upstream... but on the other hand, i'm not really a huge opensource purist 18:27:39 at this point we have about a week or so to get everything in place and working 18:27:42 re signing, elmarco was working on tools related to windows packaging, might be worth asking him about that and see if we have anything for signing 18:28:04 kalev: there's a signtool (or signcode?) tool from mono, it's in fedora 18:28:08 i think mono-devel package 18:28:11 ahh, cool 18:28:28 i haven't got it to work yet but OTH i spent like 15 minutes doing so 18:28:29 dgilmore: I am not sure any path makes that practical, but we can try 18:28:40 anyway, elmarco is on #desktop in the RH internal irc if anyone needs him 18:28:59 nirik: thats our window to get it in Beta 18:28:59 he should know what tools work and what don't 18:29:37 well, like I said we can try... but this is all very rushed. ;( 18:29:41 * dgilmore is going to order a cert for siging windows code today 18:30:09 ok, so where are we here? 18:30:58 if mbriza doesnt want to use mingw, we need to decide what binaries from windows we allow building against? 18:31:52 and should we consult legal after the comment about prebuilt binaries? 18:32:03 nirik: well i think i can use mingw but i also think this puts too much work on shoulders of people who could be doing something else, not just maintain a bunch of tools to build a single application 18:32:25 well, mingw-python could well be useful for many other people too tho 18:32:49 and we would be advancing our mission instead of ignoring it. 18:33:05 yeah, it should definitely be useful for other people too 18:34:07 * kalev is excited to get closer to having gobject-introspection support for mingw once we get python in. 18:34:36 btw when you start with it, it's not just python, it's python-qt5, python-pyquery, python-requests, python-wmi and python-win32com too and all of their dependencies 18:35:48 we have been on this for 25min now. ;) 18:35:59 at that point, maintaining just python doesn't cut it for the users sadly 18:37:00 for the record: the ticket for website changes is here: https://fedorahosted.org/fedora-websites/ticket/384 18:37:02 can we come to a conclusion, table it, or move on? I need to go afk 18:37:14 need to go soon* 18:37:31 same here, I would have to leave very soon 18:37:58 well, like I said, I would prefer the mingw path, but I am not doing the work, so it seems wrong for me to decide that. ;) 18:38:22 nirik: as FESCo we make decisions on all sorts of stuff we don't actually do the work on ;) 18:38:48 nirik: well we have about a week to have it done for f24 18:38:51 sure, but usually it's approval/disapproval... not "we want you to do it this way" 18:39:03 nirik: fair 18:39:21 at this point I am personally thinking we should punt it to f25... but I suspect that won't be popular. 18:39:42 let's see if we can get it done in the next week, if not we can punt 18:40:35 nirik: that is the only way to give us the time to get it right 18:40:39 I would definitely like to have it as _a_ download option for F24, but maybe it would be prudent to punt the default download change to F25, yeah 18:40:48 I thionk everything else is taking a shortcut 18:41:11 I guess we could just punt and try and vote in ticket/find some way that works and update the ticket. 18:41:33 I am okay with using prebuilt binaries from our upstreams in the case of a windows build 18:41:47 dgilmore: +1 18:42:06 because it does mean that we do not need to have a lot of resources maintaining a stack used for one thing 18:42:13 i agree with dgilmore 18:42:39 so is there legal concern? or that was due to it being in fedora itself ? 18:42:40 I filed the ticket because I wanted it to be a concious choice 18:42:58 nirik: I am not sure 18:43:22 well, then I would be +1 as long as legal signs off on it. 18:43:24 I had asked spot about us shipping prebuilt u-boots and he said we should not do that 18:43:36 nirik, +1 18:43:49 Proposal: ship upstream built binaries for windows executables pending legal sign off 18:43:55 * spot glares 18:43:58 +1 18:44:00 seriously? 18:44:08 sorry spot 18:44:09 spot: what exactly? 18:44:12 how would you like to be sure we're in license compliance? 18:44:25 we need to be distributing corresponding source. 18:44:46 its not the "someone else built it" problem that gets us (although, it makes me concerned) 18:44:54 its the "built it from what exactly" 18:45:40 does upstream provide a tarball/zip/envelope with the source code that matches the windows binaries? 18:46:02