HEADS UP - Changes to Ghostscript package in F28
by David Kaspar [Dee'Kej]
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>.
6 years, 2 months
F28 Self Contained Change: VA-API 1.0.0
by Jan Kurik
= Proposed Self Contained Change: VA-API 1.0.0 =
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0
Change owner(s):
* Nicolas Chauvet <kwizart - at - fedoraproject.org>
This change is about upgrading libva and others to version 2.0. This
change affects several multimedia players as there are both API and
ABI changes. This will allow some VA-API backends to be updated,
improving support for recent hardware.
== Detailed Description ==
Updating to VA-API 1.0.0 will allow to fix and clean-up issues with
the API as sum-up in this upstream topic VA-API 1.0.0:
https://github.com/intel/libva/issues/72
* fix errors in API/data structure definition, e.g. 01org#32
* add new features, e.g. 01org#69,
* deprecate some useless API/data structures, e.g. libva-tpi, libva-egl.
* provide other improvement, e.g. use portable type to define data structure.
All packages using libva will be rebuilt to take into account the new
API/ABI. Futhermore, the intel backend will be updated along (not
provided by Fedora). Others VA-API backend such the AMD and NVIDIA
backend provided by Fedora within mesa-dri-drivers will work as
appropriate. Bridges between VA-API and VDPAU will continue to be
supported , this is:
* libva-vdpau-driver which allows to use the VA-API enabled players
with VDPAU backend (such as NVIDIA binary driver).
* libvdpau-va-gl which allows to use the VDPAU API enabled players
with VA-API backends (such as intel driver).
== Scope ==
* Proposal owners:
- Update and rebuild packages that depend on libva. DONE
- Verify that everything is working as appropriate or report issue
upstream. TESTING IN PROGRESS.
* Other developers:
N/A
* Release engineering:
#7285 : https://pagure.io/releng/issue/7285
* List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 2 months
Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async
working
by Steve Dickson
On 01/29/2018 12:42 PM, Steven Whitehouse wrote:
>
>
>
> -------- Forwarded Message --------
> Subject: Re: Fedora27: NFS v4 terrible write performance, is async working
> Date: Sun, 28 Jan 2018 21:17:02 +0000
> From: Terry Barnaby <terry1(a)beam.ltd.uk>
> To: Steven Whitehouse <swhiteho(a)redhat.com>, Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, Terry Barnaby <terry1(a)beam.ltd.uk>
> CC: Steve Dickson <steved(a)redhat.com>, Benjamin Coddington <bcodding(a)redhat.com>
>
>
>
> On 28/01/18 14:38, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 28/01/18 07:48, Terry Barnaby wrote:
>>> When doing a tar -xzf ... of a big source tar on an NFSv4 file system
>>> the time taken is huge. I am seeing an overall data rate of about 1
>>> MByte per second across the network interface. If I copy a single
>>> large file I see a network data rate of about 110 MBytes/sec which is
>>> about the limit of the Gigabit Ethernet interface I am using.
>>>
>>> Now, in the past I have used the NFS "async" mount option to help
>>> with write speed (lots of small files in the case of an untar of a
>>> set of source files).
>>>
>>> However, this does not seem to speed this up in Fedora27 and also I
>>> don't see the "async" option listed when I run the "mount" command.
>>> When I use the "sync" option it does show up in the "mount" list.
>>>
>>> The question is, is the "async" option actually working with NFS v4
>>> in Fedora27 ?
No. Its something left over from v3 that allowed servers to be unsafe.
With v4, the protocol defines stableness of the writes.
>>> _______________________________________________
>>
>> What server is in use? Is that Linux too? Also, is this v4.0 or v4.1?
>> I've copied in some of the NFS team who should be able to assist,
>>
>> Steve.
>
> Thanks for the reply.
>
> Server is a Fedora27 as well. vers=4.2 the default. Same issue at other
> sites with Fedora27.
>
> Server export: "/data *.kingnet(rw,async,fsid=17)"
>
> Client fstab: "king.kingnet:/data /data nfs async,nocto 0 0"
>
> Client mount: "king.kingnet:/data on /data type nfs4
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,nocto,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.202.2,local_lock=none,addr=192.168.202.1)"
>
>
This looks normal except for setting fsid=17...
The best way to debug this is to open up a bugzilla report
and attached a (compressed) wireshark network trace to see
what is happening on the wire... The entire tar is not needed
just a good chunk...
steved.
6 years, 2 months
Non-responsive maintainer: joost
by Richard Shaw
Per the policy I am asking here if anyone knows how to get in touch with
joost (joost(a)cnoc.nl).
I have bug reports for both fpc and lazarus that have gone for weeks
without any response and it's preventing me from building cqrlog on armv7hl
in rawhide due to lazbuild and hedgewars has a segmentation fault due to a
bug in fpc.
I have tried direct emails with no response.
The following bugs have not been addressed:
fpc: needs bootstrap for armhfp
https://bugzilla.redhat.com/show_bug.cgi?id=1491788
SIGSEGV during game shutdown with hedgewars 0.9.23 (hwengine)
https://bugzilla.redhat.com/show_bug.cgi?id=1526848
CQRLOG fails to build for armv7hl on F26 & 27
https://bugzilla.redhat.com/show_bug.cgi?id=1529988
lazbuild binary not working on Rawhide for arm
https://bugzilla.redhat.com/show_bug.cgi?id=1517323
fedora-active-user shows no activity in 2018...
Last login in FAS:
joost 2017-12-31
Last action on koji:
Sat, 19 Aug 2017 package list entry revoked: lazarus in
module-package-list by pkgdb
Last package update on bodhi:
2017-03-29 08:48:02 on package fpc-3.0.2-1.fc26 lazarus-1.6.4-2.fc26
Last actions performed according to fedmsg:
- joost commented on bodhi update docker-1.13.1-44.git584d391.fc27
(karma: 1) on 2017-12-31 11:36:45 ()
- hobbes1069(a)gmail.com filed a new bug RHBZ#1529988 'CQRLOG fails to
build for armv7hl on F26...' on 2017-12-31 11:02:30 ()
- jreiser(a)bitwagon.com commented on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 11:19:14 ()
- mattia.verga(a)email.it updated 'cc' on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 04:30:24 ()
- fweimer(a)redhat.com commented on RHBZ#1526848 'SIGSEGV during game
shutdown with hedgew...' on 2017-12-18 01:39:08 ()
- airlied(a)redhat.com updated 'cc', 'component', and 'assigned_to' on
RHBZ#1526848 'SIGSEGV during game shutdown with hedgew...' on 2017-12-18
01:17:32 ()
- vascom2(a)gmail.com filed a new bug RHBZ#1525820 'Need update lazarus to
1.8.0' on 2017-12-14 00:21:33 ()
- hobbes1069(a)gmail.com commented on RHBZ#1517323 'lazbuild binary not
working on Rawhide f...' on 2017-11-24 09:33:54 ()
- hobbes1069(a)gmail.com filed a new bug RHBZ#1517323 'lazbuild binary not
working on Rawhide f...' on 2017-11-24 09:33:23 ()
- jkurik commented on RHBZ#1390060 'cqrlog does not start on raspberry pi
3' on 2017-11-16 13:04:26 ()
Last email on mailing list:
Thanks,
Richard
FAS: hobbes1069
6 years, 2 months
F28 Self Contained Change: Atomic, Cloud and Docker images for s390x
by Jan Kurik
= Proposed Self Contained Change: Atomic, Cloud and Docker images for s390x =
https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for...
Change owner(s):
* Sinny Kumari <sinnykumari AT fedoraproject DOT org>
This change is to bring s390x architecture closer to other Fedora
architectures by adding widely used Fedora variants. This includes
docker images, Atomic Host (iso, qcow2 and raw format) and regular
Cloud Images (qcow2 and raw format).
== Detailed Description ==
We already ship Atomic, Cloud and Docker images on other 64-bit Fedora
supported architectures- aarch64, x86_64 and ppc64le. With Fedora 27,
s390x is part of primary koji build system. Currently, we only ship
Server and Everything variants for s390x. So, our next steps should be
to have missing Fedora variants on s390x architecture which users will
find useful. This brings in shipping Atomic, Cloud and Docker images
in Fedora for s390x as well.
== Scope ==
* Proposal owners:
These are isolated changes which doesn't impact existing Fedora 28
release plan on s390x. To have these changes ready to ship in Fedora
28, we mainly require s390x koji builders configured to run these
composes, changes in pungi configuration [
https://pagure.io/pungi-fedora/pull-request/496 ] to enable the
additional compose and fixing s390x specific issues encountered when
compose fails to run.
* Other developers:
Changes in Fedora infrastructure configs/scripts will be required to
have s390x builders configured to run additional composes. Fedora
Infrastructure issue [
https://pagure.io/fedora-infrastructure/issue/6659 ] has been filed to
keep track of required changes to be done.
* Release engineering:
#Releng 7286: https://pagure.io/releng/issue/7286
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 2 months
Wyland is a disaster
by Howard Howell
Hi, guys,
I'm sorry, but wyland is a disaster for me. I do work on lots
of different software platforms, and things are just not working well.
They kind-of-work, which is the really worst condition one can have.
My new video board won't work with wyland, my pixycam software won't
work with wyland, some other graphics have changed colors, or don't
fully resolve with wyland, and finding compatible third party products
which was tough enough on linux to begin with is now virtually
impossible. The web compatible products work, like MPLABX from
microchip, but occasionally crash. Gscheme crashes randomly, and there
are others I haven't tried recently, but which I expect to have issues
supporting.
Whatever the impetus was to change, it must have been driven by
somebody that doesn't really use the system. I have tried starting as
an Xorg login, but somehow that seems less than operating for similar
reasons, all surrounding graphics I suspect. So whether it is wyland
or the new graphics driver, kind-of-working is not a good deal. Yes, I
can change distributions, and if that is the only solution, I will, but
isn't that contradictory to the idea of becoming the OS of choice?
I expected that all these nagging issues would be worked out by
now. But there is no sign of improvement. Worse I am not getting my
stuff done. Granted I am just a hobbyiest, but doesn't this also
affect your more professional users?
Regards,
Les H
6 years, 2 months
Writing Documentation for Fedora - Docs FAD
by Brian Exelbierd
We are looking for interested people who are willing to write docs in person for one week. You don't have to be an existing docs team member to participate. It helps if you're familiar with AsciiDoc, but if you're not, it's easy to learn.
You'll hang out with other people interested in making Fedora documentation the best in the world. Fun will be had, but mostly it will be the sort of fun which involves sitting in a small room intensely focused on writing and editing. If that's *your* idea of a good time, this will be a good experience for you.
You can find details about the FAD, including the goals here: https://fedoraproject.org/wiki/FAD_Documentation_2018
The Fedora Council has approved funding and we will make selections based on the ability to the person asking and within our approved travel budget. https://pagure.io/Fedora-Council/tickets/issue/174
Interested? Open a Pagure ticket in the Fedora Docs tracker here: https://pagure.io/fedora-docs
Please include:
- Your Name/FAS
- Why you want to come and what your background in writing (of any kind) is.
- Any specific areas of interest
- Location you will travel from
We will start picking people ASAP.
Thanks,
bex & Matthew
6 years, 2 months
Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR /
NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!
by Christian Glombek
Hello World!
My name is Christian Glombek (or simply Chris :) and I'd like to join the
Fedora Packagers Group. I'm currently a student of Electrical Engineering
and Business Management at RWTH University in Aachen, Germany.
My FAS and IRC handle is `lorbus` and on GitHub and Twitter I'm
`LorbusChris`. I've been using Fedora for two or so years on my daily
drivers, very much to my satisfaction.
Fedora's focus on modern concepts, especially container technology,
intrigues me. Its community to me has always seemed open, friendly, diverse
and knowledgeable.
I also feel that Fedora's sponsor Red Hat has established a symbiotic
relationship with this community, transparently supporting a quite
remarkable and rightfully successful business model.
I feel passionate about Open Source Technology and would like to
participate!
Over the past few months I've been feeding my interests in some corners of
the extended Fedora universe, mainly tinkering with RPM and Ansible
Playbook Bundle (APB) packaging and also trying out custom Atomic/OSTree
builds (love Atomic Workstation!).
RPMs:
NEEDSPONSOR
I want to get some packages into Fedora proper and I need a sponsor for
that!
I'd also hugely appreciate (unofficial) reviews or any other feedback for
the following packages:
coturn-rpm:
NEEDREVIEW
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1491492
COPR: https://copr.fedorainfracloud.org/coprs/lorbus/coturn/
Repo: https://github.com/LorbusChris/coturn-rpm
libreoffice-online-rpm:
NEEDREVIEW (later, WIP)
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494915
COPR: https://copr.fedorainfracloud.org/coprs/lorbus/libreoffice-online/
Repo: https://github.com/LorbusChris/libreoffice-online-rpm
Note:
The frontend part of libreoffice-online, loleaflet, uses `npm install`
during build (versioned with a npm-shrinkwrap file). From what I've read
about packaging nodejs modules, I'll probably have to manually download and
add all module sources to the rpm. WIP.
rspamd-rpm:
NEEDREVIEW (later, WIP)
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1494914
COPR: https://copr.fedorainfracloud.org/coprs/lorbus/rspamd/
Repo: https://github.com/LorbusChris/rspamd-rpm
Note:
I'll have to gather some more info about bundled softwares, possibly split
out some existing dep packages.
ragel-rpm / colm-rpm:
I also did some work updating the already-existing Ragel (dep of Rspamd)
and Colm (dep of Ragel) rpms and was consequently asked by current repo
maintainer Jason Taylor (jtaylor) to take over the position, which I'll
gladly do once I've found a sponsor and get the privilege of joining the
packagers' group!
I'd like to try out Modularity packaging for Ragel as it has two release
streams, stable and development, of which only the latter is in Fedora.
(I made a ragel-compat rpm for the stable release stream, which can be
found on COPR, but I believe Modularity's arbitrary branching would be a
perfect fit here!)
COPR ragel-compat:
https://copr.fedorainfracloud.org/coprs/lorbus/ragel-compat/
APBs:
I also like the idea of the Kubernetes Service Catalog, in conjunction with
the Ansible Service Broker (and Ansible in general) and so I did some
tinkering with Ansible Playbook Bundles, the packaging format for the
Ansible Broker:
awx-apb:
Repo: https://github.com/LorbusChris/awx-apb
Note:
APB to broker (provision/deprovision) Ansible AWX.
Can also be used as an alternative installer for AWX deployment on
OpenShift.
openshift-acme-installer:
Repo: https://github.com/LorbusChris/openshift-acme-installer
Note:
Installer for https://github.com/tnozicka/openshift-acme
Non-standard privilged (cluster-admin) APB, can be used as installer, not
currently for brokering.
Eventually, I'd like to see FreeIPA, Dovecot, Postfix, Rspamd, Clamd,
NextCloud, LibreOffice Online, Prosody and Coturn all packaged for Fedora
as RPM and Docker and for K8s Service Catalog as APB for use in a little
pet project of mine:
https://github.com/contor-cloud/contor (WIP)
Expect to see me around on the IRC, too! I'll be saying hello in the
relevant channels in the coming days.
If you have any questions or maybe have a task for me at hand, please let
me know!
Attending Conferences
In December I met up with Fedora Ambassador Till Maas (till) for tea here
in Aachen and was given answers to lots of my questions regarding Fedora.
Thanks again, Till!
He also encouraged me to attend conferences, which is why I will be at:
- DevConf.cz, Brno, Jan 26-28, that's this Weekend!
- CentOS Dojo, Brussels, Feb 2
- FOSDEM, Brussels, Feb 3
- Config Management Camp, Gent, Feb 5-7
I hope to meet some members of the community there in person! Please feel
free to ping me if you're there! :)
I'm looking forward to participating and contributing here!
Best regards
Christian Glombek
6 years, 2 months
F28 Self Contained Change: Removing ldconfig scriptlets
by Jan Kurik
= Proposed Self Contained Change: Removing ldconfig scriptlets =
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Change owner(s):
* Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org,>
* Neal Gompa <ngompa13 AT gmail DOT com>
For many years, package maintainers were required to write scriptlets
which call ldconfig in %post/%postun if they package shared libraries.
== Detailed Description ==
Since time immemorial, Red Hat/Fedora packagers have been required to
add a stanza to spec files for packages containing libraries to update
the ldconfig cache.
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
To say this is annoying is to put it mildly. However, there was no
standard mechanism to make this boilerplate go away. Now with RPM
4.13+, we should change this to file triggers and make all of that go
away.
With this change, these scriptlets can be removed and ldconfig would
be run just once per transaction.
If your package places shared libraries in special locations
referenced by ld.so.conf, you still need to run ldconfig manually.
For those who concerned about whether this is self-contained or
system-wide change: there is no overhead if packagers don't remove
ldconfig scriptlets in time, so completion doesn't depend whether
packagers remove them or not. We are just making it possible.
== Scope ==
* Proposal owners:
Make sure that DSO symlinks are being packagedcommit, add transaction
filetriggers to glibccommit + commit.
* Other developers:
Package maintainers are advised to remove ldconfig scriptlets in order
to achieve benefits specified above.
* Release engineering:
#7284: https://pagure.io/releng/issue/7284
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Packaging guidelines need to be updated to reflect reality.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 2 months