Re: Planning to start unifying native and mingw packages
by Sandro Mani
On 03.09.22 18:09, Richard Shaw wrote:
> On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com>
> wrote:
>
>
> On 03.09.22 17:10, Richard Shaw wrote:
> > I'm trying to migrate fltk right now and running into an issue:
> >
> > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> >
> > RPM build warnings:
> >
> > RPM build errors:
> > error: Could not open %files file
> > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
> such file
> > or directory
> >
> > Building the mingw packages seems to be interfering with the
> native build.
>
>
> I put %{?mingw_package_header} in the %{with mingw} (disabled)
> conditional this time and the build completed, so something in there
> is causing the issue.
You actually don't need %{?mingw_package_header} anymore at all (it
actually should just be a no-op with a current mingw-filesystem).
Sandro
1 year, 6 months
FontAwesome 6
by Jerry James
Hi all,
I would like to update the python-pydata-sphinx-theme package to its
latest version, but it needs FontAwesome 6.x. We currently have 4.x
in the fontawesome-fonts package and 5.x in the fontawesome5-fonts
package. Version 6.x has backwards compatibility helpers for both 4.x
and 5.x, so I would like to see fontawesome-fonts upgraded to 6.x and
the fontawesome5-fonts package retired. There are a few hurdles to
jump first.
One hurdle is that the current fontawesome-fonts maintainer doesn't
seem to have time to work on the package:
https://bugzilla.redhat.com/show_bug.cgi?id=1857488#c9. I'm willing
to help out with that, but would prefer to see somebody with more font
experience step into the main admin role.
Another hurdle is that you have to work a little to get the backwards
compatibility features for 4.x and 5.x. It isn't just a drop-in
replacement. I've started a COPR to work through the issues:
https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6/. This
shows both the python-pydata-sphinx-theme update I mentioned at the
top, and a patch for cantata to use 6.x natively.
Packages that need work:
- cantata (see the COPR for a possible solution)
- freeipa
- ipsilon
- python-XStatic-Font-Awesome [1]
- python-sphinx_rtd_theme (see
https://github.com/readthedocs/sphinx_rtd_theme/pull/1064)
- texlive-fontawesome
- texlive-fontawesome5
Packages with documentation built by python-pydata-sphinx-theme or
python-sphinx_rtd_theme may need to change font Requires:
- coq
- libgpuarray
- libsemigroups
- python-BTrees
- python-acme
- python-f5-sdk
- python-networkx
- python-notebook
- python-sphinx-ansible_theme
- python-streamlink
I'd appreciate any help the maintainers of these packages can offer,
as well as suggestions for improvements in what I already have.
Footnotes:
[1] Is this package needed? Nothing in Fedora seems to consume it.
It looks like it is just a bundled copy of the fonts, which also means
that its Requires on fontawesome-fonts and fontawesome-fonts-web are
wrong, since it contains the fonts.
--
Jerry James
http://www.jamezone.org/
1 year, 6 months
F37 Final blocker status update
by Ben Cotton
Fedora Linux 37 Final freeze begins Tuesday 4 October.
Action summary
====================
Accepted blockers
-----------------
1. anaconda — Custom partitioning with 2 drives selected, bootloader
fails to install due to one drive not having a BIOS Boot partition —
ON_QA
ACTION: QA to verify FEDORA-2022-c20d42f3bc
2. gnome-contacts — When a single contact is edited, it results in
multiple contacts of the same name. — ON_QA
ACTION: QA to verify FEDORA-2022-acbfee2ce8
3. gnome-initial-setup — Unable to set up enterprise account with
gnome-initial-setup, clicking continue does not join the domain —
ASSIGNED
ACTION: dgilmore to test
https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333
4. gnome-shell — GNOME Initial Setup uses the English keyboard,
instead of the default keyboard — ASSIGNED
ACTION: Upstream to diagnose and resolve issue
5. gnome-shell — Attempting to disconnect VPN connection from system
menu does nothing — VERIFIED
ACTION: (none)
6. gnome-software — Can't install a local rpm package anymore, Install
button missing (for certain RPMs) — VERIFIED
ACTION: (none)
7. greenboot — greenboot-grub2-set-counter.service fails on 38 IoT
with "cannot open `/boot/grub2/grubenv.new`: No such file or
directory." — NEW
ACTION: Maintainers to diagnose issue
8. grub2 — Windows with bitlocker enabled can't be booted, needs to
use bootnext instead of chainloader — NEW
ACTION: Maintainers to diagnose issue or provide status update
9. mesa — totem: nouveau_pushbuf_data(): totem killed by SIGABRT — NEW
ACTION: Maintainers to update mesa with fixes for F37
10. uboot-tools — Regression booting Fedora on rockchip devices
installed on PCIe NVME drives — ON_QA
ACTION: QA to verify FEDORA-2022-c1d9e8daa9
Proposed blockers
-----------------
1. chrome-gnome-shell — Project name and source repository changed to
gnome-browser-connector — NEW
ACTION: Reviewer to approve new gnome-browser-connector package.
2. gnome-shell — screencast doesn't record the top layer — NEW
ACTION: QA to verify if behavior still exists
3. gnome-shell-extension-background-logo — Update
gnome-shell-extension-background-logo to 43.0 — NEW
ACTION: Maintainer to update package
4. systemd — Czech qwerty layout configured in anaconda, but qwertz
layout used in disk unlock and in VT console — NEW
ACTION: kbd maintainers to reconsider the -legacy subpackage split
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2088113 — ON_QA
Custom partitioning with 2 drives selected, bootloader fails to
install due to one drive not having a BIOS Boot partition
When using custom partitioning on two drives with /boot on a RAID 1
device, the installer only creates one BIOS boot. grub2-install is run
against both drives, but the second fails because it has no BIOS boot
partition. FEDORA-2022-c20d42f3bc contains a candidate fix.
2. gnome-contacts — https://bugzilla.redhat.com/show_bug.cgi?id=2111003 — ON_QA
When a single contact is edited, it results in multiple contacts of
the same name.
Editing a contact results in the contact being properly updated, but
an empty contact is created with the same name. FEDORA-2022-acbfee2ce8
contains a candidate fix.
3. gnome-initial-setup —
https://bugzilla.redhat.com/show_bug.cgi?id=2123494 — ASSIGNED
Unable to set up enterprise account with gnome-initial-setup, clicking
continue does not join the domain
Initially the buttons were missing. Update FEDORA-2022-50e585b456
fixed that issue, however clicking the button does not joing the
domain. Instead, the user is returned to the domain credentials
screen, resulting in an endless loop.
https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333 contains
a backport of upstream's change which may fix it.
4. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2121110 — ASSIGNED
GNOME Initial Setup uses the English keyboard, instead of the default keyboard
Regardless of the default keyboard setting, g-i-s uses the English
keyboard. Relatedly, new users have the English keyboard selected,
even though another language is shown as the default.
FEDORA-2022-52cdfc7920 failed to fix this issue.
5. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125252 — VERIFIED
Attempting to disconnect VPN connection from system menu does nothing
Disabling a VPN doesn't disable the VPN. Fixed in FEDORA-2022-50e585b456.
6. gnome-software —
https://bugzilla.redhat.com/show_bug.cgi?id=2124869 — VERIFIED
Can't install a local rpm package anymore, Install button missing (for
certain RPMs)
What it says on the tin. Fixed in FEDORA-2022-b6246d02fa.
7. greenboot — https://bugzilla.redhat.com/show_bug.cgi?id=2121944 — NEW
greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open
`/boot/grub2/grubenv.new`: No such file or directory."
greenboot service fails on a file-not-found error. This also results
in rebase tests failing because of conflicts with the rebase triggered
by the greenboot failure.
8. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2049849 — NEW
Windows with bitlocker enabled can't be booted, needs to use bootnext
instead of chainloader
Dual-booting recent Windows 10 system with TPM 2.0 fails because
bitlocker can't be unsealed by the TPM. This was waived to F37 under
the "difficult to fix" exception. No additional updates have been
provided.
9. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=2123274 — NEW
totem: nouveau_pushbuf_data(): totem killed by SIGABRT
totem plays ~1 second of video and then crashes. This appears to
happen with all video formats. This appears to be an issue in
multithreading support in the nouveau driver, which is fixed upstream.
The fix is large and may not be suitable for backporting, but would be
available in a mesa-22.3 update.
10. uboot-tools — https://bugzilla.redhat.com/show_bug.cgi?id=2124127 — ON_QA
Regression booting Fedora on rockchip devices installed on PCIe NVME drives
uboot-tools introducted a regression when used with 5.19.x kernels.
FEDORA-2022-c1d9e8daa9 contains a candidate fix.
Proposed blockers
-----------------
1. chrome-gnome-shell —
https://bugzilla.redhat.com/show_bug.cgi?id=2106868 — NEW
Project name and source repository changed to gnome-browser-connector
Upstream has split this into two packages. Package review pending for
renamed package:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2127314
2. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125439 — NEW
screencast doesn't record the top layer
Typing and popup windows don't show when recording a screencast. This
may be fixed in pipewire-gstreamer-0.3.57-1.
3. gnome-shell-extension-background-logo —
https://bugzilla.redhat.com/show_bug.cgi?id=2127192 — NEW
Update gnome-shell-extension-background-logo to 43.0
The Fedora logo is not displayed and the package is not compatible
with gnome-shell 43.
4. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=2121106 — NEW
Czech qwerty layout configured in anaconda, but qwertz layout used in
disk unlock and in VT console
The wrong keymap is used when unlocking disks or virtual terminals. It
looks like this may have never worked. It looks like an issue with how
layouts are mapped between console and xkb. Adam is thinking about how
to approach this:
https://bugzilla.redhat.com/show_bug.cgi?id=2121106#c24
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 6 months
libxml2-2.10.3-1.fc36 breaks (part of) GraphicsMagick
by Michael J Gruber
With this libxml2 update:
```
gm convert -list format
...
gm convert: Unable to load module ("/usr/lib64/GraphicsMagick-1.3.38/modules-Q16/coders/url.la: file not found")
```
In fact, `url.so` is there but cannot be dlopen'ed. This works after downgrading libxml2 to 2.9.
I noticed because my scribus failed to start today, and this was somehow tough to track down.
I still don't know whether libxml2 had an abi change without soname bump and whether a simple rebuild of GM would solve this (in particular, which one to file a big against). But since it was diificult to spot and more packages could be broken (without a clear FTI/FTBFS) I wanted to give a heads up here.
1 year, 7 months
c99-port branches in dist-git
by Florian Weimer
I'm going to push a branch to dist-git for very few packages (so far gcc
and redhat-rpm-config) which will be used by COPR builds to port Fedora
to C99 and later language standards.
GCC 14 is expected to reject certain constructs that were removed from C
in C99:
* implicit function declarations
* implicit ints
* implicit conversion between pointers and int
(that may not have been in C89 even; details still pending)
It's possible to build with -std=gnu89 or -std=c89 to re-enable these
constructs, or fix the sources not to use them. Implicit function
declarations in particular have wasted countless programmer hours due to
difficult-to-track-down ABI mismatches, so it's definitely desirable to
cause them to fail the build.
We have tooling that identifies these constructs if GCC is used, even if
they are used in configure check. Unexpected failures in configure
checks can be tricky because if the package is well-written, the end
result is still a consistent build with some expected failures missing,
corresponding testsuite bits disabled etc.
We will contribute fixes upstream and to rawhide, either by fixing the
sources or switch to C89 mode where it is unlikely source changes will
be acceptable to upstream. The c99-port dist-git branch will only be
used for our support tooling that should not be used by production
builds in the rawhide buildroot. As this is necessarily a
cross-distribution effort, there will be some tracking mechanism to
record and share patches for which no active upstream exists anymore.
C++ packages are only affected in so far as they use the C compiler in
configure checks: these constructs haven't been part of C++ for a long,
long time and may not have been implemented in G++, ever.
I hope to submit a formal Fedora 40 change proposal after some initial
experiments.
Thanks,
Florian
1 year, 7 months
Heads-up: python-pyrsistent 0.19.1 coming to Rawhide
by Ben Beasley
On 2022-11-07, or slightly later, I plan to build python-pyrsistent
0.19.1[1] for Rawhide.
Upstream reports that this release contains a change that is technically
API-breaking:
=====
`Pmap` keys/values/items now behave more like the corresponding Python 3
methods on `dict`s. Previously they returned a materialized `PVector`
holding the items, now they return views instead. This is a slight
backwards incompatibility compared to previous behavior, hence stepping
version to 0.19.
=====
I identified python-jsonschema and python-sentry-sdk as
directly-dependent packages. Neither upper-bounds the dependency
version, and both rebuilt successfully in COPR[2] without changes, so
there should be no impact from this update.
[1] https://src.fedoraproject.org/rpms/python-pyrsistent/pull-request/4
[2] https://copr.fedorainfracloud.org/coprs/music/pyrsistent/packages/
1 year, 7 months
F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PortingToModernC.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect GCC's ability to
implement features from future C standards.
== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fweimer@redhat.com| fweimer(a)redhat.com]
== Detailed Description ==
The most important change is the <b>removal of implicit function
declarations</b>. This legacy compatibility feature causes the
compiler to automatically supply a declaration of type `int
function()` if `function` is undeclared, but called as a function.
However, the implicit return type of `int` is incompatible with
pointer-returning functions, which can lead to difficult debugging
sessions if the compiler warning is missed, as described here:
* [https://developers.redhat.com/blog/2019/04/22/implicit-function-declarati...
Implicit function declarations: flex's use of "reallocarray"]
On x86-64, functions returning `_Bool` called with an implicit
declaration will also not work correctly because the return register
value for `_Bool` functions is partially undefined (not all 32 bits in
the implicitly declared `int` are defined).
Another change for C99 is the <b>removal of implicit `int` type
declarations</b>. For example, in the following fragment, both `i` and
`j` are defined as `int` variables:
<pre>
static i = 1.0;
auto j = 2.0;
</pre>
Support for this obsolete constructs is incompatible with adoption of
type inference for `auto` definitions (which are part of C++).
Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not really related
to the feature under test. If the build system is well written, the
build still succeeds, the relevant features are automatically disabled
in the test suite and removed from reference ABI lists, and it's not
immediately apparent that feature is gone. Therefore, some care is
needed that no such alterations happen, and packages need to be ported
to C99. Various tools for this porting activity are being developed to
support this proposal. Cross-distribution collaboration will help as
well, sharing patches and insights.
GCC 14 may also make other changes by default, as described below.
These changes will also require extensive testing, and some adoption
of configure checks.
==== Removal of old-style function definitions ====
An old style function definition looks like this:
<pre>
int
sum (a, b)
char *a;
int b;
{
return atoi (a) + b;
}
</pre>
It is equivalent to this definition with a prototype:
<pre>
int
sum (char *a, int b)
{
return atoi (a) + b;
}
</pre>
This legacy feature is very close to being incompatible with the C2X
standard, which introduces unnamed function arguments. But due to a
quirk in GCC's implementation, it should be possible to support both
at the same time.
==== New keywords <code>bool</code>, <code>true</code>, <code>false</code> ====
Packages which supply their own definitions instead of including
`<stdbool.h>` (which remains available) might fail to build.
==== Change of meaning of <code>()</code> in function declarators ====
In earlier C versions, a declaration `int function()` declares
`function` as accepting an unspecified number of arguments of unknown
type. This means that both `function(1)` and `function("one")`
compile, even though they might not work correctly. In a future C
standard, `int function()` will mean that `function` does not accept
any parameters (like in C++, or as if written as `int function(void)`
in current C). Calls that specify parameters will therefore result in
compilation errors.
We believe that this change is ABI-compatible, even on ppc64le (with
its parameter save area), although it comes very close to an implicit
ABI break.
==== Rejecting implicit conversions between integers and pointers as errors ====
Currently, GCC does not treat conversion between integers at pointers
as errors, so this compiles:
<pre>
int ptr = "string";
</pre>
However, this is very unlikely to work on 64-bit architectures (it may
work by accident without PIE/PIC).
== Feedback ==
The transition plan has been discussed at various GNU Tools Cauldrons.
Feedback has been generally positive, except a general worry about the
work required.
Without a deliberate porting effort, a lot of breakage occurs,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
seen in 2016 in Fedora with an uncoordinated change], and more
recently [https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werro...
an uncoordinated Clang update].
== Benefit to Fedora ==
Programmers will no longer waste time tracking down things that look
eerily like compiler or ABI bugs because in several cases, builds will
fail with a clear error message, instead of producing a warning that
is easily missed. Potential blockers to adoption of further C language
changes are removed.
== Scope ==
* Proposal owners: Update rawhide over time to be compatible with
strict C99 compilers.
* Other developers: Help out with non-obvious porting issues, and with
upstreaming patches in case active upstreams cannot be easily
identified. Tolerate early backports of upstream-submitted fixes in
Fedora dist-git.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Fedora compiler policy will likely change
due to the adoption of GCC 14 in Fedora 40.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The change is expected to be transparent to those users who do not use
C compilers. No features are supposed to be added or removed as a
result. In fact, most of the porting effort focuses on avoiding
configuration changes.
== How To Test ==
General regression testing is sufficient.
== User Experience ==
User experience does not change.
== Dependencies ==
To avoid regressing the porting effort, GCC as the system compiler
needs to reject obsolete constructs by default. This is expected for
GCC 14, to be released as part of Fedora 40 in Spring 2024.
== Contingency Plan ==
* Contingency mechanism: Upstream GCC will probably accept obsolete
constructs longer in case distributions like Fedora cannot port to
modern C in time.
* Blocks release? No if GCC doesn't switch. If GCC switches, we have
to complete the port.
== Documentation ==
This section will be updated once more documentation of the porting
effort will become available.
== Release Notes ==
Probably not needed because no user visible impact is intended.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
