Re: hdf5 and netcdf soname update coming to rawhide, perhaps F42

[Orion Poplawski]

On 2/10/25 19:38, Orion Poplawski wrote:
Later this week I will be updating hdf5 to 1.14.6 from 1.14.5 and netcdf 
to 4.6.3 in a side tag in rawhide.  Some notes:


For a long time, hdf5 would emit a warning if a program linked to a 
version of hdf5 that did not *exactly* match the full version of the 
library it was compiled with.  For this reason man hdf5 deps have:


Requires: hdf5 = %{_hdf5_version}

or

Requires: hdf5%{?_isa} = %{_hdf5_version}

with _hdf5_version being defined in the hdf5-devel rpm.  With the update 
to 1.13 this was "fixed" upstream to be limited to the major.minor 
combo.  So I have now changed the hdf5 package to set _hdf5_version to 
be just X.Y and to also have:


Provides: %{name} = %{_hdf5_compat_version}
Provides: %{name}%{?_isa} = %{_hdf5_compat_version

as a temporary workaround.  I'm open to other suggestions for dealing 
with this if there are better ways to do it.


I think though that upstream is now using sonames better so we may be 
able to just drop the Requires in the dependent packages at a later 
point.  The packages that have this requires and will need be rebuilt are:


cgnslib
h5py
hdf5
netcdf
Field3D
gdl
matio
nexus
octave
paraview
python-pypet
vtk


I'm also updating netcdf to 4.9.3 from 4.9.2.  Despite only being a 
patch level version increment, this is a soname change and so packages 
that depend on that will be rebuilt:


GMT
LabPlot
R-ncdf4
bout++
dx
eccodes
exodusii
gdal
gdl
genesis-simulator
grace
grass
grib_api
libminc
ncl
nco
ncview
netcdf-cxx
netcdf-fortran
netcdf-perl
netcdf4-python
octave-netcdf
paraview
pymol
qgis
vtk
wgrib2


hdf5 has been updated in Rawhide and F42.  I've held up updating netcdf 
for now to deal with build failures in some dependencies.


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 42 breaks new windows installations

[Barry]

> On 17 Feb 2025, at 10:40, Frenzy Biscuit  wrote:
> 
> However, when I do not enter BIOS and just try booting normally I boot loop 
> consistently.

In the past I have seen issues when there were uefi variables that needed 
removing.
At the time I use the manufacture’s documented way to completely reset every 
setting in the uefi bios. This removed all uefi variables and put all settings 
to their defaults.

Barry


-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can't create EPEL 10 branch: Did not manage to rebase this pull-request

[Petr Pisar]

V Sun, Feb 16, 2025 at 06:58:19PM -0500, Neel Chauhan napsal(a):
> Hi,
> 
> I'm trying to create an EPEL 10 branch for a package I maintain, ttyd:
> https://pagure.io/releng/fedora-scm-requests/issue/72348
> 
> I am getting this issue in Pagure:
> 
> ===
> Traceback (most recent call last):
>   File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line
> 189, in process
> self.process_ticket(issue)
>   File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line
> 301, in process_ticket
> self.create_new_branch(issue, issue_body)
>   File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line
> 778, in create_new_branch
> self.dist_git.new_branch(
>   File "/opt/app-root/src/toddlers/utils/pagure.py", line 500, in new_branch
> raise PagureError(
> toddlers.exceptions.pagure_error.PagureError: Couldn't create branch in
> project 'rpms/ttyd'
> 
> Request to 'https://src.fedoraproject.org/api/0/rpms/ttyd/git/branch':
> {'branch': 'epel10', 'from_commit':
> '06bfff8ce8cca42ac22e297e9c880809b630abe9'}
> 
> Response:
> {'error': 'Did not manage to rebase this pull-request', 'error_code':
> 'ENOCODE'}
> 
> Status code: 400
> ===
> 
> Could a sysadmin/developer (whoever's responsible) please fix this?
> 
It is exaplained in  description
that failed SCM request needs to manually reported to
. Please, do that.

-- Petr


signature.asc
Description: PGP signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libarrow (Apache Arrow) and liborc (Apache ORC) SONAME bumps in rawhide

[Kaleb Keithley]

Side tag merged.   (Thanks Ben.)

On Fri, Feb 14, 2025 at 6:00 AM Ben Beasley  wrote:

> All three builds completed successfully. If I haven’t missed anything, it
> should be safe to merge the side tag at any time.
> On 2/13/25 10:03 PM, Ben Beasley wrote:
>
> I’ve used provenpackager privilege to kick off rebuilds of gdal, groonga,
> and root in the side tag (f43-build-side-105129):
>
> gdal: https://koji.fedoraproject.org/koji/taskinfo?taskID=129216933
>
> groonga: https://koji.fedoraproject.org/koji/taskinfo?taskID=129216924
>
> root: https://koji.fedoraproject.org/koji/taskinfo?taskID=129216944
>
> I’ll keep an eye on these builds to make sure they all complete
> successfully. I think those should be the last three necessary rebuilds.
> On 2/13/25 4:40 PM, Ben Beasley wrote:
>
> I think and hope that I’ve analyzed this correctly.
>
> It looks like these packages have already been rebuilt:
>
> - ceph
>
> - myst-nb
>
>
> https://koji.fedoraproject.org/koji/builds?order=-tag_name&tagID=105129&inherited=1&latest=1
>
> It looks like these packages still need to be rebuilt:
>
> - gdal
>
> - groonga
>
> - root
>
> It looks like these packages just depend on python3-pyarrow, not on any of
> the shared libraries, so they don’t need to be rebuilt. They would still be
> affected if there were any Python API changes.
>
> - myst-nb (but it was already rebuilt anyway)
>
> - pcp
>
> - python-dask
>
> - python-dask-expr
>
> - python-distributed
>
> - python-formulaic
>
> - python-fsspec
>
> - python-geopandas
>
> - python-papermill
>
> - python-pyogrio
>
> - python-pytest-regressions
>
> On 2/13/25 12:57 PM, Kaleb Keithley wrote:
>
> One week warning.
>
> I will be merging whatever is built in the side tag on 20 Feb.
>
> On Fri, Feb 7, 2025 at 1:25 PM Kaleb Keithley  wrote:
>
>>
>> liborc-2.1.0 and libarrow-19.0.0 are now built in the side tag
>> (f43-build-side-105129).
>>
>> On Thu, Feb 6, 2025 at 6:02 PM Kaleb Keithley 
>> wrote:
>>
>>> Arrow packages include libarrow*.rpm parquet*.rpm (libparquet*), and
>>> python-pyarrow*.rpm.   Updating to Arrow 19.0.0
>>>
>>> ORC packages include liborc2*.rpm.  Updating to ORC 2.1.0
>>>
>>> side-tag f43-build-side-105129 has been created for rebuilding the
>>> dependent packages:
>>>  * ceph (for which I am the maintainer
>>>  * gdal
>>>  * groonga
>>>  * myst-nb
>>>  * python-dask
>>>  * python-dask-expr
>>>  * python-distributed
>>>  * python-formulaic
>>>  * python-fsspec
>>>  * python-geopandas
>>>  * python-pandas
>>>  * python-papermill
>>>  * python-pyogrio
>>>  * root
>>> etc.
>>>
>>> I will be building liborc, libarrow, and ceph soon. (I'm not a proven
>>> packager, I can't build the other packages.)
>>> Tentatively I plan on merging whatever is built in the side tag on or
>>> after 20 Feb 2025.
>>>
>>
> --
>
> Kaleb
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Kaleb
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Adam Williamson]

On Mon, 2025-02-17 at 10:35 -0500, Dusty Mabe wrote:
> > 
> > One more question: are packagers able to restart the tests?
> > 
> > 
> > @Dusty Mabe  will know better, but I don't 
> > think packagers can restart the tests currently.
> 
> No. Not currently. But it is something we could look into enabling and/or 
> making easier.

You might be surprised. It might actually work already without you
knowing it.

Clicking the "Re-Run Tests" button in Bodhi causes Bodhi to publish a
new bodhi.update.status.testing.koji-build-group.build.complete message
- which is the same topic I think I advised you to use for CoreOS
update test scheduling. The only difference between a 're-trigger'
message and the message that is published when the update is a key in
the message data called `re-trigger`. It's `true` for messages
published when "Re-Run Tests" is clicked, `false` otherwise.

If your scheduler triggers off `koji-build-group.build.complete`
messages and doesn't do anything special with the `re-trigger` key, it
probably works already.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads up: python-notmuch to be removed

[Michael J Gruber]

Hi there

notmuch (the mail indexer) so far comes with two sets of python bindings:
- python3-notmuch aka legacy bindings
- python3-notmuch2 cffi bindings

The legacy bindings had been deprecated since notmuch 0.30 (2020-07-10).

In Fedora, notmuch currently is at version 0.38 (all active branches),
in EPEL 9 at 0.36. The upcoming upstream release 0.39 will drop the
legacy bindings:

https://nmbug.notmuchmail.org/nmweb/show/20250215200727.1355601-1-david%40tethera.net

"drop" means: moved to contrib area, not built nor tested by default,
to be dropped completely "soon".

In Fedora, no package requires python-notmuch, except for alot which
requires it in spec but indeed uses python3-notmuch2:

https://bugzilla.redhat.com/show_bug.cgi?id=2346110

In fact, this would have been resolved in rawhide already if only that
package built at all (different story).

So, I suggest to drop the notmuch-python subpackage with the upcoming
notmuch 0.39 in rawhide and - depending on the timing - in F42.

Please let me know in case there are users of the legacy bindings
which I"ve overlooked, and I'll look into building contrib if needs
be.

Just to be clear:
python3-notmuch2 will stay, of course. (Any afew users here? I"m
porting that to the new bindings right now ...)

F41 and F40 will stay at notmuch 0.38 which includes python3-notmuch.

Cheers
Michael

Yes, alot of words about notmuch ...
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring rdist and rssh in Rawhide

[Michal Ruprich]

Just a follow-up that I have retired rdist in Rawhide.

Regards,

Michal Ruprich

On 1/27/25 08:41, Michal Ruprich wrote:

Hi,

this is just a quick message that I'll be retiring rdist package in 
Rawhide. The Upstream of rdist is long gone and it has been recently 
hit with the GCC15 and is currently in the state of FTBFS. The only 
package that depends on it is rssh, I already spoke to Huzaifa and he 
agreed to remove it as well.


If anyone still cares about rdist (or rssh), let me know and you can 
take the maintenance under your own wings.


Regards,

Michal Ruprich



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need help with "cannot open display" error when %pyproject_check_import is run

[Chris Adams]

Once upon a time, Miro Hrončok  said:
> On 17. 02. 25 2:45, Chris Adams wrote:
> >Once upon a time, Alexander Ploumistos  said:
> >>I am trying to build the latest version of input-remapper[1] and I
> >>guess some change to the test units has led to this error:
> >>
> >>[…]
> >>+ /usr/bin/python3 -sP /usr/lib/rpm/redhat/import_all_modules.py -f
> >>/builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1-1.fc42.x86_64-pyproject-modules
> >>Check import: inputremapper
> >>Check import: inputremapper.bin
> >>Check import: inputremapper.bin.input_remapper_control
> >>Check import: inputremapper.bin.input_remapper_gtk
> >>
> >>(import_all_modules.py:1580): Gtk-WARNING **: 01:44:47.167: cannot open 
> >>display:
> >>error: Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)
> >> Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)
> >
> >It sounds like it's something trying to test under a GUI; rather than
> >try to avoid the test, try using Xvfb to satisfy it.  Add a
> >
> > BuildRequires: Xvfb xauth
> >
> >and then wrap tests with (possibly moving them to a script to call):
> >
> > xvfb-run -a -w1 [check command]
> 
> Unfortunately, the %pyproject_check_import expands to a shell scriptlet,
> so this won't be trivial.
> 
> We can amend the macro to allow using xvfb-run or xwfb-run somehow.

Yeah, I saw the macros, but an on-the-fly created shell script should
expand them fine.  Like:

cat > rpm-tests.sh <<'EOF'
#!/bin/sh
%pyproject_check_import
[and more]
EOF
chmod +x rpm-tests.sh
xfvb-run -a -w1 ./rpm-tests.sh

-- 
Chris Adams 
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Adam Williamson]

On Mon, 2025-02-17 at 11:06 +0100, Clement Verna wrote:
> On Sat, 15 Feb 2025 at 20:51, Adam Williamson 
> wrote:
> 
> > On Sat, 2025-02-15 at 14:54 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Feb 14, 2025 at 02:40:29PM -0800, Adam Williamson wrote:
> > > > On Fri, 2025-02-14 at 16:31 -0500, Dusty Mabe wrote:
> > > > > IMO the bar would only need to be that high if the user had no way
> > to ignore the test results.
> > > > > All gating does here (IIUC) is require them to do an extra step
> > before it automatically flows
> > > > > into the next rawhide compose.
> > > > 
> > > > again, technically, yes, but *please* let's not train people to have a
> > > > pavlovian reaction to waive failures, that is not the way.
> > > 
> > > IMO, the bar for *gating* tests needs to be high. I think 95% true
> > > positives would be a reasonable threshold.
> > 
> > Do you mean 95% of failures must be 'real' (i.e. up to 5% can be
> > 'false')? Is this after automatic retries and manual intervention by
> > the test system maintainers, or before?
> > 
> > Off the top of my head, 95% seems low. I'm pretty sure we do better
> > than that with openQA and people would complain if that was all we
> > managed. We usually maintain a 0% false failure rate after auto-retries
> > and <24h manual intervention -
> > 
> > https://openqa.fedoraproject.org/group_overview/2?limit_builds=100&limit_builds=400
> > has 0 false failures ATM.
> > 
> 
> Thanks, that's interesting. What do you call <24h manual intervention? One
> example that comes to mind would be to disable or snooze a test that
> started to trigger false failures in under 24h.
> If that's the case, I think that sounds achievable.

We've done that very occasionally in dire emergencies (though what
you'd actually want to do is disable *gating* on the test, not disable
the test itself - this is an edit to the greenwave policy).

Usually what it means is "rerun the test if it just flaked twice, or
fix the problem if there's a specific problem causing the failure that
is not a bug in the update itself". that could mean updating one of the
openQA screenshots, for instance, or fixing a bug in the test logic, or
working with releng/infra to fix a bug that's causing tests to fail,
e.g. pagure not responding (and then rerunning all the tests that
failed).

If the failure is caused by a real bug in the update, we usually write
up an explanation of the issue as a comment in Bodhi, or a bug report
with a link from Bodhi.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive provenpackagers for the F42 cycle

[Philip Cameron]

The package I maintain, xtrkcad, releases every 2 years give or take. If it
weren't for a build failure in f42 I would not need to build until the next
package release. So I actively maintain xtrkcad but do so infrequently as
package releases become available.

On Mon, Feb 17, 2025, 1:12 PM Mattia Verga via devel-announce <
devel-annou...@lists.fedoraproject.org> wrote:

> In accordance with FESCo policy[1], the following provenpackagers will
> be submitted for removal in two weeks based on a lack of Koji builds
> submitted in the last six months. If you received this directly, you
> can reply off-list to indicate you should still be in the
> provenpackager group.
>
> Note that removal from this group is not a "punishment" or a lack of
> appreciation for the work you have done. The intent of the process is
> to ensure contributors with distro-wide package privileges are still
> active and responsive. This process is done regularly at the branch
> point in each release.
>
> [1] 
> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status
>
> Checked 123 provenpackagers
> The following 9 provenpackagers have not submitted a Koji build since at 
> least 2024-08-12 00:00:00:
> mohanboddu
> jerboaa
> rmattes
> pbrady
> pmikova
> dwmw2
> otaylor
> mgieseki
> wtogami
>
>
> --
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Dusty Mabe]

