Orphaning ofono
by Rex Dieter
I will be orphaning the ofono package today. I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.
Recently updated to latest 1.22 release which fixed a long-standing FTBFS
issue, so at least it is in good shape for anyone interested in picking it
up.
-- Rex
5 years, 11 months
New "tests" namespace to share test code
by Petr Splichal
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/...
6 years
F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
by Jan Kurik
= 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
6 years
-z defs linker flag activated in Fedora rawhide
by Florian Weimer
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/buildf...>
Thanks,
Florian
6 years
Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot@laposte.net
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
6 years
Test gating enabled in Bodhi
by Pierre-Yves Chibon
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
6 years
CUPS will change license since 2.3 version - now incompatible with
GPLv2
by Zdenek Dohnal
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
6 years
F28 System Wide Change: GCC8
by Jan Kurik
= 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
6 years
F28 System Wide Change: Make authselect default tool instead of authconfig
by Jan Kurik
= 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
6 years