Re: SPDX Statistics - Eight-hour day edition

[Miroslav Suchý]

Dne 05. 01. 24 v 7:38 Miroslav Suchý napsal(a):


Hot news:


I forgot to mention one thing:

To ease the migration I created a scantool-tookit reports for remaining 
packages. It is available here

http://miroslav.suchy.cz/fedora/spdx-reports/

Right now there are missing packages from ELN set and all other missing Fedora packages from A to L. The script 
generating the reports is still running - It has been running whole Chrismas.


If your package is missing wait few more days. Or you can install 
scancode-toolkit and run:
~/.local/bin/scancode --license --html /tmp/spdx.html --license-references  .


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
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

SPDX Statistics - Eight-hour day edition

[Miroslav Suchý]

Hot news:

The process of adding licenses is back on track.

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 has been submitted.

Now lets dive into numbers:

Two weeks ago we had:


* 23562 spec files in Fedora

* 30067license tags in all spec files

* 11907 tags have not been converted to SPDX yet

* 5370tags can be trivially converted using `license-fedora2spdx`

* Progress: 60,04% ░░ 100%

ELN subset:

507 out of 3734 packages are not converted yet (progress 86.42%)



Today we have:

* 23542 spec files in Fedora

* 30058license tags in all spec files

* 11715 tags have not been converted to SPDX yet

* 5266tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,03% ░░ 100%

ELN subset:

290 out of 2457 packages are not converted yet (progress 88.20%)

Graph of these data with the burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

The list of packages needed to be converted is here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released. With 6 new licenses (plus some public domain declarations). 17 
licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked


Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.


New projection when we will be finished is 2024-11-30 (+16 days from last 
report).  Pure linear approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.


Why Eight-hour day? It is reference to working hours per day. Until early of 20th century it was common that working day 
ranged from 10 to 16 hours. There were numerous strikes and fights to lower it to 12 and 10. And later to 8. Until 5 
January 1914 when the Ford Motor Company took the radical step of doubling pay to $5 a day (equivalent to $150) and 
cutting shifts from nine hours to eight. When their profit margin doubled next year, other companies started to follow.


https://en.wikipedia.org/wiki/Eight-hour_day

Miroslav


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

Un-retire python-pyngus

[Hirotaka Wakabayashi via devel]

Hello everyone, 

 I would like to become the owner of python-pyngus[1]. This package was retired 
 half a year ago as a FTBFS/FTI bugs[2]. python-qpid-proton, which is a 
dependent package of python-pyngus and was the reason for the installation 
failure, is now provided in Fedora39 and Rawhide, and I have successfully built 
the package on Fedora39[3] and Rawhide[4].

---[1] https://src.fedoraproject.org/rpms/python-pyngus[2] 
https://bugzilla.redhat.com/show_bug.cgi?id=2184027 
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=111316391[4] 
https://koji.fedoraproject.org/koji/taskinfo?taskID=111315058
Best Regards,
Hirotaka
--
___
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 2256688] perl-Pod-Parser-1.67 is available

[bugzilla]

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



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

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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256688%23c7
--
___
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: Turning a XImage * into a Drawable for use with XRenderCreatePicture

[Peter Hutterer]

On Thu, Jan 04, 2024 at 06:27:01PM +0100, Florian Weimer wrote:
> The pcb-rnd package contains a call:
> 
> XRenderCreatePicture(display, lpm->img_scaled, 
> XRenderFindVisualFormat(display, DefaultVisual(display, screen)), 0, 0);
> 
> The issue here is that lpm->img_scaled is an XImage *, but
> XRenderCreatePicture expected a Drawable as its second argument.
> 
> Any idea how to turn an XImage into a Drawable?

After digging through the Xlib sources a bit: an XImage is a
Xlib-specific struct that abstracts some manipulation functions. Unlike
a Drawable which exists on the protocol. You don't do anything with an
XImage except eventually rendering it to a Drawable.

So in this case - I guess look for where the lpm->img_scale is used on a
drawable and assume that's the drawable you want to use for the XRender
call. Which may or may not be lpm->pm_scaled in this case, I don't know
what the code does but it looks like that's the drawable the image
renders to.

> Not sure how this currently works, but GCC 14 refuse to compile this, as
> a C type error (using a pointer as an integer).

It cannot currently work. From XRenderCreatePicture() [1]:
  req->drawable = (CARD32) drawable;

which means that (parts of) the pointer value is sent to the server as
XID and the server should return BadDrawable unless you're really
(un)lucky with your pointer value.

