devel January 2018

devel@lists.stg.fedoraproject.org

239 participants
308 discussions

New "tests" namespace to share test code
by Petr Splichal 13 Mar '18

13 Mar '18

Hi! While working on adding CI tests [0] using the Standard Test Interface a need arose to have a shared git repository where tests could be stored: * A large number of test files makes a dist-git repository more difficult to maintain * Tests might follow a different branching pattern than the dist-git repo, leading to code duplication * Shared maintenance for tests sometimes benefits from different access levels than the release dist-git repository The plan is to create a new “tests” namespace in Fedora git/pagure dedicated to storing the shared test code. To enable execution of these tests by the CI pipeline, tests.yml file in dist-git will be used to link the tests in the standard way as defined by the Standard Test Interface [1]. This approach should help to efficiently maintain tests & minimize test code duplication. Using a dedicated git repo for test code also means to keep dist-git more as a place for storing metadata only: Build metadata (spec file = how to build the package) and test metadata (tests.yml = how to test the package) rather than mixing spec files with test code itself. Please note that this does not mean that all tests should now go into this new namespace. You can still link tests directly from upstream (like GitHub) or any other source. Also, for unit tests it makes more sense to be kept directly with the project source and executed there. Shared tests namespace in Fedora will be suitable especially for functional and integration testing which should help to continuously ensure the OS works as a whole. For more detailed motivation and real-life examples see the Share Test Code proposal on the Fedora CI list [2]. If you have any questions or comments feel free to share them here or in the pagure issue requesting the new namespace: https://pagure.io/fedora-infrastructure/issue/6478 Thanks. psss... [0] https://fedoraproject.org/wiki/CI [1] https://fedoraproject.org/wiki/Changes/InvokingTests [2] https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/th…

7 18

F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
by Jan Kurik 12 Mar '18

12 Mar '18

= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Change owner(s): * Björn Esser <besser82 AT fedoraproject DOT org,> * Florian Weimer <fweimer AT redhat DOT com> There are plans to remove libcrypt from glibc, so we should have a replacement. == Detailed Description == Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement. It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra. The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt. == Scope == * Proposal owners: - Apply needed packaging changes to glibc - Review, import and build libxcrypt for Fedora 28 * Other developers: Test their applications using one of the following interfaces for unexpected changes in functionality: - crypt() - crypt_r() - encrypt() - encrypt_r() - fcrypt() - setkey() - setkey_r() Release engineering: #7160 https://pagure.io/releng/issue/7160 none expected * Policies and guidelines: N/A (not needed for this 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

5 10

-z defs linker flag activated in Fedora rawhide
by Florian Weimer 09 Mar '18

09 Mar '18

