Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Jonathan Bennett via devel]

Hey folks, outside observer, and long-time Fedora user weighing in with 
some thoughts. First off, I've been hyped to see Fedora lead the way 
with finally making a real move to Wayland, and retire X11. And now I'm 
fairly disappointed to hear that there's a real chance that move will 
get killed. And especially that it's not because of a technical problem 
or blocker bug.


It really seems like KDE-x11 would do better to live in a copr, with 
whatever packages needs rebuilt to make it work. Probably a better 
experience for everyone.


The proposal was to go to KDE 6 and drop X11 support. " KDE Plasma will 
not offer an X11 session" That change was approved by FESCo. And from my 
perspective running Fedora  Rawhide and KDE 6, it looks great. We even 
have HDR working! That's amazing! So let's go all in.



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

Re: Failure on fedora default backgrounds

[Neal Gompa]

On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA  wrote:
>
> Luya Tshimbalanga wrote on 2024/02/02 10:25:
> > Hello team,
> >
> > It appears a change within %{_kde4_datadir} macro caused failures on 
> > Rawhide affecting default Fedora backgrounds starting from 21.
> > Could someone from KDE SIG address that issue? Thanks.
> >
> >
> > Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:
> >
> > 
> >
> > RPM build errors:
> > error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> >  File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > Child return code was: 1
> > '''
> >
> > Reference:
> > [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
> >
>
> I am not KDE sig member, but the above failure is most likely due to
> the following change:
>
> https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
>
> /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
> definition)
> was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
>

Yes, just add "BuildRequires: kde4-filesystem".



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262363] New: perl-DateTime-TimeZone-2.62 is available

[bugzilla]

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

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



Releases retrieved: 2.62
Upstream release that is considered latest: 2.62
Current version/release in rawhide: 2.61-3.fc40
URL: http://metacpan.org/dist/DateTime-TimeZone/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262363%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3a29f0d349   
python-paramiko-2.12.0-2.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-11fae9c7fb   
python-aiohttp-3.7.4-2.el8


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

baresip-3.9.0-1.el8
boxed-cpp-1.2.2-1.el8
clifm-1.16-1.el8
cpp-jwt-1.4-6.el8
libre-3.9.0-1.el8
python-colcon-alias-0.1.0-1.el8
python-colcon-rerun-0.1.1-1.el8
root-6.30.04-1.el8

Details about builds:



 baresip-3.9.0-1.el8 (FEDORA-EPEL-2024-0eafe9d043)
 Modular SIP user-agent with audio and video support

Update Information:

# Baresip v3.9.0 (2024-01-31)   - menu autoanswer handling   - aureceiver: fix
overflow multiplications   - aur: entirely use `mbuf` in `aurecv_debug()`   -
test: call - add `AUDIO_MODE_THREAD` to `test_call_aufilt`   - cmake: add only
non-system link paths to rpath   - Renamed gzrtp `ARRAY_SIZE` macro   -
avcapture: fix deprecated `AVCaptureDeviceTypeExternalUnknown`   - aur: fix
uninitialized warning in auplay handler   - magic: use `assert()` instead of
`BREAKPOINT`   - sipsess: refactor and simplify SDP negotiation state   - aur:
set audio format correctly   - misc: bump year   - video: use `viddec_packet`
- audio: solve concurrency failures of TX thread   - aur: a mutex for `aubuf`
allocation   - call: remove unused error handling of some API functions   -
menu: an incoming call should not change the current call   - misc: `HAVE_INET6`
is always defined   - mqtt: improve disconnect reconnect handling   - misc: rx
thread activate   - cmake: refactor module detection   - ua: improve SIP 404
warning   - call: fix race condition for `call_set_video_dir()`   - message:
allow `SIP MESSAGE` with `application/json` ctype   - account/debug: fix wrong
and redundant `rtcp_mux` `printf`   - mk: bump version to 3.9.0   # libre v3.9.0
(2024-01-31)   - http: fix doxygen   - types: remove old `ARRAY_SIZE macro`   -
cmake: bump minimum to version 3.14   - test: use `re_is_aligned()`   - sipsess:
refactor and simplify SDP negotiation state   - bump year   - cmake,pc: fix
static library build   - rx thread activate   - test: fix cppcheck warnings   -
test: move `test_rtcp_decode_badmsg()` to separate testcase   - rtp: lock more
fields from `rtcp_sess`   - rtp: lock `rtcp_set_srate()`   - test: HAVE_INET6 is
always defined   - ci: add run-on-arch for ARM64 linux   - httpauth: digest
verification RFC 7616   - tmr: prevent race condition on cancel   - aubuf: fix
coverity defect   - btrace: fix coverity warning   - ci/win: downgrade openssl
- docs: update `README`   - http: client - set scopeid fixes HTTP requests for
IPv6ll   - rtp: add `rtp_source_` prefix to RTP source api   - rtp: make `struct
rtp_source` public   - rtp: sess - fix coverity warning   - mk: bump version to
3.9.0

ChangeLog:

* Thu Feb  1 2024 Robert Scheck  3.9.0-1
- Upgrade to 3.9.0 (#2262187)
* Tue Jan 23 2024 Fedora Release Engineering  - 
3.8.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
3.8.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

References:

  [ 1 ] Bug #2262187 - baresip-3.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262187
  [ 2 ] Bug #2262287 - libre-3.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262287




 boxed-cpp-1.2.2-1.el8 (FEDORA-EPEL-2024-8877a6a9d3)
 Boxing primitive types in C++

Update Information:

Automatic update for boxed-cpp-1.2.2-1.el8.  # **Changelog for boxed-cpp**
``` * Thu Feb 01 2024 Packit  - 1.2.2-1 - [packit] 1.2.2
upstream release - Resolves rhbz#2262188  ```

ChangeLog:

* Thu Feb  1 2024 Packit  - 1.2.2-1
- [packit] 1.2.2 upstream release
- Resolves rhbz#2262188

References:

  [ 1 ] Bug #2262188 - boxed-cpp-1.2.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262188




 clifm-1.16-1.el8 (FEDORA-EPEL-2024-42558a87a4)
 Shell-like, command line terminal file manager

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-54270ec4b3   
clojure-1.8.0-2.el7


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

baresip-3.9.0-1.el7
libre-3.9.0-1.el7
python-colcon-alias-0.1.0-1.el7
python-colcon-rerun-0.1.1-1.el7
wordpress-5.1.18-1.el7

Details about builds:



 baresip-3.9.0-1.el7 (FEDORA-EPEL-2024-0a280cd693)
 Modular SIP user-agent with audio and video support

Update Information:

# Baresip v3.9.0 (2024-01-31)   - menu autoanswer handling   - aureceiver: fix
overflow multiplications   - aur: entirely use `mbuf` in `aurecv_debug()`   -
test: call - add `AUDIO_MODE_THREAD` to `test_call_aufilt`   - cmake: add only
non-system link paths to rpath   - Renamed gzrtp `ARRAY_SIZE` macro   -
avcapture: fix deprecated `AVCaptureDeviceTypeExternalUnknown`   - aur: fix
uninitialized warning in auplay handler   - magic: use `assert()` instead of
`BREAKPOINT`   - sipsess: refactor and simplify SDP negotiation state   - aur:
set audio format correctly   - misc: bump year   - video: use `viddec_packet`
- audio: solve concurrency failures of TX thread   - aur: a mutex for `aubuf`
allocation   - call: remove unused error handling of some API functions   -
menu: an incoming call should not change the current call   - misc: `HAVE_INET6`
is always defined   - mqtt: improve disconnect reconnect handling   - misc: rx
thread activate   - cmake: refactor module detection   - ua: improve SIP 404
warning   - call: fix race condition for `call_set_video_dir()`   - message:
allow `SIP MESSAGE` with `application/json` ctype   - account/debug: fix wrong
and redundant `rtcp_mux` `printf`   - mk: bump version to 3.9.0   # libre v3.9.0
(2024-01-31)   - http: fix doxygen   - types: remove old `ARRAY_SIZE macro`   -
cmake: bump minimum to version 3.14   - test: use `re_is_aligned()`   - sipsess:
refactor and simplify SDP negotiation state   - bump year   - cmake,pc: fix
static library build   - rx thread activate   - test: fix cppcheck warnings   -
test: move `test_rtcp_decode_badmsg()` to separate testcase   - rtp: lock more
fields from `rtcp_sess`   - rtp: lock `rtcp_set_srate()`   - test: HAVE_INET6 is
always defined   - ci: add run-on-arch for ARM64 linux   - httpauth: digest
verification RFC 7616   - tmr: prevent race condition on cancel   - aubuf: fix
coverity defect   - btrace: fix coverity warning   - ci/win: downgrade openssl
- docs: update `README`   - http: client - set scopeid fixes HTTP requests for
IPv6ll   - rtp: add `rtp_source_` prefix to RTP source api   - rtp: make `struct
rtp_source` public   - rtp: sess - fix coverity warning   - mk: bump version to
3.9.0

ChangeLog:

* Thu Feb  1 2024 Robert Scheck  3.9.0-1
- Upgrade to 3.9.0 (#2262187)
* Tue Jan 23 2024 Fedora Release Engineering  - 
3.8.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
3.8.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

References:

  [ 1 ] Bug #2262187 - baresip-3.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262187
  [ 2 ] Bug #2262287 - libre-3.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262287




 libre-3.9.0-1.el7 (FEDORA-EPEL-2024-0a280cd693)
 Generic library for real-time communications

Update Information:

# Baresip v3.9.0 (2024-01-31)   - menu autoanswer handling   - aureceiver: fix
overflow multiplications   - aur: entirely use `mbuf` in `aurecv_debug()`   -
test: call - add `AUDIO_MODE_THREAD` to `test_call_aufilt`   - cmake: add only
non-system link paths to rpath   - Renamed gzrtp `ARRAY_SIZE` macro   -
avcapture: fix deprecated `AVCaptureDeviceTypeExternalUnknown`   - aur: fix
uninitialized warning in auplay handler   - magic: use `assert()` instead of
`BREAKPOINT`   - sipsess: refactor and simplify SDP negotiation state   - aur:
set audio format correctly   - misc: bump year   - video: use `viddec_packet`
- audio: solve concurrency failures of TX thread   - aur: a mutex for `aubuf`
allocation   - call: remove unused error handling of some API functions   -
menu: an incoming call should not change the current call   - misc: `HAVE_INET6`
is always defined   - mqtt: improve disconnect reconnect handling   - misc: rx
thread activate   - cmake: refactor module detection   - ua: improve SIP 404

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

[Justin Forbes]

On Thu, Feb 1, 2024 at 5:49 PM Leigh Scott  wrote:
>
> > Thanks for holding the push to testing, I have managed to patch nvidia 
> > 545.xx and
> > 550.xx so
> 470.xx is also patched.
>
> I think it is ok to push the new kernel to testing, the legacy nvidia drivers 
> shouldn't hold up the new kernel.

Much appreciated. It has already been noted that the updated packages work.

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

Re: Failure on fedora default backgrounds

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2024/02/02 10:25:

Hello team,

It appears a change within %{_kde4_datadir} macro caused failures on Rawhide 
affecting default Fedora backgrounds starting from 21.
Could someone from KDE SIG address that issue? Thanks.


Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:



RPM build errors:
error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
     File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
Child return code was: 1
'''

