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
9 months, 2 weeks
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
9 months, 2 weeks
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
9 months, 2 weeks
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
9 months, 3 weeks
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
9 months, 4 weeks
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
10 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
10 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
10 months, 1 week