I updated redhat-rpm-config to instruct ld to reject linking shared objects with undefined symbols. Such undefined symbols break symbol versioning because the are not necessarily bound to the correct symbol version at run time. (rhbz#1535422) ### Disable strict symbol checks in the link editor (ld) By default, the link editor will refuse to link shared objects which contain undefined symbols. In some cases (such as when a DSO is loaded as a plugin and is expected to bind to symbols in the main executable), undefined symbols are expected. In this case, you can add %undefine _strict_symbol_defs_build to the RPM spec file to disable these strict checks. Alternatively, you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc command line). The latter needs binutils 2.29.1-12.fc28 or later. This is also part of the build flags documentation at: <https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildfla…> Thanks, Florian

22 57

Proposal to increase the beta freeze to 3 weeks
by Randy Barlow 05 Mar '18

05 Mar '18

Greetings fellow Fedorans! During today's FESCo meeting[0], there was discussion around a proposal to increase the freeze period from 2 weeks to 3 weeks[1]. Several members of FESCo thought this proposal might be unpopular with Fedora developers, so a compromise proposal was made: increase the beta freeze to 3 weeks, but keep the stable freeze at 2 weeks[2]. We would like to ask for feedback from the Fedora community about this proposal. Feel free to reply here, or comment on the FESCo ticket. Thanks in advance for your thoughts! [0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-1… [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090

6 8

Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot＠laposte.net 04 Mar '18

04 Mar '18

Hi, I am proposing for inclusion a set of rpm technical files aimed at automating the packaging of forge-hosted projects. - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging - https://pagure.io/packaging-committee/issue/734 - go-srpm-macros RFE with the technical files: https://bugzilla.redhat.com/show_bug.cgi?id=1526721 This proposal is integrated with and depends on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft It builds on the hard work of the Go SIG and reuses the rpm automation of https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and produces compatible packages. What it does: - drastically shorter spec files, up to 90% in some cases, often removing hundreds of lines per spec. - simple, packager-friendly spec syntax - automated package naming derived from the native identifier (import path). No more packages names without any relation with current upstream naming. - working Go autoprovides. No forgotten provides anymore. - working Go autorequires. No forgotten requires anymore. - strict automated directory ownership (used by autorequires and autoprovides). - centralized computation of source URLs (via Forge-hosted projects packaging automation). No more packages lacking guidelines. No more broken guidelines no one notices. - easy switch between commits, tags and releases (via Forge-hosted projects packaging automation). No more packages stuck on commits when upstream starts releasing. - guidelines-compliant automated snapshot naming, including snapshot timestamps (via Forge-hosted projects packaging automation). No more packages stuck in 2014. - guidelines-compliant bootstraping. - systematic use of the Go switches defined by the Go maintainer. Easy to do changes followed by a mass rebuild. - flexibility, do the right thing transparently by default, leave room for special cases and overrides. - no bundling (a.k.a. vendoring) due to the pain of packaging one more Go dependency. - centralized Go macros that can be audited and enhanced over time. - aggressive leverage of upstream unit tests to detect quickly broken code. Please consult packaging draft for full information. The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go packages. This set is a mix of current Fedora packages, bumped to a more recent version, rewrites of Fedora packages, and completely new packages. I hope posting the second part of the automation will answer some questions people had on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft Regards, -- Nicolas Mailhot

14 63

Test gating enabled in Bodhi
by Pierre-Yves Chibon 01 Mar '18

01 Mar '18

Good Morning Fedorans! On Thursday, a new version of Bodhi was deployed that enabled Bodhi to gate updates based on test results. You may notice a "Test Gating Status" message in the right have side of the page. One thing to know about this is that there is currently a confusing issue where Bodhi will say that the tests have failed when the tests haven't finished running[0]. We are working on solving that issue, but for now you can just wait a while and it should report the result once all the tests have finished. There are three tests that must pass in order for updates to go to stable: 0. dist.depcheck - to make sure the update's dependencies are available. 1. dist.abicheck - to make sure the update's ABI remains stable in a given Fedora release. 2. AtomicCI pipeline - packages that are part of the Atomic Host *and* include in their dist-git tests, must have these tests passed in the AtomicCI pipeline This last requirement only concern packages that are in the Atomic Host while the first two is enforced for all packages. We are also working on another CI pipeline that will allow running tests stored in dist-git for all packages without discrimination. You are in control of these three tests. The first two can be fixed by making changes in the spec file, and the latter test is controlled via the tests in your repo. Finally, if it turns out you need to push an update through despite of the test results, you can do so using waiver-cli (dnf install waiverdb-cli). We are working on integrating this into Bodhi itself, making this easier. We have started a wiki page to store all of this information and that we will keep up to date as improvements are done or for any frequent questions coming up: https://fedoraproject.org/wiki/CI/gating_updates Please accept my apology in the delay in writing this message. It should have been sent last week when it was enabled, and it got lost. Thanks for your attention, Pierre [0] https://github.com/fedora-infra/bodhi/issues/2124 _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

18 38

CUPS will change license since 2.3 version - now incompatible with GPLv2
by Zdenek Dohnal 27 Feb '18

27 Feb '18

Hi, CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups(a)cups.org . Is there someone who is influenced by this change? -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C

17 43

F28 System Wide Change: GCC8
by Jan Kurik 21 Feb '18

21 Feb '18

= System Wide Change: GCC8 = https://fedoraproject.org/wiki/Changes/GCC8 Change owner(s): * Jakub Jelínek <jakub AT redhat DOT com> Switch GCC in Fedora 28 to 8.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 29. == Detailed Description == GCC 8 is currently in stage3, will move to stage4 on January 14th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. We are working on scratch gcc rpms and will perform a test mass rebuild. == Scope == All packages should be rebuilt with the new gcc once it hits f28, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots. * Proposal owners: Build gcc in f28, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin, odb). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-8/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. * Release engineering: PR#7249: https://pagure.io/releng/issue/7249 Mass rebuild requested for F28. * Policies and guidelines: No policies need to be changed -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

8 12

F28 System Wide Change: Make authselect default tool instead of authconfig
by Jan Kurik 20 Feb '18

20 Feb '18

= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault Change owner(s): * Pavel Březina <pbrezina AT redhat DOT com> Replace authconfig with authselect and make authselect a default tool to configure PAM and nsswitch.conf. A compatibility tool will help with transition period from authconfig to authselect. Authselect is a tool to select system authentication and identity sources from a list of supported profiles and it is available to users since Fedora 27. Authselect is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it ships several tested stacks (profiles) that solve primary supported use cases and are well tested and supported. At the same time, some obsolete features of authconfig are not supported by authselect. Additionally, authselect is written in C and has a small footprint which allows it to be also part of minimal installations. == Detailed Description == Authselect allows the administrator to choose one of the supported profiles. A profile provides description of how the resulting pam and nsswitch configuration looks like. The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory. The authentication and identity configuration is hardcoded within the profile. However each profile is also allowed to contain some conditional modules that can be either enabled or disabled to allow the administrator to enable some optional behaviour such as account locking or ecryptfs support. Authselect does not configure daemons that provide the selected identity and authentication services such as SSSD or winbind, it only configures PAM and nsswitch. Daemons must be configured manually or through other system tools like realmd or ipa-client-install that are better suited for this task. The default profile set contains the following profiles: * Local users + SSSD -- local users and remote users are handled by sssd * With optional smartcard or fingerprint authentication * Local users + winbind -- local users are handled by files and remote users by winbind * With optional fingerprint authentication There is no need for a separate local users profile without SSSD because the SSSD module is not called for local users and it also gracefully detect when the daemon is not running. Since authselect is very different from the authconfig, we will provide a compatibility tool that will mimic most but not all options of authconfig and translate those operations into an authselect call and configuration changes so we do not break users scripts. == Scope == * Proposal owners: Authselect is already ready and shipped with Fedora. Owners will provide compatibility tool to help with the transition. * Other developers: anaconda-core, fprintd-pam, freeipa-client and realmd are packages that depends on authconfig. We will coordinate efforts to either switch those packages to authselect or make sure that the compatibility tool is sufficient to cover their needs. * Release engineering: #7241: https://pagure.io/releng/issue/7241 * List of deliverables: all * Policies and guidelines: The policies and guidelines do not need to be updated. * 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

7 14

HEADS UP - Changes to Ghostscript package in F28
by David Kaspar [Dee'Kej] 19 Feb '18

19 Feb '18

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>.

5 11

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2018