Reference:
[1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075



I am not KDE sig member, but the above failure is most likely due to
the following change:

https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32

/usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
definition)
was moved from kde-filesystem.rpm to kde4-filesystem.rpm .

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

Re: Failure on fedora default backgrounds

[JT]

I'm the maintainer of those packages and I've already spoken with Neal
Gompa about it.  I'll be addressing that when I get home, I'm on the road
until Sunday without my system to be able to commit to fix it.
JT

On Thu, Feb 1, 2024 at 8:26 PM Luya Tshimbalanga 
wrote:

> Hello team,
>
> It appears a change within %{_kde4_datadir} macro caused failures on
> Rawhide affecting default Fedora backgrounds starting from 21.
> Could someone from KDE SIG address that issue? Thanks.
>
>
> Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:
>
> 
>
> RPM build errors:
> error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> Child return code was: 1
> '''
>
> Reference:
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
>
> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Roberto Ragusa wrote:

> On 2/1/24 14:29, Steve Cossette wrote:
> 
>> And yes, that /is/ the whole point: We want to foster the use of Wayland,
>> to increase it's adoption, to force people using it to hit snags along
>> the road and fill tickets so those issues can be fixed.
> "force people" "hit snag"
> 
> With this kind of attitude, don't be surprised when people describe Fedora
> as "the beta test" for Red Hat.

+1, kinda what I was about to say, except with s/beta/alpha/. :-)

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Steve Cossette wrote:
> But I feel like I'm going off subject. I also think you are right, the KDE
> COPR-solution would work as long as it is documented somewhere. We could
> simply put it in the Fedora docs page, but also clearly note that those
> packages are not supported, but will be updated until the underlying
> frameworks (e.g. Xorg, or when the KDE foundation no longer supports Xorg,
> whichever comes first) are no longer available.

Unlike you ("you" = the KDE SIG), I actually believe I can probably keep my 
*-x11 packages on life support for some time even if and when KDE upstream 
drops their X11 support. Kinda like I have been doing for, e.g., Blogilo. 
Realistic would be until the release of Plasma 7, unless some Plasma 6.x 
introduces major changes that make it impractical. But I hope this is not 
going to be a concern for Fedora 40.

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

Failure on fedora default backgrounds

[Luya Tshimbalanga]

Hello team,

It appears a change within %{_kde4_datadir} macro caused failures on 
Rawhide affecting default Fedora backgrounds starting from 21.

Could someone from KDE SIG address that issue? Thanks.


Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:



RPM build errors:
error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
Child return code was: 1
'''

Reference:
[1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075

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

[Bug 2259686] perl-LWP-Protocol-https-6.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-LWP-Protocol-https-6.1
   ||2-1.fc39
 Resolution|--- |ERRATA
Last Closed||2024-02-02 01:14:04



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-f7de5f3f99 has been pushed to the Fedora 39 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=2259686

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259686%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2258649] perl-SQL-Translator-1.65 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SQL-Translator-1.65-1. |perl-SQL-Translator-1.65-1.
   |fc40|fc40
   ||perl-SQL-Translator-1.65-1.
   ||fc39



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-ea7c6ef21f has been pushed to the Fedora 39 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=2258649

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202258649%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Leo Sandoval

[Steve Cossette]

Welcome to Fedora!

Drop by matrix, we don't bite (hard)!

Le jeu. 1 févr. 2024, à 19 h 48, Leo Sandoval  a
écrit :

> Dear Fedora Community!
>
> My name is Leonardo Sandoval, a software developer living in Guadalajara,
> Mexico. I have been in the industry since 2006, most of the time close to
> the Linux kernel (openmax, gstreamer, glibc, yocto project, ltib,
> toolchains) and recently doing gitlab CI/CD, but all the time under
> GNU/Linux (and emacs). Also, I recently started teaching Fundamentals of OS
> in a local university, trying to get new students involved into the Linux
> internals.
>
> Since Dic 2023 I have been working at RedHat (remote), in particular
> I  joined the  bootloader team to co-maintain Fedora grub2 and other
> bootloader tasks. I have the fortune to be surrounded by amazing  technical
> people so I am  glad to be part of this team and Fedora community in
> general.
>
> Leo
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Steve Cossette wrote:
> It would also introduce a precedent: What if later a proposal is made to
> remove some old drivers from, let's say, the kernel, and someone decides
> to package it, undermining the general efforts of that proposal?

The kernel is actually a special case in that there is a specific rule 
banning kernel modules and custom kernels from Fedora. That is a rule 
specifically for the kernel and does not apply to any other package (e.g., 
browser extensions, LibreOffice plugins, Plasma widgets (plasmoids), etc. 
can all be separately packaged).

There have been plugin-based applications where some plugins were dropped 
from the upstream tarball and/or the Fedora packaging, and subsequently 
submitted as separate packages in Fedora. As I understand it, this has never 
been vetoed (for anything other than kernel modules).

The special case for the kernel is something that I am also unhappy with, 
but that is a separate discussion. But I would be really unhappy if this 
became the standard also for userspace.

> Hopefully I'm making sense. Writing this 30mins after waking up might not
> have helped. What I'm trying to say basically is, I get that for some
> legacy nvidia users the Wayland experience may not be optimal. But will it
> *ever* be? Does that mean we can never drop x11? Will anyone ever update
> those legacy nvidia drivers? *Could they be?*

Actually, I could not care less about the experience with proprietary NVidia 
drivers. I do not use or intend to use them. That is not the reason I use 
X11. Of course, NVidia users are free to use my packages just like everybody 
else, but as always, I cannot fix bugs in the proprietary driver code, so 
please do not expect me to do miracles there. If X11 works better for NVidia 
users than Wayland, great, but if not, I am afraid there is probably not 
much I can do about that.

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

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

[Ian Laurie]

On 2/2/24 10:48, Leigh Scott wrote:

Thanks for holding the push to testing, I have managed to patch nvidia 545.xx 
and
550.xx so

470.xx is also patched.

I think it is ok to push the new kernel to testing, the legacy nvidia drivers 
shouldn't hold up the new kernel.


Thank you for doing this fix so quickly, it is greatly appreciated.

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

Re: Self Introduction: Leo Sandoval

[Neal Gompa]

On Fri, Feb 2, 2024 at 12:48 AM Leo Sandoval  wrote:
>
> Dear Fedora Community!
>
> My name is Leonardo Sandoval, a software developer living in Guadalajara, 
> Mexico. I have been in the industry since 2006, most of the time close to the 
> Linux kernel (openmax, gstreamer, glibc, yocto project, ltib, toolchains) and 
> recently doing gitlab CI/CD, but all the time under GNU/Linux (and emacs). 
> Also, I recently started teaching Fundamentals of OS in a local university, 
> trying to get new students involved into the Linux internals.
>
> Since Dic 2023 I have been working at RedHat (remote), in particular I  
> joined the  bootloader team to co-maintain Fedora grub2 and other bootloader 
> tasks. I have the fortune to be surrounded by amazing  technical people so I 
> am  glad to be part of this team and Fedora community in general.
>

Welcome to Fedora, Leo!



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

suitesparse update/soname bump coming this weekend

[Orion Poplawski]

I will be updating suitesparse to 7.6.0 with a new cmake build system. 
This is also a soname bump and I'll be rebuilding the deps in a side-tag.


$ fedrq whatrequires suitesparse -F source
ceres-solver
coin-or-Clp
freefem++
gegl04
glpk
libpano13
naev
octave
psblas3
python-cvxopt
qrmumps
suitesparse
sundials
superlu_dist


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


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

Self Introduction: Leo Sandoval

[Leo Sandoval]

Dear Fedora Community!

My name is Leonardo Sandoval, a software developer living in Guadalajara,
Mexico. I have been in the industry since 2006, most of the time close to
the Linux kernel (openmax, gstreamer, glibc, yocto project, ltib,
toolchains) and recently doing gitlab CI/CD, but all the time under
GNU/Linux (and emacs). Also, I recently started teaching Fundamentals of OS
in a local university, trying to get new students involved into the Linux
internals.

Since Dic 2023 I have been working at RedHat (remote), in particular
I  joined the  bootloader team to co-maintain Fedora grub2 and other
bootloader tasks. I have the fortune to be surrounded by amazing  technical
people so I am  glad to be part of this team and Fedora community in
general.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Mattia Verga via devel wrote:
> However, if the breakage could happen only one way, e.g. a KDE Plasma
> update will possibly break -x11 packages, but no -x11 package could
> break the "official" Wayland implementation, I'm for allowing the -x11
> packages in the main repos. I see no other reason why FESCO should block
> -x11 packages in the main repo, if a software is under an allowed
> license and doesn't harm the main system we should not refuse its
> packaging.

By their nature, I do not see how the -x11 packages can possibly break the 
Wayland implementation. To do so, they would have to be either required or 
recommended by, or supplement or obsolete one of the "official" packages 
(because otherwise, users of the "official" packages will not have or get 
those packages even installed at all, as, at the latest, the upgrade to 
Fedora 40 will have obsoleted them). That is not currently the case (neither 
the Requires/Recommends scenario nor the Supplements/Obsoletes one), and I 
do not see that ever changing, as that would require a major blunder or a 
deliberate sabotage act by one of the involved parties. And then it would 
take an additional blunder for the package that gets accidentally installed 
to actually break something (except in the Obsoletes case if it accidentally 
obsoletes an essential package).

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Neal Gompa wrote:
> My position as the KDE SIG lead based on discussions within the SIG is
> that re-introducing these packages in the main distribution would
> destroy the main point of our efforts: driving KDE Plasma Wayland to
> be the best and most complete experience. The signal of dropping
> Plasma X11 largely drove a lot of improvements in Plasma 6 very
> quickly that I do not believe would have otherwise occurred. The
> upstream KDE developers did a lot of work for us because we
> communicated priorities and worked with them very early to frame the
> roadmap for the future of Plasma Wayland.

So basically you are trying to strongarm upstreams (KDE, but also third-
party application developers) into supporting Wayland by boycotting X11. 
That makes it all the funnier that you are then accusing me of trying to 
"strongarm" you "into supporting X11" (as Steve Cossette (farchord) wrote in 
the FESCo ticket).

> We started signaling our intent two years ago to drop Plasma X11 with
> Plasma 6 at Akademy 2022, but even most of that effort wasn't taken
> seriously until last year, when I reiterated it again at Akademy there.

I am not surprised that your announcements were not taken seriously, because 
dropping X11 sounds so unreasonable to not just me that it just cannot be 
taken seriously.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Steven A. Falco wrote:
> Bug 2239016 - Plasma(Wayland) does not honor window positioning when
> setting window geometry
> For 2239016 the response was "That's just how wayland works"

As far as I know, there are actually some discussions about this issue in 
the upstream Wayland community, but there is a lot of divergence of opinions 
between compositor developers whether this should be allowed at all (GNOME 
in particular is against this and several other advanced features that users 
know from X11 and want) and if yes, how exactly the API should look like. 
See, e.g.:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
for one proposed protocol implementation.

