Re: Donate 1 minute of your time to test upgrades from F35 to F36

[Ankur Sinha]

On Fri, Mar 11, 2022 18:43:01 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 36 better? Please spend 1 minute of your time and
> try to run:
> 
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
> 
> 
> dnf --releasever=36 --setopt=module_platform_id=platform:f36 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=
> updates-testing-modular) \
> --assumeno distro-sync

Didn't get any issues on my 3 F35 installations. 

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Dropping 32bit arches from pypy2.7?

[Victor Stinner]

Thanks, I reported the issue to PyPy:
https://foss.heptapod.net/pypy/pypy/-/issues/3702

Victor

On Mon, Mar 7, 2022 at 1:26 PM Miro Hrončok  wrote:
>
> On 07. 03. 22 10:51, Victor Stinner wrote:
> > How can someone reproduce the issue? I was asked by a developer
> > running Ubuntu. Is there an easy way to:
> >
> > (*) Get Fedora 36
> > (*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the
> > command line for that?
>
> Building pypy is nontrivial. I don't know if you can "just" build it on x86_64
> for i686 without using mock, but you should be able to do it in mock:
>
>   (*) get any supported fedora, even 34 or 35
>   (*) dnf install fedpkg mock
>   (*) add the user to the mock group
>   (*) fedpkg clone -a pypy && cd pypy
>   (*) fedpkg srpm
>   (*) mock -r fedora-rawhide-i386 --enablerepo=local pypy-*.src.rpm
>
>
> Untested. Use
> https://rpm-software-management.github.io/mock/#mock-inside-podman-fedora-toolbox-or-docker-container
> if the Fedora system in fact a container.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Dropping 32bit arches from pypy2.7?

[Victor Stinner]

Thanks, I reported the issue to PyPy:
https://foss.heptapod.net/pypy/pypy/-/issues/3702

Victor

On Mon, Mar 7, 2022 at 1:26 PM Miro Hrončok  wrote:
>
> On 07. 03. 22 10:51, Victor Stinner wrote:
> > How can someone reproduce the issue? I was asked by a developer
> > running Ubuntu. Is there an easy way to:
> >
> > (*) Get Fedora 36
> > (*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the
> > command line for that?
>
> Building pypy is nontrivial. I don't know if you can "just" build it on x86_64
> for i686 without using mock, but you should be able to do it in mock:
>
>   (*) get any supported fedora, even 34 or 35
>   (*) dnf install fedpkg mock
>   (*) add the user to the mock group
>   (*) fedpkg clone -a pypy && cd pypy
>   (*) fedpkg srpm
>   (*) mock -r fedora-rawhide-i386 --enablerepo=local pypy-*.src.rpm
>
>
> Untested. Use
> https://rpm-software-management.github.io/mock/#mock-inside-podman-fedora-toolbox-or-docker-container
> if the Fedora system in fact a container.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] 2022-03-14 @ ** 16:00 ** UTC - Fedora 36 Blocker Review Meeting

[Adam Williamson]

# F36 Blocker Review meeting
# Date: 2022-03-14
# Time: ** 16:00 ** UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hi folks! We have 2 proposed Beta blockers, 1 proposed Beta freeze
exception issue, and 4 proposed Final blockers to review, so let's
have a review meeting on Monday.

Note that DST starts in North America on Sunday, so the meeting time in
UTC is now an hour earlier than before. If your region uses daylight
savings time and it starts this weekend, the meeting will be at the
same local time as usual. If your region does not use DST, or it
doesn't kick in yet, the meeting will be an hour earlier in local time
than usual. Use `date -u` to check the current UTC time if you're
unsure.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F36 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

[Test-Announce] 2022-03-14 @ ** 15:00 ** UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2022-03-14
# Time: ** 15:00 ** UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

It's been a couple of weeks since we met, so let's get together and
see where we're at for Fedora 36 and so on.

Note that DST starts in North America on Sunday, so the meeting time in
UTC is now an hour earlier than before. If your region uses daylight
savings time and it starts this weekend, the meeting will be at the
same local time as usual. If your region does not use DST, or it
doesn't kick in yet, the meeting will be an hour earlier in local time
than usual. Use `date -u` to check the current UTC time if you're
unsure.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 36 status
3. Current criteria / test case proposals
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Donate 1 minute of your time to test upgrades from F35 to F36

[Luya Tshimbalanga]

On 2022-03-11 09:43, Miroslav Suchý wrote:


Do you want to make Fedora 36 better? Please spend 1 minute of your 
time and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=36 --setopt=module_platform_id=platform:f36 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync


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

[sudo] password for luya:
Fedora 36 - x86_64  9.8 kB/s |  10 kB 00:01
Fedora 36 - x86_64  2.9 MB/s |  80 MB 00:27
Fedora 36 openh264 (From Cisco) - x86_64    537  B/s | 989 B 00:01
Fedora Modular 36 - x86_64  8.1 kB/s |  10 kB 00:01
Fedora Modular 36 - x86_64  609 kB/s | 2.3 MB 00:03
Fedora 36 - x86_64 - Updates    144 kB/s |  13 kB 00:00
Fedora 36 - x86_64 - Updates    125  B/s | 257 B 00:02
Fedora Modular 36 - x86_64 - Updates    823  B/s |  13 kB 00:16
Fedora Modular 36 - x86_64 - Updates    145  B/s | 257 B 00:01
Fedora 36 - x86_64 - Test Updates   1.6 MB/s | 8.0 MB 00:05
Fedora Modular 36 - x86_64 - Test Updates    76 kB/s | 318 kB 00:04
RPM Fusion for Fedora 36 - Free  21 kB/s | 5.3 kB 00:00
RPM Fusion for Fedora 36 - Free 1.2 MB/s | 949 kB 00:00
RPM Fusion for Fedora 36 - Free - Updates    21 kB/s | 5.2 kB 00:00
RPM Fusion for Fedora 36 - Free - Updates   589  B/s | 257 B 00:00
RPM Fusion for Fedora 36 - Nonfree   22 kB/s | 5.5 kB 00:00
RPM Fusion for Fedora 36 - Nonfree  432 kB/s | 249 kB 00:00
RPM Fusion for Fedora 36 - Nonfree - Steam   21 kB/s | 5.4 kB 00:00
RPM Fusion for Fedora 36 - Nonfree - Steam  4.9 kB/s | 2.1 kB 00:00
RPM Fusion for Fedora 36 - Nonfree - Updates 20 kB/s | 5.1 kB 00:00
RPM Fusion for Fedora 36 - Nonfree - Updates    613  B/s | 257 B 00:00
Dependencies resolved.

 Package Arch   Version Repository   Size

Installing:
 kernel  x86_64 5.17.0-0.rc7.116.fc36 
fedora  157 k
 kernel-modules  x86_64 5.17.0-0.rc7.116.fc36 
fedora   53 M
 kernel-modules-extra    x86_64 5.17.0-0.rc7.116.fc36 
fedora  3.4 M

Upgrading:
[..snip...]
Installing group/module packages:
 qgnomeplatform-qt5  x86_64 0.8.4-5.fc36 updates-testing 178 k
 replacing  qgnomeplatform.x86_64 0.8.4-4.fc35
 rit-meera-new-fonts noarch 1.2.1-2.fc36 fedora  171 k
 replacing  smc-meera-fonts.noarch 7.0.3-4.fc35
Installing dependencies:
 Lmod    x86_64 8.6.11-1.fc36 fedora  228 k
 MUMPS   x86_64 5.4.1-2.fc36 fedora  1.9 M
 MUMPS-common    noarch 5.4.1-2.fc36 fedora  805 k
 NetworkManager-initscripts-updown
 noarch 1:1.36.0-0.11.fc36 fedora   
14 k

 adwaita-qt6 x86_64 1.4.1-3.fc36 updates-testing 101 k
 byte-buddy  noarch 1.12.0-3.fc36 fedora  2.9 M
 byte-buddy-agent    noarch 1.12.0-3.fc36 fedora   61 k
 cgnslib x86_64 4.2.0-6.fc36 fedora  694 k
 cgnslib-common  noarch 4.2.0-6.fc36 fedora  105 k
 cliquer-libs    x86_64 1.22-3.fc36 fedora   38 k
 coin-or-Cbc x86_64 2.10.5-8.fc36 fedora  828 k
 coin-or-Cgl x86_64 0.60.3-6.fc36 fedora  429 k
 coin-or-Clp x86_64 1.17.6-7.fc36 fedora  931 k
 coin-or-CoinUtils   x86_64 2.11.4-6.fc36 fedora  479 k
 coin-or-Osi x86_64 0.108.6-5.fc36 fedora  319 k
 colord-gtk4 x86_64 0.3.0-1.fc36 fedora   19 k
 f36-backgrounds-base    noarch 36.0.1-2.fc36 updates-testing  22 M
 f36-backgrounds-gnome   noarch 36.0.1-2.fc36 updates-testing 7.5 k
 gecode  x86_64 6.2.0-8.fc35 fedora  3.1 M
 glpk    x86_64 5.0-4.fc36 fedora  385 k
 gnome-desktop4  x86_64 42~beta-3.fc36 fedora  148 k
 google-noto-sans-vf-fonts   noarch 20201206-9.fc36 updates-testing 492 k
 gtksourceview5  x86_64 5.3.2-3.fc36 fedora  994 k
 initscripts-rename-device   x86_64 10.16-2.fc36 updates-testing  18 k
 jacop   noarch 4.8-7.fc36 fedora  1.7 M
 

[Bug 2061505] perl-CGI-Ex-2.54 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-CGI-Ex-2.53 is |perl-CGI-Ex-2.54 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.54
Current version/release in rawhide: 2.50-6.fc36
URL: http://search.cpan.org/dist/CGI-Ex/

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://fedoraproject.org/wiki/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/7682/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2061505
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220311.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 14/214 (x86_64), 23/161 (aarch64)

ID: 1170089 Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1170089
ID: 1170092 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1170092
ID: 1170093 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1170093
ID: 1170100 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1170100
ID: 1170123 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1170123
ID: 1170131 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1170131
ID: 1170166 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/1170166
ID: 1170170 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1170170
ID: 1170193 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1170193
ID: 1170195 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1170195
ID: 1170204 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1170204
ID: 1170211 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1170211
ID: 1170212 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1170212
ID: 1170221 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1170221
ID: 1170223 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1170223
ID: 1170225 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1170225
ID: 1170241 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1170241
ID: 1170246 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1170246
ID: 1170247 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1170247
ID: 1170250 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1170250
ID: 1170265 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1170265
ID: 1170266 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1170266
ID: 1170269 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1170269
ID: 1170277 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/1170277
ID: 1170300 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1170300
ID: 1170301 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1170301
ID: 1170329 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/1170329
ID: 1170366 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1170366
ID: 1170373 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1170373
ID: 1170374 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1170374
ID: 1170376 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1170376
ID: 1170377 Test: aarch64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/1170377
ID: 1170386 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1170386
ID: 1170388 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1170388
ID: 1170389 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1170389
ID: 1170393 Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/1170393
ID: 1170397 Test: aarch64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/1170397

Soft failed openQA tests: 5/214 (x86_64), 3/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

ID: 1170096 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1170096
ID: 1170108 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1170108
ID: 1170127 Test: x86_64 

Re: Problem with cmake 3.23.0

[Fabio Valentini]

On Fri, Mar 11, 2022 at 11:15 PM Michel Alexandre Salim
 wrote:
>
> On Fri, Mar 04, 2022 at 09:26:04AM -0500, Steven A. Falco wrote:
> > There is a new FTBFS for KiCad [1].  I filed an issue with KiCad [2] and 
> > got a comment from the project leader:
> >
> > This looks like cmake issue to me. For some reason cmake is creating an 
> > incorrect build folder:
> >
> This is probably related: in cmake 3.22 (Fedora 36) and below, this
> works:
>
> ```
> mkdir some-dir
> cd some-dir
> %cmake ..
> cd -
>
> mkdir other-dir
> cd other-dir
> %cmake ..
> cd -
> ```
>
> Which is useful if you need to invoke `%cmake` several times, e.g. to
> build against different Lua runtimes (e.g. lua-luv) or to do both static
> and shared library builds (which we used to do for the folly stack).
>
> Also: if the CMakeLists.txt is not in the root of your project tarball,
> previously you can just do `%cmake actual-src-dir`.
>
> In F37's cmake 3.23, it seems that `cmake -S . ..` has the `-S .` trump
> the `..` when it comes to finding where CMakeLists.txt is, while
> previously `..` wins.
>
> I was working around it by simply `cd actual-src-dir` before `%cmake`,
> but it turns out simply passing an additional `-S` works, e.g.:
>
> ```
> mkdir some-dir
> cd some-dir
> %cmake -S ..
> cd -
> ```
>
> e.g.
> https://src.fedoraproject.org/rpms/lua-luv/pull-request/3

This makes me wonder.

A lot of the things that are now reported as "broken" look like they
should already have been broken when we switched to out-of-tree builds
for CMake by default.
And a lot of the snippets look like things that I helped fix when that
change landed.

So ... did anybody investigate what actually changed here? Was it a
behaviour change in cmake CLI argument handling, or have the actual
%cmake / %cmake_build etc. macros changed in a way that makes them no
longer backwards compatible?

> If you mean the Fedora 33 change page, it only describes the change
> from Fedora 33+ perspective.  It does not take compatibility with EPEL
> buildroots into account at all.

Also related, as far as I know, Neal put great effort into making the
macros work almost exactly the same on both Fedora and EPEL.
So I think that statement is incorrect.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem with cmake 3.23.0

[Michel Alexandre Salim]

On Fri, Mar 04, 2022 at 09:26:04AM -0500, Steven A. Falco wrote:
> There is a new FTBFS for KiCad [1].  I filed an issue with KiCad [2] and got 
> a comment from the project leader:
> 
> This looks like cmake issue to me. For some reason cmake is creating an 
> incorrect build folder:
> 
This is probably related: in cmake 3.22 (Fedora 36) and below, this
works:

```
mkdir some-dir
cd some-dir
%cmake ..
cd -

mkdir other-dir
cd other-dir
%cmake ..
cd -
```

Which is useful if you need to invoke `%cmake` several times, e.g. to
build against different Lua runtimes (e.g. lua-luv) or to do both static
and shared library builds (which we used to do for the folly stack).

Also: if the CMakeLists.txt is not in the root of your project tarball,
previously you can just do `%cmake actual-src-dir`.

In F37's cmake 3.23, it seems that `cmake -S . ..` has the `-S .` trump
the `..` when it comes to finding where CMakeLists.txt is, while
previously `..` wins.

I was working around it by simply `cd actual-src-dir` before `%cmake`,
but it turns out simply passing an additional `-S` works, e.g.:

```
mkdir some-dir
cd some-dir
%cmake -S ..
cd -
```

e.g.
https://src.fedoraproject.org/rpms/lua-luv/pull-request/3

Best regards,

-- 
Michel Alexandre Salim
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Singular soname bump and a review swap

[Jerry James]

HI Paulo,

It's great to hear from you.  I hope you are well.

On Wed, Mar 9, 2022 at 4:42 AM Paulo César Pereira de Andrade
 wrote:
>   If nobody takes it, I can review.

Ankur took it already.  On the other hand, he doesn't seem to have
actually started the review yet...

>   I was about to ask for a review as well, as I have my own version locally :)