On 2/17/25 1:35 PM, Adam Williamson wrote:
> On Mon, 2025-02-17 at 10:35 -0500, Dusty Mabe wrote:
>>>
>>> One more question: are packagers able to restart the tests?
>>>
>>>
>>> @Dusty Mabe  will know better, but I don't 
>>> think packagers can restart the tests currently.
>>
>> No. Not currently. But it is something we could look into enabling and/or 
>> making easier.
> 
> You might be surprised. It might actually work already without you
> knowing it.
> 
> Clicking the "Re-Run Tests" button in Bodhi causes Bodhi to publish a
> new bodhi.update.status.testing.koji-build-group.build.complete message
> - which is the same topic I think I advised you to use for CoreOS
> update test scheduling. The only difference between a 're-trigger'
> message and the message that is published when the update is a key in
> the message data called `re-trigger`. It's `true` for messages
> published when "Re-Run Tests" is clicked, `false` otherwise.
> 
> If your scheduler triggers off `koji-build-group.build.complete`
> messages and doesn't do anything special with the `re-trigger` key, it
> probably works already.

Interesting. I'll have to look into it.

Does this have a side effect of causing all tests to re-run, even ones that 
have already run and passed?

Dusty
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Dusty Mabe]

On 2/17/25 1:32 PM, Adam Williamson wrote:
> On Mon, 2025-02-17 at 11:06 +0100, Clement Verna wrote:
>> On Sat, 15 Feb 2025 at 20:51, Adam Williamson 
>> wrote:
>>
>>> On Sat, 2025-02-15 at 14:54 +, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Feb 14, 2025 at 02:40:29PM -0800, Adam Williamson wrote:
> On Fri, 2025-02-14 at 16:31 -0500, Dusty Mabe wrote:
>> IMO the bar would only need to be that high if the user had no way
>>> to ignore the test results.
>> All gating does here (IIUC) is require them to do an extra step
>>> before it automatically flows
>> into the next rawhide compose.
>
> again, technically, yes, but *please* let's not train people to have a
> pavlovian reaction to waive failures, that is not the way.

 IMO, the bar for *gating* tests needs to be high. I think 95% true
 positives would be a reasonable threshold.
