Hi,
I was asked to come here and write a few words about the status of the new Fedora Media Writer for Fedora, in a few major points for now. I haven't read through the full meeting log yet so more stuff can follow down the thread.
== Mac OS X Support
I was not able yet to build a working .app package with the LiveUSB Creator for Mac. I have used probably every tool there is to freeze Python scripts while using direct Qt installs, Macports and Homebrew. Usually I hit issues either with missing dynamic library or broken QML imports. That means there's not a problem with the code itself but with the way how to distribute a usable package to the users.
If there is anyone looking to help me on that, I have uploaded just a basic source code package to [1]. It's just a simple PyQt5/QML application with just two source files but fundamentally the same as the FMW.
For now, I hope a Python3 port (yes, it's still Python2) will resolve this. An other option is just to ditch the horrible Python mess and rewrite the whole tool to a saner language that's actually portable.
== Design
I heard there are some raised voices regarding the design of the application, that it's not the same as the design on gnome-design-team's github. While there are some differences, I think they are mostly the same.
The main difference now is that now you can choose your achitecture with a radiobox set in the main window below the name of your chosen Fedora flavor instead of a small popup.
If you're concerned with the lack of headerbar usage, that's because the app is written in Qt - there's no direct support for putting anything into the header bar.
== Windows Support
Current plan is to distribute the application as a .exe installer created using NSI. Either the installer or the application (or both?) will have to be signed using a code signing certificate which we currently don't have but can be obtained for I think 14 euros per year for open source projects. As mentioned in the meeting yesterday, due to a communication hiccup between me and releng, I expected I will be the one building and signing the Windows package.
Now we're trying to resolve this with dgilmore. Currently it seems we'll have to have a Windows machine running the builds or use upstream binary packages in Wine because it's not possible to just compile upstream Python using MinGW - it'd have to be heavily patched with some shady patches lying on random peoples' blogs.
For future releases, it would be good to provide this as a single self-extracting interpreter, though - in a similar way Windows installer itself does it.
That's about it for now. I guess there will be questions and I'm here to answer them.
Martin
On Thu, 2016-04-14 at 11:31 +0200, Martin Bříza wrote:
Now we're trying to resolve this with dgilmore. Currently it seems we'll have to have a Windows machine running the builds or use upstream binary packages in Wine because it's not possible to just compile upstream Python using MinGW - it'd have to be heavily patched with some shady patches lying on random peoples' blogs.
Not ideal, but slightly better than random people's blogs, there is this:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2
These are packages for Arch Linux (the same way we have mingw-* packages in Fedora), with patches when necessary.
From my earlier discussins with them, the Python patches had been partly submitted upstream, but never really merged.
Python3 might be better and require less patching, I'm not sure.
-- Mathieu
On Thu, Apr 14, 2016 at 11:31:06AM +0200, Martin Bříza wrote:
Now we're trying to resolve this with dgilmore. Currently it seems we'll have to have a Windows machine running the builds or use upstream binary packages in Wine because it's not possible to just compile upstream Python using MinGW - it'd have to be heavily patched with some shady patches lying on random peoples' blogs.
Once built, is there a plan for getting this onto the mirror network? If we make this the main download for Windows users, but don't mirror it, I'm afraid our central infrastructure will fall over under the load on release day.
(Infrastructure team, feel free to tell me if you're not worried about that.)
On Thursday, April 14, 2016 10:34:28 AM CDT Matthew Miller wrote:
On Thu, Apr 14, 2016 at 11:31:06AM +0200, Martin Bříza wrote:
Now we're trying to resolve this with dgilmore. Currently it seems we'll have to have a Windows machine running the builds or use upstream binary packages in Wine because it's not possible to just compile upstream Python using MinGW - it'd have to be heavily patched with some shady patches lying on random peoples' blogs.
Once built, is there a plan for getting this onto the mirror network? If we make this the main download for Windows users, but don't mirror it, I'm afraid our central infrastructure will fall over under the load on release day.
(Infrastructure team, feel free to tell me if you're not worried about that.)
We have not yet decided where it will live. mirros are one option. the other is just on the proxy/app servers, we also have recently been donated bandwidtha nd hosting on a cdn, perhaps its something we can put on the cdn
Dennis
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Chris Murphy
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use.
On Thursday, April 14, 2016 3:33:46 PM CDT Bastien Nocera wrote:
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
We will only be shipping code that is signed.
Dennis
On Thu, Apr 14, 2016 at 1:56 PM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 3:33:46 PM CDT Bastien Nocera wrote:
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
We will only be shipping code that is signed.
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDis...
As far as I can tell, such code signing applications or installer packages is only possible in XCode, and XCode only runs on OS X, and to get a Developer ID certificate requires belonging to the Apple Developer Program, which requires agreeing to a EULA. If Red Hat is already a Apple Developer Enterprise Program member, great. If not, I'd advise any Fedora developer ask Fedora legal to review that EULA before they agree to it.
On Thursday, April 14, 2016 4:57:31 PM CDT Chris Murphy wrote:
On Thu, Apr 14, 2016 at 1:56 PM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 3:33:46 PM CDT Bastien Nocera wrote:
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.or g
We will only be shipping code that is signed.
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDis tributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutsi de.html
As far as I can tell, such code signing applications or installer packages is only possible in XCode, and XCode only runs on OS X, and to get a Developer ID certificate requires belonging to the Apple Developer Program, which requires agreeing to a EULA. If Red Hat is already a Apple Developer Enterprise Program member, great. If not, I'd advise any Fedora developer ask Fedora legal to review that EULA before they agree to it.
https://www.digicert.com/code-signing/mac-os-codesign-tool.htm says we need a cert and use their codesign tool
Dennis
On Fri, Apr 15, 2016 at 8:40 AM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 4:57:31 PM CDT Chris Murphy wrote:
On Thu, Apr 14, 2016 at 1:56 PM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 3:33:46 PM CDT Bastien Nocera wrote:
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.or g
We will only be shipping code that is signed.
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDis tributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutsi de.html
As far as I can tell, such code signing applications or installer packages is only possible in XCode, and XCode only runs on OS X, and to get a Developer ID certificate requires belonging to the Apple Developer Program, which requires agreeing to a EULA. If Red Hat is already a Apple Developer Enterprise Program member, great. If not, I'd advise any Fedora developer ask Fedora legal to review that EULA before they agree to it.
https://www.digicert.com/code-signing/mac-os-codesign-tool.htm says we need a cert and use their codesign tool
Nope. I don't even know the point of that service or tool, especially seeing as it references a 17 year old OS.
"If you try to open an app that is not registered with Apple by an identified developer you get a warning dialog." https://support.apple.com/kb/PH21769?locale=en_US
Slightly older version of the warning dialog the user sees: http://windows.intowindows.netdna-cdn.com/wp-content/uploads/2014/05/cant-be...
If you want to get past Gatekeeper, your application has to be signed within the Apple ecosystem. If you want it signed by some 3rd party, then it'll still get flagged by the OS, and then the user is on their own when it comes to verifying that signature.
On Fri, Apr 15, 2016 at 9:50 AM, Chris Murphy lists@colorremedies.com wrote:
On Fri, Apr 15, 2016 at 8:40 AM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 4:57:31 PM CDT Chris Murphy wrote:
On Thu, Apr 14, 2016 at 1:56 PM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 14, 2016 3:33:46 PM CDT Bastien Nocera wrote:
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.or g
We will only be shipping code that is signed.
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDis tributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutsi de.html
As far as I can tell, such code signing applications or installer packages is only possible in XCode, and XCode only runs on OS X, and to get a Developer ID certificate requires belonging to the Apple Developer Program, which requires agreeing to a EULA. If Red Hat is already a Apple Developer Enterprise Program member, great. If not, I'd advise any Fedora developer ask Fedora legal to review that EULA before they agree to it.
https://www.digicert.com/code-signing/mac-os-codesign-tool.htm says we need a cert and use their codesign tool
https://www.digicert.com/code-signing/apple-certificates.htm
Here we go... "You can use a DigiCert Code Signing Certificate (standard and EV) to sign your Mac OS X software, tools, updates, utilities and applications. However if you want your apps to open on a Mac that has Gatekeeper enabled or want to distribute apps in the App Store, you may consider creating a developer ID to sign your Mac apps and installer packages."
Yeah, if nobody already got such an account we can use I am sure I can find 100 dollars in the budget to cover this.
Christian
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Thursday, April 14, 2016 3:33:46 PM Subject: Re: The status of Fedora Media Writer (was LiveUSB Creator)
----- Original Message -----
From the workstation meeting notes apr.13
14:06:46 <sesivany> 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.
What's meant by "single installation file"?
If Fedora Media Writer on OS X will be a self-contained .app (directory of all resources, the .app extension makes it appear as a single file to the user) then there are multiple ways to deliver that. It can be tar.gz, zip, or dmg. User double clicks, then drags the application to /Applications or ~/Applications or can even run the program from ~/Downloads if they want. If it's not signed, by default they get a message and have to go elsewhere to allow it to launch but that's fairly well understood at this point by most users.
Can't Red Hat pay the $100 bucks to have a developer account and have it signed?
I'm pretty sure we have some people with developer accounts internally as well, and it would be better to make it as easy as possible to use. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Signing is not the problem. PyQt and the freezing mechanisms are. As I mentioned in the first post in the thread, different tools have different issues but most often it's broken dynamic linking or broken QML imports.
Hi, update here: Fedora Media Writer as a primary downloadable was postponed to F25 for building and mainly legal reasons, logs from the FESCo meeting: https://meetbot.fedoraproject.org/fedora-meeting/2016-04-22/fesco.2016- 04-22-17.00.log.html It turned out that distributing a Windows build is a difficult task to do for Fedora. So for Fedora 24, Martin will be distributing the Windows version himself and we will at least link to it as recommended option on the wiki the same way we did for the old LUC. For F25 we're very inclined to just completely rewrite it to Qt/C++ because: 1. the current codebase is hard to maintain, 2. it would simplify building and legal review of the Windows version, 3. it would allow us to do the Mac port.
Jiri
Well lets look at this as we move forward, personally I don't think investing time and money into having a full Windows and MacOS X harness hosted by Fedora is a good use of time or money and the so called 'legal' issues seemed rather random.
Christian
----- Original Message -----
From: "Jiri Eischmann" eischmann@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, April 22, 2016 3:22:10 PM Subject: The status of Fedora Media Writer: postponed to F25
Hi, update here: Fedora Media Writer as a primary downloadable was postponed to F25 for building and mainly legal reasons, logs from the FESCo meeting: https://meetbot.fedoraproject.org/fedora-meeting/2016-04-22/fesco.2016- 04-22-17.00.log.html It turned out that distributing a Windows build is a difficult task to do for Fedora. So for Fedora 24, Martin will be distributing the Windows version himself and we will at least link to it as recommended option on the wiki the same way we did for the old LUC. For F25 we're very inclined to just completely rewrite it to Qt/C++ because:
- the current codebase is hard to maintain,
- it would simplify building and legal review of the Windows version,
- it would allow us to do the Mac port.
Jiri
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, Apr 25, 2016 at 08:26:43AM -0400, Christian Schaller wrote:
Well lets look at this as we move forward, personally I don't think investing time and money into having a full Windows and MacOS X harness hosted by Fedora is a good use of time or money and the so called 'legal' issues seemed rather random.
I'm confident the legal issues can be worked out. However, we definitely need to be concerned with security and repeatably as well; we don't want to make binaries built on a developer's personal laptop be our main downloadable. I'm not sure exactly what you mean by "full Windows and MacOS X harness".
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, April 27, 2016 2:07:57 PM Subject: Re: The status of Fedora Media Writer: postponed to F25
On Mon, Apr 25, 2016 at 08:26:43AM -0400, Christian Schaller wrote:
Well lets look at this as we move forward, personally I don't think investing time and money into having a full Windows and MacOS X harness hosted by Fedora is a good use of time or money and the so called 'legal' issues seemed rather random.
I'm confident the legal issues can be worked out. However, we definitely need to be concerned with security and repeatably as well; we don't want to make binaries built on a developer's personal laptop be our main downloadable. I'm not sure exactly what you mean by "full Windows and MacOS X harness".
My point was that we are not going into the business of making Mac and Windows software on a large scale, so demanding the same process and that we have the kind of facilities we have for building Fedora and Linux software is a crazy overkill. It goes into the old joke that when you ask an engineer to solve a problem instead of spending 5 minutes solving it he/she spends 5 Months creating a framework for solving problems like it, and that is what I am warning against here. We need to focus on solving our challenges efficiently and choose solutions that are proportional to the scope of the problem, not rat holing ourselves.
So while it of course would be wonderful to have a full fledged Windows and Mac harness that matches what we have for building Fedora, considering the size of the problem I think having something a lot simpler would be more appropriate to the size of the challenge we are having here. So a shared office Mac or shared office Windows system might be enough.
Christian
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Wed, 2016-04-27 at 14:53 -0400, Christian Schaller wrote:
I'm confident the legal issues can be worked out. However, we definitely need to be concerned with security and repeatably as well; we don't want to make binaries built on a developer's personal laptop be our main downloadable. I'm not sure exactly what you mean by "full Windows and MacOS X harness".
My point was that we are not going into the business of making Mac and Windows software on a large scale, so demanding the same process and that we have the kind of facilities we have for building Fedora and Linux software is a crazy overkill. It goes into the old joke that when you ask an engineer to solve a problem instead of spending 5 minutes solving it he/she spends 5 Months creating a framework for solving problems like it, and that is what I am warning against here. We need to focus on solving our challenges efficiently and choose solutions that are proportional to the scope of the problem, not rat holing ourselves.
So while it of course would be wonderful to have a full fledged Windows and Mac harness that matches what we have for building Fedora, considering the size of the problem I think having something a lot simpler would be more appropriate to the size of the challenge we are having here. So a shared office Mac or shared office Windows system might be enough.
Of course, if we were building FMW as a cross-distro project with all the other distros who need something exactly like it, we could be sharing all that work and taking advantage of other people's expertise in those areas...
----- Original Message -----
From: "Adam Williamson" adamwill@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, April 27, 2016 3:22:16 PM Subject: Re: The status of Fedora Media Writer: postponed to F25
On Wed, 2016-04-27 at 14:53 -0400, Christian Schaller wrote:
I'm confident the legal issues can be worked out. However, we definitely need to be concerned with security and repeatably as well; we don't want to make binaries built on a developer's personal laptop be our main downloadable. I'm not sure exactly what you mean by "full Windows and MacOS X harness".
My point was that we are not going into the business of making Mac and Windows software on a large scale, so demanding the same process and that we have the kind of facilities we have for building Fedora and Linux software is a crazy overkill. It goes into the old joke that when you ask an engineer to solve a problem instead of spending 5 minutes solving it he/she spends 5 Months creating a framework for solving problems like it, and that is what I am warning against here. We need to focus on solving our challenges efficiently and choose solutions that are proportional to the scope of the problem, not rat holing ourselves.
So while it of course would be wonderful to have a full fledged Windows and Mac harness that matches what we have for building Fedora, considering the size of the problem I think having something a lot simpler would be more appropriate to the size of the challenge we are having here. So a shared office Mac or shared office Windows system might be enough.
Of course, if we were building FMW as a cross-distro project with all the other distros who need something exactly like it, we could be sharing all that work and taking advantage of other people's expertise in those areas... --
Well there is nothing stopping anyone from taking the FMW code and releasing their version of it for their own stuff, it is all GPL. And it is not like we are trying in any form to hide the code or make that process hard.
Christian
On Wed, Apr 27, 2016 at 02:53:41PM -0400, Christian Schaller wrote:
So while it of course would be wonderful to have a full fledged Windows and Mac harness that matches what we have for building Fedora, considering the size of the problem I think having something a lot simpler would be more appropriate to the size of the challenge we are having here. So a shared office Mac or shared office Windows system might be enough.
If the security team will sign off on that as adequate, I'm fine with it.
Fedora 23 documentation "Preparing Boot Media" currently says to use SUSE Studio ImageWriter or Rawrite32. Is this still valid for Fedora 24?
Link to doc: https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-...
Either way, this docs bug/change request should be updated to reflect the Fedora 24 recommendation.
LiveUSB Creator as recommended tool for media creation https://bugzilla.redhat.com/show_bug.cgi?id=1318103
On Fri, Apr 29, 2016 at 2:23 PM, Chris Murphy lists@colorremedies.com wrote:
Fedora 23 documentation "Preparing Boot Media" currently says to use SUSE Studio ImageWriter or Rawrite32. Is this still valid for Fedora 24?
Link to doc: https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-...
Either way, this docs bug/change request should be updated to reflect the Fedora 24 recommendation.
LiveUSB Creator as recommended tool for media creation https://bugzilla.redhat.com/show_bug.cgi?id=1318103
Rats. The above applies specifically for creating Fedora install media on Windows.
This is sad to see, but I understand this decision.
Because one time I was trying to build one software for Windows, using MinGW. It was written using C++ and Qt5, as Fedora Media Writer are. And it was hell. So, I just dropped and forgot about it. Another guy with Windows as primary system did it instead of me.
P.S. Then this feature proposal was first introduced, and I have seen news article on phoronix with wireframe images, I thought it was rewritten for GNOME (GTK3, glib2, and etc).
I think the correct way to look at it is that we rewrote/updated it for Fedora Workstation, including revising the UI to fit in with UI paradigms of the desktop we ship in Workstation (GNOME). That said we did not bother moving it to GTK+ as we could do what we wanted while keeping it Qt, and with Qt's focus on being cross platform we thought it would probably make things easier. This last item did not work out as planned due to state of Qt Python bindings, but C'est la vie.
Christian
----- Original Message -----
From: "Egor Zaharov" nexfwall@gmail.com To: desktop@lists.fedoraproject.org Sent: Monday, April 25, 2016 10:40:27 AM Subject: Re: The status of Fedora Media Writer: postponed to F25
This is sad to see, but I understand this decision.
Because one time I was trying to build one software for Windows, using MinGW. It was written using C++ and Qt5, as Fedora Media Writer are. And it was hell. So, I just dropped and forgot about it. Another guy with Windows as primary system did it instead of me.
P.S. Then this feature proposal was first introduced, and I have seen news article on phoronix with wireframe images, I thought it was rewritten for GNOME (GTK3, glib2, and etc). -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, 25 Apr 2016 17:00:16 +0200, Christian Schaller cschalle@redhat.com wrote:
I think the correct way to look at it is that we rewrote/updated it for Fedora Workstation, including revising the UI to fit in with UI paradigms of the desktop we ship in Workstation (GNOME). That said we did not bother moving it to GTK+ as we could do what we wanted while keeping it Qt, and with Qt's focus on being cross platform we thought it would probably make things easier. This last item did not work out as planned due to state of Qt Python bindings, but C'est la vie.
Christian
While I'd understand that decision, there is still much less work to while sticking to Qt while using C++. Most of the code can be ported 1:1. If there's something implemented Python libraries, there's usually a Qt counterpart. There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there. C++/Qt also has the value added of having a complete and functional toolset for creating portable application packages on both Windows and Mac which should work without any tweaking. Overall I think using C++ would give us _much_ easier portability and more reliable codebase. Plus we'd have a smaller binary to distribute since it wouldn't require a Python interpreter.
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
On Wed, 27 Apr 2016 20:09:04 +0200, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
It fetches the release list, links to downloads, marketing text and screenshots from getfedora.org, spins.fp.o and labs.fp.o.
On Thu, Apr 28, 2016 at 10:38:58AM +0200, Martin Bříza wrote:
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
It fetches the release list, links to downloads, marketing text and screenshots from getfedora.org, spins.fp.o and labs.fp.o.
We should make that available in a away that doesn't require screen-scraping.
See https://fedorahosted.org/rel-eng/ticket/5805, as well as some of the discussion in https://fedorahosted.org/rel-eng/ticket/5654
On Thursday, April 28, 2016 8:37:00 AM CDT Matthew Miller wrote:
On Thu, Apr 28, 2016 at 10:38:58AM +0200, Martin Bříza wrote:
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
It fetches the release list, links to downloads, marketing text and screenshots from getfedora.org, spins.fp.o and labs.fp.o.
We should make that available in a away that doesn't require screen-scraping.
See https://fedorahosted.org/rel-eng/ticket/5805, as well as some of the discussion in https://fedorahosted.org/rel-eng/ticket/5654
We are looking at making changes in f25 so that we can put the compose metadata on the mirrors. it is some json files. you can see an example https://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160504.n.0/ compose/metadata/ you probably will need images.json
Dennis
On Wed, 04 May 2016 18:01:26 +0200, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, April 28, 2016 8:37:00 AM CDT Matthew Miller wrote:
On Thu, Apr 28, 2016 at 10:38:58AM +0200, Martin Bříza wrote:
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
It fetches the release list, links to downloads, marketing text and screenshots from getfedora.org, spins.fp.o and labs.fp.o.
We should make that available in a away that doesn't require screen-scraping.
See https://fedorahosted.org/rel-eng/ticket/5805, as well as some of the discussion in https://fedorahosted.org/rel-eng/ticket/5654
We are looking at making changes in f25 so that we can put the compose metadata on the mirrors. it is some json files. you can see an example https://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160504.n.0/ compose/metadata/ you probably will need images.json
Dennis
This is very good. If there was some marketing info included, this would be all we need in FMW. Or maybe we could figure out some other way how to provide that in a sane way.
On Thu, May 05, 2016 at 12:16:40PM +0200, Martin Bříza wrote:
We should make that available in a away that doesn't require screen-scraping. See https://fedorahosted.org/rel-eng/ticket/5805, as well as some of the discussion in https://fedorahosted.org/rel-eng/ticket/5654
This is very good. If there was some marketing info included, this would be all we need in FMW. Or maybe we could figure out some other way how to provide that in a sane way.
I don't think we want to put marketing info in the json, but maybe it could contain a metadata field giving a URL where it can be found, and then we can include it as part of the websites somewhere?
On Wed, 2016-05-04 at 11:01 -0500, Dennis Gilmore wrote:
On Thursday, April 28, 2016 8:37:00 AM CDT Matthew Miller wrote:
On Thu, Apr 28, 2016 at 10:38:58AM +0200, Martin Bříza wrote:
On Mon, Apr 25, 2016 at 05:19:24PM +0200, Martin Bříza wrote:
There are some exceptions like reading data from the websites which should be possible to be done using jQuery directly (current code uses PyQuery which works on the same principle) and probably some bits here and there.
Where does data need to be read from the websites?
It fetches the release list, links to downloads, marketing text and screenshots from getfedora.org, spins.fp.o and labs.fp.o.
We should make that available in a away that doesn't require screen-scraping.
See https://fedorahosted.org/rel-eng/ticket/5805, as well as some of the discussion in https://fedorahosted.org/rel-eng/ticket/5654
We are looking at making changes in f25 so that we can put the compose metadata on the mirrors. it is some json files. you can see an example https://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160504.n.0/ compose/metadata/ you probably will need images.json
Also there's fedfind.
import fedfind.release f23 = fedfind.release.get_release(23) print(f23.location) for img in f23.all_images: print(img['path']) f24b = fedfind.release.get_release(24, 'Beta', '1.6') print(f24b.location) for img in f24b.all_images: print(img['path'])
when the Beta is properly released: fedfind.release.get_release(24, 'Beta') will find it. You can also pass get_release a compose ID:
fedfind.release.get_release(cid='Fedora-24-20160505.n.0')
a label:
fedfind.release.get_release(release=24, label='Beta-1.6')
or a URL - the URL to the 'compose/' path of a Pungi 4 compose, or the URL to a 2-week Atomic compose:
fedfind.release.get_release(url='https://dl.fedoraproject.org/pub/alt/atomic/testing/23-20160505/') fedfind.release.get_release(url='https://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160505.n.0/c...')
fedfind tries to provide a consistent interface between 'releases' that have Pungi 4 metadata and ones that don't. It does this by synthesizing metadata in the Pungi 4 / productmd style for releases that don't have it: old stable releases, two-week atomic releases, and releases that were built with Pungi 4 but have had the metadata stripped when they were moved. So you can treat 'f23' just like 'f24b' in my example, even though 'f23' has no Pungi 4 metadata.
The items in the 'all_images' list are dicts in the productmd 'images.json' style, flattened out and with the 'variant' stuffed into each image dict.
there is a whole lot of quirkiness and detail about Fedora 'releases' (where they show up, where they move to, and what they're called, and what exactly you should get when you say "where is Fedora 24 Beta?") and fedfind's job is to try and make that as easy to deal with as I can manage without going insane. I promise to keep it working until everything is all Pungi 4 all the time, or I go stark raving bonkers and buy a yak farm.
On Mon, 25 Apr 2016 16:40:27 +0200, Egor Zaharov nexfwall@gmail.com wrote:
This is sad to see, but I understand this decision.
Because one time I was trying to build one software for Windows, using MinGW. It was written using C++ and Qt5, as Fedora Media Writer are. And it was hell. So, I just dropped and forgot about it. Another guy with Windows as primary system did it instead of me.
P.S. Then this feature proposal was first introduced, and I have seen news article on phoronix with wireframe images, I thought it was rewritten for GNOME (GTK3, glib2, and etc).
The situation in this case is even worse due to the fact the project uses Python instead of C++. Python binaries for Windows have to be compiled using MSVC or patched heavily by non-upstream patches to be possible to compile it with MinGW. Then there are some other Python libraries required to make it run on Windows.
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Chris Murphy -
Christian Schaller -
Dennis Gilmore -
Egor Zaharov -
Jiri Eischmann -
Martin Bříza -
Mathieu Bridon -
Matthew Miller