Ah, sorry, didn't mean to duplicate effort.

>   Did not double check if already done, but will need to change L-function to
> use the sage spkg as upstream is no longer available. This will also need a
> library major downgrade. But only sagemath uses it, so not a major issue.
> Optionally, could work on renaming  the L-function package to lcalc, to match
> what it is being called in the past 6+ years...

Yes, that's on the list.  This is what I had lined up to do next week
sometime, after the python-primecountpy review is completed.

- Update L-function to 2.0.5.  I did not notice that this changes the
L-function soname downwards.  Ugh.  Still, as you say, that should be
okay since sagemath is the only consumer.  I had added a comment at
the top of the spec file noting that we should rename it "lcalc". :-)
- Update python-cysignals to 1.11.2
- Update Singular to 4.2.1p3
- Update sympy to 1.10
- Add python-primecountpy 0.1.0
- Rebuild polymake due to the Singular update
- Rebuild python-pysingular due to the Singular update
- Update sagemath to 9.5
- Retire pynac, which has been absorbed into sagemath

Is there any of that you would prefer to do yourself?  I don't want to
step on your toes at all.  Or if you would like to see the changes I'm
planning to make to any of those packages, I'm happy to share the spec
files and relevant patches with you.

And then I'm going back to trying to retire from tending mathematical
packages in Fedora.  If you want any of the packages I currently
maintain, let me know and I will transfer them to you.  Regards,
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2061505] perl-CGI-Ex-2.53 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-CGI-Ex-2.52 is |perl-CGI-Ex-2.53 is
   |available   |available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.53
Current version/release in rawhide: 2.50-6.fc36
URL: http://search.cpan.org/dist/CGI-Ex/

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://fedoraproject.org/wiki/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/7682/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2061505
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Beta blocker status summary

[Ben Cotton]

Action summary


Accepted blockers
-
1. anaconda — When running anaconda on Wayland with two keyboard
layouts configured, hitting any modifier key with the second layout
selected switches to the first layout — POST
ACTION: Maintainers to package upstream PR #3912

2. fedora-release — fedora-release-identity-cloud says "Cloud
Edition", Cloud has not been an edition for years — ASSIGNED
ACTION: none

3. mutter — GNOME doesn't accept input from wireless keyboard if
there's not another "keyboard" input available — ON_QA
ACTION: QA to verify FEDORA-2022-21d81706cd

4. firefox — f36 composes still have firefox 96, f34 f35 have firefox 97 — ON_QA
ACTION: QA to verify FEDORA-2022-42ea499a7d


Proposed blockers
-

1. mutter — Workstation Live is frozen in a VM with QXL video driver
(Virtio works OK) — NEW
ACTION: Maintainers to diagnose and fix issue

2. selinux-policy — SELinux preventing systemd-network-generator from
creating files in /run/systemd/network/ — ASSIGNED
ACTION: Maintainers to update policy to fix issue


Bug-by-bug detail
=

Accepted blockers
-
1.  anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2016613 — POST
When running anaconda on Wayland with two keyboard layouts configured,
hitting any modifier key with the second layout selected switches to
the first layout

adamwill's research shows that this bug has existed since F25, but
became more viisble after KDE switched to Wayland by default. This bug
was deferred to F36 Beta under the "too hard to fix" exception.
jkonecny is working on  a fix to disconnect keyboard control between
Anaconda and the live environment. Upstream PR
https://github.com/rhinstaller/anaconda/pull/3912 has a candidate fix.

2. fedora-release —
https://bugzilla.redhat.com/show_bug.cgi?id=2018271 — ASSIGNED
fedora-release-identity-cloud says "Cloud Edition", Cloud has not been
an edition for years

Waived from F35 final under the "late blocker exception." Cloud WG is
working on a proposal to re-promote Cloud to Edition status, but that
will not happen for F36 release cycle. Council voted to waive this. An
update to the release criterion is pending that explicitly grants
Council the ability to do that.

3. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2017043 — ON_QA
GNOME doesn't accept input from wireless keyboard if there's not
another "keyboard" input available

On some hardware, devices with multiple capabilities that include
keyboard do not get registered as a keyboard. Thus they only work if
another keyboard is connected. FEDORA-2022-21d81706cd (GNOME 42
megaupdate) includes a candidate fix.

4. firefox — https://bugzilla.redhat.com/show_bug.cgi?id=2057193 — ON_QA
f36 composes still have firefox 96, f34 f35 have firefox 97

Builds of Firefox 97, which contains security fixes, are failing on
F36 and Rawhide due to a GCC 12 internal error. FEDORA-2022-42ea499a7d
provides a successful build of Firefox 97.


Proposed blockers
-

1. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2063156 — NEW
Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)

Recent composes of Workstation with the default video driver freeze on
the welcome screen. Using virtio initially (including switching to qxl
post-install) does not have this behavior.

2. selinux-policy —
https://bugzilla.redhat.com/show_bug.cgi?id=2037047 — ASSIGNED
SELinux preventing systemd-network-generator from creating files in
/run/systemd/network/.

Passing network kernel arguments (e.g. to set the nameserver) at boot
causes a failure in systemd-network-generator due to an SELinux
denial.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 36 Candidate Beta-1.1 Available Now!

[rawhide]

According to the schedule [1], Fedora 36 Candidate Beta-1.1 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/36

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Beta_1.1_Security_Lab

All Beta priority test cases for each of these test pages [2] must
pass in order to meet the Beta Release Criteria [3].

Help is available on #fedora-qa on libera.chat [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-36/f-36-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
[4] https://web.libera.chat/?channels=#fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

[Demi Marie Obenour]

On 3/11/22 13:33, Fabio Valentini wrote:
> On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III  wrote:
>>
>> On Wed, Mar 09, 2022 at 12:23:41 -0600,
>>   Bruno Wolff III  wrote:
>>> On Wed, Mar 09, 2022 at 09:06:01 -0600,
>>>
>>> The Fedora 36 beta is likely to slip because firefox was not building
>>> successfully on i686, but was on other arches.
>>
>> It is actually more complicated than I remembered. Firefox needed a gcc fix,
>> but gcc building is blocked on an i686 issue. And the delay in getting
>> that fix combined with the long time for doing a gcc build is seemingly
>> going to result in a slip because a firefox downgrade (from the f35 version)
>> would cause problems for some testers.
> 
> So ... this sounds like firefox would be a good example of a package
> that would benefit from my proposal?

