14:00:00 #startmeeting Workstation WG 14:00:00 Meeting started Wed Apr 13 14:00:00 2016 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:00 The meeting name has been set to 'workstation_wg' 14:00:02 #meetingname workstation 14:00:02 The meeting name has been set to 'workstation' 14:00:04 #topic Roll call 14:00:06 .hello pfrields 14:00:07 stickster: pfrields 'Paul W. Frields' 14:00:12 .fas eischmann 14:00:12 sesivany: eischmann 'Jiri Eischmann' 14:00:18 Hi Jiří! 14:00:22 .hella catanzaro 14:00:28 hella good 14:00:30 .hello mclasen 14:00:31 .hello catanzaro 14:00:31 mclasen: mclasen 'Matthias Clasen' 14:00:35 mcatanzaro: catanzaro 'None' 14:00:48 .hello ryanlerch 14:00:48 ryanlerch: ryanlerch 'ryan lerch' 14:01:32 #chair mcatanzaro mclasen ryanlerch sesivany 14:01:32 Current chairs: mcatanzaro mclasen ryanlerch sesivany stickster 14:01:55 .hello otaylor 14:01:56 otaylor: otaylor 'Owen Taylor' 14:01:56 cschalle says he may be a few minutes late 14:02:03 mclasen: OK, thanks, was about to ping him 14:02:08 #chair otaylor 14:02:08 Current chairs: mcatanzaro mclasen otaylor ryanlerch sesivany stickster 14:02:26 * stickster looks for kalev or rdieter_work 14:02:40 haven't seen kalev on irc today, yet 14:02:41 oh hi, time flies 14:02:47 heh, hi Rex :-) o/ 14:03:08 .hello rdieter 14:03:10 rdieter: rdieter 'Rex Dieter' 14:03:17 #chair rdieter 14:03:17 Current chairs: mcatanzaro mclasen otaylor rdieter ryanlerch sesivany stickster 14:04:08 OK, let's get started 14:04:29 I want to start with the LUC topic, because sesivany is here and I don't want to keep him the whole time, he's rather busy and important :-) 14:04:44 #topic LiveUSB Creator status 14:04:53 #link https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloadable 14:05:18 Hi everyone 14:05:40 I guess you want a status from me... 14:05:49 sesivany: So there were some questions on the list -- but maybe best to just start with that? 14:05:59 heh, *jinx... go ahead :-) 14:06:06 We have a major problem with the Mac port. 14:06:46 Python2 PyQt doesn't seem to be well maintained on Mac and Martin has not been able to build a single installation file which is what mac users expect. 14:07:28 sesivany: is there a different PyQt for Python 3? (I'm completely ignorant here) 14:07:29 He's going to port it to Python 3 in the hope that the problems are fixed there. He's been fiddling with that for weeks and haven't found any help anywhere. 14:07:36 sesivany: not able in what sense - is it just hard or are there fundamental issues? 14:07:47 * stickster keeps feeding sesivany slow pitches :-) 14:08:22 otaylor: dunno details, but problems he hasn't been able to workaround in the last 3 weeks. 14:08:41 I can ask Martin to send detail info about it. 14:09:18 But if he doesn't find someone to help him with that, we won't have the Mac port ready for F24. 14:09:26 #action sesivany Ask mbriza to send detailed info about blocking problems in python2 PyQt for Mac 14:09:50 for the Windows port 14:10:07 that should be pretty much ready as well as the linux version. 14:10:20 it's stuck on releng 14:10:28 there was some question about hosting the binaries ? 14:10:35 sesivany: stuck in what sense? 14:10:36 sesivany: I've successfully built single file applications for python on the mac in the past, but that was years ago, so I'm not sure I can provide that much active help. Still I'd be interested in hearing what the problems are. 14:11:18 they haven't proceeded much with it, moreover Dennis insists on building the whole build toolchain from source for it... 14:11:31 otaylor: ok, I'll tell him to contact you. 14:12:07 btw the testing Windows version is here: https://mbriza.fedorapeople.org/liveusb-creator.zip 14:12:18 mclasen: the build issue is part of your question of hosting binaries. The other part is how those binaries are to be included for mirrors 14:12:21 but built directly by Martin. 14:12:48 I'm not sure how we can speed up this. 14:12:51 stickster: fedora includes a whole cross-build toolchain for window, no ? 14:13:05 mclasen: mingw is what I assume you're talking about? 14:13:06 I was testing the Linux version of LUC from the COPR recently, and I notice that it has a ways to go to match the mockups in https://github.com/gnome-design-team/gnome-mockups/tree/master/USB-boot-creator 14:13:24 * linuxmodder * 14:13:43 When Martin told releng last year, they said they wouldn't do it, so he counted on building it himself, then it became a F24 feature and they changed that stance, but it's pretty late. 14:13:55 stickster: do we need to mirror them? the windows zip seems to be 35M, which is heavy in one sense, but still small compared to the distro 14:14:19 otaylor: When we're talking about a couple hundred thousand downloads, more at the outset of GA, mirroring is pretty important. 14:14:25 s/more/most/ 14:15:05 I would defer to nirik on this, though 14:15:29 mcatanzaro: I'm not sure if the mockups reflect the current design, there have been some iterrations between Martin and Jakub recently. 14:15:59 otaylor: But more importantly, this is something that probably should have been decided earlier in the change process, not three weeks before Beta 14:16:49 stickster: do we expect 100k downloads for the windows binary ? 14:17:00 that would imply a pretty stunning conversion rate of new users 14:17:31 mclasen: Probably not, I'm thinking of the overall downloads, of which that would only be a portion 14:17:42 A few thousand? Maybe not such a big deal 14:17:56 That could be hosted on alt.fp.o 14:18:11 wrt to the UI, I don't think 'matches the mockups to the pixel' is a knockout criterion - the UI needs to be useful and polished 14:18:26 sorry for being late 14:18:34 It seemed to be a huge improvement last time I looked at it (which admittedly was about 8 weeks ago) 14:19:13 it might also be good to add a brief how-to for the LUC on the magazine too around GA 14:19:45 similar to what we do for the how to upgrade posts 14:20:36 Putting aside the question of *where* we put things... sesivany, what's the state of e.g. flow for people to see the right info on website, clients getting to the right page, etc.? And does that plan include how to direct users of other distros? 14:21:18 stickster: the plan is to have it as primary download option for Windows users for now. 14:21:36 * mclasen puts luc on his list of apps to turn into an xdg-app 14:21:55 with RPM we cover only a portion of Linux users. 14:22:03 so I'd stay with ISO there. 14:22:36 sesivany: So does the websites team already have changes in to make that happen? 14:22:43 seseri, or we could just have a statically linked .tar.gz binary? 14:22:56 I think xdg-app is a good fit for this 14:22:57 err sesivany 14:23:02 cschalle: I think that's going to be hard with pyqt 14:23:08 ah 14:23:11 mclasen: +1 14:23:15 mclasen: It seems like it would be a good use case, yeah 14:23:21 and I'm not sure if it'd be the best experience... 14:23:28 * stickster catches up on notes 14:23:40 #info Windows binary is about 35M, not sure if we'll have enough downloads we need to mirror 14:23:43 I'm putting this on my list as the next app to look at 14:23:47 Let's not make this a main selling point to other distros for xdg-app though! 14:23:58 hehe 14:24:02 #info only change for websites being considered is to redirect Windows users to LUC as primary download for WS 14:24:11 stickster: Martin haven't discussed any specifics with the website team, until today I thought he kept them in the loop, but he waited until he solves issues with releng. 14:24:12 "get xdg-app support in your distro so your users can more easily install Fedora" :) 14:24:17 * mclasen suggests 'trojan' as new name for xdg-app 14:24:47 sesivany: True -- they'd need to know where the binary ends up to make the appropriate change, but the page design itself could be done ahead of time in a branch 14:24:56 using pyinstaller can be considered too 14:25:05 My primary concern is that I do not think the current UI qualifies as polished; to be blunt it looks like a poor imitation of a native (GTK+) app... but that's mostly just a theme problem, and I only tested it under GNOME on Linux; if we're only going to offer it to Windows users and offer plain ISOs for OS X and Linux, that's presumably not a problem. Could we see screenshots of the Windows version? 14:25:10 stickster: is there anyone particular to contact in this matter? 14:25:24 sesivany: My understanding is rel-eng will require the hosting of the binary to be figured out before Beta, so that's dgilmore + pbrobinson 14:25:25 Secondary concern: I really want to see the dd and MBR options removed. Those are too confusing to be in our primary deliverable. 14:26:17 stickster: I mean for the website design. 14:26:34 sesivany: The Fedora Design team, fortunately ryanlerch is here and part of that team :-) 14:26:47 sesivany: i can work on the websites portion 14:27:18 mcatanzaro: can we hide them or put them in advanced, there's certain use cases where they'd be useful (like support for a certain popular SBC where this tool should be useful too) 14:27:22 I'm not a designer, but I could easily see not having a wildly different download page itself, but more just making sure Windows clients end up there -- but that's a ryanlerch question 14:27:25 We can always do a middle step, offer the new LUC for F24 as we have had so far and make it primary download option for F25 when things settle down. 14:27:28 stickster: liveusb-creator? 14:27:38 mcatanzaro: It's a goal to have Qt as a development option for FEdora workstation, so if the theme isn't perfect, I don't think we should ding the app for that 14:27:42 stickster: we need to sort out a lot of issues with it yet 14:27:54 mostly about sanely building it 14:27:57 dgilmore: that's the topic of this part of the meeting 14:28:03 pbrobinson: Southern Baptist Convention? 14:28:10 I doubt we will be able to deliver it 14:28:25 mcatanzaro: Single Board Computer.... Fruit Pi things 14:30:19 dgilmore: can't or won't host a (essentially) 3rd-party binary? 14:31:31 rdieter: we are trying to work out how to build it 14:31:55 dgilmore: for what platforms? all of them? 14:32:04 rdieter: 14:32:06 dgilmore, which is fine, but I am not sure we want to block on building it on our servers 14:32:09 Can that be done with mingw for x86_64 only (which is mainly the folks to care about AIUI) 14:32:14 rdieter: I was told OSX is out for f24 14:32:21 it has too m any issues 14:32:30 so it is only windows 14:32:36 ok 14:32:50 We're pretty clearly not going to get an OS X buld though the build system any time soon, so maybe we need to rethink the strategy here? 14:32:52 stickster: apparently python needs massive patching to build with mingw 14:33:11 otaylor: mbriza said OSX is just not ready 14:33:19 its not that we can or can not build it 14:33:29 If for f25 if we have a OS X build, but can't distribute it because it wasn't built on our servers - we're going to have to figure out how to distribute it anyways 14:33:30 still, this seems a like a lot of work to implement a buildsys-only solution for what seems like a one-off windows tool 14:33:36 dgilmore, ok, but when it is ready is our infrastructure ready for it? 14:33:54 koji can build windows binaries 14:34:04 but I have no idea what licenses we would need 14:34:15 dgilmore: licenses for what? 14:34:19 dgilmore: but koji is building windows binaries via mingw cross-builds, and there is nothing like that for OS X 14:34:19 stickster: windows 14:34:41 otaylor: no, mingw will not work 14:34:53 otaylor: koji can build windows binaries in windows 14:35:01 is this primarily a policy decision then? to insist releng build the tool themselves? 14:35:03 not able to get luc to launch on 23 server with i3 at all works on xfce tho 14:35:04 are we doing htat for anything ? 14:35:17 building on windows in koji, I mean ? 14:35:23 mclasen: it has not yet been investigated 14:35:25 dgilmore: OK ... still I'm guessing OS X support for koji is *really* far down the releng priority list? 14:35:34 dgilmore, to take a step back, what problem are you trying to solve by rebuilding the binary? 14:35:38 no love for OSX ? 14:35:42 I do not know what we need to do licensing wise to get windows to build on 14:36:03 cschalle++ 14:36:05 need a signing key -- only blocker I'm aware of 14:36:08 dgilmore: We can *get* licenses through Red Hat channels, that's easy. 14:36:14 cschalle: we are trying to make sure that teh build is good and clean, that we can rebuild it easily if need be 14:36:37 we are trying to make sure we are not relying on a computer under someones desk 14:36:40 dgilmore, ok, but to be fair, that sounds more like a nice to have and not a blocker to me 14:36:50 cschalle: that is where we differ I guess 14:37:02 can OBS build windows and OSX binaries ? that should fit the 'rebuild easily' bill... 14:37:09 it is a must have for something that is the primary fedora deliverable 14:37:22 dgilmore: Let's get back to what is actually blocking here. 14:37:26 mclasen: OSX is off the table for now 14:37:32 because the code is not ready 14:37:38 OBS? 14:37:56 stickster: the ability to be sure of what we are shipping 14:38:10 ryanlerch: opensuse build system 14:38:11 mclasen: OSBS (OpenShift Build System)? or OBS (OpenSUSE Build System)? 14:38:14 we also have not looked at what we have to do for signing 14:38:14 dgilmore: But I think we need a plan that encompasses OS X as well 14:38:14 mclasen: ok, thanks 14:38:35 but you can read it as openshift if you want it less flame bait 14:38:42 otaylor: there is someon on the RCM team that is looking at OSX 14:38:47 mclasen: not flamey, don't worry 14:38:47 now that we know it is needed 14:38:49 singing key is $5k last I checked 14:39:10 might be able to poke a few M$ b2b dev channel folks I know tho 14:40:14 #info dgilmore says blocking factors are: (1) integrity of the bits we ship (needs to be built systematically in koji); (2) having Windows licenses for said koji builders; (3) signing binary 14:40:19 dgilmore: ^ did I miss anything there? 14:40:27 As far as I can tell, OBS supports Windows via mingw too, no mention of mac that I can find so far 14:40:51 * mclasen just confirmed that we are building and shipping software for OS X in RH 14:40:56 stickster: I think that is it 14:41:35 It doesn't sound like we've done the engineering work to build a .msi for the windows build, which I think we'd need to sign it- AFAIK (haven't researched it) you can't sign a .zip 14:42:02 dgilmore: OK. I think we can agree (2) is trivial to solve, we can request licenses at any time through Red Hat service channels internally 14:42:20 sesivany: are there plans around that? 14:42:20 stickster: I have no idea whats actually needed 14:42:31 dgilmore: "What's needed" in what sense? 14:42:31 stickster: I think internally we use MSDN licensing 14:42:38 dgilmore: No, they are two different things. 14:43:06 otaylor: around signing? 14:43:06 We can request Windows licenses separately and distinctly from any MSDN licenses 14:43:19 sesivany: around a .msi 14:43:22 stickster: I believe for the windows koji builds internally we are using software obtained under a MSDN license 14:43:33 (using wix or whatever) 14:43:43 dgilmore: That may be, because you *can* get Windows licenses that way. You just don't *have* to. 14:43:56 coming up on 45 minutes on this - do we have a clear idea of f24 goals here ? defer this all until f25 ? host binaries on alt.fp.org ? something else ? 14:44:05 mclasen: Thank you for the time check (srsly) 14:44:05 stickster: the way that koji works I do not think we can just get a windows licese 14:44:08 license 14:44:27 but I am not a lawyer 14:44:35 mclasen: if we postpone it, can we at least do the middle step? 14:44:58 dgilmore: we are not blocked legally here in any way I can see, so let's not overcomplicate this 14:45:18 ok, so might I suggest we take this into a separate meeting? and get mdmiller involved as I guess this has components of both 'how do we do something' and some questions about general Fedora policies 14:45:19 the actual problems are plenty :-) 14:45:21 mclasen: I mean to offer it the same way we have had the old LUC, make it available to users and make it primary download option for F25. 14:45:32 cschalle: That makes sense to me. 14:45:32 stickster: as a short term stop gap I am willing to build and ship something outside of koji. but I got push back from my boss on that 14:45:34 and then use the last minutes of this meeting for our other topics 14:46:08 stickster: we need to go to FESCo and check on one thing 14:46:27 stickster: that is if we need to build and ship all code 14:46:38 or if we can use vendor provided binaries 14:46:42 namely python and qt 14:47:16 dgilmore: for the windows LUC specifically, right? 14:47:29 dgilmore: So you just named a new, fourth blocker 14:47:37 ryanlerch: yes 14:47:49 stickster: sorry 14:47:58 I do think we need to check with fesco, but I can't see that this violates the mission of fedora in any way 14:47:59 I was talking to mbriza about it yesterday 14:48:11 #info (4) can we use vendor provided binaries (Python, Qt) to ship the Windows LUC 14:48:15 otaylor: esp. since it's FOSS 14:48:16 I know if it was in fedora we would say it has to all be built from source 14:48:31 well, it is; in fedora 14:48:39 I do not have a strong opinion eitehr way. but it needs to be a concious choice 14:48:40 otaylor: If it's an ideological question, that's probably for the Council 14:48:59 otaylor: there is no ideological question, Python and Qt are FOSS. 14:49:11 oops sorry otaylor... sgallagh ^ 14:49:22 Right 14:49:31 Anyway, someone already called time on this and I agree 14:49:33 * mclasen won't suggest to use the new I-cant-believe-its-not-ubuntu option of win10 to run the fedora binary 14:49:40 heh 14:49:42 stickster, well the idelogical question I guess would be if we can ship a binary not built with koji 14:50:00 Are we *shipping* that binary or only using it at build-time? 14:50:03 dgilmore: cschalle: sesivany: let's take this offline to #fedora-workstation or #fedora-releng 14:50:07 stickster: we ship it 14:50:15 ok 14:50:29 Also sesivany -- thank you for being here and participating, it made it much easier to identify where we're stuck :-) 14:50:35 * mclasen suggests "but its not run on fedora, so our purity is preserved" 14:51:00 mclasen: may be the case 14:51:11 and we may not want to make it harder on ourselves 14:51:12 stickster: ok, I'll ask Martin to send a detailed report on Windows and Mac ports when he's back at work. 14:51:13 Yeah, I could certainly get behind that statement 14:51:17 * mclasen mutters "firmware" for comparison 14:51:47 Hey, while we're on related topics... back to agenda 14:52:04 mclasen: when we asked to ship prebuilt u-boot we were told no because the source is available 14:52:14 ok next topic :) 14:52:37 #action cschalle sesivany dgilmore stickster to discuss further how to solve remaining blockers on LUC as primary d/l for Windows user conversion 14:52:41 also, without luc, people will probably use proprietary sw to make use of an install .iso on windows, so it is still a win for free sw 14:52:53 * stickster notes he has a hard stop at :00 for another meeting 14:53:09 #topic Follow-ups from next-gen Workstation rel-eng work 14:53:41 I sent a few status updates to the list 14:53:50 #info mclasen and stickster met with acarter a week or so back to talk about F25 workstation plans and deliverables 14:54:19 dking is on vacation this week, before he left he was trying to get an installer working, ran into some issues and out of time 14:54:58 #link https://fedoraproject.org/wiki/Workstation/BuildingXdgApps 14:55:08 #link https://fedoraproject.org/wiki/Changes/WorkstationOstree 14:55:28 mclasen: an installer of what working? 14:55:42 ryanlerch: rpm-ostree based Workstation I believe 14:55:50 an installer that installs from/with the ostree repo, instead of yum repos 14:56:07 the equivalent of the installer for fedora atomic 14:57:08 #info xdg-app building is part of this topic as well. We were solicited for rel-eng requirements for F25 a while ago and put that on the list -- our meeting with Amanda was about the first link above, trying to clarify the goal/requirement for F25 14:57:22 mclasen: as a side note, we got the ostree deliverables working in pungi this week, happy to start getting it enabled for rawhide 14:57:31 woop woop 14:58:02 dgilmore: cool 14:58:23 stickster: support for building xdg-apps, or runtimes/sdks, or both? 14:58:42 I guess you'll first put that in practice for atomic ? but we'd certainly like to follow along shortly afterward 14:59:22 ryanlerch: both 14:59:23 mclasen: I think there's also an important point we're missing, which is socializing and encouraging community awareness on xdg-app 14:59:29 ryanlerch: owen has been looking at ways to get xdg-app building integrated 14:59:37 well, not "missing" but maybe more like "we need to improve" 14:59:42 but with 30 seconds left, not sure how much he can summarize... 14:59:49 yeah, this is tricky. 14:59:56 cschalle: Would you like to take gavel? 14:59:58 I'm about 70% to a working prototype - it's along the lines ofthe linked to wiki page 15:00:00 #chair cschalle 15:00:00 Current chairs: cschalle mcatanzaro mclasen otaylor rdieter ryanlerch sesivany stickster 15:00:01 * mcatanzaro is encouraged to see GNOME Software installed by default in Ubuntu 16.04, but does it support installing xdg-apps like it does in Fedora? 15:00:19 stickster: we have an idea for the socializing part, that we are taking the first steps to preparing 15:01:11 cschalle: mclasen: ^^^ see above, take gavel please, I have to run 15:01:17 stickster, I don't actually know the IRC commands, so hopefully mclasen can do it 15:01:19 :) 15:01:26 remember that pound-endmeeting is how you close out here 15:01:41 wheeeeee next meeting 15:02:03 otaylor, any particular obstacles so far, or smooth ride ? 15:03:40 mclasen: Nothing too bad for obstacles, but I'm worried that the resulting patch is fairly small but more intrusive into existing parts of the code than I'd like - I think I'll need to spend some time explaining myself for why it makes sense :-) 15:05:00 * ryanlerch has to go too -- 1am here 15:05:02 mclasen: Maybe the koji developers will have better ideas about how to achieve the same thing 15:05:19 ryanlerch: good night! 15:05:28 night mclasen, night all! 15:06:28 * mcatanzaro going to call it, thanks guys 15:06:32 #endmeeting