Re: SoPlex and SCIP builds

[Jerry James]

On Thu, Feb 22, 2024 at 10:00 AM Jerry James  wrote:
> Thanks to Benson Muite and Kai Hiller, the final package reviews
> needed for the SoPlex and SCIP effort are done.  The packages will be
> built in these side tags:
>
> f41-build-side-84341
> f40-build-side-84343
>
> There are several packages that take multiple hours to build, and must
> be built serially due to dependencies between them, so the builds will
> probably take 2-3 days.  If you need to build any of the following
> packages in the next 2-3 days, please coordinate with me.  The
> maintainers are BCCed on this message.
>
> - bliss
> - coin-or-Alps
> - coin-or-Bcp
> - coin-or-Bcps
> - coin-or-Blis
> - coin-or-Bonmin
> - coin-or-Cbc
> - coin-or-Cgl
> - coin-or-Clp
> - coin-or-CoinMP
> - coin-or-CoinUtils
> - coin-or-Couenne
> - coin-or-Dip
> - coin-or-DyLP
> - coin-or-FlopC++
> - coin-or-Ipopt
> - coin-or-lemon
> - coin-or-OS
> - coin-or-Osi
> - coin-or-SYMPHONY
> - freefem++
> - gfan
> - Macaulay2
> - mp
> - opencv
> - openms
> - polymake
> - python-cyipopt
> - python-jupymake
> - python-pysingular
> - Singular
> - TOPCOM
>
> I will reply to this message when the side tags are ready to merge.  A
> big thank you to everyone who helped along the way.

The Rawhide side tag is being merged into Rawhide now.  The F40 builds
have hit an unfortunate snag and have not progressed far.  If anybody
from releng is reading this, I need
https://pagure.io/releng/issue/11977 processed before I can make
further progress.  I appreciate any help.
-- 
Jerry James
http://www.jamezone.org/
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Sérgio Basto]

On Sat, 2024-02-24 at 09:47 +0100, Ralf Corsépius wrote:
> 
> 
> Am 24.02.24 um 01:36 schrieb Samuel Sieb:
> > On 2/23/24 15:38, Sérgio Basto wrote:
> > > On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:
> > > > 
> > > > 
> > > > Am 23.02.24 um 22:37 schrieb Samuel Sieb:
> > > > > On 2/23/24 10:50, Ralf Corsépius wrote:
> > > > > > 
> > > > > > # dnf system-upgrade download --releasever=40
> > > > > > ...
> > > > > > No match for group package "multican"
> > > > > > ...
> > > > > > 
> > > > > > WTH?
> > > > > 
> > > > > It was a program for controlling Canon cameras that has been
> > > > > retired.
> > > > > Some group you have installed has that package listed in it.
> > > > Ah, this likely explains why neither "dnf repoquery" nor "dnf
> > > > group
> > > > list" could find "multican".
> > > > 
> > > > >   The comps
> > > > > groups need to be cleaned out and that's just a warning.
> > > > Well, ... IMHO, most about comps and groups is in an
> > > > embarrassing
> > > > unusable shape.
> > > > 
> > > No match for group package "baekmuk-ttf-batang-fonts"
> > [snip]
> > > No match for group package "util-linux-user"
> > > 
> > > I got these ones , is something on my rpm db ?
> 
> I am seeing these on another machine, too.
> 
> > No.  Well, sort of.  As mentioned, those are packages that have
> > been 
> > removed from the distro, but are still listed in the comps groups. 
> > dnf 
> > checks the installed groups for packages that need to be updated
> > and 
> > can't find these ones.
> Really? How do I check for which groups I have installed?
> 
> At least I haven't found any way to check for them, neither with rpm
> nor 
> with dnf.
> 
> 
> Finally, another issue:
> ...
> Error:
>   Problem: conflicting requests
>    - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
> conflicts with intel-media-driver provided by 
> intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
>    - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from
> fedora 
> conflicts with intel-media-driver provided by 
> intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
>    - problem with installed package intel-media-driver-23.4.3-
> 1.fc39.x86_64
>    - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
> belong to a distupgrade repository
> (try to add '--allowerasing' to command line to replace conflicting 
> packages or '--skip-broken' to skip uninstallable packages)
> 
> I see 2 potential issues in there:
> 1. I think, I once "dnf swapped" these packages => Does "dnf 
> system-upgrade" handle "swapped" packages correctly?
> 
> 2. Why does dnf system-upgrade wants to pull-in a i686 package in
> this 
> case? IMO, this doesn't make sense.

we are trying fix this one in here :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6861


-- 
Sérgio M. B.
--
___
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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-109c5d3d12   
gifsicle-1.95-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

ganglia-3.7.2-46.el8
libstrophe-0.13.1-1.el8