>>>
>>> Do you mean 95% of failures must be 'real' (i.e. up to 5% can be
>>> 'false')? Is this after automatic retries and manual intervention by
>>> the test system maintainers, or before?
>>>
>>> Off the top of my head, 95% seems low. I'm pretty sure we do better
>>> than that with openQA and people would complain if that was all we
>>> managed. We usually maintain a 0% false failure rate after auto-retries
>>> and <24h manual intervention -
>>>
>>> https://openqa.fedoraproject.org/group_overview/2?limit_builds=100&limit_builds=400
>>> has 0 false failures ATM.
>>>
>>
>> Thanks, that's interesting. What do you call <24h manual intervention? One
>> example that comes to mind would be to disable or snooze a test that
>> started to trigger false failures in under 24h.
>> If that's the case, I think that sounds achievable.
> 
> We've done that very occasionally in dire emergencies (though what
> you'd actually want to do is disable *gating* on the test, not disable
> the test itself - this is an edit to the greenwave policy).
> 
> Usually what it means is "rerun the test if it just flaked twice, or
> fix the problem if there's a specific problem causing the failure that
> is not a bug in the update itself". that could mean updating one of the
> openQA screenshots, for instance, or fixing a bug in the test logic, or
> working with releng/infra to fix a bug that's causing tests to fail,
> e.g. pagure not responding (and then rerunning all the tests that
> failed).
>
> 
> If the failure is caused by a real bug in the update, we usually write
> up an explanation of the issue as a comment in Bodhi, or a bug report
> with a link from Bodhi.