Cheers,
  Peter

[1] 
https://gitlab.freedesktop.org/xorg/lib/libxrender/-/blob/master/src/Picture.c?ref_type=heads#L91
--
___
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 2256688] perl-Pod-Parser-1.67 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256688%23c6
--
___
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: Non responsive maintainer check for marxin

[Priscila Gutierres]

I would like to apologize if it seems that I’m being rude asking for a
review in this thread.
My point of view is that if the package is a dependency and no one is
looking on it, it would be a priority to keep it up to date.
I don’t know if merging it would be possible, since the maintainer is not
responding, if not, I can close it.
Also, I noticed any maintainer can merge it.
I am a new maintainer and I don’t want to create polemics, I am here to
hear and learn, but if I don’t participate in the discussion is more hard
to learn. In any case, I apologize again if I was impolite.


Em qui., 4 de jan. de 2024 às 20:07, Sandro  escreveu:

> On 04-01-2024 23:05, Priscila Gutierres wrote:
> > I bumped python-pebble to the latest version.
> > Can someone please review this PR?
> > https://src.fedoraproject.org/rpms/python-pebble/pull-request/3
>
> Reviewing the PR is not a problem. However, who would merge it, once
> approved? That needs a proven packager in the current situation, since
> the sole maintainer is unresponsive.
>
> No offense, but you are kinda hijacking this thread.
>
> -- Sandro
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: Non responsive maintainer check for marxin

[Sandro]

On 04-01-2024 23:05, Priscila Gutierres wrote:

I bumped python-pebble to the latest version.
Can someone please review this PR?
https://src.fedoraproject.org/rpms/python-pebble/pull-request/3


Reviewing the PR is not a problem. However, who would merge it, once 
approved? That needs a proven packager in the current situation, since 
the sole maintainer is unresponsive.


No offense, but you are kinda hijacking this thread.

-- Sandro

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

Re: Non responsive maintainer check for marxin

[Priscila Gutierres]

I bumped python-pebble to the latest version.
Can someone please review this PR?
https://src.fedoraproject.org/rpms/python-pebble/pull-request/3


On Tue, Jan 2, 2024 at 5:05 PM Sandro  wrote:

> On 02-01-2024 20:28, Priscila Gutierres wrote:
> > Does any package depend on python-pebble?
> > I could not find anything running repoquery  --whatrequires python-pebble
>
> You need to query for `python3-pebble`.
>
> $ dnf repoquery --whatrequires python3-pebble
> Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02.
> cvise-0:2.8.0-1.fc39.x86_64
> python3-bluepyopt-0:1.14.3-1.fc39.x86_64
> python3-bluepyopt-0:1.14.6-5.fc39.x86_64
>
> I use `fedrq` these days.
>
> $ fedrq wr -s python3-pebble
> cvise-2.9.0-1.fc40.src
> python-bluepyopt-1.14.6-5.fc40.src
>
> -- Sandro
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: ARM PAC on koji vs COPR

[Jarek Prokop]

On 1/4/24 16:10, Jarek Prokop wrote:


On 1/4/24 10:47, Florian Weimer wrote:

* Jarek Prokop:


This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the
flag with pac-ret seems to be appended to libruby.so in the case of
the upstream fix [2].

>From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?


Not sure how I would check that.


By compiling on an ARM machine, duh!

Compiling with file test.c like this:
~~~
$ cat test.c
#include 
#include 

int main() {
    printf("%d", __ARM_FEATURE_BTI_DEFAULT);
    printf("%d", __ARM_FEATURE_PAC_DEFAULT);
    return 0;
}
$ gcc -mbranch-protection=standard -mbranch-protection=pac-ret test.c
test.c: In function ‘main’:
test.c:5:18: error: ‘__ARM_FEATURE_BTI_DEFAULT’ undeclared (first use in 
this function)

    5 | printf("%d", __ARM_FEATURE_BTI_DEFAULT);
  |  ^
test.c:5:18: note: each undeclared identifier is reported only once for 
each function it appears in

~~~
So it seems anything related to BTI gets actually skipped in the 
upstream Context.S file, since their only option is for `=pac-ret`.

And for completenes, same file, but with =standard:
~~~
$ gcc -mbranch-protection=standard test.c
$ ./a.out
11
~~~

tl;dr No, it doesn't seem to remain enabled if this double definition is 
done.


Thanks,
Jarek
--
___
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: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote:
> I just wanted to give you a quick heads-up that I plan to enable the
> BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
> gets distributed to mirrors.

This has happened now.  Fedora Copr builds F40 (Rawhide) with DNF5 now.
Should you face any issue, please report it.

Thanks!
Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
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: Schedule for Thursday's FESCo Meeting (2024-01-04)

[Stephen Gallagher]

=
#fedora-meeting-2: FESCO (2024-01-04)
=


Meeting started by sgallagh at 17:00:18 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2024-01-04/fesco.2024-01-04-17.00.log.html
.



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

* #3101 Change: Remove OpenSSL Compat  (sgallagh, 17:09:26)
  * AGREED: The Change is approved, any package still depending on
openssl-compat at Beta Freeze will be dropped from Fedora at that
time. (+7, 0, -1)  (sgallagh, 17:26:11)

* New Meeting Time  (sgallagh, 17:26:47)
  * LINK: https://whenisgood.net/agyhckd/results/sxn8wpk   (sgallagh,
17:27:11)
  * The new FESCo meeting time will be at 1930 UTC, beginning on
2024-01-16  (sgallagh, 17:41:35)

* Next Week's Chair  (sgallagh, 17:43:23)
  * ACTION: sgallagh to send out the voting announcements on 2024-01-08
(sgallagh, 17:44:02)
  * ACTION: tstellar will chair the 2024-01-15 meeting and offers to
mentor jistone at the same time  (sgallagh, 17:49:40)

* Open Floor  (sgallagh, 17:49:52)
  * ACTION: sgallagh to update the FESCo Meeting Process with new
bat-time, new bat-location  (sgallagh, 17:57:15)

Meeting ended at 18:01:26 UTC.




Action Items

* sgallagh to send out the voting announcements on 2024-01-08
* tstellar will chair the 2024-01-15 meeting and offers to mentor
  jistone at the same time
* sgallagh to update the FESCo Meeting Process with new bat-time, new
  bat-location




Action Items, by person
---
* jistone
  * tstellar will chair the 2024-01-15 meeting and offers to mentor
jistone at the same time
* sgallagh
  * sgallagh to send out the voting announcements on 2024-01-08
  * sgallagh to update the FESCo Meeting Process with new bat-time, new
bat-location
* tstellar
  * tstellar will chair the 2024-01-15 meeting and offers to mentor
jistone at the same time
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (80)
* Son_Goku (39)
* nirik (21)
* dcantrell (20)
* zbyszek (18)
* zodbot (17)
* jistone (17)
* jednorozec (17)
* tstellar (8)
* michel-slm (7)
* smooge (6)
* decathorpe (4)
* jonathanspw (2)
* humaton (0)
* mhayden (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)
* Eighth_Doctor (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
--
___
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: rawhide missing xgettext: command not found

[Michael J Gruber]

Am Do., 4. Jan. 2024 um 18:29 Uhr schrieb Martin Gansser
:
>
> Hi,
>
> when compiling vdr-extrecmenung for rawhide fc40 the error message [1] 
> "/bin/sh: line 1: xgettext: command not found" appears
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/6182/111296182/build.log
>
> How can i solve this ?

Add
BuildRequires: gettext
to the spec?

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

rawhide missing xgettext: command not found

[Martin Gansser]

Hi,

when compiling vdr-extrecmenung for rawhide fc40 the error message [1] 
"/bin/sh: line 1: xgettext: command not found" appears

[1] https://kojipkgs.fedoraproject.org//work/tasks/6182/111296182/build.log

How can i solve this ?

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

Turning a XImage * into a Drawable for use with XRenderCreatePicture

[Florian Weimer]

The pcb-rnd package contains a call:

XRenderCreatePicture(display, lpm->img_scaled, XRenderFindVisualFormat(display, 
DefaultVisual(display, screen)), 0, 0);

The issue here is that lpm->img_scaled is an XImage *, but
XRenderCreatePicture expected a Drawable as its second argument.

Any idea how to turn an XImage into a Drawable?

Not sure how this currently works, but GCC 14 refuse to compile this, as
a C type error (using a pointer as an integer).

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

Update to dav1d v1.3.0 including soname bump coming to rawhide

[Fabio Valentini]

Hi all,

I am planning to push the update for dav1d v1.3.0 to rawhide. It
involves an soname bump from libdav1d.so.6 to libdav1d.so.7 due to
minor ABI changes. According to the release notes, there are were no
actual breaking changes to existing APIs, so the update should be
safe:

https://code.videolan.org/videolan/dav1d/-/blob/1.3.0/NEWS

As far as I can tell, the following packages will need to be rebuilt:

- ffmpeg
- firefox
- libavif
- libheif
- seamonkey
- vlc
- xine-lib

The builds will be handled in a side-tag by me, other provenpackagers,
or multimedia-sig members.

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 2256825] New: perl-App-cpm-0.997015 is available

[bugzilla]

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

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



Releases retrieved: 0.997015
Upstream release that is considered latest: 0.997015
Current version/release in rawhide: 0.997.014-1.fc40
URL: https://metacpan.org/release/App-cpm

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/8399/


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256825%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

[Bug 2256688] perl-Pod-Parser-1.67 is available

[bugzilla]

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



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256688%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

[Bug 2256688] perl-Pod-Parser-1.67 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-3437982daf has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3437982daf


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256688%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: ARM PAC on koji vs COPR

[Jarek Prokop]

On 1/4/24 10:47, Florian Weimer wrote:

* Jarek Prokop:


This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the
flag with pac-ret seems to be appended to libruby.so in the case of
the upstream fix [2].

 From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?


Not sure how I would check that.

But `-mbranch-protection=standard` should currently be BTI+PAC:

"standard turns on all types of branch protection.
    Currently standard implies pac-ret+bti."
--
https://developer.arm.com/documentation/102433/0200/Applying-these-techniques-to-real-code

Whether we end up with generated code that's also BTI is not certain. In 
any case it actually seems like
we want to not use that configure branch at all for now, as we can use 
just =standard and achieve better effect

than with the uncertain result of the combined flags that is happening now.

and if I understand the text correctly, we on Fedora with that =standard 
do not actually therefore need =pac-ret

for the -mbranch-protection flag.

Digging deeper in Arm's documentation regarding this, it seems the 
generated assembly is actually reasonably compatible

across CPU variants, or well... has the ability to be if it is handwritten



Can't you put -mbranch-protection=standard into ASFLAGS?
We probably can, and it might be the way to go for Fedora Ruby based on 
the mentioned ARM developer article. At least for the moment.

I'll inspect and see.


The check is a bit weird:

diff --git a/configure.ac b/configure.ac
index 9286946fc15f4..18b4247991d42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [
AS_FOR(option, opt, [-mbranch-protection=pac-ret 
-msign-return-address=all], [
  RUBY_TRY_CFLAGS(option, [branch_protection=yes], 
[branch_protection=no])
  AS_IF([test "x$branch_protection" = xyes], [
+# C compiler and assembler must be consistent for 
-mbranch-protection
+# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition.
  RUBY_APPEND_OPTION(XCFLAGS, option)
+RUBY_APPEND_OPTION(ASFLAGS, option)
  break
  ])
  ])



The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option.

That does sound better, I'll do some exploring for this.
Thanks for taking a look.



2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
up in the .so library and Ruby binary extensions link against that
solib, do the binary extensions also have to be compiled with that
exact option?

It depends on how fiber handling is implemented.  If fiber switching
relies on code in header files or that is statically linked into Ruby
extensions, then yes, these extensions will need to be compiled with PAC
support as well.  But I expect that this isn't the case, but haven't
checked it.  The relevant code should be in the Ruby DSO only and be
linked dynamically.
That seems to be our case, we do not ship static artifacts to link 
against AFAICT.

It also seems unlikely that many C extensions would be aware of fiber
switching, but I haven't checked that, either.
Quickly grepping through sources suggests that if extensions are aware 
of fiber switching,
they are doing it through the Ruby C-api that has responsible code in 
the DSO.


So I can probably scratch that concern off of my list.

3. If we do not fix this bug in Ruby 3.3.0 but wait with this for
3.3.1 where the fix will most probably land, will we by effect exclude
a subset of ARM CPUs, that actually have the PAC capability, for that
in-between period?

I think you should fix this with a backport.  It's going to impact quite
a few users.


4. Why do koji and copr have CPU flag set that differs so much? Is our
koji infra OK?

It's different machines, so they are expect to have different
capabilities.  This isn't even aarch64-specific.
I see. I didn't know how much different actually which was answered by 
other people here.



5. Why does it fail on copr and does not fail on koji? It seems the
paca/pacg have to be present and set on the CPU flags for the
segfaults to occur.

PAC is not process-switched on Linux.  If it is turned on at the
kernel/hypervisor level, it's currently impossible to turn off.  This is
not something the buildroot can control.  It's not 

Re: RISC-V ABI issue with ULEB128

[David Abdurachmanov]

On Thu, Jan 4, 2024 at 4:07 PM Nick Clifton  wrote:
>
> Hi David,
>
> > binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it
> > as failed. The failures don't seem to be related to binutils package
> > itself. Seems like CI test is/was broken, or maybe a temporary network
> > issue, or something else.
>
> It looks like rpminspect does not like two of the licenses used
> by the binutils:
>
>BAD
>Unapproved license in binutils-2.41-19.fc40.src:
>GPL-2.0-or-later LGPL-2.1-or-later
>
> Which seems wrong to me, since they are listed in the allowed
> licenses list for Fedora.  I'll ask David Cantrell about it.

I think this one was always failing. The one that probably causes the
issue in Bodhi is: fedora-ci.koji-build.tier0.functional

There is already a comment for binutils-2.41-19.fc40 in Bodhi.
Basically the existing test will fail due to wget -> wget2 change. It
sounds like you need to ignore this failing test for now.

Cheers,
david

>
> Cheers
>Nick
>
>
--
___
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 2256784] New: perl-Math-BigInt-FastCalc-0.5017 is available

[bugzilla]

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

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



Releases retrieved: 0.5017
Upstream release that is considered latest: 0.5017
Current version/release in rawhide: 0.501.600-1.fc40
URL: https://metacpan.org/dist/Math-BigInt-FastCalc/

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/12782/


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256784%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: RISC-V ABI issue with ULEB128

[Nick Clifton]

Hi David,


binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it
as failed. The failures don't seem to be related to binutils package
itself. Seems like CI test is/was broken, or maybe a temporary network
issue, or something else.


It looks like rpminspect does not like two of the licenses used
by the binutils:

  BAD
  Unapproved license in binutils-2.41-19.fc40.src:
  GPL-2.0-or-later LGPL-2.1-or-later

Which seems wrong to me, since they are listed in the allowed
licenses list for Fedora.  I'll ask David Cantrell about it.

Cheers
  Nick

--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Neal Gompa]

On Thu, Jan 4, 2024 at 7:50 AM Sam Varshavchik  wrote:
>
> Oron Peled writes:
>
> > • I.e: a developer that need cross-compilation, install the wanted
> > toolchain(s) and all library packages are immediately available from 
> > standard
> > repositories.
> >
> > I guess Fedora people that work on ARM/ARM64/RISC-V would love such a
> > support.
>
> There are a number deb packaging policies that rpm would be wise to adopt.
>
> A package's shared libraries get rolled into a separate 
> package right off the bat. An ABI break and a transition where both the new
> and the old libraries must coexist becomes a nothing-burger. The updated
> package's libraries go into a subpackage with, effectively, a new name that
> does not cause the older library's uninstallation. There is no need to
> create a compat package. It's the same package, from the previous version.
>

That is not a deb vs rpm thing, plenty of rpm distributions do it. We
don't do it in Fedora because we don't want it to be automatic for
older libraries to hang around, plain and simple.



-- 
真実はいつも一つ！/ 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

[rpms/perl-Pod-Parser] PR #11: 1.67 bump

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Pod-Parser` that you 
are following.

Merged pull-request:

``
1.67 bump
``

https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/11
--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Sam Varshavchik]

Oron Peled writes:

• I.e: a developer that need cross-compilation, install the wanted  
toolchain(s) and all library packages are immediately available from standard  
repositories.


I guess Fedora people that work on ARM/ARM64/RISC-V would love such a  
support.


There are a number deb packaging policies that rpm would be wise to adopt.

A package's shared libraries get rolled into a separate   
package right off the bat. An ABI break and a transition where both the new  
and the old libraries must coexist becomes a nothing-burger. The updated  
package's libraries go into a subpackage with, effectively, a new name that  
does not cause the older library's uninstallation. There is no need to  
create a compat package. It's the same package, from the previous version.




pgphaQFO76cNT.pgp
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

[rpms/perl-Pod-Parser] PR #11: 1.67 bump

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Pod-Parser` that 
you are following:
``
1.67 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/11
--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Oron Peled]

On Wednesday, 3 January 2024 10:07:02 IST Marián Konček wrote:
> Note that mingw-* packages currently in Fedora install into the 
> /usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
> 
> This is a different topic but if each archful package installed its 
> files into a directory containing the arch name, it would allow parallel 
> installability without configuring dnf and possibly make it more 
> convenient for cross-platform development.

This is very similar to Debian's Multiarch[1], but they have 
/usr/lib/ (less pollution of top-level /usr)
Indeed, such organization is ideal for cross-platform development:
 *  Libraries are installed in the same path, both for native and for cross 
compilation
 *  As a result, normal packages in the distribution already have the 
libraries in the correct locations for both native/cross compilation
 *  The packaging system (APT) was adapted to allow co-installation of such 
packages (since the files don't conflict)
 *  At a later stage, the distribution began shipping complete toolchains 
for all supported architectures -- built from exactly the same source (same 
gcc, same binutils, etc.)
 *  I.e: a developer that need cross-compilation, install the wanted 
toolchain(s) and all library packages are immediately available from standard 
repositories.

I guess Fedora people that work on ARM/ARM64/RISC-V would love such a support.

Bye,

--
Oron Peled

> On 2. 1. 2024 16:23, Vít Ondruch wrote:
> >
> >
> > Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
> >>
> >>
> >> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch  wrote:
> >>
> >>
> >> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
> >>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> >>> optimized implementations of ''shared objects'' [3]. This means that
> >>> packages can provide optimized libraries and they linker will be
> >>> automatically load them from separate directories if appropriate.
> >>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
> >>>
> >>
> >> Is this something specific to x86_64 that the libs needs to be
> >> nested in a place such as
> >> `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> >> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
> >> universal.
> >>
> >>
> >> Adding directories to the /usr sub-space generally gets bogged down 
> >> into 'You are polluting my name-space' arguments which get no-where 
> >> because some of the people getting angry is having to live with some 
> >> 3rd party rules and regulations which stipulated how things look and 
> >> will only get updated once a decade or so. [The same goes with 
> >> subdirectories in /usr/bin etc where it causes similar problems.] 
> >> There tends to be no 'general' case which works unless it gets 
> >> 'agreed' upon by some outside of the distro body that publishes 
> >> 'versioned' standards.
> >
> >
> > Checking what Debian does, they have paths such as 
> > `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
> >
> >
> > Vít
> >
> >
> >> Vít
> >>
> >> --
> >> ___
> >> 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 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 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
> 
> 


-- 
Oron Peled Voice: +972-4-8228492

Unsolicited commercial email read for $500 per 

[rpms/perl-Pod-Parser] PR #10: 1.67 bump

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Pod-Parser` that you 
are following.

Merged pull-request:

``
1.67 bump
``

https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/10
--
___
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: RISC-V ABI issue with ULEB128

[David Abdurachmanov]

On Thu, Jan 4, 2024 at 11:20 AM Nick Clifton  wrote:
>
> Hi David, Hi Florian,
>
>  Here's the bug:
> 
>  https://sourceware.org/bugzilla/show_bug.cgi?id=31179
>  RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
> 
>  It refers to this change in binutils 2.41:
> 
>  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
>
> FYI, a second patch is also needed: "RISC-V: Clarify the behaviors of 
> SET/ADD/SUB relocations."
> This is commit: 2029e13917d53d2289d3ebb390c4f40bd2112d21

Yes. This one is the actual fix. The one mentioned above is a
temporary workaround to accept older broken object files.

>
>
> > In Fedora/RISCV we typically end up using the latest available
> > binutils. We are slightly different from upstream/normal Fedora.
>
> I have now backported both of the above commits to rawhide binutils.
> Build: binutils-2.31-18.fc40

I saw you making some builds, and I had a guess that you are most
likely working on it :)

binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it
as failed. The failures don't seem to be related to binutils package
itself. Seems like CI test is/was broken, or maybe a temporary network
issue, or something else.

Cheers,
david

>
> Cheers
>Nick
>
>
--
___
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-Pod-Parser] PR #10: 1.67 bump

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Pod-Parser` that 
you are following:
``
1.67 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/10
--
___
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: Packed relative ELF relocations (DT_RELR) enabled by default in rawhide

[Florian Weimer]

* Alessandro Astone:

> It also appears for aarch64.
> It is an issue because software may use `-Wl,--fatal-warnings` so this 
> warning breaks the build.
> As an example, pretty much the entire KDE software collection now fails to 
> compile on aarch64 and s390x: 
> https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/04affb76a6af4ccbda50abfe264c62d7b7f60d84/kde-modules/KDECompilerSettings.cmake#L549

The redhat-rpm-config-274-1.fc40 update should have a workaround for
that.  It skips -z pack-relative-relocs on aarch64 and s390x.

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: ARM PAC on koji vs COPR

[Florian Weimer]

* Jarek Prokop:

> This spawns a few questions for me:
> 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
> CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
> defaults,
> I see default CFLAGS contain `-mbranch-protection=standard` and the
> flag with pac-ret seems to be appended to libruby.so in the case of
> the upstream fix [2].
>
> From what I understand, it shouldn't cause problems to have these 2
> flags at the same time on the correct compilation artifacts, is that
> correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?

Can't you put -mbranch-protection=standard into ASFLAGS?

The check is a bit weird:

diff --git a/configure.ac b/configure.ac
index 9286946fc15f4..18b4247991d42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [
AS_FOR(option, opt, [-mbranch-protection=pac-ret 
-msign-return-address=all], [
 RUBY_TRY_CFLAGS(option, [branch_protection=yes], 
[branch_protection=no])
 AS_IF([test "x$branch_protection" = xyes], [
+# C compiler and assembler must be consistent for 
-mbranch-protection
+# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition.
 RUBY_APPEND_OPTION(XCFLAGS, option)
+RUBY_APPEND_OPTION(ASFLAGS, option)
 break
 ])
 ])



The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option.

> 2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
> up in the .so library and Ruby binary extensions link against that
> solib, do the binary extensions also have to be compiled with that
> exact option?

It depends on how fiber handling is implemented.  If fiber switching
relies on code in header files or that is statically linked into Ruby
extensions, then yes, these extensions will need to be compiled with PAC
support as well.  But I expect that this isn't the case, but haven't
checked it.  The relevant code should be in the Ruby DSO only and be
linked dynamically.

It also seems unlikely that many C extensions would be aware of fiber
switching, but I haven't checked that, either.

> 3. If we do not fix this bug in Ruby 3.3.0 but wait with this for
> 3.3.1 where the fix will most probably land, will we by effect exclude
> a subset of ARM CPUs, that actually have the PAC capability, for that
> in-between period?

I think you should fix this with a backport.  It's going to impact quite
a few users.

> 4. Why do koji and copr have CPU flag set that differs so much? Is our
> koji infra OK?

It's different machines, so they are expect to have different
capabilities.  This isn't even aarch64-specific.

> 5. Why does it fail on copr and does not fail on koji? It seems the
> paca/pacg have to be present and set on the CPU flags for the
> segfaults to occur.

PAC is not process-switched on Linux.  If it is turned on at the
kernel/hypervisor level, it's currently impossible to turn off.  This is
not something the buildroot can control.  It's not actually a hardware
limitation, it's just how it has been implemented on Linux.  (Although
we would turn it on for the Fedora buildroots at this point.)

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: ARM PAC on koji vs COPR

[Peter Robinson]

On Wed, Jan 3, 2024 at 9:08 PM Stephen Smoogen  wrote:
>
>
>
> On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý  wrote:
>>
>> Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
>>
>> 4. Why do koji and copr have CPU flag set that differs so much? Is our koji 
>> infra OK?
>>
>> For convenience of readers:
>>
>> Koji:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm lrcpc dcpop asimddp ssbs
>>
>> Copr:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
>> uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
>>
>> In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn 
>> this machine in AWS you should be able to reproduce.
>
>
> My information may be old, but I believe the Fedora systems will be mostly 
> virtual machines running on Ampere systems from 2-3 years ago. I think there 
> are a couple of other systems which may be in usage also. The AWS systems are 
> a newer generation and different chipset. Another issue is that ARM like 
> Intel systems may be of the same generation but have different flags.
>

Ultimately builds should be using distro specified flags, not flags
based on detected build system features because that will lead to
builds that can't run on all supported platforms of a particular
architecture.
--
___
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-Pod-Parser] PR #9: 1.67 bump

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Pod-Parser` that you 
are following.

Merged pull-request:

``
1.67 bump
``

https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/9
--
___
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: RISC-V ABI issue with ULEB128

[Nick Clifton]

Hi David, Hi Florian,


Here's the bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=31179
RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects

It refers to this change in binutils 2.41:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc


FYI, a second patch is also needed: "RISC-V: Clarify the behaviors of SET/ADD/SUB 
relocations."
This is commit: 2029e13917d53d2289d3ebb390c4f40bd2112d21



In Fedora/RISCV we typically end up using the latest available
binutils. We are slightly different from upstream/normal Fedora.


I have now backported both of the above commits to rawhide binutils.
Build: binutils-2.31-18.fc40

Cheers
  Nick

--
___
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-Pod-Parser] PR #9: 1.67 bump

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Pod-Parser` that 
you are following:
``
1.67 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Pod-Parser/pull-request/9
--
___
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 2256688] perl-Pod-Parser-1.67 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED



--- Comment #3 from Michal Josef Spacek  ---
Changes:

03-Jan-2024  Marek Rouchal
 -
 Version 1.67
 + fix CPAN#149426: format of tar container, thanks HMBRAND


No functional change
For Rawhide, F38 and F39


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256688%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: Error updating libvirt-dbus in F38

[Adam Williamson]

On 2024-01-04 00:20, Peter Boy wrote:

Just started to update one of our Fedora Servers (F38)

I got the message:


   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132
   Cleaning up   : libvirt-dbus-1.4.1-1.fc38.x86_64   124/132
   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132
/var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed, 
Exit-status 1

Error in POSTUN scriptlet in rpm package libvirt-dbus
  Cleaning up: libacl-2.3.1-6.fc38.x86_64  125/132




Warning or error, what is it?


Both. It's an error in the scriptlet. As far as dnf/rpm is concerned, 
scriptlet errors are warnings (it warns you about them, but continues, 
as failing the entire transaction on them is unlikely ever to be a 
better choice).


Can I be sure that a reboot will be successful?


Nope. This is a fundamental issue with packages in general: package 
scriptlets are just...entirely arbitrary code running as root on your 
system. What does a scriptlet do? Nobody but the packager can say with 
much confidence. How bad is it if it fails? Again, impossible to say 
except on a case-by-case investigation basis.



My experiences with reports of this kind are quite mixed. From problem-free 
reboots to total failure, everything is possible. Unfortunately, reports of 
this kind do not exactly boost confidence in the reliability and usability of 
our Fedora.

We should improve this and make reports of problems clearer.


It's fundamentally difficult to do so in the context of RPM packages. 
All the package system can know is "the scriptlet of this package failed".


Looking into this specific case, it looks like the 1.4.1-1 package 
%postun tries to do:


%systemd_postun_with_reload %{name}.service

but that macro doesn't seem to exist on F38, AFAICT. It exists on 
Rawhide, but not F38.


The 1.4.1-2 package changes this to:

%systemd_postun_with_restart %{name}.service

which *does* exist on F38, so it should work. Ironically, you see the 
bug in the 1.4.1-1 package when you upgrade to 1.4.1-2, as the %postun 
of 1.4.1-1 runs when it's being removed to install 1.4.1-2.


This particular case shouldn't cause any real problems, since the macro 
does nothing on upgrade anyway (only on package removal), and the 
scriptlet did not want to do anything after that.

--
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: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)

[Beniamino Galvani]

On Thu, Dec 21, 2023 at 04:51:37PM +, Gary Buhrmaster wrote:
> On Wed, Dec 20, 2023 at 7:51 PM Chris Adams  wrote:
> >
> > Once upon a time, Aoife Moloney  said:
> > > Enable IPv4 Address Conflict Detection by default in NetworkManager.
> >
> > Huh, I didn't realize NM didn't already do this... ye olde
> > network-scripts did.
> >
> 
> 
> As I recall, depending on configuration(s),
> systemd-networkd has done so for quite
> some time.  Off hand I do not recall its
> various values, but it might make sense
> to align the settings.

systemd-networkd supports DAD for both static and dynamic addresses,
and it's disabled by default. For static addresses, DAD must be
enabled via:

  [Address]
  Address=192.168.1.1/24
  DuplicateAddressDetection=ipv4

For DHCP, it is enabled by setting Dhcpv4.SendDecline=true

In both cases, the maximum timeout is the one from RFC 5227 (9
seconds) and it's not configurable. I have filed an issue to make the
value configurable:

  https://github.com/systemd/systemd/issues/30724

Beniamino


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

Error updating libvirt-dbus in F38

[Peter Boy]

Just started to update one of our Fedora Servers (F38)

I got the message: 

>   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
>   Cleaning up   : libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
>   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
> /var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
> Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed, 
> Exit-status 1
> 
> Error in POSTUN scriptlet in rpm package libvirt-dbus
>  Cleaning up: libacl-2.3.1-6.fc38.x86_64  125/132 



Warning or error, what is it? 

Can I be sure that a reboot will be successful? 

My experiences with reports of this kind are quite mixed. From problem-free 
reboots to total failure, everything is possible. Unfortunately, reports of 
this kind do not exactly boost confidence in the reliability and usability of 
our Fedora. 

We should improve this and make reports of problems clearer.


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