Of course, having a protocol would not instantly make this work for you. The 
protocol will have to be implemented both by kwin-wayland and by the toolkit 
your application uses. Which also means that the application will have to be 
ported to the latest major version of the toolkit (e.g., Qt 6), because this 
is a new feature and as such will likely never be backported to legacy 
toolkit versions (such as Qt 5). Though at least for Konsole, that last part 
should not be an issue.

> Bug 2239029 - Plasma(Wayland) does not save windows between sessions

That one is also reportedly being worked on, but it is a particularly big 
mess (i.e., probably requires more than one new Wayland protocol to solve 
completely), so I do not expect this to be solved completely any time soon. 
(The fact that the upstream bug was opened back in 2021 indeed gives you an 
idea.) As I understand it, Plasma 6.0 will have no support at all for this, 
Plasma 6.1 will remember the applications, but neither will KWin (or the 
applications themselves, but then see also your other issue) remember their 
window geometry nor will the applications remember their state. As far as I 
know, there is at this time no Wayland protocol to tell applications to save 
their state. A more complete session save/restore implementation is expected 
by upstream KDE developers only for around 2025.


There are also more X11 features of this type that are not currently 
implemented in Wayland.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Daniel P. Berrangé wrote:
> The approved KDE change
> https://fedoraproject.org/wiki/Changes/KDE_Plasma_6 indicates the intent
> for existing Plasma X11 installs to switch to Wayland during the upgrade
> process.
> 
> There's no perfect answer as some users will be happy to switch to
> Wayland, while others will not, while perhaps more will not even be aware
> of anything changing.
> 
> IMHO if the KDE Sig wants the upgrade path to take users from X11 to
> Wayland automatically, then the criteria for allowing back in RPMs
> with X11 builds should include "no interference with the X11->Wayland
> upgrade path determined by the KDE Sig".
> 
> The BZ ticket indicates that there was some testing to show that is not
> causing a problem with the upgrades, so it might be a non-issue, but
> setting clear expectations in this respect would be a good idea anyway.

As I wrote (and confirmed by testing) in the BZ ticket, the packages as 
submitted already do not interfere with the X11->Wayland upgrade path 
determined by the KDE Sig, and I do not intend changing that. (Adding 
versioned self-Obsoletes could possibly theoretically achieve that, but that 
is a game I do not intend to play. The only thing I care about, which is why 
I bumped that Epoch, is that the upgrade Obsoletes is applied only ONCE on 
the upgrade to Fedora 40 and not on routine updates in Fedora 40 or on 
upgrades from Fedora 40 to later releases, because anybody who still/again 
has the -x11 packages on Fedora 40 has explicitly opted in and should not 
have to opt in repeatedly.)

While (as also stated in the BZ ticket) I disagree that it is helpful to 
forcefully remove the -x11 packages on the upgrade to F40, my packages do 
not and will not interfere with that process.

If you want to explicitly encode this in the proposal, I am OK with that, 
but then it should also explicitly say that further updates/upgrades should 
not obsolete my packages (i.e., that the KDE SIG is not allowed to bump the 
Epoch of their Obsoletes – I really do not want to get into an Epoch war 
about that Obsoletes and I hope the KDE SIG does not want that either).

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Alessandro Astone wrote:
> Also "major changes" would be the ~fibonacci-weekly~ Plasma bugfix
> release, as the -x11 package will require an exact version match of the
> common libraries. Not really a rare occasion. --

This can be solved with communication.

That said, if the KDE SIG does not want to have to coordinate changes with 
any third party, not even as far as just notifying us of the impending 
changes (Stephen Gallagher's proposal does not even require you to wait for 
me or anybody else to reply! Just to asynchronously notify me/us, i.e., drop 
a single mail to kwin-x11-owner@….), then the easy way would be to just go 
back to building those subpackages as part of the respective main package. 
I.e., let me and/or anyone else who wants Plasma on X11 comaintain the 2 
packages and assign any X11 issues to me/them. That would probably be the 
least work for everyone.

But the separate packages as I submitted them for review are the next best 
solution.

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

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

[Leigh Scott]

> Thanks for holding the push to testing, I have managed to patch nvidia 545.xx 
> and
> 550.xx so
470.xx is also patched.

I think it is ok to push the new kernel to testing, the legacy nvidia drivers 
shouldn't hold up the new kernel.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Kofler via devel]

Alessandro Astone wrote:
> But am I supposed to ignore the fact that kkofler is already bullying the
> KDE SIG into not breaking that one other package they maintain that
> occasionally breaks on kde updates? See example:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584

To make it clear about the situation of that particular package: The KDE SIG 
never notifies me in advance about kdepim bumps. They push them to Rawhide, 
then I eventually get FTI/FTBFS reports for Blogilo filed by some automatic 
process, and then I scramble to fix Blogilo in Rawhide. If they bothered 
notifying me, it would probably get fixed sooner.

In the particular case I complained about above, they immediately proceeded 
to build the kdepim update for the current stable release without giving me 
any time to fix the breakage in Rawhide.

The nature of the upstream update was also such that the kdepim libraries 
removed/moved some APIs upstream, so this was really an incompatible library 
change, not the usual backwards-compatible change expected within a KDE 
major release. I am not sure why the upstream kdepim developers opted to 
make these changes in their KF5 versions, which should really have been in 
maintenance mode by then, instead of doing them only in the KF6 versions 
where such changes would have been expected as part of the major version 
bump. (Hence, my "yet another incompatible kdepim stack update" complaint 
was also about upstream, not only about the KDE SIG.)

The normal Fedora policy for this kind of changes is to give time for 
maintainers of dependent applications, even if they are legacy applications, 
to fix the applications before pushing the update to stable releases. In the 
Blogilo case, I do not remember having agreed to (nor having been ordered by 
FESCo to accept) anything different. I fixed Blogilo as quickly as I could 
even though it was not trivial. I am sorry for the few days of delay caused 
by that.

I do not expect the *-x11 updates to take that long, because all I normally 
need to do there is to bump Version, use the same tarball as for the Wayland 
version, and rebuild. As long as upstream maintains X11 support, I will not 
be in a situation like for Blogilo where I have to backport support for 
changed library APIs to an ancient codebase not updated anymore by upstream. 
So I do not expect the user experience to be that bad.

The one thing that would be helpful is, if I have the *-x11 packages already 
updated in Rawhide dist-git, to just sync them to the release branch and 
build them in the side tag when they prepare an update for a release. (As I 
understand it, the scripts they use to sync branches and build updates can 
probably do that with no extra human effort.) Though, if not, I can do that 
too, if only they tell me about the update and the side tag as soon as 
possible, at least before they hit that "push to stable" button.

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

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

[Leigh Scott]

> On Thu, Feb 1, 2024 at 1:45 AM Leigh Scott  wrote:
> 
> This is not accurate.  The 6.7.3 (and 6.6.15) updates did break the
> nvidia driver. It has nothing to do with debugging being enabled.   A
> proper and valid bugfix:
> 
> 5ec8e8ea8b7783fab150cf86404fc38cb4db8800 mm/sparsemem: fix race in
> accessing memory_section->usage
> 
> added calls to rcu_read_lock() and rcu_read_unlock() which use symbols
> that are exported GPL only. This was not some attempt to stab at
> nvidia, but their non-GPL module is failing as a result because that
> bug fix now pulls those calls into their driver build.  Some people
> have suggested removing the EXPORT_SYMBOL_GPL on these symbols and
> leaving them as regular exports.  That is not a valid fix for Fedora
> to carry for many reasons.  I will leave 6.7.3 in updates testing for
> a while to give nvidia some time to come up with a work around, but at
> some point things have to move forward, and I will not hold non nvidia
> users bugfixes hostage because of an out of tree driver, this has
> always been Fedora's policy.
> 
> Justin
> 
> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6859
> >
> >
> https://forums.developer.nvidia.com/t/linux-6-7-beta-550-40-07-error-modp...
> > --
> > ___
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
Thanks for holding the push to testing, I have managed to patch nvidia 545.xx 
and 550.xx so
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Looking for a new maintainer for ode

[Hans de Goede]

Hi Gwyn,

On 2/1/24 17:08, Gwyn Ciesla via devel wrote:
> Hi! I'd be happy to take ode, Xaw3d, and libcddb.

Great, thank you. I have handed over ownership
of all three packages to you now.

> Thank you for everything over the years. :)

You're welcome.

Regards,

Hans




> On Tuesday, January 30th, 2024 at 4:15 AM, Hans de Goede 
>  wrote:
> 
>> Hi All,
>>
> 
>> I used to do a lot of gaming related Fedora packaging and I still maintain
>> over 200 pkgs, but I really don't have much time for Fedora package
>> maintainership anymore.
>>
> 
>> The last few years I have been limiting my package maintainership
>> to fixing FTBFS, which for many game packages is fine since they
>> are not seeing any new upstream releases.
>>
> 
>> ode is currently 1 minor release behing the latest upstream release
>> and I don't have the time to fix it (since this is just a minor bump
>> the rebase should be trivial):
>>
> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=2218304
>>
> 
>> Anyone interested in taking over ode maintainership from me ?
>>
> 
>> Regards,
>>
> 
>> Hans
>>
> 
>>
> 
>>
> 
>>
> 
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package review ticket status change after approval

[Fabio Valentini]

On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel
 wrote:
>

(snip)

>
> That said, I'd like to make a request and maybe make all reviewers aware
> of a feature which was implemented some time ago. I've noticed many
> reviewers change the ticket status from ASSIGNED to POST when they flag
> the package as approved: I'd like to request to not do that.
>
> The Package Review Tracker webpages make a distinction between packages
> approved (fedora-review flag set to +) and packages approved AND being
> built in Fedora. That distinction relies on the ticket status change to
> POST, which is automatically set when the repository is created in src.fp.o.

Hum ... am I missing something here?

The bot that creates the dist-git repos does *NOT*, in fact, set the
bug status to POST:
https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5

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

[Bug 2262294] perltidy-20240202 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perltidy-20240202-1.fc40
Last Closed||2024-02-01 20:19:19



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-532a47babe has been pushed to the Fedora 40 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=2262294

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262294%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262294] perltidy-20240202 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2024-532a47babe has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-532a47babe


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262294%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Adam Williamson]

On 2024-02-01 07:40, Sérgio Basto wrote:


I have an obvious answer is when the authors decide, in this case Xorg,
when Xorg decides that it will stop supporting X11, like happened to
Python2 or PHP5 and 7 or Gnome

In fact, it is something I've been thinking about, IMHO, downstream
shouldn't decide when software is deprecated or not like KDE and Red
HAt did , it's weird to me [1], although in RHEL we could have the
packages via EPEL, I think, and RHEL 10 is only in a year and a half


A lot of the people involved at different parts of the stack are just 
the same people wearing different hats.