What you are describing is exactly what we do. Either:

1. Fix the source of the false failure (i.e. test needs updating)
2. Retry because it was a infra or network flake (and possibly open PR to make 
test more robust)
3. Try to open an issue against failed component and report negative karma in 
bug
   because we have high confidence it's an actual issue in the update.

It just happens that the messiness between 1. and 2. is something we aren't 
currently
accounting for in the metric Clement posted. Of course when you stamp out 
flakes and
sources of false failures and run the tests one final time and it passes then 
you can
get your false failure rate down to 0% :) 

Dusty
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Dusty Mabe]

On 2/17/25 5:12 AM, Clement Verna wrote:
> 
> 
> On Sun, 16 Feb 2025 at 13:52, Zbigniew Jędrzejewski-Szmek  > wrote:
> 
> On Sat, Feb 15, 2025 at 11:11:49AM -0500, Dusty Mabe wrote:
> > On 2/15/25 9:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Feb 14, 2025 at 02:40:29PM -0800, Adam Williamson wrote:
> > >> On Fri, 2025-02-14 at 16:31 -0500, Dusty Mabe wrote:
> > >>> IMO the bar would only need to be that high if the user had no way 
> to ignore the test results.
> > >>> All gating does here (IIUC) is require them to do an extra step 
> before it automatically flows
> > >>> into the next rawhide compose.
> > >>
> > >> again, technically, yes, but *please* let's not train people to have 
> a
> > >> pavlovian reaction to waive failures, that is not the way.
> > >
> > > IMO, the bar for *gating* tests needs to be high. I think 95% true
> > > positives would be a reasonable threshold.
> >
> > I can't promise 95% true positive rate. These aren't unit tests. They 
> are system wide
> > tests that try to test real world scenarios as much as possible. That 
> does mean pulling
> > things from github/quay/s3/Fedora infra/etc.. and thus flakes happen. 
> Now, in our
> > tests we do collect failures and Retry them. If a retry succeeds we 
> take it as success
> > and never report the failure at all. However there are parts of our 
> pipeline that might
> > not be so good at retrying.
> >
> > All I'm trying to say is that when you don't control everything it's 
> hard to say with
> > confidence something will be 95%.
> 
> As AdamW wrote in the other part of the thread, OpenQA maintains a
> false positive rate close to 0%. So it seems possible, even with our
> somewhat unreliable infrastructure…
> 
> I am worried about the high failure rate for the coreos tests. But it
> is possible that if we make them gating, the reliability will improve.
> I know that in case of systemd, there was a failure that affected quite
> a few of the updates because it wasn't fixed immediately. If we blocked
> the first update, the percentage of failures would be lower. So I
> think it makes sense to try this… If after a few months with this
> we still have too many updates blocked by gating, we can reevaluate.
> 
> 
> I would be happy to provide a monthly report of failures so that we can 
> measure the rate of false positives. 
> 
> 
> > As I promised before, maybe just work with us on it. These tests have 
> been enabled for
> > a while and I've only seen a handful of package maintainers look at the 
> failures (you,
> > Zbyszek, being one of them; thank you!).
> >
> > We do want them to be useful tests and I promise when a failure happens 
> because of our
> > infra or tests themselves being flakey we try to get it fixed.
> 
> One more question: are packagers able to restart the tests?
> 
> 
> @Dusty Mabe  will know better, but I don't think 
> packagers can restart the tests currently.

No. Not currently. But it is something we could look into enabling and/or 
making easier.

Dusty
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need help with "cannot open display" error when %pyproject_check_import is run

[Alexander Ploumistos]

Thank you all very much for your input.

A long time ago I had needed to run some graphical tests in %check and
I vaguely remember using some dummy driver which was then
superseded(?) by xvfb and then for some reason I stopped needing to
care about all that and that cache in my brain got flushed. Thanks for
putting that info back.

Thinking it was the easiest option, I decided to go with Karolina's
suggestion and skip the offending module, which sure enough, allowed
the tests to proceed and lead to a wall of failures:

= 475 failed, 12 passed, 4 deselected, 4 warnings, 112 errors in
146.02s (0:02:26) =

https://koji.fedoraproject.org/koji/taskinfo?taskID=129355209

I was hoping that Ben, who authored the pytest part of the spec file,
would be able to shed some light as to what is going on, though I
suspect I need to get in touch with upstream. I can't make heads or
tails of anything. Why does test_autoload fail? What should the "Patch
is already started" error message mean to me?