Details about builds:



 ganglia-3.7.2-46.el8 (FEDORA-EPEL-2024-fce897bfa8)
 Distributed Monitoring System

Update Information:

Update to ganglia-web 3.7.6 and fix build problem on newer Fedoras.

ChangeLog:

* Sat Feb 24 2024 Terje Rosten  - 3.7.2-46
- Upgrade to ganglia web 3.7.6
* Mon Feb  5 2024 Terje Rosten  - 3.7.2-45
- Fix GCC 14 issue
* Wed Jan 24 2024 Fedora Release Engineering  - 
3.7.2-44
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
3.7.2-43
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
3.7.2-42
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Thu Jan 19 2023 Fedora Release Engineering  - 
3.7.2-41
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

References:

  [ 1 ] Bug #2180500 - ganglia-web not working due to changes in PHP 8
https://bugzilla.redhat.com/show_bug.cgi?id=2180500




 libstrophe-0.13.1-1.el8 (FEDORA-EPEL-2024-cf83fa99fe)
 An XMPP library for C

Update Information:

Update to 0.13.1

ChangeLog:

* Sat Feb 24 2024 Matthieu Saulnier  - 0.13.1-1
- Update to 0.13.1

References:

  [ 1 ] Bug #2265496 - libstrophe-0.13.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2265496


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-bd2367203c   
gifsicle-1.95-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

fedora-distro-aliases-1.3-1.el9
ganglia-3.7.2-46.el9
highway-1.1.0-1.el9
libstrophe-0.13.1-1.el9
python-pyrate-limiter-2.10.0-3.el9
rust-is_ci-1.2.0-1.el9
rust-libbpf-cargo-0.22.1-1.el9
rust-strip-ansi-escapes0.1-0.1.1-2.el9
rust-sval-2.11.1-1.el9
rust-sval_buffer-2.11.1-1.el9
rust-sval_derive-2.11.1-1.el9
rust-sval_derive_macros-2.11.1-1.el9
rust-sval_dynamic-2.11.1-1.el9
rust-sval_flatten-2.11.1-1.el9
rust-sval_fmt-2.11.1-1.el9
rust-sval_json-2.11.1-1.el9
rust-sval_nested-2.11.1-1.el9
rust-sval_ref-2.11.1-1.el9
rust-sval_serde-2.11.1-1.el9
rust-sval_test-2.11.1-1.el9
rust-transpose-0.2.3-1.el9
rust-value-bag-1.7.0-1.el9
rust-value-bag-serde1-1.7.0-1.el9
rust-value-bag-sval2-1.7.0-1.el9

Details about builds:



 fedora-distro-aliases-1.3-1.el9 (FEDORA-EPEL-2024-0286632389)
 Aliases for active Fedora releases

Update Information:

https://github.com/rpm-software-management/fedora-distro-
aliases/releases/tag/fedora-distro-aliases-1.3-1

ChangeLog:

* Sat Feb 24 2024 Jakub Kadlcik  1.3-1
- Make sure everything behaves correctly during the branching window
  (fros...@email.cz)
- Add releasers.conf (fros...@email.cz)




 ganglia-3.7.2-46.el9 (FEDORA-EPEL-2024-3ff8291512)
 Distributed Monitoring System

Update Information:

Update to ganglia-web 3.7.6 and fix build problem on newer Fedoras.

ChangeLog:

* Sat Feb 24 2024 Terje Rosten  - 3.7.2-46
- Upgrade to ganglia web 3.7.6
* Mon Feb  5 2024 Terje Rosten  - 3.7.2-45
- Fix GCC 14 issue
* Wed Jan 24 2024 Fedora Release Engineering  - 
3.7.2-44
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
3.7.2-43
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
3.7.2-42
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Thu Jan 19 2023 Fedora Release Engineering  - 
3.7.2-41
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

References:

  [ 1 ] Bug #2180500 - ganglia-web not working due to changes in PHP 8
https://bugzilla.redhat.com/show_bug.cgi?id=2180500




 highway-1.1.0-1.el9 (FEDORA-EPEL-2024-636b179cd4)
 Efficient and performance-portable SIMD

Update Information:

Update to version 1.1.0.
Release notes: https://github.com/google/highway/releases/tag/1.1.0

ChangeLog:

* Sat Feb 24 2024 Fabio Valentini  - 1.1.0-1
- Update to version 1.1.0; Fixes RHBZ#2264702
* Wed Jan 24 2024 Fedora Release Engineering  - 
1.0.7-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Sat Jan 20 2024 Fedora Release Engineering  - 
1.0.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild




 libstrophe-0.13.1-1.el9 (FEDORA-EPEL-2024-4cdc7704f9)
 An XMPP library for C

Update Information:

Update to 0.13.1

ChangeLog:

* Sat Feb 24 2024 Matthieu Saulnier  - 0.13.1-1
- Update to 0.13.1