Wayland and X.org are both part of freedesktop. Whatever maintenance is 
still happening on X.org is mostly being done by people who primarily 
work on Wayland. There isn't some kind of holy war going on between The 
Wayland Developers who want to kill X.org, and The X.org Developers who 
believe it is great and want to keep it. They're nearly all the same 
people, and they all want X.org to die. AFAIK there isn't anybody who is 
actually clamoring to *do the work of maintaining X.org upstream*. There 
are people who don't want it to die because Wayland doesn't yet have the 
features they need or the NVIDIA proprietary driver doesn't work well on 
Wayland or whatever, but AFAIK, none of those people is actually 
volunteering to maintain X.org long-term. If you look through 
https://gitlab.freedesktop.org/xorg/xserver/-/commits/master you will 
see the majority of commits are from people who also work on Wayland 
(and most of the commits are actually to Xwayland).


A lot of the same people who are the graphics stack maintainers for 
freedesktop.org are *also* involved in distribution efforts to move to 
Wayland. So it's not as simple as "distributions making the decisions 
instead of upstream". AFAIK, most of the upstream folks dearly *want* 
distributions to move off of X.org and onto Wayland, but they feel kind 
of obliged to continue minimal maintenance of X.org upstream until this 
move is further along.


Apologies if any of that is inaccurate, and I'm sure folks will correct 
me if so.

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

Re: Mounting USB Storage devices with "sync" option ?

[Justin Forbes]

On Wed, Jan 31, 2024 at 6:36 AM Leon Fauster via devel
 wrote:
>
> Am 31.01.24 um 09:57 schrieb Larina Loriasel via devel:
> >> 'sync' has some strong downsides though: various operations become
> >> painfully slow (this depends a lot on the hardware and its age, and
> >> the history of previous writes, etc.), write operations block read
> >> operations, and the total number of writes may be increased, leading
> >> to more wear on the hardware.
> >
> > The udev rule only applies to USB Storage devices, and I think the total 
> > number of writes increasing only happens if the data to be written is 
> > changed constantly (e.g. writes that overlap on same region/block of a 
> > device)
> > Most USB Storage devices are used for storing simple, consecutive streams 
> > of data, such as Music, Pictures and other simple files and are not usually 
> > modified much, thus, I think enabling sync makes sense in this regard.
> > In my opinion, the benefits of mounting USB Storage devices with sync 
> > outweigh the detriments.
> > Writes blocking reads is concerning.
>
>
>
> Thats a to narrow view, as the USB interface is used in a ton of
> scenarios (backups etc.) where maximum data flow is an expectation.

This is a huge point.  For someone writing something quickly to a USB
stick, the behavior characteristic of sync is not entirely horrible.
For people with large USB drives frequently or always mounted, the
expectations are completely different.  As USB gets faster, and
laptops/nucs/etc get smaller, we see more and more people using USB
SSDs to expand storage.

Justin

>
> >> We approach this problem from a different angle: the user is supposed
> >> to sync the filesystem before removing. Graphical environments have
> >> an "eject" button, and for non-graphical environments, the user
> >> just needs to do a sync manually.
> >
> > I am aware of that, but it leads to a poor user experience, being notified 
> > that a copying operation has been completed, while in reality, it has not.
>
>
> CLI: Doesn't that trigger the umount command already ... so no need to
> think about it (as user). As soon the umount completes the device can be
> unplugged.
>
>
>
> >> The same is true for "normal" writes to a harddrive. Operations are
> >> generally async, and the user needs to do a shutdown, during which
> >> we sync and unmount filesystems. If you "yank" the cord, this may (*)
> >> result in lost data and file system inconsistency.
> >
> > My proposal was exclusively for USB Storage devices, not internal ones, as 
> > I can understand the benefits of async outweighing the detriments in the 
> > case of internal/network etc storage devices.
>
>
> I never had a big issue in the GUI (long time/waits), as it clearly
> states to wait until removal is allowed (also stated via notify).
> Normally (here) this is just a few seconds (single digit).
>
> Maybe the idea can be implemented more transparently via vm.dirty_*
> sysctl per device if possible or is it a global threshold only?
>
>
> --
> Leon
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

SQLAlchemy major version upgrade

[Nils Philippsen]

Hi everybody,

just a heads up: with the compat package for version 1.4 in place[1],
I’m about to upgrade the main python-sqlalchemy package to version 2 in
Rawhide.

This is part of the SQLAlchemy 2 Change for Fedora 40[2] and when the
upgraded package is available, we can verify whether or not packages
using SQLAlchemy are compatible with the new API or if they need to
depend on the compat package.

Cheers,
Nils

[1]: https://src.fedoraproject.org/rpms/python-sqlalchemy1.4
[2]: https://fedoraproject.org/wiki/Changes/SQLAlchemy_2
-- 
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Adam Williamson]

On 2024-02-01 04:08, Steve Cossette wrote:
So, if you all don't mind, I'd like to steer this discussion in a 
slightly different way:


What /is/ the definition of a Fedora Change Proposal?

I was under the impression it was an announcement of intent by the 
maintainers of a specific subset of the fedora project to "change" 
something. Once said announcement has been discussed publicly, Fesco 
(Sorry if the capitals are incorrect) discusses it internally (albeit, 
publicly) and either blocks or approves the change, making it official.


/(Please note: The following paragraphs will use "we" as a pronoun which 
is intended to be the Fedora project as a whole)/

/
/
Once approved, we announced our intent to drop X11 from the KDE spin of 
Fedora. That announcement has gained traction everywhere, got publicized 
and everything. As Neal Gompa also stated, it has already caused some 
substantial development effort upstream to effectively iron out the 
rough edges of many of the problems, with what I assume is more to come.
I would not read it quite like that. I would say that by approving the 
Change, "we" - in the sense of "Fedora as a whole" - approved of the KDE 
SIG's decision to stop maintaining Plasma X11. I can't speak for FESCo, 
but if I had been on FESCo, I don't think I would've had in my mind 
"approving this Change creates a ban on anybody at all maintaining 
Plasma X11 packages in Fedora" when voting on it.

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

Re: Re: Re: A reminder: you cannot just "revert" package version bumps

[Kevin Fenzi]

On Thu, Feb 01, 2024 at 02:51:54AM +0100, Kevin Kofler via devel wrote:
> kevin wrote:
> > distro-sync is nice and all, but it's not a silver bullet.
> > In cases of simple packages a downgrade may not break anything, but in
> > cases where other things already built upon it, where the new one
> > changed conguration or interface, or even where the upgrade changed
> > data, it can leave things in a pretty unfortunate state.
> 
> And the proposed "solution" of bumping Epoch fixes none of that. It just 
> introduces an Epoch that we will be stuck with forever. It will not 
> magically make the downgrade safe in any of the 3 situations you describe.

I am unsure when I proposed Epoch's. I'm not a great fan of them either.
In addition to what you mentioned, Epochs have another problem:
Depending on how dependent packages (build)require your package, they
must be adjusted for the new Epoch too.

Anyhow, to be more clear: 

I don't think we can or should say "just downgrade whenever you like",
unless/until dnf5 gets rid of update and only has distro-sync.
Nor do I think we should rush to using Epochs. In rare cases we should
go back to older versions, but it should be a discussion and other
alternatives should all be exhausted first (patch the problem and push a
newer update, push a revert of the problematic part, engage with
upstream for a solution, etc). 

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

Re: Mounting USB Storage devices with "sync" option ?

[Larina Loriasel via devel]

Such a way to dynamically mount and perform reads/writes to the device only 
when needed is truly an ideal solution, looking forward to udisks implementing 
such a feature.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CI failure: Too many packages to install: 233 (threshold 100). Please use 'repository-file' artifact instead.

[Cole Robinson]

On 2/1/24 12:35 AM, Florian Weimer wrote:
> How can we fix this error?
> 
>   
> 
> 
> I think it's related to the fact that glibc has many subpackages.  This
> used to be a problem with slow tests timing out in Zuul, but it didn't
> prevent any rpm-tmt-test subtests from running.
> 

Seeing similar with qemu too. I filed this issue before I saw your mail:

https://pagure.io/fedora-ci/general/issue/453

I googled around and checked tmt git but couldn't find where that error
string is coming from, or any relevant hits about 'repository-file'

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kilian Hanich via devel]

Am 01.02.24 um 17:44 schrieb Neal Gompa:

That is not necessarily true. For your example about window placement,
there is 
this:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

Am 01.02.24 um 17:46 schrieb Neal Gompa:

Sorry, I meant to point to this as well:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247


These two are imo more example which try to prove Falco's point because of:
1. How long this is going on.
2. How many attempts this person made so far.
3. How much some of the maintainers don't want *something* like this (if
you go and read through the thread).

But yeah, I hope we get something at some point which isn't as stupidly
complicated like needing to generate and register transient desktop
files to set dynamic window icons (you can't always know them in advance
if you have a plugin based application; or when multiple windows should
have different ones). I know that there is also a proposal (after
multiple failed tries) in discussion, but there are even more
maintainers who don't want that. (And I am kinda afraid that if it comes
around, it will be a non-flatpak thing, which would be sad considering
that I like Flatpak and immutable distros, so I hope that I could at
least turn that "protection" off).

But well, Let's hope for the best.

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

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

[Justin Forbes]

On Thu, Feb 1, 2024 at 1:45 AM Leigh Scott  wrote:
>
> Kernel-6.7.3 still has debugging enabled which will break the nvidia driver

This is not accurate.  The 6.7.3 (and 6.6.15) updates did break the
nvidia driver. It has nothing to do with debugging being enabled.   A
proper and valid bugfix:

5ec8e8ea8b7783fab150cf86404fc38cb4db8800 mm/sparsemem: fix race in
accessing memory_section->usage

added calls to rcu_read_lock() and rcu_read_unlock() which use symbols
that are exported GPL only. This was not some attempt to stab at
nvidia, but their non-GPL module is failing as a result because that
bug fix now pulls those calls into their driver build.  Some people
have suggested removing the EXPORT_SYMBOL_GPL on these symbols and
leaving them as regular exports.  That is not a valid fix for Fedora
to carry for many reasons.  I will leave 6.7.3 in updates testing for
a while to give nvidia some time to come up with a work around, but at
some point things have to move forward, and I will not hold non nvidia
users bugfixes hostage because of an out of tree driver, this has
always been Fedora's policy.

Justin

> https://bugzilla.rpmfusion.org/show_bug.cgi?id=6859
>
> https://forums.developer.nvidia.com/t/linux-6-7-beta-550-40-07-error-modpost-gpl-incompatible-module-nvidia-ko-uses-gpl-only-symbol-rcu-read-lock/280908
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/1/24 11:46 AM, Neal Gompa wrote:

I'd like to think that the gaps will be fixed, but it seems to me that because 
of policy, some gaps (like apps controlling their own window placement) will 
never be fixed.



That is not necessarily true. For your example about window placement,
there is this: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264


Is there a way to see what gaps remain, which ones are being worked on, and which ones 
will be declared "not a gap - won't fix"?





Sorry, I meant to point to this as well:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247


Thanks for the links.  I am hopeful that the issues you are tracking will make 
it in time for f40.

Steve

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