I know our guidelines about unit tests and I can see the point in
upstream having them in place, but do we as a downstream distribution
need to run all of these? It's not like a math library, that might
produce different results on different architectures, this program
either works or it doesn't. 500 tests that ultimately tell us nothing
about the state of the program once it is installed seem like an
overkill.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 42 breaks new windows installations

[Samuel Sieb]

On 2/17/25 11:47 AM, luciano s. wrote:

I won't have a source for what I said right now, but likely searching for
Secure Boot + TPM2 issues when dual booting will help
Hope that helps,
Mateus Rodrigues Costa


Is it that what you mentioned ? :
https://bugzilla.redhat.com/show_bug.cgi?id=2049849


No, that's for trying to boot windows from grub.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Packaging Radeon ProRender addon for Blender

[Luya Tshimbalanga]

Hello team,

I stumble in Radeon ProRender engine [1] and attempt to package it 
following the python guideline:

https://copr.fedorainfracloud.org/coprs/g/designsuite/blender/build/8665473/

It seems an alternative to both Blender Cycles engine (has issue for AMD 
GCN architecture with newer ROCm release) and Lux Render supporting all 
videocards hardware. Could someone give a point how

to properly packaging it please as addon for Blender?

Thank you.


Reference:
---

[1] https://gpuopen.com/radeon-prorender-suite/#prorender

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

packit and mass prebuild

[Orion Poplawski]

It seems like it would be very helpful to integrate something like mass 
prebuild [1] with packit [2].  As such, I've filed the following request 
[3] for integration if possible.


In the meantime, I've found that a mpb.config like:

arch: x86_64
chroot: fedora-rawhide
packages:
  python-sphinx-gallery:
src_type: git
src: 
https://src.fedoraproject.org/forks/packit/rpms/python-sphinx-gallery.git

committish: rawhide-update-pull_from_upstream
name: python-sphinx-gallery-update
verbose: 1

to be helpful with packit PRs.

Any other thoughts / suggestions?

1 - https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
2 - https://packit.dev/docs/fedora-releases-guide/dist-git-onboarding
3 - https://github.com/packit/packit/issues/2531

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 42 breaks new windows installations

[luciano s.]

> I won't have a source for what I said right now, but likely searching for
> Secure Boot + TPM2 issues when dual booting will help
> Hope that helps,
> Mateus Rodrigues Costa

Is it that what you mentioned ? :
https://bugzilla.redhat.com/show_bug.cgi?id=2049849
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Inactive provenpackagers for the F42 cycle

[Mattia Verga via devel]

In accordance with FESCo policy[1], the following provenpackagers will
be submitted for removal in two weeks based on a lack of Koji builds
submitted in the last six months. If you received this directly, you
can reply off-list to indicate you should still be in the
provenpackager group.

Note that removal from this group is not a "punishment" or a lack of
appreciation for the work you have done. The intent of the process is
to ensure contributors with distro-wide package privileges are still
active and responsive. This process is done regularly at the branch
point in each release.

[1]
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status
Checked 123 provenpackagers
The following 9 provenpackagers have not submitted a Koji build since at least 
2024-08-12 00:00:00:
mohanboddu
jerboaa
rmattes
pbrady
pmikova
dwmw2
otaylor
mgieseki
wtogami-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20250217.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250216.n.0
NEW: Fedora-Rawhide-20250217.n.0

= SUMMARY =
Added images:2
Dropped images:  1
Added packages:  1
Dropped packages:5
Upgraded packages:   71
Downgraded packages: 0

Size of added packages:  24.20 KiB
Size of dropped packages:15.26 MiB
Size of upgraded packages:   2.44 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   22.98 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: WSL_Base docker x86_64
Path: Container/x86_64/images/Fedora-WSL-Base-Rawhide-20250217.n.0.x86_64.tar.xz
Image: WSL_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-WSL-Base-Rawhide-20250217.n.0.aarch64.tar.xz

= DROPPED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20250216.n.0.iso

= ADDED PACKAGES =
Package: rust-rust-fuzzy-search-0.1.1-1.fc43
Summary: Fuzzy Search with trigrams implemented in Rust
RPMs:rust-rust-fuzzy-search+default-devel rust-rust-fuzzy-search-devel
Size:24.20 KiB


= DROPPED PACKAGES =
Package: grib_api-1.27.0-23.fc41
Summary: WMO FM-92 GRIB (v1,v2) interface accessible from C and FORTRAN programs
RPMs:grib_api grib_api-devel grib_api-static
Size:13.99 MiB

Package: rust-deflate0.8-0.8.6-8.fc42
Summary: DEFLATE, zlib and gzip encoder written in rust
RPMs:rust-deflate0.8+benchmarks-devel rust-deflate0.8+default-devel 
rust-deflate0.8+gzip-devel rust-deflate0.8+gzip-header-devel 
rust-deflate0.8-devel
Size:100.08 KiB

Package: rust-fixedbitset0.2-0.2.0-8.fc42
Summary: Simple bitset collection
RPMs:rust-fixedbitset0.2+default-devel rust-fixedbitset0.2+std-devel 
rust-fixedbitset0.2-devel
Size:36.93 KiB

Package: rust-hidpipe-0.1.1-5.fc42
Summary: Pass hid devices to micro vms
RPMs:hidpipe
Size:1.09 MiB

Package: rust-miniz_oxide0.3-0.3.7-12.fc42
Summary: DEFLATE compression and decompression library rewritten in Rust based 
on miniz
RPMs:rust-miniz_oxide0.3+default-devel rust-miniz_oxide0.3-devel
Size:55.93 KiB


= UPGRADED PACKAGES =
Package:  SFML-2.6.2-5.fc43
Old package:  SFML-2.6.2-2.fc42
Summary:  Simple and Fast Multimedia Library
RPMs: SFML SFML-devel
Size: 6.34 MiB
Size change:  89.51 KiB
Changelog:
  * Sun Feb 16 2025 Robert-Andr?? Mauchin  - 2.6.2-4
  - Fix FTBFS and cleanup SPEC

  * Sun Feb 16 2025 Robert-Andr?? Mauchin  - 2.6.2-5
  - License reanalysis with scancode