References:

  [ 1 ] Bug #2265496 - libstrophe-0.13.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2265496




 python-pyrate-limiter-2.10.0-3.el9 (FEDORA-EPEL-2024-989bc5113c)
 The request rate limiter using Leaky-bucket algorithm

Re: Help needed to fix FTBFS in scikit learn

[Sergio Pascual]

I have reproduced the problem with a test case. The problem is in
cython. It generates code with this type
of problem in some cases (inlined methods of derived classes).

I have reported the problem upstream
https://github.com/cython/cython/issues/6033

I don't know how to continue from here. Is it possible to build C code
with the old behaviour?


Best, Sergio


El sáb, 17 feb 2024 a las 22:19, Jakub Jelinek () escribió:
>
> On Sat, Feb 17, 2024 at 10:03:39PM +0100, Sergio Pascual wrote:
> > Hello, currently python-scikit-learn fails to build in f40 and rawhide
> > https://bugzilla.redhat.com/show_bug.cgi?id=2261602
> >
> > The problem is a series of incompatible pointer conversions that
> > appear in cython generated C code.
> > The code has classes defined in cython and in the offending code
> > "self" is passed as a pointer to the base class with a conversion to
> > the derived class
> >
> > sklearn/metrics/_dist_metrics.c: In function
> > ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_dist_csr’:
> > sklearn/metrics/_dist_metrics.c:51033:90: error: passing argument 1 of
> > ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_rdist_csr’
> > from incompatible pointer type [-Wincompatible-pointer-types]
> >
> > note: expected ‘struct
> > __pyx_obj_7sklearn_7metrics_13_dist_metrics_EuclideanDistance32 *’
> > but argument is of type ‘struct
> > __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric32 *’
>
> If the conversion is correct and desirable, it needs to be explicit, not
> implicit.
>
> Jakub
> --
> ___
> 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: Introduction / unorphaning package request

[Michel Lind]

Hi Josh,


On Fri, Feb 23, 2024 at 09:23:34AM -0500, Joshua Stone wrote:
> Hello everyone,
> 
> 
> I also spend time maintaining several apps on Flathub, and I'd like to
> expand maintenance efforts to Fedora!
> 
Welcome!

> Earlier I filed a request for unorphaning a package:
> 
> https://pagure.io/releng/issue/11963
> 
> It would appear that there are several requirements I must fulfill,
> especially finding a sponsor. If there's anyone who can help, then I'd
> really appreciate it! I hope to be more involved with the Fedora community!
>
You might want to join https://matrix.to/#/#golang:fedoraproject.org -
the Golang SIG members are there, and you might get one of them to
sponsor you.

Note that there is a specific template to use for unretiring (not
unorphaning - the package is retired because it was orphaned for too
long), and it would have asked for the Bugzilla issue for the re-review
- the package would have to be reviewed again as if it's a new package.

I can't link to the template now since it seems OpenID is acting up
right now :(

This provides the full instructions for becoming a packager:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

and this for unretiring

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

and these are the packaging guidelines for Golang

https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/

HTH,

-- 
Michel Lind
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Login issues to lists.* and src.*? Any outages?

[Christopher]

I don't think mine was a timeout error... it could have been, but I
don't remember. I thought it looked like an authentication failure,
rather than a timeout. But, it's working now, so I can't reproduce it.
:shrug:

On Sat, Feb 24, 2024 at 7:02 AM Barry Scott  wrote:
>
>
>
> On 22 Feb 2024, at 20:20, Christopher  wrote:
>
> Are there any known issues right now for logging in to 
> lists.fedoraproject.org or src.fedoraproject.org?
> Do we have a page for known outages?
>
> I can log in to accounts.fedoraproject.org, so I know my password and 2FA 
> token still works, but not to src.f.o or lists.f.o.
> I tried to disable my 2FA in there, to see if that had an effect, but it 
> wouldn't let me (I thought it was optional?)
>
> I'm still in the packager group in accounts.f.o (not inactive). So, I'm not 
> sure what the problem is.
>
> Is this a known issue? I haven't seen anything about this on the devel list 
> recently.
>
>
> I am seeing the same issue for https://discussion.fedoraproject.org
> When I click to login and try to use my FAS ID I end up on
> Here https://id.fedoraproject.org/login/pam
> with the error:
>
> Gateway Timeout
>
> The gateway did not receive a timely response from the upstream server or 
> application.
>
> But I can and did login successfully to https://accounts.fedoraproject.org
>
> Barry
>
>
>
> Thanks,
> Christopher
>
> --
> ___
> 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
--
___
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: Does Fedora Mobility work with Pinetab 2?

[Kevin Kofler via devel]

Ryan Bach via devel wrote:

>> Allan via devel wrote:
>> 
>> Not in Fedora ≥ 40 anymore.
>> https://fedoraproject.org/wiki/Changes/Wget2asWget
>> https://gitlab.com/gnuwget/wget2/-/wikis/Home#what-is-missing
>> 
>> Kevin Kofler
> How do I use that, it idoesn't work like wget...

Complain to the people who pushed for this broken change. No idea why we 
have to ship a broken wget instead of the tried and true version that 
everyone knows. Why cannot wget2 be shipped as wget2?

Kevin Kofler
--
___
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: koji news and 1.34.0 upgrade

[Fabio Valentini]

On Sat, Feb 24, 2024 at 7:27 PM Neal Gompa  wrote:
>
> On Sat, Feb 24, 2024 at 12:59 PM Otto Liljalaakso
>  wrote:
> >
> > Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:
> > > Greetings. After the outage that just completed, koji has been upgraded
> > > to 1.34.0 plus a few patches from upstream. Some highlights:
> > >
> > > * A patch has been added allowing us to set 'noarch_arches' on build
> > > tags. This allows us to specify what arch builders will do noarch
> > > builds. Without any setting it's any arch, but this presents problems
> > > for noarch packages that have some dependencies that have dropped i686.
> > > For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> > > (ie, excluding i686). If this works well we can extend it to other build
> > > tags.
> > What does this mean in practice for packagers? Can I now stop adding
> > `ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still
> > keep doing that until we know "if this works well"?
>
> You should no longer need to do that.

With one caveat:

> For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> (ie, excluding i686). If this works well we can extend it to other build
> tags.

Fabio
--
___
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: koji news and 1.34.0 upgrade

[Neal Gompa]

On Sat, Feb 24, 2024 at 12:59 PM Otto Liljalaakso
 wrote:
>
> Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:
> > Greetings. After the outage that just completed, koji has been upgraded
> > to 1.34.0 plus a few patches from upstream. Some highlights:
> >
> > * A patch has been added allowing us to set 'noarch_arches' on build
> > tags. This allows us to specify what arch builders will do noarch
> > builds. Without any setting it's any arch, but this presents problems
> > for noarch packages that have some dependencies that have dropped i686.
> > For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> > (ie, excluding i686). If this works well we can extend it to other build
> > tags.
> What does this mean in practice for packagers? Can I now stop adding
> `ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still
> keep doing that until we know "if this works well"?

You should no longer need to do that.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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: koji news and 1.34.0 upgrade

[Otto Liljalaakso]

Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:

Greetings. After the outage that just completed, koji has been upgraded
to 1.34.0 plus a few patches from upstream. Some highlights:

* A patch has been added allowing us to set 'noarch_arches' on build
tags. This allows us to specify what arch builders will do noarch
builds. Without any setting it's any arch, but this presents problems
for noarch packages that have some dependencies that have dropped i686.
For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
(ie, excluding i686). If this works well we can extend it to other build
tags.
What does this mean in practice for packagers? Can I now stop adding 
`ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still 
keep doing that until we know "if this works well"?

--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Otto Liljalaakso]

Miroslav Suchý kirjoitti 21.2.2024 klo 9.11:

dnf --releasever=40 --setopt=module_platform_id=platform:f40 \

--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync

In addition to some problems that already have Bugzilla entries or such, 
and were already reported in this thread too, I got some problems with 
retired Rubygems:


|$ LANG=C.UTF-8 sudo dnf --releasever=40 --enablerepo=updates-testing 
--assumeno distro-sync Problem 3: package 
rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires 
libruby.so.3.2()(64bit), but none of the providers can be installed - 
ruby-libs-3.2.2-181.fc39.x86_64 from @System does not belong to a 
distupgrade repository - problem with installed package 
rubygem-byebug-11.1.3-5.fc39.x86_64 Problem 4: package 
rubygem-shoulda-3.6.0-14.fc39.noarch from @System requires 
(rubygem(shoulda-context) >= 1.0 with rubygem(shoulda-context) < 2 with 
rubygem(shoulda-context) >= 1.0.1), but none of the providers can be 
installed - rubygem-shoulda-context-1.2.2-16.fc39.noarch from @System 
does not belong to a distupgrade repository - problem with installed 
package rubygem-shoulda-3.6.0-14.fc39.noarch Problem 6: cannot install 
both ruby-libs-3.3.0-4.fc40.x86_64 from fedora and 
ruby-libs-3.2.2-181.fc39.x86_64 from @System - package 
ruby-3.3.0-4.fc40.x86_64 from fedora requires ruby-libs(x86-64) = 
3.3.0-4.fc40, but none of the providers can be installed - package 
ruby-3.3.0-4.fc40.x86_64 from fedora requires libruby.so.3.3()(64bit), 
but none of the providers can be installed - package 
rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires 
libruby.so.3.2()(64bit), but none of the providers can be installed - 
problem with installed package ruby-3.2.2-181.fc39.x86_64 - package 
rubygem-pry-byebug-3.6.0-13.fc39.noarch from @System requires 
(rubygem(byebug) >= 11.0 with rubygem(byebug) < 12), but none of the 
providers can be installed - ruby-3.2.2-181.fc39.x86_64 from @System 
does not belong to a distupgrade repository - problem with installed 
package rubygem-pry-byebug-3.6.0-13.fc39.noarch |


||

I filed a PR for fedora-obsolete-packages for these [1].

[1]: 
https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86


|
|
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Otto Liljalaakso]

Dominique Martinet kirjoitti 21.2.2024 klo 15.13:

Miroslav Suchý wrote on Wed, Feb 21, 2024 at 08:11:49AM +0100:

dnf --releasever=40 --setopt=module_platform_id=platform:f40 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync

Error:
  Problem 6: package network-scripts-teamd-1.32-4.fc40.x86_64 from fedora 
requires network-scripts, but none of the providers can be installed
   - problem with installed package network-scripts-teamd-1.32-1.fc39.x86_64
   - package network-scripts-10.20-1.fc39.x86_64 from @System requires 
initscripts(x86-64) = 10.20-1.fc39, but none of the providers can be installed
   - network-scripts-teamd-1.32-1.fc39.x86_64 from @System  does not belong to 
a distupgrade repository
   - initscripts-10.20-1.fc39.x86_64 from @System  does not belong to a 
distupgrade repository


I got this one as well. This happens because network-scripts sub-package 
was just recently dropped from initscripts [1,2]. It looks like it was 
improperly dropped, because the existing dependents were not handled.


I am not sure if I should comment in already closed bug about dropping 
network-scripts, or open a new one (against which component?). I'll cc 
initscripts maintainers here. Could you check network-scripts-teamd and 
possible other remaining dependents of network-scripts and handle them, 
by arranging them to be retired and obsoleted or whatever is appropriate 
in each case?


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2262795
[2]: 
https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide

--
___
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: google-re2 pacakge update and facebook vs google python bindings ?

[Fabio Valentini]

On Sat, Feb 24, 2024 at 11:49 AM Michael J Gruber  
wrote:
>
> Am Sa., 24. Feb. 2024 um 03:37 Uhr schrieb Adam Williamson
> :
> >
> > On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote:
> > > On Wed, 7 Feb 2024, Ben Beasley wrote:
> > >
> > > > Subject: Re: google-re2 pacakge update and facebook vs google python 
> > > > bindings
> > >
> > > I haven't heard back from any of the maintainers.
> > >
> > > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the
> > > first step towards getting python-google-re2 working.
> > >
> > > https://src.fedoraproject.org/rpms/re2/pull-request/6
> >
> > You now seem to have just built re2 for Rawhide without any of the
> > deps:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d
> >
> > that's not how you're supposed to do things, these days. You should
> > build re2 on a side tag and then get all the deps rebuilt on the same
> > side tag, then create a combined update. The update failed tests
> > because of this.
> >
> > The best thing to do at this point would be to create a side tag, bump
> > re2 and do a new build on the side tag, then ask maintainers of
> > dependencies and/or provenpackagers to rebuild the dependencies on the
> > side tag.
> > --
>
> Also, the commit introduced a switch to autochangelog, which should be
> the maintainer's decision, and is best done in a separate commit
> before the bump. Besides, the changelog file was not committed to
> dist-git. Did this just erase all changelog history from the rpm?

Yes, this was done incorrectly (both the uncoordinated non-side-tag
build *and* the conversion to rpmautospec) ... I would suggest
somebody revert the two commits in git for now.

Fabio
--
___
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 40 compose report: 20240224.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240223.n.0
NEW: Fedora-40-20240224.n.0

= SUMMARY =
Added images:3
Dropped images:  3
Added packages:  0
Dropped packages:0
Upgraded packages:   67
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   8.94 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-40-20240224.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240224.n.0.iso
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-40-20240224.n.0.iso

= DROPPED IMAGES =
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-40-20240223.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-40-20240223.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-40-20240223.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-vcd-1.4.12-1.fc40
Old package:  R-vcd-1.4.11-5.fc40
Summary:  Visualizing categorical data
RPMs: R-vcd
Size: 1.36 MiB
Size change:  21.01 KiB
Changelog:
  * Fri Feb 23 2024 Iztok Fister Jr.  - 
1.4.12-1
  - Update to 1.4-12


Package:  ardour8-8.4.0-2.fc40
Old package:  ardour8-8.4.0-1.fc40
Summary:  Digital Audio Workstation
RPMs: ardour8
Size: 65.52 MiB
Size change:  25.14 KiB

Package:  arm-image-installer-4.1-1.fc40
Old package:  arm-image-installer-4.0-1.fc40
Summary:  Writes binary image files to any specified block device
RPMs: arm-image-installer
Size: 46.65 KiB
Size change:  73 B
Changelog:
  * Fri Feb 23 2024 Paul Whalen  - 4.1-1
  - limit lvm commands (bz#2265422)


Package:  atril-1.28.0-1.fc40
Old package:  atril-1.26.2-2.fc40
Summary:  Document viewer
RPMs: atril atril-caja atril-devel atril-libs atril-thumbnailer
Size: 13.30 MiB
Size change:  -16.70 KiB
Changelog:
  * Fri Feb 23 2024 Wolfgang Ulbrich  - 1.28.0-1
  - update to 1.28.0


Package:  authselect-1.5.0-4.fc40
Old package:  authselect-1.5.0-3.fc40
Summary:  Configures authentication and identity sources from supported 
profiles
RPMs: authselect authselect-devel authselect-libs
Size: 1.71 MiB
Size change:  -158.19 KiB
Changelog:
  * Fri Feb 23 2024 Pavel B??ezina  - 1.5.0-4
  - Add back with-files-access-provider
  - Remove outdated scriptlets
  - Group merging added to nsswitch.conf group in all profiles
  - myhostname is put right before dns module in nsswitch.conf hosts 
(rhbz#2257197)
  - Internal packaging changes


Package:  bcachefs-tools-1.6.4-1.fc40
Old package:  bcachefs-tools-1.4.1-1.fc40
Summary:  Userspace tools for bcachefs
RPMs: bcachefs-tools
Size: 4.84 MiB
Size change:  -1.32 MiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
1.4.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 23 2024 Fedora Release Engineering  - 
1.4.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Wed Feb 14 2024 Neal Gompa  - 1.6.1-1
  - Update to 1.6.1

  * Fri Feb 16 2024 Neal Gompa  - 1.6.2-1
  - Update to 1.6.2

  * Tue Feb 20 2024 Neal Gompa  - 1.6.3-1
  - Update to 1.6.3

  * Fri Feb 23 2024 Neal Gompa  - 1.6.3-2
  - Backport patches to fix the build

  * Fri Feb 23 2024 Neal Gompa  - 1.6.4-1
  - Update to 1.6.4
  - Drop backported patches


Package:  caja-1.28.0-1.fc40
Old package:  caja-1.26.3-4.fc40
Summary:  File manager for MATE
RPMs: caja caja-core-extensions caja-devel caja-schemas
Size: 18.04 MiB
Size change:  142.58 KiB
Changelog:
  * Fri Feb 23 2024 Wolfgang Ulbrich  - 1.28.0-1
  - update to 1.28.0


Package:  caja-actions-1.28.0-1.fc40
Old package:  caja-actions-1.26.0-8.fc40
Summary:  Caja extension for customizing the context menu
RPMs: caja-actions caja-actions-devel caja-actions-doc
Size: 8.37 MiB
Size change:  56.31 KiB
Changelog:
  * Fri Feb 23 2024 Wolfgang Ulbrich  - 1.28.0-1
  - update to 1.28.0


Package:  caja-extensions-1.28.0-1.fc40
Old package:  caja-extensions-1.26.1-7.fc40
Summary:  Set of extensions for caja file manager
RPMs: caja-audio-video-properties caja-beesu caja-extensions-common 
caja-image-converter caja-open-terminal caja-sendto caja-sendto-devel 
caja-share caja-wallpaper caja-xattr-tags
Added RPMs:   caja-audio-video-properties
Size: 1.24 MiB
Size change:  128.06 KiB
Changelog:
  * Fri Feb 23 2024 Wolfgang Ulbrich  - 1.28.0-1
  - update to 1.28.0


Package:  chromium-122.0.6261.69-1.fc40
Old package:  chromium-122.0.6261.57-1.fc40
Summary:  A WebKit (Blink) powered web browser

Some mozjs102.spec weirdness

[Richard W.M. Jones]

There's a couple things about this spec file which are quite strange.

Firstly the %autosetup directory parameter is not the top level
directory:

  %prep
  %autosetup -n firefox-%{version}/js/src -N

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_108)

This means if you re-run 'fedpkg local' (or mock, I guess, without a
cleaning step) then it doesn't actually delete all the old files, only
the ones under js/src, and that causes build failures later on when it
tries to recreate directories that already exist:

  + mkdir third_party/python/looseversion
  mkdir: cannot create directory ‘third_party/python/looseversion’: File exists

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_121)

Secondly the mock /builddir path is hard-coded in a few places, eg:

  export AC_MACRODIR=/builddir/build/BUILD/firefox-%{version}/build/autoconf/
 
  sh ../../build/autoconf/autoconf.sh 
--localdir=/builddir/build/BUILD/firefox-%{version}/js/src configure.in > 
configure

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_150)

This breaks local builds with 'fedpkg build' or rpmbuild entirely.

Are these bugs?  Is there a reason to do things this way?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Login issues to lists.* and src.*? Any outages?

[Barry Scott]

> On 22 Feb 2024, at 20:20, Christopher  wrote:
> 
> Are there any known issues right now for logging in to 
> lists.fedoraproject.org  or 
> src.fedoraproject.org ?
> Do we have a page for known outages?
> 
> I can log in to accounts.fedoraproject.org 
> , so I know my password and 2FA token 
> still works, but not to src.f.o or lists.f.o.
> I tried to disable my 2FA in there, to see if that had an effect, but it 
> wouldn't let me (I thought it was optional?)
> 
> I'm still in the packager group in accounts.f.o (not inactive). So, I'm not 
> sure what the problem is.
> 
> Is this a known issue? I haven't seen anything about this on the devel list 
> recently.

I am seeing the same issue for https://discussion.fedoraproject.org
When I click to login and try to use my FAS ID I end up on
Here https://id.fedoraproject.org/login/pam
with the error:

Gateway Timeout

The gateway did not receive a timely response from the upstream server or 
application.

But I can and did login successfully to https://accounts.fedoraproject.org

Barry



> 
> Thanks,
> Christopher
> 
> --
> ___
> 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: Login issues to lists.* and src.*? Any outages?

[Richard W.M. Jones]

On Thu, Feb 22, 2024 at 04:26:26PM -0800, Kevin Fenzi wrote:
> On Thu, Feb 22, 2024 at 04:46:23PM -0500, Christopher wrote:
> > On Thu, Feb 22, 2024 at 4:01 PM Gary Buhrmaster
> >  wrote:
> > >
> > > On Thu, Feb 22, 2024 at 8:20 PM Christopher  
> > > wrote:
> > > >
> > > > Are there any known issues right now for logging in to 
> > > > lists.fedoraproject.org or src.fedoraproject.org?
> > > > Do we have a page for known outages?
> > >
> > > https://status.fedoraproject.org/
> > >
> > > It currently reports all systems operational
> > >
> > 
> > Yeah, I found that after asking. It also says it's updated manually,
> > so I'm not sure how reliable it is.
> 
> Well, I am not sure how to answer that... if we know about some issue
> that affects a lot of people we try and update it. If we don't know
> about an issue, we can't know to update it and if the issue is something
> that doesn't seem to affect a lot of people or is something we can
> quickly fix, we often don't update it.

So I sometimes have issues logging in.  For example it happened about
5 minutes ago, but the error isn't very interesting:

  Original URL: 
https://id.fedoraproject.org/login/gssapi/negotiate?ipsilon_transaction_id=8d11a868-b8f5-4e65-b48b-a53f592d2cfb
  Redirected URL: https://id.fedoraproject.org/login/pam

  Gateway Timeout

  The gateway did not receive a timely response from the upstream
  server or application.

Is it useful to report these?  Sometimes just retrying works, as
in fact happened when I retried it this time.

Rich.

> > > > I can log in to accounts.fedoraproject.org, so I know my password and 
> > > > 2FA token still works, but not to src.f.o or lists.f.o.
> > > > I tried to disable my 2FA in there, to see if that had an effect, but 
> > > > it wouldn't let me (I thought it was optional?)
> 
> What happens when you try and login?
> Hangs? an error? a timeout? 
> 
> We have had one of our identity provider vm's from time to time stop
> responding to requests (although it responds to liveness checks). 
> This might be a case of that if you see it timeout.
> I just checked and they are both up and working now... are you still
> seeing this?
> 
> > > Enrolling in 2FA is a one-way action
> > > (like Hotel California, you can never leave).
> 
> You can actually, but you have to mail ad...@fedoraproject.org, use some
> method to prove you are you and then your token can be removed. 
> 
> kevin



> --
> ___
> 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


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
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: google-re2 pacakge update and facebook vs google python bindings ?

[Michael J Gruber]

Am Sa., 24. Feb. 2024 um 03:37 Uhr schrieb Adam Williamson
:
>
> On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote:
> > On Wed, 7 Feb 2024, Ben Beasley wrote:
> >
> > > Subject: Re: google-re2 pacakge update and facebook vs google python 
> > > bindings
> >
> > I haven't heard back from any of the maintainers.
> >
> > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the
> > first step towards getting python-google-re2 working.
> >
> > https://src.fedoraproject.org/rpms/re2/pull-request/6
>
> You now seem to have just built re2 for Rawhide without any of the
> deps:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d
>
> that's not how you're supposed to do things, these days. You should
> build re2 on a side tag and then get all the deps rebuilt on the same
> side tag, then create a combined update. The update failed tests
> because of this.
>
> The best thing to do at this point would be to create a side tag, bump
> re2 and do a new build on the side tag, then ask maintainers of
> dependencies and/or provenpackagers to rebuild the dependencies on the
> side tag.
> --

Also, the commit introduced a switch to autochangelog, which should be
the maintainer's decision, and is best done in a separate commit
before the bump. Besides, the changelog file was not committed to
dist-git. Did this just erase all changelog history from the rpm?

Michael
--
___
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

[Bug 2265788] New: perl-Crypt-URandom-0.40 is available

[bugzilla]

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

Bug ID: 2265788
   Summary: perl-Crypt-URandom-0.40 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Crypt-URandom
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.40
Upstream release that is considered latest: 0.40
Current version/release in rawhide: 0.39-4.fc40
URL: http://search.cpan.org/dist/Crypt-URandom/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/6647/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Crypt-URandom


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2265788

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265788%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F39 to F40

[Samuel Sieb]

On 2/24/24 01:12, Samuel Sieb wrote:

On 2/24/24 00:47, Ralf Corsépius wrote:

Error:
  Problem: conflicting requests
   - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
   - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
   - problem with installed package 
intel-media-driver-23.4.3-1.fc39.x86_64
   - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)


I see 2 potential issues in there:
1. I think, I once "dnf swapped" these packages => Does "dnf 
system-upgrade" handle "swapped" packages correctly?


How you installed the package is mostly irrelevant.  The package is 
installed, so it will get upgraded if possible.


2. Why does dnf system-upgrade wants to pull-in a i686 package in this 
case? IMO, this doesn't make sense.


I'm unclear on which way the check is going.  Which package(s) do you 
have installed?


Never mind that question.  The following lines show which one you have.
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Samuel Sieb]

On 2/24/24 00:47, Ralf Corsépius wrote:

Am 24.02.24 um 01:36 schrieb Samuel Sieb:

On 2/23/24 15:38, Sérgio Basto wrote:

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:



Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been
retired.
Some group you have installed has that package listed in it.

Ah, this likely explains why neither "dnf repoquery" nor "dnf group
list" could find "multican".


  The comps
groups need to be cleaned out and that's just a warning.

Well, ... IMHO, most about comps and groups is in an embarrassing
unusable shape.


No match for group package "baekmuk-ttf-batang-fonts"

[snip]

No match for group package "util-linux-user"

I got these ones , is something on my rpm db ?


I am seeing these on another machine, too.


I expect you would see that on all machines.

No.  Well, sort of.  As mentioned, those are packages that have been 
removed from the distro, but are still listed in the comps groups.  
dnf checks the installed groups for packages that need to be updated 
and can't find these ones.

Really? How do I check for which groups I have installed?

At least I haven't found any way to check for them, neither with rpm nor 
with dnf.


dnf group list --installed


Finally, another issue:
...
Error:
  Problem: conflicting requests
   - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
   - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree

   - problem with installed package intel-media-driver-23.4.3-1.fc39.x86_64
   - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)


I see 2 potential issues in there:
1. I think, I once "dnf swapped" these packages => Does "dnf 
system-upgrade" handle "swapped" packages correctly?


How you installed the package is mostly irrelevant.  The package is 
installed, so it will get upgraded if possible.


2. Why does dnf system-upgrade wants to pull-in a i686 package in this 
case? IMO, this doesn't make sense.


I'm unclear on which way the check is going.  Which package(s) do you 
have installed?


rpm -qa | grep intel-media
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Ralf Corsépius]

Am 24.02.24 um 01:36 schrieb Samuel Sieb:

On 2/23/24 15:38, Sérgio Basto wrote:

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:



Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been
retired.
Some group you have installed has that package listed in it.

Ah, this likely explains why neither "dnf repoquery" nor "dnf group
list" could find "multican".


  The comps
groups need to be cleaned out and that's just a warning.

Well, ... IMHO, most about comps and groups is in an embarrassing
unusable shape.


No match for group package "baekmuk-ttf-batang-fonts"

[snip]

No match for group package "util-linux-user"

I got these ones , is something on my rpm db ?


I am seeing these on another machine, too.

No.  Well, sort of.  As mentioned, those are packages that have been 
removed from the distro, but are still listed in the comps groups.  dnf 
checks the installed groups for packages that need to be updated and 
can't find these ones.

Really? How do I check for which groups I have installed?

At least I haven't found any way to check for them, neither with rpm nor 
with dnf.



Finally, another issue:
...
Error:
 Problem: conflicting requests
  - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
  - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree

  - problem with installed package intel-media-driver-23.4.3-1.fc39.x86_64
  - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)


I see 2 potential issues in there:
1. I think, I once "dnf swapped" these packages => Does "dnf 
system-upgrade" handle "swapped" packages correctly?


2. Why does dnf system-upgrade wants to pull-in a i686 package in this 
case? IMO, this doesn't make sense.



Ralf
--
___
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