It would be, yes.


-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2005973] perl-Crypt-OpenSSL-PKCS10: FTBFS with OpenSSL 3.0.0 in Fedora Rawhide

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-f1728ecc63 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-f1728ecc63`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f1728ecc63

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2005973
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2061969] perl-Devel-PPPort-3.67 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-22f1e90841 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-22f1e90841`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-22f1e90841

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2061969
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062685] perl-Scalar-Properties-1.100860-30.fc37 FTBFS: Distribution files are missing in MANIFEST: .package_note-perl-Scalar-Properties-1.100860-30.fc37.x86_64.ld

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-f74d4a7c62 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-f74d4a7c62`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f74d4a7c62

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062685
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Justin Forbes]

On Thu, Mar 10, 2022 at 10:51 AM Simo Sorce  wrote:
>
> On Thu, 2022-03-10 at 09:44 -0500, Colin Walters wrote:
> >
> > On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote:
> > > Hi Fedora, CentOS, and EPEL Communities!
> > >
> > > As part of our continued 3 year major Red Hat Enterprise Linux
> > > release
> > > cadence, RHEL 9 development is starting to wrap up with the spring
> > > 2022 release coming soon.  That means planning for the next release
> > > will start in earnest in the very near future.  As some of you may
> > > know, Red Hat has been using both Bugzilla and Jira via
> > > issues.redhat.com for RHEL development for several years.  Our
> > > intention is to move to using issues.redhat.com only for the major
> > > RHEL releases after RHEL 9.

My only real concern here from a Fedora standpoint is security
tracking.  As it stands, the security team files fedora bugs for us
linking back to the umbrella issue where most discussion happens.  I
would really miss that workflow if it were to break as unfortunately
the kernel does get a number of CVEs to address (we are at 43 so far
in 2022, we had 211 in 2021).

> > I think it's unfortunate to replace the FOSS Bugzilla with
> > proprietary software.  I am eternally conflicted about this with
> > respect to GitHub (xref
> > https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is
> > not as compelling of a user experience upgrade.
> >
> > A continual challenge related to this I feel is using the same
> > software to track product bugs with potentially sensitive customer
> > data in it, and public open development.
> >
> > To link these things, I quite commonly move Bugzilla discussion that
> > has no need to be private to Github, because I know Github is always
> > public (from our PoV).
> >
> > One thing that may help is to at least use different themes (e.g.
> > blue colors for public CentOS issues, red for RHEL?) on
> > issues.redhat.com.
> >
> > Long term if Bugzilla slowly morphs into only being used by Fedora,
> > personally I'd prefer to have bugs/issues in gitlab instead.
>
> Given how we use bugzilla (we do not really use any big feature there)
> in Fedora I would give a big +1 to use an issue tracker embedded in the
> forge we use to store the packages (whether that is pagure, gitlab,
> github, or something else).

I would be very much against this move to integrate with the source
forge. While It would probably work well for large parts of the
distribution, it would be a bit of a nightmare for something like
kernel with the number of bugs that it gets, and the rate of moving
through things.  I am not advocating for Jira here either, but at
least what I currently see in gitlab and pagure would be a bit of a
nightmare for me.  I do very much like the idea of being able to
perhaps tie bugs to kernel versions rather than Fedora releases
though.  It would be a useful feature in whatever we might choose if
we were to move.

Justin

> Also I always resented that I need two separate accounts to deal with
> Fedora packages, I think reducing that to host all in the same place
> with the same authentication will also be a positive factor in
> fostering collaboration, less barriers. It will also reduce
> administrative overhead of having to configure components/ownership/etc
> in multiple places and what not.
>
> Finally by having issues and code in the same place it means we can
> easily connect commits/PRs/MRs to the issues meaning our issue tracker
> a lot more useful, and will allow us to have better content also in our
> updates, where today associating an update to an issue (a bz) is not
> happening as well as it could.
>
> HTH,
> Simo.
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: undefined symbol `__libc_stack_end' in F36/Rawhide

[Kevin Fenzi]

On Fri, Mar 11, 2022 at 11:21:09AM +, Sérgio Basto wrote:
> Hello,
> 
> On Thu, 2022-03-10 at 09:36 +0100, Florian Weimer wrote:
> > * Ron Olson:
> > 
> > > Building swiftlang on F36/Rawhide results in a a failure that,
> > > boiled down to its essence, appears to be:
> > > 
> > > /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32
> > > against undefined symbol `__libc_stack_end' can not be used when
> > > making a shared object; recompile with -fPIC
> > > 
> > > It compiles fine on 35 so I’m guessing glibc has been updated; a
> > > bunch of web searching hasn’t come up with any useful suggestions,
> > > the one ancient Bugzilla ticket I found was not resolved.
> > > 
> > > Any suggestions on what to do about this?
> > 
> > How is __libc_stack_end declared in the sources?  This could be a
> > Clang
> > bug or a bug in the source package.
> 
> by coincidence rawhide compose doomed since 20220309 (...) , i.e. maybe
> this is a serious thing and someone need to look what is happening to
> rawhide composes 

rawhide composes have been failing due to qt/kde broken deps. :)

Nothing to do with this as far as I can see. 

kevin


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

[Fabio Valentini]

On Fri, Mar 11, 2022 at 5:51 PM Yaakov Selkowitz  wrote:

(snip)

> I don't see the opt-out as being "simple" at all, as IIUC all it would take is
> one maintainer not paying close enough attention to reverse dependencies to
> break the i686 buildroot.  Not to mention that it ends up polluting the vast
> majority of packages with a spec file change that isn't technically accurate
> (since the package *could* be built for i686, we've just choosing not to, and
> the proper place to express that is in the build tag's arches).
>
> Since the number of packages actually needed for i686 -- wine and its deps,
> plus deps for those RPM Fusion i686 library packages, it seems -- should be a
> small minority of the entire distribution, it should be those where the
> changes are made.  Doesn't it make more sense to special-case the exception
> rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg
> files should be better than hardcoding a list in fedpkg, as the former doesn't
> require the lag time involved in pushing an update when the list changes.)
>
> It also avoids this becoming a piecemeal change, which will likely drag on for
> years if left to individual maintainers.

Please stop moving goalposts. The goal of my proposal was never to
drop support for i686 from *all* possible packages.
It's about making it easy to drop unnecessary support for i686 from
packages *where it matters to the maintainer*.
And for this reason, I think a simple *opt-out* mechanism is the best solution.

If you want to talk about making it the norm to drop support for i686
unless the maintainer does *opt-in* to i686 for multilib, then that
can be a follow-up Change that can build on top of this one. But
please don't conflate the two things, as they are very different.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

[Fabio Valentini]

On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III  wrote:
>
> On Wed, Mar 09, 2022 at 12:23:41 -0600,
>   Bruno Wolff III  wrote:
> >On Wed, Mar 09, 2022 at 09:06:01 -0600,
> >
> >The Fedora 36 beta is likely to slip because firefox was not building
> >successfully on i686, but was on other arches.
>
> It is actually more complicated than I remembered. Firefox needed a gcc fix,
> but gcc building is blocked on an i686 issue. And the delay in getting
> that fix combined with the long time for doing a gcc build is seemingly
> going to result in a slip because a firefox downgrade (from the f35 version)
> would cause problems for some testers.

So ... this sounds like firefox would be a good example of a package
that would benefit from my proposal?

- It's already almost a leaf package (only some other GUI apps - that
could also drop i686 support without any consequences - depend on it).
- We already do not publish or ship firefox.i686 RPMs - or RPMs for
the 4 dependent applications, for that matter - to anybody, so
building them is just a waste of time and maintainer resources.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

===
#fedora-meeting: ELN SIG 2022-03-11
===


Meeting started by sgallagh at 17:00:13 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting/2022-03-11/eln.2022-03-11-17.00.log.html
.



Meeting summary
---
* Init Process  (sgallagh, 17:00:13)

* Status Report  (sgallagh, 17:04:18)
  * Composes are timing out and failing, but we did get a good one on
Mar. 9  (sgallagh, 17:06:12)
  * ELN SIG spoke to the Fedora Council yesterday, see recording at
https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow when
available  (sgallagh, 17:08:29)
  * ELN-Extras is in progress, but slow going due to other commitments.
Reviews requested for

https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/merge_requests/37
(sgallagh, 17:11:45)

* x86_64-v3  (sgallagh, 17:13:54)
  * ACTION: sgallagh to discuss the impact of x86_64-v3 on RHEL for Edge
with RHEL Pgm  (sgallagh, 17:54:10)
  * Important points raised: v3 was not universally available until
2017, which means existing hardware may need replacement to run
(sgallagh, 17:55:20)
  * non-AVX2 hardware is still in production, and widely deployed in
long-lifecycle environments (emdedded/pos/appliances/etc.) that
could be impacted by this change  (dcavalca, 17:55:30)
  * Concerns about ISV and integrator cases for x86_64-v3 for RHEL.
Would prefer to see us look into supporting multiple flavors for
x86_64 in parallel like done in the past with ppc64 with p7 and
x86_32 with i586 and i686  (Eighth_Doctor, 17:55:34)
  * Edge devices frequently use low-power Intel chips such as Atom and
many (most?) don't have v3 support  (sgallagh, 17:55:47)
  * Increasing the baseline will lead to smaller code (both in less disk
space and higher efficiency)  (sgallagh, 17:56:47)
  * On the other hand, multiple builds in the OS do not clean the pipes
for ISVs, which would have to deliver multiple builds as well to
avoid support issues.  (fweimer, 17:56:51)
  * The guaranteed availability of AVX2 extensions would benefit
high-performance computing, particularly machine-learning.
(sgallagh, 17:57:20)
  * OpenMandriva has an implementation of x86_64 flavors we can use as a
basis to understand implementing a similar system for supporting
x86_64-vX levels in parallel.  (Eighth_Doctor, 17:58:32)

Meeting ended at 18:03:44 UTC.




Action Items

* sgallagh to discuss the impact of x86_64-v3 on RHEL for Edge with RHEL
  Pgm




Action Items, by person
---
* sgallagh
  * sgallagh to discuss the impact of x86_64-v3 on RHEL for Edge with
RHEL Pgm
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* Eighth_Doctor (66)
* sgallagh (59)
* fweimer (37)
* jforbes (29)
* dcavalca (24)
* zodbot (11)
* cyberpear (2)
* Conan_Kudo (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Function


>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Donate 1 minute of your time to test upgrades from F35 to F36

[Miroslav Suchý]

Do you want to make Fedora 36 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

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


This command does not replace `dnf system-upgrade`, but it will reveal 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
36. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F36FailsToInstall) 
reports:

https://bugzilla.redhat.com/buglist.cgi?bug_id=1992487_id_type=anddependson=tvp_id=12486533

Thank you

Miroslav___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Adam Williamson]

On Thu, 2022-03-10 at 11:51 -0500, Simo Sorce wrote:
> Given how we use bugzilla (we do not really use any big feature there)

Uhhh! Whoah! Yes, we certainly do!

I think people may be underestimating how much of Bugzilla we use.
Replacing it would *certainly* not be a drop-in operation.

We use the dependency tracking extensively, as part of core Fedora
processes (the release blocker process and the Change process at
least). We use flags for package review. We use keywords and
whiteboards for various housekeeping and documentation processes. I
know a lot of people use Bugzilla saved searches.

I'm not saying we need to keep Bugzilla forever, but we need to be
realistic about how disruptive a change moving off it would be. It is
not a simple thing to do.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062963] perl-Crypt-OpenSSL-PKCS10-0.18 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Scratch build failed. Details bellow:

GenericError: File upload failed:
cli-build/1647019973.7948303.oefuhEEZ/perl-Crypt-OpenSSL-PKCS10-0.18-1.fc34.src.rpm
Traceback:
  File
"/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 3027, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 2962, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062963
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062963] perl-Crypt-OpenSSL-PKCS10-0.18 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Crypt-OpenSSL-PKCS10-0 |perl-Crypt-OpenSSL-PKCS10-0
   |.17 is available|.18 is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.18
Current version/release in rawhide: 0.16-20.fc37
URL: http://search.cpan.org/dist/Crypt-OpenSSL-PKCS10/

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://fedoraproject.org/wiki/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/2746/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062963
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Daniel P . Berrangé]

On Fri, Mar 11, 2022 at 01:52:53PM +, Peter Robinson wrote:
> > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters  wrote:
> > > Long term if Bugzilla slowly morphs into only being used by Fedora,
> > > personally I'd prefer to have bugs/issues in gitlab instead.
> >
> > Yes, I personally think gitlab.com would be a good replacement for
> > src.fedoraproject.org and bugzilla.redhat.com.
> 
> I disagree as the interface for agile development like sprints, kanban
> and other team tools is rudimentary at best and really not suitable
> for anything more than the basics and is not a patch on the
> functionality and plugin ecosystem that is available in Jira. The
> gitlab functionality there is a toy in comparison.

The comparison is reasonable, but I would ask if support for things
like sprints, kanban, etc is actually important for Fedora's bug
reporting needs ? Personally I can't see that it is given the way
I see that maintainers work in Fedora in an adhoc way, usually
independantly, and light on any formally required processes or
bureaucracy.

When I look at how we've evolved & used Bugzilla over the years
for RHEL, I feel like much of the unpleasantness has been because
we've tried to take a bug tracking tool, and bend it into being
a project management tool. Thankfully Fedora kept its use of
bugzilla simple, and didn't try to make it apply specific dev
practices/workflows.

IOW to me the appeal of the git forge bug trackers is precisely
that they are very simple, to both reporters and maintainers.
They may not be suitable for RHEL, but they feel like a decent
fit for Fedora.

IMHO if there are times when some group of Fedora maintainers is
closely collaborating and wants to use agile dev practice, it
ought to be possible to use a separate tool for those tasks,
linking to the bug tracker if & when relevant.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

[luya]

On 2022-03-11 1:34 a.m., Dan Horák  wrote:

On Fri, 11 Mar 2022 01:24:58 -0800
Luya Tshimbalanga  wrote:

> Hello team,
>
> I encountered a weird error[0] when building blender[1] with upstream
> patch[2] for USD support:
>
> ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

looks like something is wrong with USD library detection

...
-- Found USD: /usr/lib64
...

^^^ this should be a file (like /usr/lib64/libUSD.so)



Thank you Dan! Adding 'libusd_usd_ms.so' in /usr/lib64 resolved the 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

[Yaakov Selkowitz]

On Fri, 2022-03-11 at 15:31 +0100, Fabio Valentini wrote:
> On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott  wrote:
> > 
> > > On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
> > > 
> > > Why isn't this as simple as:
> > > 
> > > 1) Create an f37-multilib-build build tag with all supported arches +
> > > i686,
> > > and an f37-multilib{,-candidate} build targets to use it (with
> > > destination tag
> > > of f37-updates-candidate);
> > > 
> > > 2) Drop i686 from f37-build tag;
> > > 
> > > 3) Maintainers of wine and its deps etc. opt-in to i686 with a
> > > package.cfg:
> > > 
> > > [koji]
> > > targets = f37-multilib
> > > 
> > > (Yes, that would have to be updated after branch point, but that could
> > > possibly be automated.)
> > > 
> > > 4) Everyone else leaves their spec files alone, no need to add
> > > ExcludeArch:
> > > i686.
> > > 
> > > Would that work?
> > 
> > That works ok for rpmfusion.
> > 
> > https://koji.rpmfusion.org/koji/taginfo?tagID=483
> > 
> > fedpkg could be adapted as well, see
> > 
> > https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
> 
> This might work for RPMFusion, but only because you have a limited set
> of packages, and because you can rely on the Fedora buildroot and
> dependencies always to be there.
> For Fedora itself, we do not have that luxury. We would need to know
> the packages that are needed to build and maintain the base buildroot
> plus everything needed to build multilib packages. As I said, this is
> not so easy. And then we're back to modifying (adding config files)
> all packages that need to be included (or maintaining a hard-coded
> list of required packages in fedpkg), so you don't gain anything at
> all, compared to the simple opt-out mechanism from this Proposal.

I don't see the opt-out as being "simple" at all, as IIUC all it would take is
one maintainer not paying close enough attention to reverse dependencies to
break the i686 buildroot.  Not to mention that it ends up polluting the vast
majority of packages with a spec file change that isn't technically accurate
(since the package *could* be built for i686, we've just choosing not to, and
the proper place to express that is in the build tag's arches).

Since the number of packages actually needed for i686 -- wine and its deps,
plus deps for those RPM Fusion i686 library packages, it seems -- should be a
small minority of the entire distribution, it should be those where the
changes are made.  Doesn't it make more sense to special-case the exception
rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg
files should be better than hardcoding a list in fedpkg, as the former doesn't
require the lag time involved in pushing an update when the list changes.)

It also avoids this becoming a piecemeal change, which will likely drag on for
years if left to individual maintainers.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Simo Sorce]

On Fri, 2022-03-11 at 13:52 +, Peter Robinson wrote:
> > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters 
> > wrote:
> > > Long term if Bugzilla slowly morphs into only being used by
> > > Fedora,
> > > personally I'd prefer to have bugs/issues in gitlab instead.
> > 
> > Yes, I personally think gitlab.com would be a good replacement for
> > src.fedoraproject.org and bugzilla.redhat.com.
> 
> I disagree as the interface for agile development like sprints,
> kanban
> and other team tools is rudimentary at best and really not suitable
> for anything more than the basics and is not a patch on the
> functionality and plugin ecosystem that is available in Jira. The
> gitlab functionality there is a toy in comparison.

Peter,
Bugzilla has no support for any sprints or kanban at all, so I do not
see how this is relevant.
Unless your claim is that Fedora absolutely needs a sprint/kanban based
organizational tool which would surprise me.

I personally do not think Fedora should tie itself to Red Hat's Jira.
For community oriented development Jira is simply not a great tool IMO,
because it is built with a "traditional" organization in mind, not for
community use.

Keeping it simple is actually an existential requirement for Fedora
where we have so many drive-by volunteers. Complex on-boarding becomes
quickly an impenetrable barrier to participation.
This is another reason I think common forges issue systems, while
limited are a better fit for community issue reporting than either
Bugzilla or Jira, because they are simple and immediately available.

You can easily write automation to pull in/mirror issues into your own
Jira projects if that's what you use for work and feel the need for,
IMO.

And just to be clear I am both a *heavy* Jira and Bugzilla user
(including writing automation for both and other stuff via bots) for
work, so I think I can say I know what I am talking about.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Brian Stinson]

On Fri, Mar 11, 2022, at 04:55, Florian Weimer wrote:
> * Josh Boyer:
>
>> As part of our continued 3 year major Red Hat Enterprise Linux release
>> cadence, RHEL 9 development is starting to wrap up with the spring
>> 2022 release coming soon.  That means planning for the next release
>> will start in earnest in the very near future.  As some of you may
>> know, Red Hat has been using both Bugzilla and Jira via
>> issues.redhat.com for RHEL development for several years.  Our
>> intention is to move to using issues.redhat.com only for the major
>> RHEL releases after RHEL 9.
>
> Thanks for posting this publicly.
>
>> - Fedora Linux and EPEL have their own Bugzilla product families and
>> are not directly impacted in their own workflows by the choice to use
>> only issues.redhat.com for RHEL.
>> - There will be impacts on existing documentation that provide
>> guidance on requesting things from RHEL in various places like EPEL.
>> We will be happy to help adjust these.
>
> There is already an “FC” project on issues.redhat.com, into which Fedora
> bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
> mirror+ Bugzilla flag publicly, and make the FC project public, so that
> people can experiment with that?
>
>> If there are other impacts that you can think of, please raise them on
>> this thread.  We’d like to ensure we’re covering as much as possible
>> as this rolls out.
>
> What is going to happen to the CentOS Mantis instance
> ?  From the looks of it, it probably should
> just be switched off?

Since we've moved CentOS Stream to bugzilla/jira I think it will make more and 
more sense to look at deduplicating the number of bug trackers we have. CentOS 
Linux 7 bugs are still nominally tracked in Mantis, though. 

We do not have active plans to retire bugs.centos.org yet. 

--Brian 

>
> Thanks,
> Florian
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Brian Stinson]

On Fri, Mar 11, 2022, at 04:55, Florian Weimer wrote:
> * Josh Boyer:
>
>> As part of our continued 3 year major Red Hat Enterprise Linux release
>> cadence, RHEL 9 development is starting to wrap up with the spring
>> 2022 release coming soon.  That means planning for the next release
>> will start in earnest in the very near future.  As some of you may
>> know, Red Hat has been using both Bugzilla and Jira via
>> issues.redhat.com for RHEL development for several years.  Our
>> intention is to move to using issues.redhat.com only for the major
>> RHEL releases after RHEL 9.
>
> Thanks for posting this publicly.
>
>> - Fedora Linux and EPEL have their own Bugzilla product families and
>> are not directly impacted in their own workflows by the choice to use
>> only issues.redhat.com for RHEL.
>> - There will be impacts on existing documentation that provide
>> guidance on requesting things from RHEL in various places like EPEL.
>> We will be happy to help adjust these.
>
> There is already an “FC” project on issues.redhat.com, into which Fedora
> bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
> mirror+ Bugzilla flag publicly, and make the FC project public, so that
> people can experiment with that?
>
>> If there are other impacts that you can think of, please raise them on
>> this thread.  We’d like to ensure we’re covering as much as possible
>> as this rolls out.
>
> What is going to happen to the CentOS Mantis instance
> ?  From the looks of it, it probably should
> just be switched off?

Since we've moved CentOS Stream to bugzilla/jira I think it will make more and 
more sense to look at deduplicating the number of bug trackers we have. CentOS 
Linux 7 bugs are still nominally tracked in Mantis, though. 

We do not have active plans to retire bugs.centos.org yet. 

--Brian 

>
> Thanks,
> Florian
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Ken Dreyer]

On Fri, Mar 11, 2022, 8:53 AM Peter Robinson  wrote:

> > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters 
> wrote:
> > > Long term if Bugzilla slowly morphs into only being used by Fedora,
> > > personally I'd prefer to have bugs/issues in gitlab instead.
> >
> > Yes, I personally think gitlab.com would be a good replacement for
> > src.fedoraproject.org and bugzilla.redhat.com.
>
> I disagree as the interface for agile development like sprints, kanban
> and other team tools is rudimentary at best and really not suitable
> for anything more than the basics and is not a patch on the
> functionality and plugin ecosystem that is available in Jira. The
> gitlab functionality there is a toy in comparison.
>

Toys are fun, one of the four Fs for Fedora. I'm not interested in bringing
sprints or kanban to Fedora. I am interested in making it fun for
volunteers :)

- Ken
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220311.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/229 (x86_64), 13/161 (aarch64)

New failures (same test not failed in Fedora-36-20220310.n.0):

ID: 1169479 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1169479
ID: 1169540 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1169540
ID: 1169541 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1169541
ID: 1169575 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1169575
ID: 1169582 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1169582
ID: 1169636 Test: x86_64 universal install_addrepo_metalink_graphical
URL: https://openqa.fedoraproject.org/tests/1169636
ID: 1169742 Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/1169742

Old failures (same test failed in Fedora-36-20220310.n.0):

ID: 1169443 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1169443
ID: 1169466 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1169466
ID: 1169531 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1169531
ID: 1169567 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1169567
ID: 1169573 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1169573
ID: 1169596 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1169596
ID: 1169597 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1169597
ID: 1169610 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1169610
ID: 1169616 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1169616
ID: 1169619 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1169619
ID: 1169650 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1169650
ID: 1169651 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1169651
ID: 1169716 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1169716
ID: 1169724 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1169724

Soft failed openQA tests: 7/229 (x86_64), 2/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-36-20220310.n.0):

ID: 1169428 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1169428
ID: 1169431 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1169431
ID: 1169462 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1169462
ID: 1169481 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1169481
ID: 1169571 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1169571
ID: 1169589 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1169589
ID: 1169615 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1169615

Old soft failures (same test soft failed in Fedora-36-20220310.n.0):

ID: 1169473 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1169473
ID: 1169491 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1169491

Passed openQA tests: 146/161 (aarch64), 214/229 (x86_64)

New passes (same test not passed in Fedora-36-20220310.n.0):

ID: 1169520 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1169520
ID: 1169641 Test: x86_64 universal install_with_swap
URL: https://openqa.fedoraproject.org/tests/1169641
ID: 1169669 Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/1169669

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.03 to 0.14
Previous test data: https://openqa.fedoraproject.org/tests/1167770#downloads
Current test data: https://openqa.fedoraproject.org/tests/1169363#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 12 MiB to 7 MiB
1 packages(s) 

[Bug 2063243] New: perl-Data-MessagePack-1.02 is available

[bugzilla]

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

Bug ID: 2063243
   Summary: perl-Data-MessagePack-1.02 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Data-MessagePack
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: cicku...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.02
Current version/release in rawhide: 1.01-7.fc36
URL: http://search.cpan.org/dist/Data-MessagePack/

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://fedoraproject.org/wiki/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/2768/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2063243
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-36-20220311.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/15 (x86_64), 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220310.0):

ID: 1169928 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1169928
ID: 1169940 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1169940
ID: 1169941 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1169941

Passed openQA tests: 14/15 (aarch64), 13/15 (x86_64)

New passes (same test not passed in Fedora-IoT-36-20220310.0):

ID: 1169943 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1169943
ID: 1169955 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1169955

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.59 to 0.34
Previous test data: https://openqa.fedoraproject.org/tests/1168235#downloads
Current test data: https://openqa.fedoraproject.org/tests/1169942#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2060072] perl-Inline-C-0.82 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Inline-C-0.82-1.fc37   |perl-Inline-C-0.82-1.fc37
   |perl-Inline-C-0.82-1.el8|perl-Inline-C-0.82-1.el8
   |perl-Inline-C-0.82-1.fc34   |perl-Inline-C-0.82-1.fc34
   ||perl-Inline-C-0.82-1.fc35



--- Comment #12 from Fedora Update System  ---
FEDORA-2022-81c67ba011 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2060072
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: undefined symbol `__libc_stack_end' in F36/Rawhide

[Ron Olson]

I tried building on Rawhide for aarch64 and had a similar, but different 
error:


/usr/bin/ld: /tmp/lto-llvm-759ff6.o: relocation 
R_AARCH64_ADR_PREL_PG_HI21 against symbol `signgam@@GLIBC_2.17' which 
may bind externally can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: /tmp/lto-llvm-759ff6.o(.text.__interceptor_lgamma+0x9c): 
unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol 
`signgam@@GLIBC_2.17'

/usr/bin/ld: final link failed: bad value



On 11 Mar 2022, at 5:21, Sérgio Basto wrote:


Hello,

On Thu, 2022-03-10 at 09:36 +0100, Florian Weimer wrote:

* Ron Olson:


Building swiftlang on F36/Rawhide results in a a failure that,
boiled down to its essence, appears to be:

/usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32
against undefined symbol `__libc_stack_end' can not be used when
making a shared object; recompile with -fPIC

It compiles fine on 35 so I’m guessing glibc has been updated; a
bunch of web searching hasn’t come up with any useful suggestions,
the one ancient Bugzilla ticket I found was not resolved.

Any suggestions on what to do about this?


How is __libc_stack_end declared in the sources?  This could be a
Clang
bug or a bug in the source package.


by coincidence rawhide compose doomed since 20220309 (...) , i.e. 
maybe

this is a serious thing and someone need to look what is happening to
rawhide composes



--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Daniel P . Berrangé]

On Fri, Mar 11, 2022 at 02:34:29PM +0100, mkol...@redhat.com wrote:
> On Fri, 2022-03-11 at 08:59 +, Daniel P. Berrangé wrote:
> > On Thu, Mar 10, 2022 at 01:41:15PM -0500, Simo Sorce wrote:
> > > On Thu, 2022-03-10 at 19:28 +0100, Dominik 'Rathann' Mierzejewski
> > > wrote:
> > > > On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote:
> > > > [...]
> > > > > Also I always resented that I need two separate accounts to
> > > > > deal with
> > > > > Fedora packages,
> > > > 
> > > > It's been possible to log in with FAS credentials (automatically
> > > > if you
> > > > have an active Kerberos ticket) into bugzilla for quite some time
> > > > now.
> > > > I still have my old bugzilla account but I'm not sure it's
> > > > required
> > > > anymore.
> > > 
> > > Ah thanks, I missed that change, obviously my experience is now
> > > almost
> > > 2 decades long since I had to create my account, but I still think
> > > that
> > > having bugs and code in the same place is a big win for a project
> > > like
> > > Fedora, it is the same model followed by most upstream projects at
> > > this
> > > point and seem to be working well.
> > 
> > Yes, I find having the issue tracker alongside the code repo is a
> > good
> > thing for usability. For a start you have a list of bugs to browse,
> > visible from a single click. No need to do a search, excluding
> > countless
> > products/projects that are unrelated to Fedora and component you
> > want.
> > Similarly, you get the link to file a new bug directly against the
> > code
> > you're looking at, compared to bugzilla where you must navigate
> > through
> > several pages to even get to selecting Fedora, and then again select
> > the
> > component in the form.
> But what about bugs filled on the wrong component (I maintain both
> initial-setup & firstboot, lets say some users have a different idea
> about what these project names mean) or bugs that are filled on one
> component but turn out to be caused by another one ?
> 
> If all the bugs are effectively attached to a forge ditgit repo, what
> to do you effectively need to take them a attach them to a different
> repo ? Close the old one and open a new one on the correct repo ? If
> so, there should be at least some automation for this.

GitLab at least has a "Move issue" button that lets you move
issues between repositories. Behind the scenes it is essentially
re-creating the issue in the new repo and closing the old
one. 

> Another thing, tracking bugs or bugs/RFEs impacting multiple
> componenets, where to put those ? Wikipa pages like with the change
> process or some empty forge repo perhaps ?

Bugzilla was no good at tracking stuff across components either.
All the cross-component cloning and linking people did turned
into a big mess, which is a large part of why people increasingly
disliked Bugzilla for RHEL.

At least from Fedora's POV, the Feature page acts as a central
point of information linking off to many different places. I
don't know if that's the best answer, but bending a component
level bug tracker to that does is not it, no matter what bug
tracker we choose, because the granularity is a mismatch.


> Also, while searching in Bugzilla can be quite a mess due to everything
> being one one big pile by default, it can also be very useful to search
> for say error messages, stack traces and other similar behavior across
> bugs. It would be good to check if the forge solution also supports
> that natively, not just searching the bugs attached to a project/repo.

GitLab lets you search across multiple repos at the group level


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

[Fabio Valentini]

On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott  wrote:
>
> > On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
> >
> > Why isn't this as simple as:
> >
> > 1) Create an f37-multilib-build build tag with all supported arches + i686,
> > and an f37-multilib{,-candidate} build targets to use it (with destination 
> > tag
> > of f37-updates-candidate);
> >
> > 2) Drop i686 from f37-build tag;
> >
> > 3) Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
> >
> > [koji]
> > targets = f37-multilib
> >
> > (Yes, that would have to be updated after branch point, but that could
> > possibly be automated.)
> >
> > 4) Everyone else leaves their spec files alone, no need to add ExcludeArch:
> > i686.
> >
> > Would that work?
>
> That works ok for rpmfusion.
>
> https://koji.rpmfusion.org/koji/taginfo?tagID=483
>
> fedpkg could be adapted as well, see
>
> https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187

This might work for RPMFusion, but only because you have a limited set
of packages, and because you can rely on the Fedora buildroot and
dependencies always to be there.
For Fedora itself, we do not have that luxury. We would need to know
the packages that are needed to build and maintain the base buildroot
plus everything needed to build multilib packages. As I said, this is
not so easy. And then we're back to modifying (adding config files)
all packages that need to be included (or maintaining a hard-coded
list of required packages in fedpkg), so you don't gain anything at
all, compared to the simple opt-out mechanism from this Proposal.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2060072] perl-Inline-C-0.82 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Inline-C-0.82-1.fc37   |perl-Inline-C-0.82-1.fc37
   |perl-Inline-C-0.82-1.el8|perl-Inline-C-0.82-1.el8
   ||perl-Inline-C-0.82-1.fc34



--- Comment #11 from Fedora Update System  ---
FEDORA-2022-2ba3793d42 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2060072
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Peter Robinson]

> On Thu, Mar 10, 2022 at 9:45 AM Colin Walters  wrote:
> > Long term if Bugzilla slowly morphs into only being used by Fedora,
> > personally I'd prefer to have bugs/issues in gitlab instead.
>
> Yes, I personally think gitlab.com would be a good replacement for
> src.fedoraproject.org and bugzilla.redhat.com.

I disagree as the interface for agile development like sprints, kanban
and other team tools is rudimentary at best and really not suitable
for anything more than the basics and is not a patch on the
functionality and plugin ecosystem that is available in Jira. The
gitlab functionality there is a toy in comparison.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2005973] perl-Crypt-OpenSSL-PKCS10: FTBFS with OpenSSL 3.0 .0 in Fedora Rawhide

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-f1728ecc63 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f1728ecc63


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2005973
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unretiring Icedtea-web

[Richard W.M. Jones]

On Thu, Mar 10, 2022 at 09:25:36AM -0500, Steve Cossette wrote:
> Le jeu. 10 mars 2022, à 09 h 24, Fabio Valentini  a
> écrit :
> > "Deployment tools have been deprecated for a while now"
> Ah, didn't see that on the page. Thanks!

I've occasionally used icedtea-web to run Java applets as local
applications.  There aren't too many of them today, but I guess they
still exist.  Do you or anyone know what might have replaced
icedtea-web?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2042867] Please branch and build perl-Data-Compare for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Data-Compare-1.27-1.el
   ||9
 Status|ON_QA   |CLOSED
Last Closed||2022-03-11 13:43:13



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-cf1a4cc94c has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2042867
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2005973] perl-Crypt-OpenSSL-PKCS10: FTBFS with OpenSSL 3.0 .0 in Fedora Rawhide

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Crypt-OpenSSL-PKCS10-0
   ||.16-20.fc37
Link ID||CPAN 141722
   Assignee|wjhns...@hardakers.net  |ppi...@redhat.com
 Status|NEW |MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2005973
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2060072] perl-Inline-C-0.82 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Inline-C-0.82-1.fc37   |perl-Inline-C-0.82-1.fc37
   ||perl-Inline-C-0.82-1.el8
Last Closed||2022-03-11 13:33:50



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2022-0dc2e14956 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2060072
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[mkolman]

On Fri, 2022-03-11 at 08:59 +, Daniel P. Berrangé wrote:
> On Thu, Mar 10, 2022 at 01:41:15PM -0500, Simo Sorce wrote:
> > On Thu, 2022-03-10 at 19:28 +0100, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote:
> > > [...]
> > > > Also I always resented that I need two separate accounts to
> > > > deal with
> > > > Fedora packages,
> > > 
> > > It's been possible to log in with FAS credentials (automatically
> > > if you
> > > have an active Kerberos ticket) into bugzilla for quite some time
> > > now.
> > > I still have my old bugzilla account but I'm not sure it's
> > > required
> > > anymore.
> > 
> > Ah thanks, I missed that change, obviously my experience is now
> > almost
> > 2 decades long since I had to create my account, but I still think
> > that
> > having bugs and code in the same place is a big win for a project
> > like
> > Fedora, it is the same model followed by most upstream projects at
> > this
> > point and seem to be working well.
> 
> Yes, I find having the issue tracker alongside the code repo is a
> good
> thing for usability. For a start you have a list of bugs to browse,
> visible from a single click. No need to do a search, excluding
> countless
> products/projects that are unrelated to Fedora and component you
> want.
> Similarly, you get the link to file a new bug directly against the
> code
> you're looking at, compared to bugzilla where you must navigate
> through
> several pages to even get to selecting Fedora, and then again select
> the
> component in the form.
But what about bugs filled on the wrong component (I maintain both
initial-setup & firstboot, lets say some users have a different idea
about what these project names mean) or bugs that are filled on one
component but turn out to be caused by another one ?

If all the bugs are effectively attached to a forge ditgit repo, what
to do you effectively need to take them a attach them to a different
repo ? Close the old one and open a new one on the correct repo ? If
so, there should be at least some automation for this.

Another thing, tracking bugs or bugs/RFEs impacting multiple
componenets, where to put those ? Wikipa pages like with the change
process or some empty forge repo perhaps ?

Also, while searching in Bugzilla can be quite a mess due to everything
being one one big pile by default, it can also be very useful to search
for say error messages, stack traces and other similar behavior across
bugs. It would be good to check if the forge solution also supports
that natively, not just searching the bugs attached to a project/repo.


> 
> The Red Hat Jira instance mentioned earlier is just as bad as
> Bugzilla
> in this respect, actually probably worse. It wants to show you all
> bugs
> in the system straight away, until you type in the right search query
> terms to restrict it down to a particular product and component you
> are actually looking for bugs in.
> 
> With regards,
> Daniel
> -- 
> > : https://berrange.com  -o-   
> > https://www.flickr.com/photos/dberrange :|
> > : https://libvirt.org -o-   
> > https://fstop138.berrange.com :|
> > : https://entangle-photo.org    -o-   
> > https://www.instagram.com/dberrange :|
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 compose report: 20220311.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220310.n.0
NEW: Fedora-36-20220311.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

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

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

= ADDED IMAGES =
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-36-20220311.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: undefined symbol `__libc_stack_end' in F36/Rawhide