Package:  Singular-4.4.1-1.fc43
Old package:  Singular-4.4.0p4-2.fc42
Summary:  Computer Algebra System for polynomial computations
RPMs: Singular Singular-devel Singular-doc Singular-emacs 
Singular-libpolys Singular-libpolys-devel Singular-libs factory factory-devel 
factory-gftables
Size: 90.31 MiB
Size change:  613.14 KiB
Changelog:
  * Sun Feb 16 2025 Jerry James  - 4.4.1-1
  - Version 4.4.1
  - Drop upstreamed type-mismatch and fix-id-saturate patches
  - Drop unused Java BRs (thanks to Mari??n Kon??ek)
  - Remove dependency on surf-geometry


Package:  accel-ppp-1.13.0-9.fc43
Old package:  accel-ppp-1.13.0-8.fc42
Summary:  High-performance VPN and broadband protocol server
RPMs: accel-ppp
Size: 1.63 MiB
Size change:  148.96 KiB
Changelog:
  * Mon Feb 17 2025 Neel Chauhan  - 1.13.0-9
  - EPEL 10 modifications


Package:  aom-3.12.0-1.fc43
Old package:  aom-3.11.0-1.fc43
Summary:  Royalty-free next-generation video format
RPMs: aom libaom libaom-devel
Size: 74.21 MiB
Size change:  23.80 KiB
Changelog:
  * Tue Feb 11 2025 Robert-Andr?? Mauchin  - 3.12.0-1
  - Update to 3.12.0


Package:  cairo-dock-plug-ins-3.5.99^20250214git2fabf99-2.rc2.fc43
Old package:  cairo-dock-plug-ins-3.5.99^20250214git2fabf99-1.rc2.fc43
Summary:  Plug-ins files for Cairo-Dock
RPMs: cairo-dock-plug-ins cairo-dock-plug-ins-base 
cairo-dock-plug-ins-common cairo-dock-plug-ins-dbus cairo-dock-plug-ins-kde 
cairo-dock-plug-ins-unstable cairo-dock-plug-ins-webkit 
cairo-dock-plug-ins-xfce cairo-dock-python3 cairo-dock-ruby cairo-dock-vala 
cairo-dock-vala-devel
Size: 17.53 MiB
Size change:  992.97 KiB
Changelog:
  * Sun Feb 16 2025 Mamoru TASAKA  - 
3.5.99^20250214git2fabf99-2.rc2
  - Add BR: json-c for weather module


Package:  calibre-7.26.0-1.fc43
Old package:  calibre-7.25.0-1.fc43
Summary:  E-book converter and library manager
RPMs: calibre
Size: 51.77 MiB
Size change:  111.98 KiB
Changelog:
  * Mon Feb 17 2025 Kevin Fenzi  - 7.26.0-1
  - Update to 7.26.0. Fixes rhbz#2345675


Package:  dl-fedora-1.3-1.fc43
Old package:  dl-fedora-1.2.1-2.fc42
Summary:  Fedora image download tool
RPMs: dl-fedora
Size: 29.00 MiB
Size change:  4.21 MiB
Changelog:
  * Sat Feb 01 2025 Jens Petersen  - 1.2.1-3
  - use %bcond for tests

  * Sun Feb 16 2025 Jens Petersen  - 1.3-1
  - https://hackage.haskell.org/package/dl-fedora-1.3/changelog


Package:  erofs

Re: Need help with "cannot open display" error when %pyproject_check_import is run

[Karolina Surma]

Hi,


[…]
+ /usr/bin/python3 -sP /usr/lib/rpm/redhat/import_all_modules.py -f
/builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1-1.fc42.x86_64-pyproject-modules
Check import: inputremapper
Check import: inputremapper.bin
Check import: inputremapper.bin.input_remapper_control
Check import: inputremapper.bin.input_remapper_gtk

(import_all_modules.py:1580): Gtk-WARNING **: 01:44:47.167: cannot open display:
error: Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)
 Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)


This comes from %pyproject_check_import macro which doesn't know 
anything about pytest and its deselected tests.


You'll need to tweak the list of the importable modules, so that the 
problematic ones are skipped. You can utilize the `-e` option for that:
it takes globs with patterns to exclude the matching module names and 
can be used multiple times.
In this case that would mean adding `-e 
inputremapper.bin.input_remapper_gtk` to the macro invocation.
Or maybe even `-e inputremapper.bin.*` if contents of the bin/ module is 
not designed to be imported.


Hope this helps - I'm also on Fedora Matrix if you have any questions.

--
Karolina Surma (she/her/hers)
Software Engineer
Python Maintenance Team, Red Hat

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 42 compose report: 20250217.n.0 changes

[Fedora Branched Report]

OLD: Fedora-42-20250216.n.0
NEW: Fedora-42-20250217.n.0

= SUMMARY =
Added images:2
Dropped images:  2
Added packages:  1
Dropped packages:5
Upgraded packages:   54
Downgraded packages: 0

Size of added packages:  24.20 KiB
Size of dropped packages:15.27 MiB
Size of upgraded packages:   2.21 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   24.59 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: WSL_Base docker aarch64
Path: Container/aarch64/images/Fedora-WSL-Base-42-20250217.n.0.aarch64.tar.xz
Image: WSL_Base docker x86_64
Path: Container/x86_64/images/Fedora-WSL-Base-42-20250217.n.0.x86_64.tar.xz

= DROPPED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-42-20250216.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-42-20250216.n.0.iso

= ADDED PACKAGES =
Package: rust-rust-fuzzy-search-0.1.1-1.fc42
Summary: Fuzzy Search with trigrams implemented in Rust
RPMs:rust-rust-fuzzy-search+default-devel rust-rust-fuzzy-search-devel
Size:24.20 KiB