[Bug 2261449] perl-Prima-1.71-3.fc40: FTBFS in F40: img/codec_Xpm.c:635:28: error: assignment to ‘Bool (*)(struct ImgCodec *, struct _ImgLoadFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, stru

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 151523




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261449
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:44 PM Neal Gompa  wrote:
>
> On Thu, Feb 1, 2024 at 4:40 PM Steven A. Falco  wrote:
> >
> > On 2/1/24 11:28 AM, Neal Gompa wrote:
> > > On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa  
> > > wrote:
> > >>
> > >> On 2/1/24 14:29, Steve Cossette wrote:
> > >>
> > >>> And yes, that /is/ the whole point: We want to foster the use of 
> > >>> Wayland, to increase it's adoption, to force people using it to hit 
> > >>> snags along the road and fill tickets so those issues can be fixed.
> > >> "force people" "hit snag"
> > >>
> > >> With this kind of attitude, don't be surprised when people describe 
> > >> Fedora
> > >> as "the beta test" for Red Hat.
> > >>
> > >
> > > To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
> > > less about KDE. A "beta test" for Red Hat is pretty useless when it
> > > has basically no impact for Red Hat, positively or negatively.
> > >
> > > We are doing this because without doing so, the gaps will *never* be
> > > identified to be fixed in the first place. And they *are* getting
> > > fixed at a rapid clip.
> >
> > I'd like to think that the gaps will be fixed, but it seems to me that 
> > because of policy, some gaps (like apps controlling their own window 
> > placement) will never be fixed.
> >
>
> That is not necessarily true. For your example about window placement,
> there is this: 
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
>
> > Is there a way to see what gaps remain, which ones are being worked on, and 
> > which ones will be declared "not a gap - won't fix"?
> >
>

Sorry, I meant to point to this as well:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:40 PM Steven A. Falco  wrote:
>
> On 2/1/24 11:28 AM, Neal Gompa wrote:
> > On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa  wrote:
> >>
> >> On 2/1/24 14:29, Steve Cossette wrote:
> >>
> >>> And yes, that /is/ the whole point: We want to foster the use of Wayland, 
> >>> to increase it's adoption, to force people using it to hit snags along 
> >>> the road and fill tickets so those issues can be fixed.
> >> "force people" "hit snag"
> >>
> >> With this kind of attitude, don't be surprised when people describe Fedora
> >> as "the beta test" for Red Hat.
> >>
> >
> > To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
> > less about KDE. A "beta test" for Red Hat is pretty useless when it
> > has basically no impact for Red Hat, positively or negatively.
> >
> > We are doing this because without doing so, the gaps will *never* be
> > identified to be fixed in the first place. And they *are* getting
> > fixed at a rapid clip.
>
> I'd like to think that the gaps will be fixed, but it seems to me that 
> because of policy, some gaps (like apps controlling their own window 
> placement) will never be fixed.
>

That is not necessarily true. For your example about window placement,
there is this: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

> Is there a way to see what gaps remain, which ones are being worked on, and 
> which ones will be declared "not a gap - won't fix"?
>

I have a list of things I'm tracking. I've been reluctant to publish
it because people will think that it's some kind of "general Wayland
tracker" since I have no influence or impact on GNOME Wayland (which
is the one most people are concerned about).



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/1/24 11:28 AM, Neal Gompa wrote:

On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa  wrote:


On 2/1/24 14:29, Steve Cossette wrote:


And yes, that /is/ the whole point: We want to foster the use of Wayland, to 
increase it's adoption, to force people using it to hit snags along the road 
and fill tickets so those issues can be fixed.

"force people" "hit snag"

With this kind of attitude, don't be surprised when people describe Fedora
as "the beta test" for Red Hat.



To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
less about KDE. A "beta test" for Red Hat is pretty useless when it
has basically no impact for Red Hat, positively or negatively.

We are doing this because without doing so, the gaps will *never* be
identified to be fixed in the first place. And they *are* getting
fixed at a rapid clip.


I'd like to think that the gaps will be fixed, but it seems to me that because 
of policy, some gaps (like apps controlling their own window placement) will 
never be fixed.

Is there a way to see what gaps remain, which ones are being worked on, and which ones 
will be declared "not a gap - won't fix"?

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa  wrote:
>
> On 2/1/24 14:29, Steve Cossette wrote:
>
> > And yes, that /is/ the whole point: We want to foster the use of Wayland, 
> > to increase it's adoption, to force people using it to hit snags along the 
> > road and fill tickets so those issues can be fixed.
> "force people" "hit snag"
>
> With this kind of attitude, don't be surprised when people describe Fedora
> as "the beta test" for Red Hat.
>

To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
less about KDE. A "beta test" for Red Hat is pretty useless when it
has basically no impact for Red Hat, positively or negatively.

We are doing this because without doing so, the gaps will *never* be
identified to be fixed in the first place. And they *are* getting
fixed at a rapid clip.

And we've been using Wayland by default for Fedora KDE for the past
three years. This is the next step on that path.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steve Cossette]

On 2024-02-01 11:21 a.m., Roberto Ragusa wrote:

On 2/1/24 14:29, Steve Cossette wrote:

And yes, that /is/ the whole point: We want to foster the use of 
Wayland, to increase it's adoption, to force people using it to hit 
snags along the road and fill tickets so those issues can be fixed.

"force people" "hit snag"

With this kind of attitude, don't be surprised when people describe 
Fedora

as "the beta test" for Red Hat.

Regards.


When you think about it, we are!

Fedora Packages go to CentOS stream, which then go over to RHEL... It's 
well documented!

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Roberto Ragusa]

On 2/1/24 14:29, Steve Cossette wrote:


And yes, that /is/ the whole point: We want to foster the use of Wayland, to 
increase it's adoption, to force people using it to hit snags along the road 
and fill tickets so those issues can be fixed.

"force people" "hit snag"

With this kind of attitude, don't be surprised when people describe Fedora
as "the beta test" for Red Hat.

Regards.

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

[rpms/perl-Term-Cap] PR #1: Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Term-Cap` that you 
are following.

Merged pull-request:

``
Package tests
``

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

Re: Looking for a new maintainer for ode

[Gwyn Ciesla via devel]

Hi! I'd be happy to take ode, Xaw3d, and libcddb.

Thank you for everything over the years. :)


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

On Tuesday, January 30th, 2024 at 4:15 AM, Hans de Goede  
wrote:

> Hi All,
> 

> I used to do a lot of gaming related Fedora packaging and I still maintain
> over 200 pkgs, but I really don't have much time for Fedora package
> maintainership anymore.
> 

> The last few years I have been limiting my package maintainership
> to fixing FTBFS, which for many game packages is fine since they
> are not seeing any new upstream releases.
> 

> ode is currently 1 minor release behing the latest upstream release
> and I don't have the time to fix it (since this is just a minor bump
> the rebase should be trivial):
> 

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

> Anyone interested in taking over ode maintainership from me ?
> 

> Regards,
> 

> Hans
> 

> 

> 

> 

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

signature.asc
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262294] perltidy-20240202 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perltidy-20240202-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=112741397


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262294%23c2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Term-Cap] PR #1: Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Term-Cap` that 
you are following:
``
Package tests
``

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

[Bug 2262294] perltidy-20240202 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2014404
  --> https://bugzilla.redhat.com/attachment.cgi?id=2014404=edit
Update to 20240202 (#2262294)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262294%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262294] New: perltidy-20240202 is available

[bugzilla]

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

Bug ID: 2262294
   Summary: perltidy-20240202 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perltidy
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 20240202
Upstream release that is considered latest: 20240202
Current version/release in rawhide: 20230912-3.fc40
URL: http://search.cpan.org/dist/Perl-Tidy/

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


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


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


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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perltidy


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262294%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steve Cossette]

On 2024-02-01 10:27 a.m., Peter Boy wrote:


Sorry, a bit off-topic here, but nevertheless:


Am 01.02.2024 um 15:14 schrieb Steve Cossette :

Hello Pgnd,

I honestly do appreciate your point of view. Especially from a 
business owner standpoint. I do manage small business servers, and I 
feel you in that regard.


I do have to also applaud your nerves of steel though, using Fedora 
as a server in a business environment, to me anyway, always felt 
ill-advised as things tend to take rough 90 degree turns in Fedora 
which can often cause breakages in some server scenarios and stuff 
(The F40 mysql change comes to mind).



Hello Steve and hello Pgnd,

I would like to ask you (and invite you) to discuss your "take rough 
90 degree turns“ assessment for Fedora Server on Fedora Server list 
(and hopefully diminish your need for nerves of steel). I rather hear 
sometimes a kind of disappointment (or rebuke) about Fedora Server, 
that it is boring and it changes too little, no excitement, no 
surprise, too little new, everything just works as it has always 
worked, ... That kind of thing, just boring.


We aim to avoid „90 degree turns“ and disruption and proof to be able 
to provide the latest functionality of software services in a stable 
and reliable environment without much delay and, above all, without 
disruption. And if I look at our download statistics, an increasing 
number of admins seem to like it.


Your example about the mysql change does not seem to me to be in any 
way as significant as the decision about KDE and Xorg. And does not 
represent a disruption, but rather an evolution.



Would really like to discuss with you about recent 90 degree turns 
(I’m not aware of any in the last 2-3 years) and how to avoid it.




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast






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


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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steve Cossette]

On 2024-01-30 8:04 a.m., Germano Massullo wrote:

What does it mean that FESCo is applying an injunction?

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


An injunction is a hold. Not blocking it outright, just holding it back 
until we're done discussing this.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> 
> 
> > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > want
> > drop X11 and force user to use wayland .
> 
> 
> Looking from the side I wonder If its the SIG or more the
> circumstances
> that everything is in a forward flow and the SIG is facing it. So, if
> the best time was not two or one year ago, and obviously also not
> now.
> When then? The fact is that there must be a point in time when the 
> display server takes an evolution step forward.
> 
> Pressure in such transition helps to get forward, so I understand the
> SIGs POV. Albeit, from the practical POV there are some issue and 
> therefore X11 is still the place to be.
> 
> Maybe some elaboration should be done about the current state of X11
> vs
> Wayland (is it just nvidia?) and a timeframe calculation to have a 
> resolution. Maybe it won't look so bad then and a interim solution is
> then more acceptable.


I have an obvious answer is when the authors decide, in this case Xorg,
when Xorg decides that it will stop supporting X11, like happened to
Python2 or PHP5 and 7 or Gnome 

In fact, it is something I've been thinking about, IMHO, downstream
shouldn't decide when software is deprecated or not like KDE and Red
HAt did , it's weird to me [1], although in RHEL we could have the
packages via EPEL, I think, and RHEL 10 is only in a year and a half 


[1]
https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_deprecated_and_will_remove/


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

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Boy]

Sorry, a bit off-topic here, but nevertheless:

> Am 01.02.2024 um 15:14 schrieb Steve Cossette :
> 
> Hello Pgnd,
> 
> I honestly do appreciate your point of view. Especially from a business owner 
> standpoint. I do manage small business servers, and I feel you in that regard.
> 
> I do have to also applaud your nerves of steel though, using Fedora as a 
> server in a business environment, to me anyway, always felt ill-advised as 
> things tend to take rough 90 degree turns in Fedora which can often cause 
> breakages in some server scenarios and stuff (The F40 mysql change comes to 
> mind).


Hello Steve and hello Pgnd,

I would like to ask you (and invite you) to discuss your "take rough 90 degree 
turns“ assessment for Fedora Server on Fedora Server list (and hopefully 
diminish your need for nerves of steel). I rather hear sometimes a kind of 
disappointment (or rebuke) about Fedora Server, that it is boring and it 
changes too little, no excitement, no surprise, too little new, everything just 
works as it has always worked, ... That kind of thing, just boring.

We aim to avoid „90 degree turns“ and disruption and proof to be able to 
provide the latest functionality of software services in a stable and reliable 
environment without much delay and, above all, without disruption. And if I 
look at our download statistics, an increasing number of admins seem to like it.

Your example about the mysql change does not seem to me to be in any way as 
significant as the decision about KDE and Xorg. And does not represent a 
disruption, but rather an evolution. 


Would really like to discuss with you about recent 90 degree turns (I’m not 
aware of any in the last 2-3 years) and how to avoid it.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org 

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast





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

Re: Orphaned python-mccabe (dependency of pylint)

[Gwyn Ciesla via devel]

Excellent, thank you both! 




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

On Thursday, February 1st, 2024 at 2:52 AM, Michel Lind 
 wrote:

> On Thu, Feb 01, 2024 at 01:03:55AM +0100, Miro Hrončok wrote:
> 

> > On 01. 02. 24 0:51, Michel Lind wrote:
> > 

> > > I see limb already took the package (thanks limb) - note that the
> > > default bugzilla assignee still seems to be 'orphan', I'm assuming that
> > > will fix itself eventually
> > 

> > Not by itself, the package has a epel bugzilla contact override, so when the
> > main admin changes, the fedora bugzilla contact needs to be changed as well.
> > I've just done that.
> 

> Thank you! python-hypothesmith now fixed, and confirmed working by
> rebuilding python-libcst with tests enabled (which requires
> hypothesmith).
> 

> The non-bootstrap python-libcst 1.1.0 is building in Koji now.
> 

> Best,
> 

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

signature.asc
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2261449] perl-Prima-1.71-3.fc40: FTBFS in F40: img/codec_Xpm.c:635:28: error: assignment to ‘Bool (*)(struct ImgCodec *, struct _ImgLoadFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, stru

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Hardware|Unspecified |i686
   Doc Type|--- |If docs needed, set a value
Summary|perl-Prima: FTBFS in Fedora |perl-Prima-1.71-3.fc40:
   |rawhide/f40 |FTBFS in F40:
   ||img/codec_Xpm.c:635:28:
   ||error: assignment to ‘Bool
   ||(*)(struct ImgCodec *,
   ||struct _ImgLoadFileInstance
   ||*)’ {aka ‘long int
   ||(*)(struct ImgCodec *,
   ||struct _ImgLoadFileInstance
   ||*)’} from incompatible
   ||pointer type



--- Comment #4 from Petr Pisar  ---
The failure only exhibits on i686:

gcc -c  -Iinclude -Iinclude/generic -I/usr/include/fribidi
-I/usr/include/freetype2 -I/usr/include/sysprof-6 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libpng16
-I/usr/include/harfbuzz -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/atk-1.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/cloudproviders
-I/usr/include/webp -I/usr/include/blkid -I/usr/include/at-spi-2.0
-I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/pixman-1
-I/usr/include/openjpeg-2.5  -fopenmp -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic
-msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables
-fstack-clash-protection -fwrapv -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m32
-march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
-fasynchronous-unwind-tables -fstack-clash-protection   -DVERSION=\"1.71\"
-DXS_VERSION=\"1.71\" -fPIC "-I/usr/lib/perl5/CORE"   img/codec_Xpm.c -o
img/codec_Xpm.o
img/codec_Xpm.c: In function ‘apc_img_codec_Xpm’:
img/codec_Xpm.c:635:28: error: assignment to ‘Bool (*)(struct ImgCodec *,
struct _ImgLoadFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, struct
_ImgLoadFileInstance *)’} from incompatible pointer type ‘int (*)(struct
ImgCodec *, struct _ImgLoadFileInstance *)’ [-Wincompatible-pointer-types]
  635 | vmt. load  = load;
  |^
img/codec_Xpm.c:639:28: error: assignment to ‘Bool (*)(struct ImgCodec *,
struct _ImgSaveFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, struct
_ImgSaveFileInstance *)’} from incompatible pointer type ‘int (*)(struct
ImgCodec *, struct _ImgSaveFileInstance *)’ [-Wincompatible-pointer-types]
  639 | vmt. save  = save;
  |^


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261449%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Florian Weimer]

* Richard W. M. Jones:

>> We will have to fix this again (and wrap-find-debuginfo.sh and as well)
>> once Fedora adopts the standard RISC-V paths.
>
> Shouldn't we adopt the normal Fedora paths instead?

No, we should use the official RISC-V paths because we might need them
if we want to adopt other RISC-V ABIs.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Leon Fauster via devel]

Am 01.02.24 um 14:18 schrieb Sérgio Basto:



The problem is not KDE SIG not support X11, the problem is KDE SIG want
drop X11 and force user to use wayland .



Looking from the side I wonder If its the SIG or more the circumstances
that everything is in a forward flow and the SIG is facing it. So, if 
the best time was not two or one year ago, and obviously also not now.
When then? The fact is that there must be a point in time when the 
display server takes an evolution step forward.


Pressure in such transition helps to get forward, so I understand the
SIGs POV. Albeit, from the practical POV there are some issue and 
therefore X11 is still the place to be.


Maybe some elaboration should be done about the current state of X11 vs
Wayland (is it just nvidia?) and a timeframe calculation to have a 
resolution. Maybe it won't look so bad then and a interim solution is

then more acceptable.

--
Leon






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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[David Abdurachmanov]

On Thu, Feb 1, 2024 at 4:10 PM David Abdurachmanov
 wrote:
>
> On Thu, Feb 1, 2024 at 3:44 PM Richard W.M. Jones  wrote:
> >
> > On Thu, Feb 01, 2024 at 02:24:10PM +0100, Florian Weimer wrote:
> > > * David Abdurachmanov:
> > >
> > > > Hi Florian,
> > > >
> > > > I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> > > > but it failed. It seems to be related to your last commit.
> > > >
> > > > [..]
> > > > + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> > > > + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> > > > + set +x
> > > > + ln -s . usr/lib64/lp64d
> > > > ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> > > > error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> > > > [..]
> > > >
> > > > Full log: 
> > > > http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> > > > Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> > > >
> > > > This is probably related to this:
> > > > https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> > > >
> > > > Cheers,
> > > > david
> > > > - - -
> > > > [0] 
> > > > https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide
> > >
> > > That refers to:
> > >
> > > %ifarch riscv64
> > > # RISC-V ABI wants to install everything in /lib64/lp64d or 
> > > /usr/lib64/lp64d.
> > > # Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
> > > # 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
> > > for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
> > >   mkdir -p $d
> > >   (cd $d && ln -sf . lp64d)
> > > done
> > > %endif
> >
> > Although it was me who added this in 2018, I think it looks like a
> > mess now.  Why do we need this .../lp64d subdir for Fedora?
>
> That's because RISCV uses ../lib64/ as the default library path.
>
> [davidlt@fedora-riscv ~]$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' '\n'
> SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64/lp64d")
> SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64")
> SEARCH_DIR("=/usr/riscv64-redhat-linux/lib6464/lp64d")
> SEARCH_DIR("=/usr/lib6464/lp64d")
> SEARCH_DIR("=/usr/lib64")
> SEARCH_DIR("=/usr/local/lib64/lp64d")
> SEARCH_DIR("=/usr/local/lib64")
> SEARCH_DIR("=/lib64/lp64d")
> SEARCH_DIR("=/lib64")
> SEARCH_DIR("=/usr/lib64/lp64d")
> SEARCH_DIR("=/usr/riscv64-redhat-linux/lib")
> SEARCH_DIR("=/usr/local/lib")
> SEARCH_DIR("=/lib")
> SEARCH_DIR("=/usr/lib")

I forgot to attach the default search paths for ld-linux-riscv6-lp64d.so.1:

[..]
Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib64/lp64d (system search path)
  /usr/lib64/lp64d (system search path)
[..]

>
> There are some (probably now old) binutils versions that didn't even
> look at the lib64 directory at all.
>
> Thus by default RISCV looks like multilib, and looks into the proper
> ABI directories.
>
> We actually compile GCC as multilib with just one ABI listed.
>
> [..]
> --with-arch=rv64gc --with-abi=lp64d --with-multilib-list=lp64d
> [..]
>
> >
> > > Please try this:
> > >
> > > diff --git a/glibc.spec b/glibc.spec
> > > index 6116752..e4d5e44 100644
> > > --- a/glibc.spec
> > > +++ b/glibc.spec
> > > @@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
> > >   set +x
> > >   slbase=$(basename $sl)
> > >   sltarget=$(basename $(readlink $sl))
> > > + if test "$sltarget" = . ; then
> > > + # This is the lp64d symbolic link on riscv64, see above.
> > > + continue
> > > + fi
> > >   if ! test -r usr/$lib/$sltarget; then
> > >   echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
> > >   exit 1
> > >
> > > We will have to fix this again (and wrap-find-debuginfo.sh and as well)
> > > once Fedora adopts the standard RISC-V paths.
> >
> > Shouldn't we adopt the normal Fedora paths instead?
>
> That's definitely a discussion object, but we need to check if this
> actually works.
>
> Basically RISCV doesn't comply with FHS, unless something changed.
>
> david
>
> >
> > 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
> >
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[David Abdurachmanov]

On Thu, Feb 1, 2024 at 3:44 PM Richard W.M. Jones  wrote:
>
> On Thu, Feb 01, 2024 at 02:24:10PM +0100, Florian Weimer wrote:
> > * David Abdurachmanov:
> >
> > > Hi Florian,
> > >
> > > I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> > > but it failed. It seems to be related to your last commit.
> > >
> > > [..]
> > > + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> > > + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> > > + set +x
> > > + ln -s . usr/lib64/lp64d
> > > ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> > > error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> > > [..]
> > >
> > > Full log: 
> > > http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> > > Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> > >
> > > This is probably related to this:
> > > https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> > >
> > > Cheers,
> > > david
> > > - - -
> > > [0] 
> > > https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide
> >
> > That refers to:
> >
> > %ifarch riscv64
> > # RISC-V ABI wants to install everything in /lib64/lp64d or 
> > /usr/lib64/lp64d.
> > # Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
> > # 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
> > for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
> >   mkdir -p $d
> >   (cd $d && ln -sf . lp64d)
> > done
> > %endif
>
> Although it was me who added this in 2018, I think it looks like a
> mess now.  Why do we need this .../lp64d subdir for Fedora?

That's because RISCV uses ../lib64/ as the default library path.

[davidlt@fedora-riscv ~]$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' '\n'
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64/lp64d")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib6464/lp64d")
SEARCH_DIR("=/usr/lib6464/lp64d")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib64/lp64d")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64/lp64d")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64/lp64d")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")

There are some (probably now old) binutils versions that didn't even
look at the lib64 directory at all.

Thus by default RISCV looks like multilib, and looks into the proper
ABI directories.

We actually compile GCC as multilib with just one ABI listed.

[..]
--with-arch=rv64gc --with-abi=lp64d --with-multilib-list=lp64d
[..]

>
> > Please try this:
> >
> > diff --git a/glibc.spec b/glibc.spec
> > index 6116752..e4d5e44 100644
> > --- a/glibc.spec
> > +++ b/glibc.spec
> > @@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
> >   set +x
> >   slbase=$(basename $sl)
> >   sltarget=$(basename $(readlink $sl))
> > + if test "$sltarget" = . ; then
> > + # This is the lp64d symbolic link on riscv64, see above.
> > + continue
> > + fi
> >   if ! test -r usr/$lib/$sltarget; then
> >   echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
> >   exit 1
> >
> > We will have to fix this again (and wrap-find-debuginfo.sh and as well)
> > once Fedora adopts the standard RISC-V paths.
>
> Shouldn't we adopt the normal Fedora paths instead?

That's definitely a discussion object, but we need to check if this
actually works.

Basically RISCV doesn't comply with FHS, unless something changed.

david

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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Richard W.M. Jones]

On Thu, Feb 01, 2024 at 02:24:10PM +0100, Florian Weimer wrote:
> * David Abdurachmanov:
> 
> > Hi Florian,
> >
> > I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> > but it failed. It seems to be related to your last commit.
> >
> > [..]
> > + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> > + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> > + set +x
> > + ln -s . usr/lib64/lp64d
> > ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> > error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> > [..]
> >
> > Full log: 
> > http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> > Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> >
> > This is probably related to this:
> > https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> >
> > Cheers,
> > david
> > - - -
> > [0] 
> > https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide
> 
> That refers to:
> 
> %ifarch riscv64
> # RISC-V ABI wants to install everything in /lib64/lp64d or /usr/lib64/lp64d.
> # Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
> # 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
> for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
>   mkdir -p $d
>   (cd $d && ln -sf . lp64d)
> done
> %endif

Although it was me who added this in 2018, I think it looks like a
mess now.  Why do we need this .../lp64d subdir for Fedora?

> Please try this:
> 
> diff --git a/glibc.spec b/glibc.spec
> index 6116752..e4d5e44 100644
> --- a/glibc.spec
> +++ b/glibc.spec
> @@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
>   set +x
>   slbase=$(basename $sl)
>   sltarget=$(basename $(readlink $sl))
> + if test "$sltarget" = . ; then
> + # This is the lp64d symbolic link on riscv64, see above.
> + continue
> + fi
>   if ! test -r usr/$lib/$sltarget; then
>   echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
>   exit 1
> 
> We will have to fix this again (and wrap-find-debuginfo.sh and as well)
> once Fedora adopts the standard RISC-V paths.

Shouldn't we adopt the normal Fedora paths instead?

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steve Cossette]

On 2024-02-01 8:18 a.m., Sérgio Basto wrote:

On Thu, 2024-02-01 at 07:08 -0500, Steve Cossette wrote:

So, if you all don't mind, I'd like to steer this discussion in a
slightly different way:

What is the definition of a Fedora Change Proposal?

Proposal was not accepted by many members of the community try accept
that .
A proposal will always have opposing members, that's how it always is 
for everything in life. That's why Fesco then makes a judgement call and 
decides on what to do. But I do believe your reply was besides the point.




I was under the impression it was an announcement of intent by the
maintainers of a specific subset of the fedora project to "change"
something. Once said announcement has been discussed publicly, Fesco
(Sorry if the capitals are incorrect) discusses it internally
(albeit, publicly) and either blocks or approves the change, making
it official.

(Please note: The following paragraphs will use "we" as a pronoun
which is intended to be the Fedora project as a whole)

Once approved, we announced our intent to drop X11 from the KDE spin
of Fedora. That announcement has gained traction everywhere, got
publicized and everything. As Neal Gompa also stated, it has already
caused some substantial development effort upstream to effectively
iron out the rough edges of many of the problems, with what I assume
is more to come.

My fear is that, while those x11 libraries/runtimes/... would indeed
no longer be maintained by the KDE sig, we would basically just be
partially rolling back that initial proposal. And the quality of said
packages would also maybe suffer from them being updated separately,
which might also reflect poorly on us (again, in this context, "us" =
the Fedora Project).

First, KDE SIG people are not the only persons that support and
maintain KDE , I'm maintainer of smb4k , kdenlive, kwave , smplayer and
more packages related with KDE and Qt .

The problem is not KDE SIG not support X11, the problem is KDE SIG want
drop X11 and force user to use wayland .

The other problem is not reach to an agreement with some members of KDE
SIG , which they think that can impose his decisions .


Yes, and we (Again, as-in, the Fedora community) deeply appreciates you 
for your contributions. I was, again, trying to make a big picture 
comment about the whole thing, not as an attack on you specifically.


And yes, that /is/ the whole point: We want to foster the use of 
Wayland, to increase it's adoption, to force people using it to hit 
snags along the road and fill tickets so those issues can be fixed.


You'd be amazed how many issues I've seen being fixed in the last couple 
months.





It would also introduce a precedent: What if later a proposal is made
to remove some old drivers from, let's say, the kernel, and someone
decides to package it, undermining the general efforts of that
proposal?

Hopefully I'm making sense. Writing this 30mins after waking up might
not have helped. What I'm trying to say basically is, I get that for
some legacy nvidia users the Wayland experience may not be optimal.
But will it ever be? Does that mean we can never drop x11? Will
anyone ever update those legacy nvidia drivers? Could they be?

Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a
écrit :

Link to the FESCo ticket:https://pagure.io/fesco/issue/3165

and I'm very upset

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


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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Florian Weimer]

* David Abdurachmanov:

> Hi Florian,
>
> I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> but it failed. It seems to be related to your last commit.
>
> [..]
> + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> + set +x
> + ln -s . usr/lib64/lp64d
> ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> [..]
>
> Full log: 
> http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
>
> This is probably related to this:
> https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
>
> Cheers,
> david
> - - -
> [0] 
> https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide

That refers to:

%ifarch riscv64
# RISC-V ABI wants to install everything in /lib64/lp64d or /usr/lib64/lp64d.
# Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
# 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
mkdir -p $d
(cd $d && ln -sf . lp64d)
done
%endif

Please try this:

diff --git a/glibc.spec b/glibc.spec
index 6116752..e4d5e44 100644
--- a/glibc.spec
+++ b/glibc.spec
@@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
set +x
slbase=$(basename $sl)
sltarget=$(basename $(readlink $sl))
+   if test "$sltarget" = . ; then
+   # This is the lp64d symbolic link on riscv64, see above.
+   continue
+   fi
if ! test -r usr/$lib/$sltarget; then
echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
exit 1

We will have to fix this again (and wrap-find-debuginfo.sh and as well)
once Fedora adopts the standard RISC-V paths.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-01 at 07:08 -0500, Steve Cossette wrote:
> So, if you all don't mind, I'd like to steer this discussion in a
> slightly different way: 
> 
> What is the definition of a Fedora Change Proposal?

Proposal was not accepted by many members of the community try accept
that .


> I was under the impression it was an announcement of intent by the
> maintainers of a specific subset of the fedora project to "change"
> something. Once said announcement has been discussed publicly, Fesco
> (Sorry if the capitals are incorrect) discusses it internally
> (albeit, publicly) and either blocks or approves the change, making
> it official.
> 
> (Please note: The following paragraphs will use "we" as a pronoun
> which is intended to be the Fedora project as a whole)
> 
> Once approved, we announced our intent to drop X11 from the KDE spin
> of Fedora. That announcement has gained traction everywhere, got
> publicized and everything. As Neal Gompa also stated, it has already
> caused some substantial development effort upstream to effectively
> iron out the rough edges of many of the problems, with what I assume
> is more to come.
> 
> My fear is that, while those x11 libraries/runtimes/... would indeed
> no longer be maintained by the KDE sig, we would basically just be
> partially rolling back that initial proposal. And the quality of said
> packages would also maybe suffer from them being updated separately,
> which might also reflect poorly on us (again, in this context, "us" =
> the Fedora Project).

First, KDE SIG people are not the only persons that support and
maintain KDE , I'm maintainer of smb4k , kdenlive, kwave , smplayer and
more packages related with KDE and Qt .

The problem is not KDE SIG not support X11, the problem is KDE SIG want
drop X11 and force user to use wayland .

The other problem is not reach to an agreement with some members of KDE
SIG , which they think that can impose his decisions .

> 
> It would also introduce a precedent: What if later a proposal is made
> to remove some old drivers from, let's say, the kernel, and someone
> decides to package it, undermining the general efforts of that
> proposal?
> 
> Hopefully I'm making sense. Writing this 30mins after waking up might
> not have helped. What I'm trying to say basically is, I get that for
> some legacy nvidia users the Wayland experience may not be optimal.
> But will it ever be? Does that mean we can never drop x11? Will
> anyone ever update those legacy nvidia drivers? Could they be?
> 
> Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a
> écrit :
> > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> > 
> > and I'm very upset 
> > 
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue

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

[rpms/perl-TermReadKey] PR #2: Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-TermReadKey` that you 
are following.

Merged pull-request:

``
Package tests
``

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Naheem Zaffar]

Another option is to allow the x11-compatible packages but as a clearly
forked desktop with a clearly different name

On Thu, 1 Feb 2024, 12:10 Steve Cossette,  wrote:

> So, if you all don't mind, I'd like to steer this discussion in a slightly
> different way:
>
> What *is* the definition of a Fedora Change Proposal?
>
> I was under the impression it was an announcement of intent by the
> maintainers of a specific subset of the fedora project to "change"
> something. Once said announcement has been discussed publicly, Fesco (Sorry
> if the capitals are incorrect) discusses it internally (albeit, publicly)
> and either blocks or approves the change, making it official.
>
> *(Please note: The following paragraphs will use "we" as a pronoun which
> is intended to be the Fedora project as a whole)*
>
> Once approved, we announced our intent to drop X11 from the KDE spin of
> Fedora. That announcement has gained traction everywhere, got publicized
> and everything. As Neal Gompa also stated, it has already caused some
> substantial development effort upstream to effectively iron out the rough
> edges of many of the problems, with what I assume is more to come.
>
> My fear is that, while those x11 libraries/runtimes/... *would* indeed no
> longer be maintained by the KDE sig, we would basically just be partially
> rolling back that initial proposal. And the quality of said packages would
> also maybe suffer from them being updated separately, which might also
> reflect poorly on us (*again, in this context, "us" = the Fedora Project)*
> .
>
> It would also introduce a precedent: What if later a proposal is made to
> remove some old drivers from, let's say, the kernel, and someone decides to
> package it, undermining the general efforts of that proposal?
>
> Hopefully I'm making sense. Writing this 30mins after waking up might not
> have helped. What I'm trying to say basically is, I get that for some
> legacy nvidia users the Wayland experience may not be optimal. But will it
> *ever* be? Does that mean we can never drop x11? Will anyone ever update
> those legacy nvidia drivers? *Could they be?*
>
> Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a
> écrit :
>
>> Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>>
>> and I'm very upset
>>
>> --
>> Sérgio M. B.
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-TermReadKey] PR #2: Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-TermReadKey` that 
you are following:
``
Package tests
``

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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Richard W.M. Jones]

[Adding Fedora devel]

