Hello guys! :)
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
----------------
I would like to inform you that Ghostscript package has received proper cleanup in accordance to Fedora Packaging Guidelines (FPG), and comments from upstream were also incorporated into the changes.
The aim was to simplify the package maintenance, to bring the Fedora's Ghostscript package as close as possible to upstream's vanilla build, to completely debundle the Ghostscript package of software/resources that we already have available (packaged) in Fedora, and to transform the layout of subpackages to be more sane and granular...
The changes are described more in detail below:
* libijs -- the IJS library has been debundled and is now provided as a separate package: https://src.fedoraproject.org/rpms/libijs
* libgs -- new separate package, created from Ghostscript's shared library. It contains all necessary files for other software/packages that are build upon Ghostscript's functionality. * libgs-devel -- new separate subpackage, for development purposes or Fedora's build process. The 'ghostscript-devel' is still provided for now as a virtual subpackage.
->> This particular change will allow packages depending on Ghostscript functionality (like evince for example) to only require 'libgs', instead of requiring almost the whole Ghostscript (and thus pulling in files that many users don't want/need or might even never use).
* ghostscript -- is no longer a metapackage. It's a regular package instead, and it contains Ghostscript's binaries as well as some typical conversion scripts people are used to (and expect to have installed together with Ghostscript by default).
* ghostscript-tools-fonts -- new subpackage that contains 3 scripts that are useful only for people who are working with AFM, PFB or PFA files (conversions usually). * ghostscript-tools-printing -- new subpackage that contains only utilities for formatting and printing text files using either Ghostscript, or BubbleJet, DeskJet, DeskJet 500, & LaserJet printers.
->> These subpackages contain files that only a small amount of people will ever need. Having them in a separate subpackages will avoid polluting users' filesystem after fresh F28+ installations.
* ghostscript-core -- has became an empty metapackage for upgrade purposes. It will be removed once Fedora 28 is EOL, and all other packages has updated their specfiles to require correct subpackages.
->> This metapackage makes sure that upgrade from old package layout to new package layout should be smooth (tested in F27).
* LPR setup scripts are no longer being shipped. In case people still need those, then 'ghostscript-tools-lpr' will be created for it. * examples/ from 'ghostscript-doc' are no longer shipped. * Documentation and resources paths no longer contain version string inside of them.
* Support for /usr/share/ghostscript/conf.d/ folder was dropped to use Ghostscript's default choice for rendering of CJK glyphs, which is Google Droid Sans Fallback font. In case this proves insufficient, the conf.d/ folder support will be re-established.
->> This change is still being discussed with Peng Wu and Akira Tagoh. So far, we have agreed to this change, but I will be ready to revert it in case people depending on printing CJK-based texts will have any problems. In case the Ghostscript's default functionality would prove to be sufficent and work OK, then the 'ghostscript-chinese' package could be retired as a result. ->> For now, we are also waiting for rebase of 'google-droid-fonts' for Ghostscript to have the latest version of Droid Sans Fallback font and thus the latest CJK glyphs coverage.
* Symbolic links for direct resources locations have been added to speedup Ghostscript's startup time. * Ghostscript's search path was updated to include only fonts locations, which will be used only as a backup (in case of broken symbolic links).
->> This change is a preferred method (advised) from upstream.
* Ghostscript itself (as a whole) has been completely debundled (to a point where it still makes sense). It newly requires these packages:
https://src.fedoraproject.org/rpms/adobe-mappings-cmap https://src.fedoraproject.org/rpms/adobe-mappings-pdf https://src.fedoraproject.org/rpms/libijs https://src.fedoraproject.org/rpms/urw-base35-fonts https://src.fedoraproject.org/rpms/google-droid-fonts
->> I will send additional separate e-mails to this mailing list tomorrow to inform others of availability of some of these packages.
* As a result of debundling, 'poppler-data' is no longer a requirement for Ghostscript, and it is no longer necessary to do a rebuild of 'poppler-data' when Ghostscript is rebased.
----------------------
These changes shouldn't influence most of the users in any significant way. Some of Fedora developers might need to update their specfiles to require correct new (sub)package names. For that I will create a new tracking BZ for all related packages, and I will create necessary pull-requests on Pagure, or open corresponding BZs if pull-requests are disabled.
The new Ghostscript should be available for trying/testing in Rawhide in a few hours. I will follow up with additional information (e.g. tracking BZ link) here in this thread.
Best regards,
David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat http://www.redhat.com/en/about/trusted.
On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
As far as I understand, this is going to affect how other packages are built, installed, and run. It should be reviewed by the affected parties to decide whether it is a self-contained or system-wide change and the respective process should be followed.
The new Ghostscript should be available for trying/testing in Rawhide in a few hours. I will follow up with additional information (e.g. tracking BZ link) here in this thread.
It would be better to create a Copr for testing purposes to avoid disruption of Fedora development.
Kamil
On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
As far as I understand, this is going to affect how other packages are built, installed, and run. It should be reviewed by the affected parties to decide whether it is a self-contained or system-wide change and the respective process should be followed.
The new Ghostscript should be available for trying/testing in Rawhide in a few hours. I will follow up with additional information (e.g. tracking BZ link) here in this thread.
It would be better to create a Copr for testing purposes to avoid disruption of Fedora development.
+1 (or a tag). Lots of stuff hangs off of ghostscript. It'd be nice to have the implications of this at least broadly figured out in advance rather than "doing it live" in Rawhide.
On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
The new Ghostscript should be available for trying/testing in Rawhide
in a
few hours. I will follow up with additional information (e.g. tracking
BZ
link) here in this thread.
It would be better to create a Copr for testing purposes to avoid
disruption
of Fedora development.
+1 (or a tag). Lots of stuff hangs off of ghostscript. It'd be nice to have the implications of this at least broadly figured out in advance rather than "doing it live" in Rawhide.
I was trying to make the F28 planning phase deadline, in case people would require to create System-wide / Self-contained change wiki page for it. In the rush I didn't think of your point, and automatically submitted 'fedpkg build'.
But I agree with your point. I will try to be more aware of this in the future, to not repeat this mistake again.
On Tue, Jan 9, 2018 at 5:51 PM, David Kaspar [Dee'Kej] dkaspar@redhat.com wrote:
Hello guys! :)
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
Overall, I think this is awesome. Just some questions and nits below...
->> These subpackages contain files that only a small amount of people will ever need. Having them in a separate subpackages will avoid polluting users' filesystem after fresh F28+ installations.
- ghostscript-core -- has became an empty metapackage for upgrade purposes.
It will be removed once Fedora 28 is EOL, and all other packages has updated their specfiles to require correct subpackages.
->> This metapackage makes sure that upgrade from old package layout to new package layout should be smooth (tested in F27).
Is there a specific bug that forces us to require we have transitional packages like this? RPM's Conflicts+Obsoletes logic is powerful enough to allow us to avoid this.
- LPR setup scripts are no longer being shipped. In case people still need
those, then 'ghostscript-tools-lpr' will be created for it.
- examples/ from 'ghostscript-doc' are no longer shipped.
- Documentation and resources paths no longer contain version string inside
of them.
Why are examples not shipped? For documentation, this seems to be fine, especially since it's a separate subpackage anyway.
- Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
Ghostscript's default choice for rendering of CJK glyphs, which is Google Droid Sans Fallback font. In case this proves insufficient, the conf.d/ folder support will be re-established.
->> This change is still being discussed with Peng Wu and Akira Tagoh. So far, we have agreed to this change, but I will be ready to revert it in case people depending on printing CJK-based texts will have any problems. In case the Ghostscript's default functionality would prove to be sufficent and work OK, then the 'ghostscript-chinese' package could be retired as a result. ->> For now, we are also waiting for rebase of 'google-droid-fonts' for Ghostscript to have the latest version of Droid Sans Fallback font and thus the latest CJK glyphs coverage.
I'm confused why we would drop support for conf.d directories. Unless it's completely unavoidable, I don't see why we would do this. We can't possibly know of everyone who might be using them, and generally speaking, I'd like to see more software configurable this way, not less.
On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa ngompa13@gmail.com wrote:
Is there a specific bug that forces us to require we have transitional packages like this? RPM's Conflicts+Obsoletes logic is powerful enough to allow us to avoid this.
I'm not aware of any BZ/Fedora wiki page that is requiring this. This solution was based solely on my best judgment. To clarify on this:
The 'ghostscript-core' is a "main" subpackage in previous subpackage scheme. It basically contained almost everything from Ghostscript's compilation, and IIRC few of other packages were requiring this package directly in their specfiles...
Other packages were not yet updated to requires correct subpackage from new subpackage layout. Therefore I decided to transform 'ghostscript-core' into auxiliary subpackage, since it was already there.
This should have allowed new Ghostscript to be rolled out without breaking build process for them (hopefully completely, or at least it should at mitigate most of the problems). And the other packages can be then rebuild immediately once their requirements have been appropriately updated. :)
Why are examples not shipped? For documentation, this seems to be
fine, especially since it's a separate subpackage anyway.
Upstream has decided to drop the examples/ completely from the next version of Ghostscript release (9.23). According to them those files are more useful for testing purposes rather than actual examples, and those files are poorly written PostScript files. They wouldn't help people who would like to learn how to write PostScript documents. That's why upstream does not want to ship those files anymore.
Since I was doing changes to contents/layout of Ghostscript, I thought it was a good time to incorporate this change into the package already.
- Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
Ghostscript's default choice for rendering of CJK glyphs, which is Google Droid Sans Fallback font. In case this proves insufficient, the conf.d/ folder support will be re-established.
->> This change is still being discussed with Peng Wu and Akira Tagoh. So far, we have agreed to this change, but I will be ready to revert it in
case
people depending on printing CJK-based texts will have any problems. In
case
the Ghostscript's default functionality would prove to be sufficent and
work
OK, then the 'ghostscript-chinese' package could be retired as a result. ->> For now, we are also waiting for rebase of 'google-droid-fonts' for Ghostscript to have the latest version of Droid Sans Fallback font and
thus
the latest CJK glyphs coverage.
I'm confused why we would drop support for conf.d directories. Unless it's completely unavoidable, I don't see why we would do this. We can't possibly know of everyone who might be using them, and generally speaking, I'd like to see more software configurable this way, not less.
The folder /usr/share/ghostscript/conf.d/ actually comes from the package 'ghostscript-chinese'. Ghostscript itself was just configured to check that folder for configuration before, if there was any.
The folder itself contained mappings for specific locales into specific CJK-based fonts. It was used only after 'ghostscript-chinese' was installed. This solution was introduced into Ghostscript more than a decade ago, and it is based on this project: https://www.freedesktop.org/wiki/Software/ CJKUnifonts/
If you look at the project, you will that it is basically dead, and the 'ghostscript-chinese' package itself received last update in 2012.
The main purpose of using 'ghostscript-chinese' is to introduce a workaround for displaying/printing of CJK-based documents which do not have the correct font embedded (for displaying the glyphs inside the document text). When document wouldn't have correct CJK font(s) embedded inside it, then Ghostscript would the closest substitution(s), so the document can be at least displayed/printed in a readable/legible way. However, the substitution will never be perfect, and will always be best-effort workaround.
The above described situation was valid several years ago. Nowadays upstream has its own solution (i.e. workaround) on doing so, which is based only on one (different) font - Google Droid Sans Fallback.
I'm still discussing this change with Peng Wu (maintainer of 'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer) off-the-list, but for now we have agreed to try use the default upstream's solution for this scenario.
If it works well, this should mean less maintenance work for Peng ('ghostscript-chinese' could be dropped), and we wouldn't have a downstream solution that could potentially cause additional issues in the future. Also, the downstream solutions were really not popular with upstream before (IMHO they didn't like Fedora at all because of it), and I was working with them for last half and a year to improve our relationship with them from Fedora side. :)
I hope I didn't forget to mention something important... :D If something is unclear, lay it on me! ;)
On Wed, Jan 10, 2018 at 3:30 PM, David Kaspar [Dee'Kej] dkaspar@redhat.com wrote:
I hope I didn't forget to mention something important... :D If something is unclear, lay it on me! ;)
Yeah, I forgot one more small thing to mention... :D For now I'm waiting for 'google-droid-fonts' to be rebased to latest version, to make sure that the upstream's default solution for CJK-based documents missing embedded fonts is up-to-date. (https://bugzilla.redhat.com/show_bug.cgi?id=1532523)
On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej] dkaspar@redhat.com wrote:
On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa ngompa13@gmail.com wrote:
Is there a specific bug that forces us to require we have transitional packages like this? RPM's Conflicts+Obsoletes logic is powerful enough to allow us to avoid this.
I'm not aware of any BZ/Fedora wiki page that is requiring this. This solution was based solely on my best judgment. To clarify on this:
The 'ghostscript-core' is a "main" subpackage in previous subpackage scheme. It basically contained almost everything from Ghostscript's compilation, and IIRC few of other packages were requiring this package directly in their specfiles...
Other packages were not yet updated to requires correct subpackage from new subpackage layout. Therefore I decided to transform 'ghostscript-core' into auxiliary subpackage, since it was already there.
This should have allowed new Ghostscript to be rolled out without breaking build process for them (hopefully completely, or at least it should at mitigate most of the problems). And the other packages can be then rebuild immediately once their requirements have been appropriately updated. :)
If the content of "ghostscript-core" is now part of "ghostscript", you can do the following:
Obsoletes: ghostscript-core < 9.22-5 Provides: ghostscript-core = %{version}-%{release}
In addition, packages that currently require "ghostscript-core" can and should be fixed for Fedora 28. In my view, there's nothing that necessitates this metapackage for a development branch.
If this was going into Fedora 27, for example, then sure, it makes sense.
Why are examples not shipped? For documentation, this seems to be fine, especially since it's a separate subpackage anyway.
Upstream has decided to drop the examples/ completely from the next version of Ghostscript release (9.23). According to them those files are more useful for testing purposes rather than actual examples, and those files are poorly written PostScript files. They wouldn't help people who would like to learn how to write PostScript documents. That's why upstream does not want to ship those files anymore.
Since I was doing changes to contents/layout of Ghostscript, I thought it was a good time to incorporate this change into the package already.
Makes sense to me. Thanks for the detailed rationale. :)
- Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
Ghostscript's default choice for rendering of CJK glyphs, which is Google Droid Sans Fallback font. In case this proves insufficient, the conf.d/ folder support will be re-established.
->> This change is still being discussed with Peng Wu and Akira Tagoh. So far, we have agreed to this change, but I will be ready to revert it in case people depending on printing CJK-based texts will have any problems. In case the Ghostscript's default functionality would prove to be sufficent and work OK, then the 'ghostscript-chinese' package could be retired as a result. ->> For now, we are also waiting for rebase of 'google-droid-fonts' for Ghostscript to have the latest version of Droid Sans Fallback font and thus the latest CJK glyphs coverage.
I'm confused why we would drop support for conf.d directories. Unless it's completely unavoidable, I don't see why we would do this. We can't possibly know of everyone who might be using them, and generally speaking, I'd like to see more software configurable this way, not less.
The folder /usr/share/ghostscript/conf.d/ actually comes from the package 'ghostscript-chinese'. Ghostscript itself was just configured to check that folder for configuration before, if there was any.
The folder itself contained mappings for specific locales into specific CJK-based fonts. It was used only after 'ghostscript-chinese' was installed. This solution was introduced into Ghostscript more than a decade ago, and it is based on this project: https://www.freedesktop.org/wiki/Software/CJKUnifonts/
If you look at the project, you will that it is basically dead, and the 'ghostscript-chinese' package itself received last update in 2012.
The main purpose of using 'ghostscript-chinese' is to introduce a workaround for displaying/printing of CJK-based documents which do not have the correct font embedded (for displaying the glyphs inside the document text). When document wouldn't have correct CJK font(s) embedded inside it, then Ghostscript would the closest substitution(s), so the document can be at least displayed/printed in a readable/legible way. However, the substitution will never be perfect, and will always be best-effort workaround.
The above described situation was valid several years ago. Nowadays upstream has its own solution (i.e. workaround) on doing so, which is based only on one (different) font - Google Droid Sans Fallback.
I'm still discussing this change with Peng Wu (maintainer of 'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer) off-the-list, but for now we have agreed to try use the default upstream's solution for this scenario.
If it works well, this should mean less maintenance work for Peng ('ghostscript-chinese' could be dropped), and we wouldn't have a downstream solution that could potentially cause additional issues in the future. Also, the downstream solutions were really not popular with upstream before (IMHO they didn't like Fedora at all because of it), and I was working with them for last half and a year to improve our relationship with them from Fedora side. :)
Okay, this makes sense. I'm a bit disappointed that we couldn't have the conf.d thing upstreamed, but we'll see how it goes...
On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa ngompa13@gmail.com wrote:
If the content of "ghostscript-core" is now part of "ghostscript", you can do the following:
Obsoletes: ghostscript-core < 9.22-5 Provides: ghostscript-core = %{version}-%{release}
In addition, packages that currently require "ghostscript-core" can and should be fixed for Fedora 28. In my view, there's nothing that necessitates this metapackage for a development branch.
If this was going into Fedora 27, for example, then sure, it makes sense.
Unfortunately in the current situation, it's not that simple... :-/ Let me try to explain:
In the context of changes mentioned here (package layout change, software/resources debundling) specifying Obsoletes/Provides as you mentioned above for 'ghostscript' (or any other subpackage) wasn't enough. As I said before, the 'ghostscript-core' contained almost everything from Ghostscript's build, and 'ghostscript' was an empty metapackage, requiring 'ghostscript-core', 'ghostscript-x11'.
If I would specify the Obsoletes/Provides inside 'ghostscript' package as you suggest, then the 'ghostscript' package would still miss some scripts that are now in separate subpackages (*-tools-*). It could lead to people complaining (in BZs, mailing list) about missing scripts after upgrade to F28 (the scripts would have been uninstalled during upgrade in this way). I'm trying to avoid any disturbance to our users that could generally lead to negative feelings about our distribution.
In order to have the scripts kept during the upgrade, then I would have to specify additional requirements in 'ghostscript' package for the 'ghostscript-tools-*' subpackages. However, this would create again the problem I was trying to solve in the first place (to have more granular package layout), and 'ghostscript' package itself would just become "new" 'ghostscript-core'. I.e., the contents would have been moved from 'ghostscript-core' into 'ghostscript', which is not exactly what I wanted. :)
So right now, none of the (sub)package has Obsoletes/Provides/Requires for 'ghostscript-core'. Instead, I kept the 'ghostscript-core' with requirements on 'libgs', 'ghostscript', 'ghostscript-tools-*'. This way the 'ghostscript-core' will not be installed automatically on fresh F28 installations, but for users upgrading from previous version to F28, it will kept the Ghostscript scripts installed.
My plan is to remove the 'ghostscript-core' once F28 has reached EOL. I realize now that this might influence the users doing the upgrade anyway (the 'ghostscript-tools-*' might get uninstalled during upgrade and some of them might be missing them). But before I need to deal with this, I want to make sure other packages requiring Ghostscript are fixed first. To kind of grind the huge change into a smaller chunks of changes, if possible. :)
I'm sorry if my explanation does not make sense. :-/ If that's the chase, then it might be better to look in the specfile at the package layout (and dependencies) before and after the change. ( https://src.fedoraproject.org/rpms/ghostscript)
Okay, this makes sense. I'm a bit disappointed that we couldn't have the conf.d thing upstreamed, but we'll see how it goes...
Generally it's hard to get something upstreamed unless they have any benefit from it. I had really hard times trying to convince them to create a new Github repository for 'urw-base35-fonts' and accepting the AppStream and fontconfig configuration files there.
For upstream accepting something might mean additional maintenance work, and they are (understandably) trying to avoid it. :)
On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote:
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
You should create a change request for this. It's very significant, IMHO.
I've encountered a problem with this change. ImageMagick tests require the 'gs_resmp.ps' resource file to be around, but I cannot find where this file lives now. Where is it now?
Hello guys!
I wanted to let you know I have decided to create additional subpackage 'ghostscript-tools-dvipdf' after some discusssions. It is because the 'dvipdf' tool requires 'dvips' utility to work correctly, which is provided in 'texlive-dvips' subpackage. This resulted in lot of texlive packages being pulled in as a dependency of 'ghostscript' where the 'dvipdf' tool initially was.
However, many of our users might not need the 'dvipdf' tool nor the texlive itself. This change might cause some inconvenience to some users, but for most of the people it should save them some disk space when they don't need the texlive installed.
Also, the new 'ghostscript-tools-dvipdf' subpackage is not required by 'ghostscript-core' meta subpackage. This will ensure that users doing upgrade to F28 will not get texlive automatically installed in case they didn't have it before.
On Wed, Jan 17, 2018 at 4:01 PM, Michael Cronenworth mike@cchtml.com wrote:
On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote:
Initial NOTE: I have made some bigger changes in Ghostscript package during the cleanup, which should be self-contained. In my opinion those changes are not so significant to create "self-contained change" wiki page for it (for F28), but if the consensus of people here will be the opposite, then I will create it additionally...
You should create a change request for this. It's very significant, IMHO.
OK, I'll start working on that once I all the necessary packages in the tracking BZ.
I've encountered a problem with this change. ImageMagick tests require the 'gs_resmp.ps' resource file to be around, but I cannot find where this file lives now. Where is it now?
The file is generally located in Resource/Init folder of Ghostscript. As I mentioned before, the version of the Ghostscript is no longer part of this path: /usr/share/ghostscript/*9.22*/Resource/Init/gs_resmp.ps ->> /usr/share/ghostscript/Resource/Init/gs_resmp.ps
It is part of the 'libgs' package now: https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549&filename=/us...
Hello guys,
and sorry for the delay - I've got caught in my other responsibilites. I have created the Wiki page for this change, as requested: https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28
To comply with the guidelines there, I had to categorize this as a "system-wide change" though.
The pull-requests to update specfiles for all the dependant packages have been already submitted. Some of them were already accepted. You can see the progress in this tracking BZ: https://bugzilla.redhat.com/ show_bug.cgi?id=1534638
The mass rebuild of F28 is done, and I'm aware only about one FTBFS related to these changes: https://bugzilla.redhat.com/show_bug.cgi?id=1535860 (upstream is already aware of this issue)
Best regards,
David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat http://www.redhat.com/en/about/trusted.