= DROPPED PACKAGES =
Package: grib_api-1.27.0-23.fc41
Summary: WMO FM-92 GRIB (v1,v2) interface accessible from C and FORTRAN programs
RPMs:grib_api grib_api-devel grib_api-static
Size:13.99 MiB

Package: rust-deflate0.8-0.8.6-8.fc42
Summary: DEFLATE, zlib and gzip encoder written in rust
RPMs:rust-deflate0.8+benchmarks-devel rust-deflate0.8+default-devel 
rust-deflate0.8+gzip-devel rust-deflate0.8+gzip-header-devel 
rust-deflate0.8-devel
Size:100.10 KiB

Package: rust-fixedbitset0.2-0.2.0-8.fc42
Summary: Simple bitset collection
RPMs:rust-fixedbitset0.2+default-devel rust-fixedbitset0.2+std-devel 
rust-fixedbitset0.2-devel
Size:36.93 KiB

Package: rust-hidpipe-0.1.1-5.fc42
Summary: Pass hid devices to micro vms
RPMs:hidpipe
Size:1.09 MiB

Package: rust-miniz_oxide0.3-0.3.7-12.fc42
Summary: DEFLATE compression and decompression library rewritten in Rust based 
on miniz
RPMs:rust-miniz_oxide0.3+default-devel rust-miniz_oxide0.3-devel
Size:55.93 KiB


= UPGRADED PACKAGES =
Package:  SFML-2.6.2-5.fc42
Old package:  SFML-2.6.2-2.fc42
Summary:  Simple and Fast Multimedia Library
RPMs: SFML SFML-devel
Size: 6.34 MiB
Size change:  89.57 KiB
Changelog:
  * Sun Feb 16 2025 Robert-Andr?? Mauchin  - 2.6.2-4
  - Fix FTBFS and cleanup SPEC

  * Sun Feb 16 2025 Robert-Andr?? Mauchin  - 2.6.2-5
  - License reanalysis with scancode


Package:  aom-3.12.0-1.fc42
Old package:  aom-3.11.0-1.fc42
Summary:  Royalty-free next-generation video format
RPMs: aom libaom libaom-devel
Size: 74.21 MiB
Size change:  23.10 KiB
Changelog:
  * Tue Feb 11 2025 Robert-Andr?? Mauchin  - 3.12.0-1
  - Update to 3.12.0


Package:  cairo-dock-plug-ins-3.5.99^20250214git2fabf99-2.rc2.fc42
Old package:  cairo-dock-plug-ins-3.5.99^20250214git2fabf99-1.rc2.fc42
Summary:  Plug-ins files for Cairo-Dock
RPMs: cairo-dock-plug-ins cairo-dock-plug-ins-base 
cairo-dock-plug-ins-common cairo-dock-plug-ins-dbus cairo-dock-plug-ins-kde 
cairo-dock-plug-ins-unstable cairo-dock-plug-ins-webkit 
cairo-dock-plug-ins-xfce cairo-dock-python3 cairo-dock-ruby cairo-dock-vala 
cairo-dock-vala-devel
Size: 17.54 MiB
Size change:  996.20 KiB
Changelog:
  * Sun Feb 16 2025 Mamoru TASAKA  - 
3.5.99^20250214git2fabf99-2.rc2
  - Add BR: json-c for weather module