On Thu, Feb 01, 2024 at 02:29:41PM +0200, David Abdurachmanov wrote:
> Hi Florian,
> 
> I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> but it failed. It seems to be related to your last commit.
> 
> [..]
> + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> + set +x
> + ln -s . usr/lib64/lp64d
> ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> [..]
> 
> Full log: 
> http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> 
> This is probably related to this:
> https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> 
> Cheers,
> david
> - - -
> [0] 
> https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide

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

[rpms/perl-threads] PR #2: Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-threads` that you are 
following.

Merged pull-request:

``
Package tests
``

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

[rpms/perl-threads] PR #2: Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-threads` that you 
are following:
``
Package tests
``

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steve Cossette]

So, if you all don't mind, I'd like to steer this discussion in a slightly
different way:

What *is* the definition of a Fedora Change Proposal?

I was under the impression it was an announcement of intent by the
maintainers of a specific subset of the fedora project to "change"
something. Once said announcement has been discussed publicly, Fesco (Sorry
if the capitals are incorrect) discusses it internally (albeit, publicly)
and either blocks or approves the change, making it official.

*(Please note: The following paragraphs will use "we" as a pronoun which is
intended to be the Fedora project as a whole)*

Once approved, we announced our intent to drop X11 from the KDE spin of
Fedora. That announcement has gained traction everywhere, got publicized
and everything. As Neal Gompa also stated, it has already caused some
substantial development effort upstream to effectively iron out the rough
edges of many of the problems, with what I assume is more to come.

My fear is that, while those x11 libraries/runtimes/... *would* indeed no
longer be maintained by the KDE sig, we would basically just be partially
rolling back that initial proposal. And the quality of said packages would
also maybe suffer from them being updated separately, which might also
reflect poorly on us (*again, in this context, "us" = the Fedora Project)*.

It would also introduce a precedent: What if later a proposal is made to
remove some old drivers from, let's say, the kernel, and someone decides to
package it, undermining the general efforts of that proposal?

Hopefully I'm making sense. Writing this 30mins after waking up might not
have helped. What I'm trying to say basically is, I get that for some
legacy nvidia users the Wayland experience may not be optimal. But will it
*ever* be? Does that mean we can never drop x11? Will anyone ever update
those legacy nvidia drivers? *Could they be?*

Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a écrit :

> Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>
> and I'm very upset
>
> --
> Sérgio M. B.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Alessandro Astone]

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 01, 2024 at 07:51:59AM +, Neal Gompa wrote:
[snip]
> My position as the KDE SIG lead based on discussions within the SIG is
> that re-introducing these packages in the main distribution would
> destroy the main point of our efforts: driving KDE Plasma Wayland to
> be the best and most complete experience. The signal of dropping
> Plasma X11 largely drove a lot of improvements in Plasma 6 very
> quickly that I do not believe would have otherwise occurred.
[snip]
> The consensus from the KDE SIG is that we believe that reintroducing
> the packages into the distribution will not only unwind a major part
> of the approved Change, but it will add complications for the SIG for
> shipping updates to KDE Plasma on the cadence that we typically do and
> we would rather the X11 packages stay in COPR.

All of what you wrote (in the snipped parts too) is true. But we have
to take into account that there is a bunch of people who want to work
on the alternate approach. It's their right and we shouldn't _force_
obsolescence of older software, especially if it still has users.
The sitatation with X11 is complicated: many people report that it
still works better for them (whatever the reasons may be).
So I think that it's fine to say "KDE SIG, go ahead, do your thing
without waiting for X11", but it's not fine to say "we will forbid having
KDE-X11 packages in Fedora".

Zbyszek


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

Re: Orphaning python-represent

[Michel Lind]

On Wed, Jan 24, 2024 at 05:48:58PM +0100, Lumír Balhar wrote:
> Hello.
> 
> I'm going to orphan python-represent. I updated it to the latest version so
> if you take it, there is nothing to be done now. It's a leaf package and I
> don't have any use for it.
> 
I've taken it, thanks!

-- 
Michel Lind (né 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 31, 2024 at 09:27:52PM -, Alessandro Astone wrote:
> I can support that.
> 
> But am I supposed to ignore the fact that kkofler is already bullying the KDE 
> SIG into not breaking that one other package they maintain that occasionally 
> breaks on kde updates? See example: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
> 
> Am I going to have to see kkofler rant in every plasma update that their xorg 
> stack breaks?

I hope not ;) Essentially, the proposed resolution say that it's OK to
ignore packages that part of the -x11 stack if they haven't been fixed
sufficiently quickly. 

On Wed, Jan 31, 2024 at 10:38:27PM -, Alessandro Astone wrote:
> The "personal attack" is a consideration on the proposed maintainer of these 
> packages.
>
> > every effort in order to not to break things must be made.

This describes the normal policy for updates. Here we are talking
about an exception: every effort DOES NOT have to be made. I assume
the maintainers will do what is reasonable, but the only strict
requirement is a "notice before major changes".

KDE is already subject an Updates Policy exception that allows major
updates in stable releases [1,2]. This will make it harder for the -x11
stack to keep up.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#kde
[2] https://fedoraproject.org/wiki/SIGs/KDE/Update_policy

> Then I cannot support these packages being added. It is putting
> additional effort on the KDE-SIG up to once per every week;
> especially since we're at the beginning of the Plasma 6 release
> cycle and releases are going to be hectic.
> The proposed resolutions by adamw, zbyszek, etc. seem to imply that
> it would not be required. blogilo is as much of a
> non-release-blocking component as plasma-workspace-x11 would be.

This all sounds like maintaining the -x11 stack will be a lot of work.
Nevertheless, with the proposed resolution, this is not _your_ problem.
It's the job of the folks who signed up to maintain the older packages
to do that.

I know that you expect that this will cause additional friction
and user confusion and slows things down. I expect that you are right.
Things would be a bit smoother if we dropped the -x11 packages
completely, but in this case, the reasons to not do that are
also important.

Firstly, Fedora is about letting people work on the stuff that they
want to work on. We can't and — I'm very certain — shouldn't prevent
people from working on the -x11 stack if they want to. By the same
token, I support your desire to not work on the -x11 and concentrate
on the wayland variants.

Secondly, there are strong benefits from having packages in the main
distro. The proposed approaches with a copr or other form of external
packages are possible, and would be OK for more advanced users, but
it's just easier and more secure for "normal" users if packages are in
the main repo. If it turns out that this approach doesn't work, we
can always move to one of the other approaches later (or abandon
the old stack completely).

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

Re: Orphaned python-mccabe (dependency of pylint)

[Michel Lind]

On Thu, Feb 01, 2024 at 01:03:55AM +0100, Miro Hrončok wrote:
> On 01. 02. 24 0:51, Michel Lind wrote:
> > I see limb already took the package (thanks limb) - note that the
> > default bugzilla assignee still seems to be 'orphan', I'm assuming that
> > will fix itself eventually
> 
> Not by itself, the package has a epel bugzilla contact override, so when the
> main admin changes, the fedora bugzilla contact needs to be changed as well.
> I've just done that.
> 
Thank you! python-hypothesmith now fixed, and confirmed working by
rebuilding python-libcst with tests enabled (which requires
hypothesmith).

The non-bootstrap python-libcst 1.1.0 is building in Koji now.

Best,

-- 
Michel Lind (né 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Re: A reminder: you cannot just "revert" package version bumps

[Gary Buhrmaster]

On Thu, Feb 1, 2024 at 3:11 AM Kevin Kofler via devel
 wrote:
>
> If the distro-sync (which should be the default way to do updates
> at least on Rawhide, if not everywhere) mentions a package being downgraded,
> that is much more likely to be noticed.
>

I look forward to your formal change proposal
to replace what we know of today as upgrade
to be distro-sync.

While I will reserve judgement on the proposal
until I see the full details, I am going to say
that as today I am dubious that that is the right
way forward.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mounting USB Storage devices with "sync" option ?

[Roberto Ragusa]

On 1/31/24 07:43, Abyss Ether via devel wrote:

I created a simple PoC udev rule to mount USB Storage devices with the "sync 
option.
Available here : 
https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules

Currently, USB Storage devices are mounted without the "sync" option, causing 
their writes to be cached.
This causes an issue, especially with GUI file managers like GNOME Files, where 
after a file copy operation, it would notify the user that the operation has 
been completed. If the user then tries to unmount the USB Storage device, they 
get notified that data is still being written to disk and that they should not 
remove the USB Storage device from their PC/Laptop/device.


Users should have learned to use "eject", this should be known since Windows 98,
it is 25 years ago.
Why should I be forced to work around terrible speed by default on my backup 
drive
because of these clueless users?

Regards.

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

Re: Figure out what killed an app (rhbz#2253099)

[Ondrej Mosnáček]

On Thu, 1 Feb 2024 at 09:13, Milan Crha  wrote:
> The kernel tracing log for sig==9 shows:
>
> gnome-terminal--2924[002] dN.2.  2520.462889: signal_generate:
> sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0
>
> There is no such thing (apart of the tracing log) when Evolution is
> suddenly killed, the logs are muted. That makes me believe it's not the
> OOM killer whom kills the application. I'm back at square 1; or maybe
> square 2, as I know possibly kernel sends it, but not why.

Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as
root) and then collect the kernel trace again. That should give you a
backtrace of kernel functions from the signal generation, which could
help you/us to figure out the reason the process was killed.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

[Milan Crha]

On Wed, 2024-01-31 at 13:40 -0500, Paul Grosu wrote:
> 2) Or you can completely disable it:

Hi,
I do not want to disable the oom service. Remember, it does that on
user machines, not only on mine. Telling people: "you want to use app
a, b, c, then disable oom" as a new Fedora 40 feature is not great ;)

Nonetheless, I though I'll give it a try and will trigger the oom, to
see what it does. I wrote a little app to allocate gigabytes of memory
(until malloc() returns NULL) and one process was not enough, thus I
ran second and then third and then I've been notified by a gnome-shell
bubble telling me "Virtual Terminal Stopped" with a reason that memory
is almost full. Looking on the terminals the second process I ran had
been killed and the `dmesg` shows a reason:

[ 1712.960372] oom-
kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0
,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/ap
p.slice/app-org.gnome.Terminal.slice/vte-spawn-7f4b1469-38d1-498f-b363-
1c8311d2fcff.scope,task=alloc-too-much,pid=3323,uid=1000

[ 1712.960389] Out of memory: Killed process 3323 (alloc-too-much)
total-vm:137300925912kB, anon-rss:128kB, file-rss:1280kB, shmem-
rss:0kB, UID:1000 pgtables:1544608kB oom_score_adj:200

The journal contains similar information, plus a lot of debugging
information from kernel, starting with:

Feb 01 08:45:47 localhost.localdomain kernel: alloc-too-much invoked
oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP),
order=0,...

The kernel tracing log for sig==9 shows:

gnome-terminal--2924[002] dN.2.  2520.462889: signal_generate:
sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0

There is no such thing (apart of the tracing log) when Evolution is
suddenly killed, the logs are muted. That makes me believe it's not the
OOM killer whom kills the application. I'm back at square 1; or maybe
square 2, as I know possibly kernel sends it, but not why.

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