Dropping elfutils-libelf-devel-static and elfutils-devel-static
subpackages
by Mark Wielaard
Hi,
I would like to drop the elfutils-libelf-devel-static and elfutils-
devel-static subpackages which provide static libraries for libelf and
libdw/libasm. They seem to have been provided a long time ago for some
core binaries, like rpm, to provide static binaries. But it looks like
nothing is using this mechanism anymore today. The static libdw library
probably never really worked correctly till 0.180 (released just a few
weeks ago), because it depended on dynamically open some other non-
static libraries... oops. I don't believe there is any good reason to
not simply link against the normal shared libraries (they have been
binary compatible for years).
Nothing seems to require these packages, but that might be simply be
because they are static libraries, so there aren't any runtime
requirements. Is there some way to determine if anything would start
failing to build if I simply remove them? Apart from simply waiting for
the bug reports to pop up :)
Is there a procedure to follow for dropping these sub-packages, or can
I simply remove them from the spec file?
Thanks,
Mark
3 years, 11 months
[HEADS-UP] OpenJDK 11 is now the default Java in rawhide
by Fabio Valentini
(Sending this heads-up in a new thread for better visibility.)
Yesterday the f33-java11 side tag was merged into rawhide, which
brings the necessary changes to make java-11-openjdk the default Java
in fedora. All packages depending on Java should also have been
rebuilt in this side tag.
The "new" Java SIG (@java-maint-sig) is still dealing with a pretty
small amount of fallout from this change. For example, some packages
that are stuck on Java 8 for various reasons are failing to compile or
run because their dependencies have been built with bytecode that is
too new for OpenJDK 8.
We're tracking the packages that are stuck with OpenJDK 8 here:
https://pagure.io/java-maint-sig/issue/10
There's also a complete bytecode version analysis of all Java packages
in fedora in progress to identify more possible issues:
https://pagure.io/java-maint-sig/issue/7
I have tried to deal with the pretty long list of "easy fixes" for
Java 11 compatibility, having fixed over 50 FTBFS issues over the past
few days alone. The remaining "EasyFix" candidates are tracked here,
though we'll probably close this ticket soon.
https://pagure.io/java-maint-sig/issue/1
If you see any issues with Java 11 as default in rawhide (the change
is live in rawhide and will be part of the next successful compose,
possibly today), feel free to comment on the linked tickets if you
have similar issues, or open a new ticket with @java-maint-sig on
pagure if you need help.
Fabio
3 years, 11 months
pagure pull-request email workflow
by Mark Wielaard
Hi,
I got a pagure pull-request for my package (a first!).
But I am slightly confused how to handle this.
The email that pagure sents is not very helpful since it doesn't
include the actual patch to try out. Also when I replied to the email
it seems to have not gone to the actual submitter (and just seems to
have disappeared completely). So I have no idea how to interact with
them (actually I figured out there is a patch link on the website,
which luckily does include the submitters email, so I could email them
with some questions, but it wasn't very intuitive or easily
discoverable).
Do you have to handle them on that pagure website? Is it possible to
handle these pull-request through email? Or is there a normal (git)
command line interface for these?
Thanks,
Mark
3 years, 11 months
Policy for Modules in Fedora and Fedora ELN - Fedora 33
Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ModularPolicy
== Summary ==
Establish a set of rules for Modular content in Fedora to ensure an
optimal user and packager experience.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
Over the last several months, members of the Modularity WG and FESCo
have been working to establish a policy for module inclusion in
Fedora. We now have a proposal that FESCo requested be taken to the
Fedora community via the Change Proposal.
There is a preview of the new policy available at
https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
== Benefit to Fedora ==
This policy makes explicit what packagers can and cannot do with
Modules in Fedora, which should avoid future issues like those that
were seen during the Fedora 31 and Fedora 32 cycles.
== Scope ==
* Proposal owners:
The proposal is written, so minimal work remains. We may need to make
revisions or clarifications based on public feedback.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
N/A this is not a user-facing change.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 11 months
Modularity Improvements Objective
by Daniel Mach
Hello everyone,
There's a Modularity Improvements Objective draft available[1].
The Objective summarizes the work that is in progress already as well as
highlights our plans for Fedora 34.
We're planning to fix the current modularity in Fedora 33 and 34.
We may look into alternatives or bigger design changes in Fedora 35 and
later.
You can find more details in the Objective document[1].
- Daniel
[1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
3 years, 11 months
PSA: dnf autoremove cleans fedora-repos-modular
by Igor Raits
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora-
repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora-
repos (DEPENDENCY) and nothing depends on fedora-repos-modular so it is
not needed anymore (from the solver POV).
The fedora-repos is being pulled in by fedora-release-common (that is
brought by fedora-release-workstation or others). fedora-repos is not
part of the @core group in comps so its reason recorded in DNF DB is 1.
enum class TransactionItemReason : int {
UNKNOWN = 0,
DEPENDENCY = 1,
USER = 2,
CLEAN = 3, // hawkey compatibility
WEAK_DEPENDENCY = 4,
GROUP = 5
};
On my laptop:
❯ sqlite3 /var/lib/dnf/history.sqlite
sqlite> select trans_id,name,epoch,version,release,reason from
trans_item join rpm on rpm.item_id=trans_item.item_id where name like
'fedora-release%' or name like 'fedora-repos%';
1|fedora-release-common|0|33|0.8|1
1|fedora-release-identity-workstation|0|33|0.8|1
1|fedora-release-workstation|0|33|0.8|5
1|fedora-repos|0|33|0.6|1
1|fedora-repos-rawhide|0|33|0.6|1
21|fedora-release-common|0|33|0.9|1
21|fedora-release-common|0|33|0.8|1
21|fedora-release-identity-workstation|0|33|0.9|1
21|fedora-release-identity-workstation|0|33|0.8|1
21|fedora-release-workstation|0|33|0.9|5
21|fedora-release-workstation|0|33|0.8|5
143|fedora-repos-modular|0|33|0.8|1
143|fedora-repos-rawhide-modular|0|33|0.8|1
143|fedora-repos|0|33|0.8|1
143|fedora-repos|0|33|0.6|1
143|fedora-repos-rawhide|0|33|0.8|1
143|fedora-repos-rawhide|0|33|0.6|1
The packages that have been brought by the obsoletes inherit reason
(DEPENDENCY in this case) and since nothing depends on those they are
automatically cleaned up on the autoremove.
I don't know where / which the fix should be: DNF, comps or both.
Simply putting the fedora-repos-modular in comps won't help since DNF
is only using them when running `group install/update/remove`.
So sending this email just in case somebody will see this interesting
behavior.
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8G97AACgkQEV1auJxc
Hh6SkBAAo4iTvTmSImNbSRAZe6VzKfUJ1gBPjgMITEueM7pxa8zlZ7g2bOpl1UiI
TD+DKI953Qk2gZcN+WBvkQO13Cef/FD/lp6nGXvyo87mOs2ThSc+a6UgufEBceVY
Z5kGCoCQnfA6JkBtRtFdMbsCvVKtSRSOFJXlW7DCybLGKizUlFPqHdug0qxGpoO2
XWldoX0Bw0F11Pr2FqujZXlcfXe5G51lkfPFnChc0a4O0+d0/AsWZJ0dM0l1ff6l
GT43t+boiw9Dwp8KEBZTh7uTWQAeLAo9UxGIs2T2oZikHNwSSo13N6nwcS6x2XYd
AaHVET5dn4tITH9WjiknS9IHy06D5MZ8pWBRs46aav52Ro6GxNYeALYdhjaM2heG
mMGkjAWkXJ0qtaRR9qi68CfQiDfQjzYe0JXEHJTrLV+Pv42OrJJJoq7NWGOJbqV0
T9DYJoO63W74q/rttMNVMIBG8GtzbTBqoxuP9ooykpAzRv2LPn1Jc1L3eEBXSO0w
QW0SH5i6v6OgajCrc813TytboOua9zDZ55ENP0dJNXjqAiznZJjqrYG3RWUJH4cA
qx6xygK3OvZHm9vuL4VnXCp4wW/TDGf8MNGF0hoF75IbRN1+nrAAtGorx9BdV2g+
SvTV1Cs9CPyOKy0Q2brILtBZq6em6JNzkFAMg5h9xoce4brbyA8=
=UXSc
-----END PGP SIGNATURE-----
3 years, 11 months