Package:  cpp-httplib-0.19.0-1.fc42
Old package:  cpp-httplib-0.18.3-2.fc42
Summary:  A C++11 single-file header-only cross platform HTTP/HTTPS library
RPMs: cpp-httplib-devel
Size: 373.65 KiB
Size change:  4.39 KiB
Changelog:
  * Mon Feb 17 2025 Orion Poplawski  - 0.19.0-1
  - Update to 0.19.0 (CVE-2025-0825) (rhbz#2343758)


Package:  dl-fedora-1.3-1.fc42
Old package:  dl-fedora-1.2.1-2.fc42
Summary:  Fedora image download tool
RPMs: dl-fedora
Size: 29.00 MiB
Size change:  4.21 MiB
Changelog:
  * Sat Feb 01 2025 Jens Petersen  - 1.2.1-3
  - use %bcond for tests

  * Sun Feb 16 2025 Jens Petersen  - 1.3-1
  - https://hackage.haskell.org/package/dl-fedora-1.3/changelog


Package:  docker-compose-2.33.0-1.fc42
Old package:  docker-compose-2.32.4-1.fc42
Summary:  Define and run multi-container applications with Docker
RPMs: docker-compose
Size: 56.14 MiB
Size change:  4.02 MiB
Changelog:
  * Wed Feb 12 2025 Bradley G Smith  - 2.33.0-1
  - Update to release v2.33.0
  - Resolves rhbz#2345162
  - Upstream new features and fixes
  - From upstream: "This release introduce support for Bake to manage builds
as an alternative to the internal buildkit client. This new feature can
be enabled by setting COMPOSE_BAKE=1 variable. Bake will become the
default builder in a future release."


Package:  erofs-utils-1.8.5-2.fc42
Old package:  erofs-utils-1.8.5-1.fc42
Summary:  Utilities for wo

Re: Gating Fedora updates on Fedora CoreOS CI

[Clement Verna]

On Sun, 16 Feb 2025 at 13:52, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Sat, Feb 15, 2025 at 11:11:49AM -0500, Dusty Mabe wrote:
> > On 2/15/25 9:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Feb 14, 2025 at 02:40:29PM -0800, Adam Williamson wrote:
> > >> On Fri, 2025-02-14 at 16:31 -0500, Dusty Mabe wrote:
> > >>> IMO the bar would only need to be that high if the user had no way
> to ignore the test results.
> > >>> All gating does here (IIUC) is require them to do an extra step
> before it automatically flows
> > >>> into the next rawhide compose.
> > >>
> > >> again, technically, yes, but *please* let's not train people to have a
> > >> pavlovian reaction to waive failures, that is not the way.
> > >
> > > IMO, the bar for *gating* tests needs to be high. I think 95% true
> > > positives would be a reasonable threshold.
> >
> > I can't promise 95% true positive rate. These aren't unit tests. They
> are system wide
> > tests that try to test real world scenarios as much as possible. That
> does mean pulling
> > things from github/quay/s3/Fedora infra/etc.. and thus flakes happen.
> Now, in our
> > tests we do collect failures and Retry them. If a retry succeeds we take
> it as success
> > and never report the failure at all. However there are parts of our
> pipeline that might
> > not be so good at retrying.
> >
> > All I'm trying to say is that when you don't control everything it's
> hard to say with
> > confidence something will be 95%.
>
> As AdamW wrote in the other part of the thread, OpenQA maintains a
> false positive rate close to 0%. So it seems possible, even with our
> somewhat unreliable infrastructure…
>
> I am worried about the high failure rate for the coreos tests. But it
> is possible that if we make them gating, the reliability will improve.
> I know that in case of systemd, there was a failure that affected quite
> a few of the updates because it wasn't fixed immediately. If we blocked
> the first update, the percentage of failures would be lower. So I
> think it makes sense to try this… If after a few months with this
> we still have too many updates blocked by gating, we can reevaluate.
>

I would be happy to provide a monthly report of failures so that we can
measure the rate of false positives.


> > As I promised before, maybe just work with us on it. These tests have
> been enabled for
> > a while and I've only seen a handful of package maintainers look at the
> failures (you,
> > Zbyszek, being one of them; thank you!).
> >
> > We do want them to be useful tests and I promise when a failure happens
> because of our
> > infra or tests themselves being flakey we try to get it fixed.
>
> One more question: are packagers able to restart the tests?
>

@Dusty Mabe  will know better, but I don't think
packagers can restart the tests currently.


>
> Zbyszek
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intent to orphan evolution-mapi and openchange packages for f43

[Milan Crha]

On Mon, 2025-02-10 at 10:36 +0100, Milan Crha wrote:
> I believe it's time to retire the MAPI protocol in Fedora. I'll wait
> with the orphan for one week.

Hi,
as announced the last week, I just orphaned evolution-mapi and
openchange packages in the Fedora (I clicked the "Orphan" button in the
https://src.fedoraproject.org/rpms/openchange , whatever it does it did
it).

Bye,
Milan

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 42 breaks new windows installations

[Frenzy Biscuit]

Yes, the windows install exists in BIOS and yes if I manually select the entry 
it will boot into windows.

However, when I do not enter BIOS and just try booting normally I boot loop 
consistently.

I can confirm windows is the only entry in the bios list, fedora isn't anywhere 
on there.

I can also confirm this issue doesn't happen when fedora 42 is installed.

I have tried to reinstall windows several times, nada, nothing. Has fedora 42 
changed the way the boot loader is installed compared to fedora 41?
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need help with "cannot open display" error when %pyproject_check_import is run

[Miro Hrončok]

On 17. 02. 25 2:45, Chris Adams wrote:

Once upon a time, Alexander Ploumistos  said:

I am trying to build the latest version of input-remapper[1] and I
guess some change to the test units has led to this error:

[…]
+ /usr/bin/python3 -sP /usr/lib/rpm/redhat/import_all_modules.py -f
/builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1-1.fc42.x86_64-pyproject-modules
Check import: inputremapper
Check import: inputremapper.bin
Check import: inputremapper.bin.input_remapper_control
Check import: inputremapper.bin.input_remapper_gtk

(import_all_modules.py:1580): Gtk-WARNING **: 01:44:47.167: cannot open display:
error: Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)
 Bad exit status from /var/tmp/rpm-tmp.QjGEES (%check)


It sounds like it's something trying to test under a GUI; rather than
try to avoid the test, try using Xvfb to satisfy it.  Add a

 BuildRequires: Xvfb xauth

and then wrap tests with (possibly moving them to a script to call):

 xvfb-run -a -w1 [check command]


Unfortunately, the %pyproject_check_import expands to a shell scriptlet,
so this won't be trivial.

We can amend the macro to allow using xvfb-run or xwfb-run somehow.

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Gating Fedora updates on Fedora CoreOS CI

[Clement Verna]

On Sat, 15 Feb 2025 at 20:51, Adam Williamson 
wrote:

> On Sat, 2025-02-15 at 14:54 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Feb 14, 2025 at 02:40:29PM -0800, Adam Williamson wrote:
> > > On Fri, 2025-02-14 at 16:31 -0500, Dusty Mabe wrote:
> > > > IMO the bar would only need to be that high if the user had no way
> to ignore the test results.
> > > > All gating does here (IIUC) is require them to do an extra step
> before it automatically flows
> > > > into the next rawhide compose.
> > >
> > > again, technically, yes, but *please* let's not train people to have a
> > > pavlovian reaction to waive failures, that is not the way.
> >
> > IMO, the bar for *gating* tests needs to be high. I think 95% true
> > positives would be a reasonable threshold.
>
> Do you mean 95% of failures must be 'real' (i.e. up to 5% can be
> 'false')? Is this after automatic retries and manual intervention by
> the test system maintainers, or before?
>
> Off the top of my head, 95% seems low. I'm pretty sure we do better
> than that with openQA and people would complain if that was all we
> managed. We usually maintain a 0% false failure rate after auto-retries
> and <24h manual intervention -
>
> https://openqa.fedoraproject.org/group_overview/2?limit_builds=100&limit_builds=400
> has 0 false failures ATM.
>

Thanks, that's interesting. What do you call <24h manual intervention? One
example that comes to mind would be to disable or snooze a test that
started to trigger false failures in under 24h.
If that's the case, I think that sounds achievable.


> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads-up: msgraph soname bump in F43 and F42

[Ondřej Holý]

Hi,

in one week (2025-02-24), I plan to update the msgraph package from 0.2.3
to 0.3.3[1] in F43 and F42. It is an API-breaking update with SONAME
version bump. I will also update the only dependent package - gvfs to
1.57.2 version that needs the updated msgraph package. I will use side tags
for these updates, using @gnome-sig membership.

[1]
https://src.fedoraproject.org/rpms/msgraph/c/2e06e7c7813ebcd5f307e823ea4738b5e906fcaa

Regards

Ondrej
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue