Macro to smoke-test-import a Python module in %check
by Miro Hrončok
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].
The semantics is quite simple:
%check
%py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at
lest one fails to import, the entire build fails. The above line is translated
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the
implementation [0] for more accurate representation). Given the Python
semantics, it is possible to use commas as module separators as well (but no
parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to
be manually BuildRequired or even better, generated in %generate_buildrequires
via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is
undesired (e.g. when only one module can be imported from the same Python
interpreter):
%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name?
- Do you have better ideas for the macro semantics?
[0]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 7 months
Assimp soname bump
by Rich Mattes
Hi,
I plan to update assimp from 3.3.1 to the latest release (5.0.1) in
rawhide this week. The following packages will be affected:
fawkes-0:1.3.0-11.fc33.src
mrpt-0:1.4.0-17.fc33.src
pioneer-0:20200203-1.fc33.src
vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src
I will take care of the rebuilds and any fallout/updates that need to
happen.
Rich
2 years, 8 months
How to easily automate test builds in a COPR project
by Richard Shaw
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
2 years, 8 months
rpmautospec deployment into production
by Nils Philippsen
Hi everybody,
we've scheduled the rpmautospec plugin to be deployed into production
for tomorrow, from 14:00 UTC on.
This means installing the relevant packages and restarting kojid
processes on the builders, which will restart any tasks which are being
processed at that time, i.e. expect delays for builds in-flight at the
time.
We'll announce when the deployment is done.
Cheers,
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
2 years, 8 months
F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
== Summary ==
Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub.
== Detailed Description ==
'''''Note that this proposal is about user experience, procedures, and
technology - the high-level concept has already been discussed and
approved by the Fedora Council and FESCO.'''''
Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub. This means that applications on
Flathub that have been explicitly approved (by a new process proposed
here) will be available in GNOME Software and on the
<code>flatpak</code> command line. If the user follows following the
instructions on https://flatpak.org/setup/Fedora/, then the filter is
removed, and the user gets a full view of Flathub.
Roughly speaking, the criteria for including software is a) will not
cause legal or other problems for Fedora to point to b) does not
overlap Fedora Flatpaks or software in Fedora that could easily be
made into a Flatpak c) works reasonably well. For Fedora 35, We expect
to include all software from the top 50 most popular applications on
Flathub that meet these criteria plus selected other software of
interest to the Fedora target audience - Fedora community members are
welcome to propose additions.
Already reviewed: Zoom, Microsoft Teams, Skype, Bitwarden, Postman,
Minecraft<br>
Other likely software from the top 50: Discord, Anydesk, WPS Office,
OnlyOffice, MasterPDFEditor, Slack, UngoogledChromium, Flatseal,
WhatsAppQT, GreenWithEnvy
The expectation is that many included applications will be things that
are hard or impossible to package in Fedora - proprietary
applications, Electron-based applications, and so forth. This is
consistent with the third-party software policy, and does not reflect
a change from what we do currently with third-party repositories.
Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/108 #108 Add selected
Flathub apps to the third-party repos]
== Conformance to Fedora policies ==
The goal here is to be in conformance with the Fedora
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]. The current form of this policy was
explicitly written and approved with the filtered view of Flathub
being one of the use cases. See
https://pagure.io/fesco/fesco-docs/pull-request/34
In detail, this proposal meets
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/...
Key requirements for third-party repositories]. We consider each
application included in the filter as a separate "mini" repository
<blockquote>
Third-party repositories must be approved by an active Fedora working
group or SIG, or by FESCo. Groups who approve the inclusion of third
party repositories must have a documented process which allows for
community input, which produces a traceable history for each decision
(for example, a ticket or other record).
</blockquote>
The traceable process is filing a merge request to
https://pagure.io/fedora-flathub-filter/
<blockquote>
Additionally, repositories included in an edition or spin’s
third-party repository list must conform to the following
requirements:
* Just as with any software hosted by Fedora, third party repositories
must not contain material that poses an undue legal risk for the
Fedora Project or its sponsors. This risk includes, but is not limited
to, software with known patent issues, copyright issues, or software
tailored for conducting illegal activities. Fedora working groups
should evaluate if a proposed addition or provider poses a significant
risk, and if in doubt, confer with Fedora Legal for advice.
</blockquote>
This is done for each pull request to the `fedora-flathub-filter` repository.
<blockquote>
* Changes made by one Edition or spin should not impact other Fedora
editions or spins.
</blockquote>
Each spin has the ability to include filtered view of Flathub or not.
We do not foresee having *separate* filters for different spins.
<blockquote>
* Working groups and SIGs should maintain oversight over the software
that is made available through third-party repositories, to prevent
unvetted software being made available to Fedora users. As part of
this, third-party repositories should allow easy auditing by Fedora
Legal. This requirement implies that third-party repositories should
limit themselves to a small number of packages, or that measures
should be put in place to define which packages are made available
from a particular repository by default.
</blockquote>
The filter is a "measure ... to define which packages are made available".
== Technical implementation ==
* The <code>fedora-third-party</code> script added by
[[Changes/Third_Party_Software_Mechanism]] will also include support
for Flatpak repositories.
* A new package <code>fedora-flathub-repository</code> will be added
with a configuration file
<code>/etc/fedora-third-party.d/flathub.conf</code> and a file
<code>/etc/flatpak/filters/fedora-flathub.filter</code> that is
referenced by the <code>flathub</code> remote when created.
* The filter is maintained by the scripts and procedures in
https://pagure.io/fedora-flathub-filter/ - additions correspond to
pull requests.
* If the user explicitly installs Flathub, by, for example, following
the instructions on https://flatpak.org/setup/Fedora/, then the filter
is removed, and the user gets a full view of Flathub. (This is
standard behavior already implemented in the Flatpak client)
== Benefit to Fedora ==
Fedora users who opt-in to third-party software repositories will have
immediate access to more software out-of-the-box.
== Scope ==
* Proposal owners
** Add flatpak support to the `fedora-third-party` script
** Add a `fedora-flathub-repository` package that is built from the
output of `fedora-flathub-filter` and integrates with the
`fedora-third-party` repository package.
* Other developers:
** No actions needed
* Release engineering: [https://pagure.io/releng/issue/10187 #10187]
** No actions needed
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No significant alignment
== Upgrade/compatibility impact ==
The expectation is that:
* If the system already has a flathub remote installed, nothing
happens, whether or not the user has opted-in to third-party software.
* If the system does not have a flathub remote installed, and the user
opts-in to third-party software at upgrade time, then the filtered-in
apps are then available.
== How To Test ==
* On a fresh install or upgrade, if the user opts-in to third-party
software, applications such as Skype are visible in GNOME Software and
`flatpak search`.
* On a fresh install or upgrade, if the user does not opt-in to
third-party software, applications such as Skype are not visible in
GNOME Software and `flatpak search`.
* If https://flatpak.org/setup/Fedora/ is followed before upgrade, the
remote remains unfiltered.
* If https://flatpak.org/setup/Fedora/ is followed after upgrade, the
remote becomes unfiltered.
== User Experience ==
Fedora users who opt-in to third-party software repositories will have
immediate access to more software out-of-the-box.
== Dependencies ==
This depends on [[Changes/Third_Party_Software_Mechanism]]
== Contingency Plan ==
* Contingency mechanism: remove the dependency of
fedora-workstation-release on `fedora-flathub-repository`
* Contingency deadline: release candidate
* Blocks release? No - the contingency plan could be used at any point
== Documentation ==
The review process is described at https://pagure.io/fedora-flathub-filter/
== Release Notes ==
With Fedora 35, if the user opts-in to third-party software
repositories selected applications from https://flathub.org are now
available by default in GNOME Software, in KDE Discover, and on the
Flatpak command line.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
building against epel8 modules
by Jiri Vanek
Hello!
I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8:
Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8:
CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00
Error:
Problem 1: conflicting requests
- package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
Problem 2: conflicting requests
- package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
Problem 3: conflicting requests
- package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
web search is failing me. Is there some magical spec switch which is enbaling... modules? or something?
Thanx!
j.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
2 years, 8 months
F35 Change: libmemcached-awesome (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/libmemcached-awesome
== Summary ==
Switch from libmemcached to libmemcached-awesome
== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
libmemcache 1.0.18 was released in February 2014, so hasn't received
an update for 7 years.
libmemcache-awesome is a fork providing same libraries, tools with
API/ABI compatibility.
== Benefit to Fedora ==
Rely on a maintained project.
== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* install and play with your application
== User Experience ==
Developers and system administrators will have the great benefit or
running a maintained library.
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* [https://awesomized.github.io/libmemcached/ Upstream documentation]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
Improving Fedora sponsors discoverability
by Jakub Kadlcik
Hello fellow Fedora people,
Inspired by @msuchy's Flock 2016 presentation, I
would like to tackle one of the topics discussed there - The
discoverability of Fedora sponsors for newcomers.
I have a website ready to be deployed. If you are interested in the
technical details, please see this RFE
https://pagure.io/packager-sponsors/issue/470
and also the code
https://github.com/FrostyX/fedora-sponsors
The page design is as simple as possible. You can see some screenshots
here.
https://pagure.io/packager-sponsors/issue/470#comment-735105
A very important feature to me is grouping sponsors by their areas of
interests / expertise, and I would like to ask for your help in this
matter.
At this moment, I have manually defined areas such as Python, C/C++,
Haskell, Ruby, Functional programming, Web development, Modularity,
etc and manually assigned people to them (the small number, that I
personally know that do these kinds of things).
Do you have any idea if there is a way to generate such areas and tie
people to them based on some already existing information within the
Fedora infrastructure?
Otherwise, we will have to stick with manually defined groups, which is
fine with me. But in that case I would like to ask you, what areas of
interest you would like to see. And if you are a Fedora packager
sponsor, in what areas would you like to be listed?
Thank you,
Jakub
2 years, 8 months
F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism
== Summary ==
Update mechanism for opting-in to "Third-Party Software Repositories"
so that the repositories are immediately enabled.
== Owner ==
* Name: [[User:otaylor| Owen Taylor]]
* Email: otaylor(a)redhat.com
== Detailed Description ==
''''''Note that this proposal is about a change to how third-party
repositories are enabled, not about including anything new in
Fedora.'''''
Currently, when the user opts in to "Enable Third-Party Software
repositories", the` fedora-workstation-repositories` package is
installed, but with the repositories disabled.
With this change, `fedora-workstation-repositories` will be installed
by default (required by `fedora-release-workstation`), and opting in
to "Third-party Software Repositories" will actually enable the
repositories.
Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/105 #105 Ship
fedora-workstation-repositories on install media]
== Conformance to Fedora policies ==
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]:
<blockquote>
The third-party nature of the repository must be apparent to the user
when they enable it, as should the non-free status of its content, if
such. To ensure this, repository files must initially include the
enabled=0 (or equivalent) setting, and the user must explicitly enable
third-party repositories to install from them.
</blockquote>
This proposals is a new implementation of "explictly enable
third-party repositories". There is no proposed change to which
third-party repostories are shipped - and in particular this change
does not include splitting fedora-workstation-repositories to conform
to the recommendation of the current guidelines.
== Technical implementation ==
* There is a <code>fedora-third-party</code> package with a
<code>fedora-third-party</code> script with
<code>enable/disable/refresh/query</code> subcommands. The status is
stored in <code>/etc/fedora-third-party.conf</code>
* Packages like <code>fedora-workstation-repositories</code> that
include third-party repositories will drop config files into
<code>/etc/fedora-third-party.d/*.conf</code>. There will be a
post-transaction file trigger to run <code>fedora-third-party
refresh</code>, which applies the users opt-in status to newly
installed repository files.
* We add a new page to GNOME Initial Setup that asks a single
question, *along the lines of*:<br>
'''Enable Third Party Software repositories?''' <br>
☑ Access additional software from selected third party sources. Some
of this software is proprietary and therefore has restrictions on use,
sharing, and access to source code. <br>
[Find out more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_...
* If the user leaves the box checked, GNOME Initial setup runs
`fedora-third-party enable`.
* For upgrades, GNOME Software shows an info-bar with the same
question if no status is stored in `/etc/fedora-thirdparty.conf`
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The main benefit of this proposal is the removal of the state where
the user has opted in to third party repositories but they are not
actually enabled. PackageKit supports the
<code>enabled_metadata=1</code> key in a repository file, which allows
applications to be searched in this state, but this is not supported
by DNF.
The new method is also easily extensible to Flatpaks, where there also
no equivalent to <code>enabled_metadata=1</code>, even in GNOME
Software.
== Scope ==
* Proposal owners: Create and test proposed
<code>fedora-third-party</code> package. Implement the graphical
controls for this in GNOME Software and gnome-initial-setup.
* Release engineering: [https://pagure.io/releng/issue/10186 #10186]
No changes are required.
* Policies and guidelines: Third-party Software guidelines will need
minor changes to remove references to `enabled_metadata=1`. Pending
finalization of technical implementation.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No real alignment
== Upgrade/compatibility impact ==
Because the "opt-in" status to 3rd party software is currently
represented by whether fedora-workstation-repositories is installed,
and because fedora-workstation-repositories will become an
installed-by-default package, users will need to opt-in again.
They can do this either by responding in the infobar that will be
displayed in GNOME Software, or by running <code>fedora-third-party
enable</code> on the command line.
== How To Test ==
* A fresh install of Fedora Workstation where the user ''does not''
opt-in should have all repositories disabled.
* A fresh install of Fedora Workstation where the user ''does'' opt-in
should have all 3rd-party repositories enabled.
* On an upgrade from F34, if the user opts-out, the enablement status
of third-party repositories should be ''unchanged'' (try enabling one
before the upgrade)
* On an upgrade from F35, if the user opts-in, all 3rd party
repositories should be enabled.
== User Experience ==
The user will get less confusing behavior around third-party
repositories - enabled will mean enabled and will take affect no
matter how they are installing packages.
See https://hackmd.io/@owtaylor/fedora-third-party-repos for a
detailed description of the *current* experience along with some notes
about the desired behavior.
== Dependencies ==
The changes are limited to the following packages:
* The new `fedora-third-party` package
* `fedora-workstation-repositories`
* `gnome-software`
* `gnome-initial-setup`
* `fedora-release-workstation` and other release packages that will
now require fedora-workstation-repositories.
This change proposal is a prerequisite for a separate change proposal
to add a filtered view of Flathub to the set of third-party
repositories.
== Contingency Plan ==
* Contingency mechanism: revert all changes back to the F34 state.
(This will also require reverting the filtered-view-of-Flathub
change.)
* Contingency deadline: beta freeze
* Blocks release? Yes - this needs to be finished or reverted
== Documentation ==
'''This should be a link to a man page for the `fedora-third-party` tool'''
== Release Notes ==
Fedora optionally provides repository definitions allowing users to
install certain third-party software. This used to be done as a
two-step process where when the user asked to enable third-party
repositories, the repository definitions were installed but not
actually enabled, and they had to be separately enabled. With Fedora
35, this is simplified so that the repository definitions are
installed by default, but only enabled if the user opts in.
If you are upgrading from an older version of Fedora, you'll need to
opt-in again - this can be done by running GNOME Software and
accepting the prompt that is shown on the initial page. Alternatively,
you can run <code>fedora-third-party enable</code> from the command
line. If you do not wish to enable third-party repositories, no action
is needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months