[Sérgio Basto]

Hello,

On Thu, 2022-03-10 at 09:36 +0100, Florian Weimer wrote:
> * Ron Olson:
> 
> > Building swiftlang on F36/Rawhide results in a a failure that,
> > boiled down to its essence, appears to be:
> > 
> > /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32
> > against undefined symbol `__libc_stack_end' can not be used when
> > making a shared object; recompile with -fPIC
> > 
> > It compiles fine on 35 so I’m guessing glibc has been updated; a
> > bunch of web searching hasn’t come up with any useful suggestions,
> > the one ancient Bugzilla ticket I found was not resolved.
> > 
> > Any suggestions on what to do about this?
> 
> How is __libc_stack_end declared in the sources?  This could be a
> Clang
> bug or a bug in the source package.

by coincidence rawhide compose doomed since 20220309 (...) , i.e. maybe
this is a serious thing and someone need to look what is happening to
rawhide composes 



-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220311.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220310.0):

ID: 1169352 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1169352
ID: 1169358 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1169358

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Florian Weimer]

* Josh Boyer:

> As part of our continued 3 year major Red Hat Enterprise Linux release
> cadence, RHEL 9 development is starting to wrap up with the spring
> 2022 release coming soon.  That means planning for the next release
> will start in earnest in the very near future.  As some of you may
> know, Red Hat has been using both Bugzilla and Jira via
> issues.redhat.com for RHEL development for several years.  Our
> intention is to move to using issues.redhat.com only for the major
> RHEL releases after RHEL 9.

Thanks for posting this publicly.

> - Fedora Linux and EPEL have their own Bugzilla product families and
> are not directly impacted in their own workflows by the choice to use
> only issues.redhat.com for RHEL.
> - There will be impacts on existing documentation that provide
> guidance on requesting things from RHEL in various places like EPEL.
> We will be happy to help adjust these.

There is already an “FC” project on issues.redhat.com, into which Fedora
bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
mirror+ Bugzilla flag publicly, and make the FC project public, so that
people can experiment with that?

> If there are other impacts that you can think of, please raise them on
> this thread.  We’d like to ensure we’re covering as much as possible
> as this rolls out.

What is going to happen to the CentOS Mantis instance
?  From the looks of it, it probably should
just be switched off?

Thanks,
Florian
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Florian Weimer]

* Josh Boyer:

> As part of our continued 3 year major Red Hat Enterprise Linux release
> cadence, RHEL 9 development is starting to wrap up with the spring
> 2022 release coming soon.  That means planning for the next release
> will start in earnest in the very near future.  As some of you may
> know, Red Hat has been using both Bugzilla and Jira via
> issues.redhat.com for RHEL development for several years.  Our
> intention is to move to using issues.redhat.com only for the major
> RHEL releases after RHEL 9.

Thanks for posting this publicly.

> - Fedora Linux and EPEL have their own Bugzilla product families and
> are not directly impacted in their own workflows by the choice to use
> only issues.redhat.com for RHEL.
> - There will be impacts on existing documentation that provide
> guidance on requesting things from RHEL in various places like EPEL.
> We will be happy to help adjust these.

There is already an “FC” project on issues.redhat.com, into which Fedora
bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
mirror+ Bugzilla flag publicly, and make the FC project public, so that
people can experiment with that?

> If there are other impacts that you can think of, please raise them on
> this thread.  We’d like to ensure we’re covering as much as possible
> as this rolls out.

What is going to happen to the CentOS Mantis instance
?  From the looks of it, it probably should
just be switched off?

Thanks,
Florian
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Richard W.M. Jones]

On Fri, Mar 11, 2022 at 10:57:29AM +0100, Miro Hrončok wrote:
> On 11. 03. 22 10:36, Richard W.M. Jones wrote:
> >On Fri, Mar 04, 2022 at 11:14:31AM +, Richard W.M. Jones wrote:
> >>On Fri, Mar 04, 2022 at 11:01:20AM +, Richard W.M. Jones wrote:
> >>>On Fri, Mar 04, 2022 at 10:51:48AM +, Richard W.M. Jones wrote:
> I'll see if we can move the OCaml packages to CRB.  It seems to be the
> easiest way to fix the original coccinelle build problem.
> >>>
> >>>This gets odder.  I see from our internal spreadsheet and downloads
> >>>that some of the ocaml packages are in fact already in CRB for RHEL
> >>>9.0, and others are not.  We previously requested that all ocaml-*
> >>>packages be added to CRB.
> >>>
> >>>Binary packages which are not in CRB but should be:
> >>>
> >>>ocaml-calendar*
> >>>ocaml-camomile*
> >>>ocaml-csexp*
> >>>ocaml-csv*
> >>>ocaml-curses*
> >>>ocaml-dune*
> >>>ocaml-fileutils*
> >>>ocaml-gettext*
> >>>ocaml-libvirt*
> >>>ocaml-source
> >>>ocaml-xml-light*
> >>>
> >>>Do you need a BZ opened to move these packages to CRB?
> >>
> >>https://bugzilla.redhat.com/show_bug.cgi?id=2060850
> >
> >Currently even with this bug fixed we won't be able to build
> >Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
> >This (if true) is ridiculous.  Is there some other solution?
> 
> Given that EPEL 9 now builds against CentOS Stream, this is not necessarily 
> true.
> 
> The other solution would have been to include the packages in CRB sooner :D

I've surely learned a lesson never to use RHEL buildroot for anything.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2063099] F36FailsToInstall: perl-Crypt-PWSafe3

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-e541fc8d0d has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e541fc8d0d


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2063099
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Miro Hrončok]

On 11. 03. 22 10:36, Richard W.M. Jones wrote:

On Fri, Mar 04, 2022 at 11:14:31AM +, Richard W.M. Jones wrote:

On Fri, Mar 04, 2022 at 11:01:20AM +, Richard W.M. Jones wrote:

On Fri, Mar 04, 2022 at 10:51:48AM +, Richard W.M. Jones wrote:

I'll see if we can move the OCaml packages to CRB.  It seems to be the
easiest way to fix the original coccinelle build problem.


This gets odder.  I see from our internal spreadsheet and downloads
that some of the ocaml packages are in fact already in CRB for RHEL
9.0, and others are not.  We previously requested that all ocaml-*
packages be added to CRB.

Binary packages which are not in CRB but should be:

ocaml-calendar*
ocaml-camomile*
ocaml-csexp*
ocaml-csv*
ocaml-curses*
ocaml-dune*
ocaml-fileutils*
ocaml-gettext*
ocaml-libvirt*
ocaml-source
ocaml-xml-light*

Do you need a BZ opened to move these packages to CRB?


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


Currently even with this bug fixed we won't be able to build
Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
This (if true) is ridiculous.  Is there some other solution?


Given that EPEL 9 now builds against CentOS Stream, this is not necessarily 
true.

The other solution would have been to include the packages in CRB sooner :D

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2063099] New: F36FailsToInstall: perl-Crypt-PWSafe3

[bugzilla]

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

Bug ID: 2063099
   Summary: F36FailsToInstall: perl-Crypt-PWSafe3
   Product: Fedora
   Version: 36
Status: NEW
 Component: perl-Crypt-PWSafe3
  Assignee: c...@fea.st
  Reporter: mhron...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: c...@fea.st, mkre...@gmail.com,
perl-devel@lists.fedoraproject.org
Blocks: 1992487 (F36FailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically. If you feel that
this output has mistakes, please contact me via email (mhron...@redhat.com).

Your package (perl-Crypt-PWSafe3) Fails To Install in Fedora 36:

can't install perl-Crypt-PWSafe3:
  - nothing provides perl(:MODULE_COMPAT_5.32.1) needed by
perl-Crypt-PWSafe3-1.22-17.fc34.noarch

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-36-x86_64 --disablerepo='*' --enablerepo=local install
perl-Crypt-PWSafe3


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1992487
[Bug 1992487] Fedora 36 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2063099
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Richard W.M. Jones]

On Fri, Mar 04, 2022 at 11:14:31AM +, Richard W.M. Jones wrote:
> On Fri, Mar 04, 2022 at 11:01:20AM +, Richard W.M. Jones wrote:
> > On Fri, Mar 04, 2022 at 10:51:48AM +, Richard W.M. Jones wrote:
> > > I'll see if we can move the OCaml packages to CRB.  It seems to be the
> > > easiest way to fix the original coccinelle build problem.
> > 
> > This gets odder.  I see from our internal spreadsheet and downloads
> > that some of the ocaml packages are in fact already in CRB for RHEL
> > 9.0, and others are not.  We previously requested that all ocaml-*
> > packages be added to CRB.
> > 
> > Binary packages which are not in CRB but should be:
> > 
> > ocaml-calendar*
> > ocaml-camomile*
> > ocaml-csexp*
> > ocaml-csv*
> > ocaml-curses*
> > ocaml-dune*
> > ocaml-fileutils*
> > ocaml-gettext*
> > ocaml-libvirt*
> > ocaml-source
> > ocaml-xml-light*
> > 
> > Do you need a BZ opened to move these packages to CRB?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2060850

Currently even with this bug fixed we won't be able to build
Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
This (if true) is ridiculous.  Is there some other solution?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

[Dan Horák]

On Fri, 11 Mar 2022 01:24:58 -0800
Luya Tshimbalanga  wrote:

> Hello team,
> 
> I encountered a weird error[0] when building blender[1] with upstream 
> patch[2] for USD support:
> 
> ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

looks like something is wrong with USD library detection

...
-- Found USD: /usr/lib64  
...

^^^ this should be a file (like /usr/lib64/libUSD.so)


Dan
 
> Can someone investigate the problem? I included the patch for testing 
> purpose.
> 
> Reference:
> 
> [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=84003450
> 
> [1] https://src.fedoraproject.org/rpms/blender/blob/rawhide/f/blender.spec
> 
> [2] https://developer.blender.org/D14184
> 
> 
> Thanks in advance.
> 
> -- 
> 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

[Luya Tshimbalanga]

Hello team,

I encountered a weird error[0] when building blender[1] with upstream 
patch[2] for USD support:


ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

Can someone investigate the problem? I included the patch for testing 
purpose.


Reference:

[0] https://koji.fedoraproject.org/koji/taskinfo?taskID=84003450

[1] https://src.fedoraproject.org/rpms/blender/blob/rawhide/f/blender.spec

[2] https://developer.blender.org/D14184


Thanks in advance.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
diff --git a/source/blender/io/usd/intern/usd_reader_light.cc b/source/blender/io/usd/intern/usd_reader_light.cc
--- a/source/blender/io/usd/intern/usd_reader_light.cc
+++ b/source/blender/io/usd/intern/usd_reader_light.cc
@@ -9,8 +9,6 @@
 #include "DNA_light_types.h"
 #include "DNA_object_types.h"
 
-#include 
-
 #include 
 #include 
 #include 
@@ -40,14 +38,17 @@
   if (!prim_) {
 return;
   }
+#if PXR_VERSION >= 2111
+  pxr::UsdLuxLightAPI light_api(prim_);
+#else
+  pxr::UsdLuxLight light_api(prim_);
+#endif
 
-  pxr::UsdLuxLight light_prim(prim_);
-
-  if (!light_prim) {
+  if (!light_api) {
 return;
   }
 
-  pxr::UsdLuxShapingAPI shaping_api(light_prim);
+  pxr::UsdLuxShapingAPI shaping_api;
 
   /* Set light type. */
 
@@ -63,6 +64,8 @@
   else if (prim_.IsA()) {
 blight->type = LA_LOCAL;
 
+shaping_api = pxr::UsdLuxShapingAPI(prim_);
+
 if (shaping_api && shaping_api.GetShapingConeAngleAttr().IsAuthored()) {
   blight->type = LA_SPOT;
 }
@@ -73,7 +76,7 @@
 
   /* Set light values. */
 
-  if (pxr::UsdAttribute intensity_attr = light_prim.GetIntensityAttr()) {
+  if (pxr::UsdAttribute intensity_attr = light_api.GetIntensityAttr()) {
 float intensity = 0.0f;
 if (intensity_attr.Get(, motionSampleTime)) {
   blight->energy = intensity * this->import_params_.light_intensity_scale;
@@ -92,14 +95,14 @@
   light_prim.GetDiffuseAttr().Get(, motionSampleTime);
 #endif
 
-  if (pxr::UsdAttribute spec_attr = light_prim.GetSpecularAttr()) {
+  if (pxr::UsdAttribute spec_attr = light_api.GetSpecularAttr()) {
 float spec = 0.0f;
 if (spec_attr.Get(, motionSampleTime)) {
   blight->spec_fac = spec;
 }
   }
 
-  if (pxr::UsdAttribute color_attr = light_prim.GetColorAttr()) {
+  if (pxr::UsdAttribute color_attr = light_api.GetColorAttr()) {
 pxr::GfVec3f color;
 if (color_attr.Get(, motionSampleTime)) {
   blight->r = color[0];
diff --git a/source/blender/io/usd/intern/usd_reader_stage.cc b/source/blender/io/usd/intern/usd_reader_stage.cc
--- a/source/blender/io/usd/intern/usd_reader_stage.cc
+++ b/source/blender/io/usd/intern/usd_reader_stage.cc
@@ -18,7 +18,13 @@
 #include 
 #include 
 #include 
-#include 
+
+#if PXR_VERSION >= 2111
+#  include 
+#  include 
+#else
+#  include 
+#endif
 
 #include 
 
@@ -55,7 +61,12 @@
   if (params_.import_meshes && prim.IsA()) {
 return new USDMeshReader(prim, params_, settings_);
   }
+#if PXR_VERSION >= 2111
+  if (params_.import_lights && (prim.IsA() ||
+prim.IsA())) {
+#else
   if (params_.import_lights && prim.IsA()) {
+#endif
 return new USDLightReader(prim, params_, settings_);
   }
   if (params_.import_volumes && prim.IsA()) {
@@ -82,7 +93,11 @@
   if (prim.IsA()) {
 return new USDMeshReader(prim, params_, settings_);
   }
+#if PXR_VERSION >= 2111
+  if (prim.IsA() || prim.IsA()) {
+#else
   if (prim.IsA()) {
+#endif
 return new USDLightReader(prim, params_, settings_);
   }
   if (prim.IsA()) {
diff --git a/source/blender/io/usd/intern/usd_reader_xform.cc b/source/blender/io/usd/intern/usd_reader_xform.cc
--- a/source/blender/io/usd/intern/usd_reader_xform.cc
+++ b/source/blender/io/usd/intern/usd_reader_xform.cc
@@ -131,7 +131,7 @@
 return false;
   }
 
-  if (prim_.IsInMaster()) {
+  if (prim_.IsInPrototype()) {
 /* We don't consider prototypes to be root prims,
  * because we never want to apply global scaling
  * or rotations to the prototypes themselves. */
diff --git a/source/blender/io/usd/intern/usd_writer_light.cc b/source/blender/io/usd/intern/usd_writer_light.cc
--- a/source/blender/io/usd/intern/usd_writer_light.cc
+++ b/source/blender/io/usd/intern/usd_writer_light.cc
@@ -33,7 +33,12 @@
   pxr::UsdTimeCode timecode = get_export_time_code();
 
   Light *light = static_cast(context.object->data);
-  pxr::UsdLuxLight usd_light;
+#if PXR_VERSION >= 2111
+  pxr::UsdLuxLightAPI usd_light_api;
+#else
+  pxr::UsdLuxLight usd_light_api;
+
+#endif
 
   switch (light->type) {
 case LA_AREA:
@@ -42,21 +47,33 @@
 case LA_AREA_ELLIPSE: { /* An ellipse light will deteriorate into a disk light. */
   pxr::UsdLuxDiskLight disk_light = pxr::UsdLuxDiskLight::Define(stage, usd_path);
   disk_light.CreateRadiusAttr().Set(light->area_size, timecode);
-  usd_light = disk_light;
+#if PXR_VERSION >= 2111
+  usd_light_api = disk_light.LightAPI();
+#else
+  

ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

[Luya Tshimbalanga]

Hello team,

I encountered a weird error when building blender[1] with upstream 
patch[2] for USD support:


ld.gold: fatal error: /usr/lib64: pread failed: Is a directory

Can someone investigate the problem? I included the patch for testing 
purpose.


Reference:

[1] https://src.fedoraproject.org/rpms/blender/blob/rawhide/f/blender.spec

[2] https://developer.blender.org/D14184


Thanks in advance.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
diff --git a/source/blender/io/usd/intern/usd_reader_light.cc b/source/blender/io/usd/intern/usd_reader_light.cc
--- a/source/blender/io/usd/intern/usd_reader_light.cc
+++ b/source/blender/io/usd/intern/usd_reader_light.cc
@@ -9,8 +9,6 @@
 #include "DNA_light_types.h"
 #include "DNA_object_types.h"
 
-#include 
-
 #include 
 #include 
 #include 
@@ -40,14 +38,17 @@
   if (!prim_) {
 return;
   }
+#if PXR_VERSION >= 2111
+  pxr::UsdLuxLightAPI light_api(prim_);
+#else
+  pxr::UsdLuxLight light_api(prim_);
+#endif
 
-  pxr::UsdLuxLight light_prim(prim_);
-
-  if (!light_prim) {
+  if (!light_api) {
 return;
   }
 
-  pxr::UsdLuxShapingAPI shaping_api(light_prim);
+  pxr::UsdLuxShapingAPI shaping_api;
 
   /* Set light type. */
 
@@ -63,6 +64,8 @@
   else if (prim_.IsA()) {
 blight->type = LA_LOCAL;
 
+shaping_api = pxr::UsdLuxShapingAPI(prim_);
+
 if (shaping_api && shaping_api.GetShapingConeAngleAttr().IsAuthored()) {
   blight->type = LA_SPOT;
 }
@@ -73,7 +76,7 @@
 
   /* Set light values. */
 
-  if (pxr::UsdAttribute intensity_attr = light_prim.GetIntensityAttr()) {
+  if (pxr::UsdAttribute intensity_attr = light_api.GetIntensityAttr()) {
 float intensity = 0.0f;
 if (intensity_attr.Get(, motionSampleTime)) {
   blight->energy = intensity * this->import_params_.light_intensity_scale;
@@ -92,14 +95,14 @@
   light_prim.GetDiffuseAttr().Get(, motionSampleTime);
 #endif
 
-  if (pxr::UsdAttribute spec_attr = light_prim.GetSpecularAttr()) {
+  if (pxr::UsdAttribute spec_attr = light_api.GetSpecularAttr()) {
 float spec = 0.0f;
 if (spec_attr.Get(, motionSampleTime)) {
   blight->spec_fac = spec;
 }
   }
 
-  if (pxr::UsdAttribute color_attr = light_prim.GetColorAttr()) {
+  if (pxr::UsdAttribute color_attr = light_api.GetColorAttr()) {
 pxr::GfVec3f color;
 if (color_attr.Get(, motionSampleTime)) {
   blight->r = color[0];
diff --git a/source/blender/io/usd/intern/usd_reader_stage.cc b/source/blender/io/usd/intern/usd_reader_stage.cc
--- a/source/blender/io/usd/intern/usd_reader_stage.cc
+++ b/source/blender/io/usd/intern/usd_reader_stage.cc
@@ -18,7 +18,13 @@
 #include 
 #include 
 #include 
-#include 
+
+#if PXR_VERSION >= 2111
+#  include 
+#  include 
+#else
+#  include 
+#endif
 
 #include 
 
@@ -55,7 +61,12 @@
   if (params_.import_meshes && prim.IsA()) {
 return new USDMeshReader(prim, params_, settings_);
   }
+#if PXR_VERSION >= 2111
+  if (params_.import_lights && (prim.IsA() ||
+prim.IsA())) {
+#else
   if (params_.import_lights && prim.IsA()) {
+#endif
 return new USDLightReader(prim, params_, settings_);
   }
   if (params_.import_volumes && prim.IsA()) {
@@ -82,7 +93,11 @@
   if (prim.IsA()) {
 return new USDMeshReader(prim, params_, settings_);
   }
+#if PXR_VERSION >= 2111
+  if (prim.IsA() || prim.IsA()) {
+#else
   if (prim.IsA()) {
+#endif
 return new USDLightReader(prim, params_, settings_);
   }
   if (prim.IsA()) {
diff --git a/source/blender/io/usd/intern/usd_reader_xform.cc b/source/blender/io/usd/intern/usd_reader_xform.cc
--- a/source/blender/io/usd/intern/usd_reader_xform.cc
+++ b/source/blender/io/usd/intern/usd_reader_xform.cc
@@ -131,7 +131,7 @@
 return false;
   }
 
-  if (prim_.IsInMaster()) {
+  if (prim_.IsInPrototype()) {
 /* We don't consider prototypes to be root prims,
  * because we never want to apply global scaling
  * or rotations to the prototypes themselves. */
diff --git a/source/blender/io/usd/intern/usd_writer_light.cc b/source/blender/io/usd/intern/usd_writer_light.cc
--- a/source/blender/io/usd/intern/usd_writer_light.cc
+++ b/source/blender/io/usd/intern/usd_writer_light.cc
@@ -33,7 +33,12 @@
   pxr::UsdTimeCode timecode = get_export_time_code();
 
   Light *light = static_cast(context.object->data);
-  pxr::UsdLuxLight usd_light;
+#if PXR_VERSION >= 2111
+  pxr::UsdLuxLightAPI usd_light_api;
+#else
+  pxr::UsdLuxLight usd_light_api;
+
+#endif
 
   switch (light->type) {
 case LA_AREA:
@@ -42,21 +47,33 @@
 case LA_AREA_ELLIPSE: { /* An ellipse light will deteriorate into a disk light. */
   pxr::UsdLuxDiskLight disk_light = pxr::UsdLuxDiskLight::Define(stage, usd_path);
   disk_light.CreateRadiusAttr().Set(light->area_size, timecode);
-  usd_light = disk_light;
+#if PXR_VERSION >= 2111
+  usd_light_api = disk_light.LightAPI();
+#else
+  usd_light_api = disk_light;
+#endif
   break;
 }
 

Re: Upcoming tesseract and proj updates with soname bumps

[Sandro Mani]

On 09.03.22 21:50, Sandro Mani wrote:



On 03.03.22 11:29, Sandro Mani wrote:

Hi

I'm planing on landing tesseract-5.1.0 and proj-9.0.0 in rawhide and 
F36 in the coming days. I'm doing a test run in these COPR repos:


tesseract: https://copr.fedorainfracloud.org/coprs/smani/tesseract5/ 
(all builds already complete)
proj: https://copr.fedorainfracloud.org/coprs/smani/proj9/ (starting 
now)


Once done there, I plan to move ahead building all of these in a 
side-tag for F37 and then F36. Probably some time this weekend to 
beginning of next week.


It took me a while to hunt down a python-cartopy test failure [1], 
I'll now proceed with the builds in the side-tag f37-build-side-51749. 
I won't be pushing this to F36. I'll be building the following packages:


tesseract-5.1.0
proj-9.0.0

and then rebuilding the following dependencies:


[...]

This is now done and the side-tag has been submitted.

Sandro___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Daniel P . Berrangé]

On Thu, Mar 10, 2022 at 01:41:15PM -0500, Simo Sorce wrote:
> On Thu, 2022-03-10 at 19:28 +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote:
> > [...]
> > > Also I always resented that I need two separate accounts to deal with
> > > Fedora packages,
> > 
> > It's been possible to log in with FAS credentials (automatically if you
> > have an active Kerberos ticket) into bugzilla for quite some time now.
> > I still have my old bugzilla account but I'm not sure it's required
> > anymore.
> 
> Ah thanks, I missed that change, obviously my experience is now almost
> 2 decades long since I had to create my account, but I still think that
> having bugs and code in the same place is a big win for a project like
> Fedora, it is the same model followed by most upstream projects at this
> point and seem to be working well.

Yes, I find having the issue tracker alongside the code repo is a good
thing for usability. For a start you have a list of bugs to browse,
visible from a single click. No need to do a search, excluding countless
products/projects that are unrelated to Fedora and component you want.
Similarly, you get the link to file a new bug directly against the code
you're looking at, compared to bugzilla where you must navigate through
several pages to even get to selecting Fedora, and then again select the
component in the form.

The Red Hat Jira instance mentioned earlier is just as bad as Bugzilla
in this respect, actually probably worse. It wants to show you all bugs
in the system straight away, until you type in the right search query
terms to restrict it down to a particular product and component you
are actually looking for bugs in.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220311.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220310.0):

ID: 1169336 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1169336
ID: 1169342 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1169342

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Petr Pisar]

V Thu, Mar 10, 2022 at 12:35:32PM -0500, Matthew Miller napsal(a):
> On Thu, Mar 10, 2022 at 11:55:39AM +0100, Alex wrote:
> > I have seen in https://lwn.net/Articles/887313/ that you plan to remove the
> > "telnet" protocol from curl-minimal.
> > I use `curl -v telnet://` almost every day for debugging purpose just
> > because curl is in the most systems by default installed.
> > I know that there are some other tools like socat, normal telnet, nmap and 
> > so
> > on but this tools need to be installed which is not always possible when
> > fedora is used as docker image.
> 
> Or use bash?
> 
> $ exec 3<>/dev/tcp/towel.blinkenlights.nl/23
> $ cat <&3
> 
That misses the point that telnet is a protocol which e.g. prescribes how to
encode an end of line. Specifically this feature mismatches with the shell
environement we speak about. And because telnet is an underlying layer of
many protocols like SMTP, or HTTP, your recommendation will break any
debugging of them.

-- 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Daniel P . Berrangé]

On Thu, Mar 10, 2022 at 07:07:09PM -0500, Nico Kadel-Garcia wrote:
> On Thu, Mar 10, 2022 at 6:41 AM Paul Howarth  wrote:
> >
> > On Thu, 10 Mar 2022 12:26:54 +0100
> > Vitaly Zaitsev via devel  wrote:
> >
> > > On 10/03/2022 11:55, Alex wrote:
> > > > May I suggest to leave at least the telnet protocol in curl-minimal
> > > > for debugging purposes.
> > >
> > > Telnet is an extremely vulnerable protocol. It must be disable.
> > >
> > > If you need it, you can always install libcurl-full.
> >
> > I wonder, do you have the "telnet" program installed on your machine(s)?
> 
> "netcat" or "nc" is a much better, more scriptable tool than telnet.

Actually they're not because there are several different implementations
of these tools that don't all have the same command line arguments syntax
and behaviour. For scripting, pick  socat every time.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure