[EPEL-devel] EPEL8: New Ansible and (native) python modules

[Igor Raits]

Hello,

The new ansible (5.x) is in the EPEL stable which works great until
one tries to use some non-trivial modules which require some Python
modules to be available… At that point you realize that the new
Ansible is built against Python 3.8 (default is 3.6) and we don't have
many python38-* packages (almost none).

The question is: What is the recommendation on how to get those
modules available in EPEL8? Do we want to go with
python3_other_pkgversion (which is not defined now) and build all
packages with python36/python38 both available or is there a plan to
switch default Python in EL8 to 3.8?
-- 
— Igor Raits.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: VirtualBox and HOST kernel-5.17.12 weirdness

[Ian Laurie]

On 6/6/22 20:25, Paul Black via devel wrote:

On Sat, 4 Jun 2022 at 05:17, Ian Laurie  wrote:

Is anyone else seeing crashes and other strange events in VirtualBox
6.1.34 (from RPMFusion) with Linux guests when the Linux host is
running
Fedora 36 with kernel-5.17.12?



I do and on two different machines (one a Lubuntu guest and the other 
with CentOS 7). 5.17.11 works fine on both.


I tried 6.1.35 which has fixes for 5.18 - 
https://www.virtualbox.org/ticket/20914 - but that was no different.


With 6.1.97, the problem seems harder to trigger but not impossible.



Problem persists with 5.17.13, for VirtualBox users seems the last 
usable kernel is 5.17.11.


--

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

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

[updates]

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

remmina-1.4.25-4.el7

Details about builds:



 remmina-1.4.25-4.el7 (FEDORA-EPEL-2022-f18e1a4121)
 Remote Desktop Client

Update Information:

- Add patch: 0006_paste_as_keystrokes_fix_git_partial_eb3d59fb.patch

ChangeLog:

* Mon Jun  6 2022 Phil Wyett  - 1.4.25-4
- Add patch: 0006_paste_as_keystrokes_fix_git_partial_eb3d59fb.patch


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

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

[updates]

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

pugixml-1.12.1-1.el8
remmina-1.4.26-3.el8

Details about builds:



 pugixml-1.12.1-1.el8 (FEDORA-EPEL-2022-be11c39161)
 A light-weight C++ XML processing library

Update Information:

Update to latest rawhide version.

ChangeLog:

* Wed Feb 16 2022 Richard Shaw  - 1.12.1-1
- Update to 1.12.1, fixes RHBZ#2052866.
* Fri Feb 11 2022 Richard Shaw  - 1.12-1
- Update to 1.20.
* Fri Jan 21 2022 Fedora Release Engineering  - 
1.11.4-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering  - 
1.11.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Wed Jan 27 2021 Fedora Release Engineering  - 
1.11.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild




 remmina-1.4.26-3.el8 (FEDORA-EPEL-2022-aaeea29207)
 Remote Desktop Client

Update Information:

- Add patch: 0001_paste_as_keystrokes_fix_git_partial_eb3d59fb.patch - Add
libssh BuildRequires minimum required version of 0.8.0. - Remove EL7 build
support due to new libssh minimum required version. - Remove telepathy plugin
activation switch as no longer required. - Eliminate cmake build folder warning.

ChangeLog:

* Mon Jun  6 2022 Phil Wyett  - 1.4.26-3
- Add patch: 0001_paste_as_keystrokes_fix_git_partial_eb3d59fb.patch
- Add libssh BuildRequires minimum required version of 0.8.0.
- Remove EL7 build support due to new libssh minimum required version.
- Remove telepathy plugin activation switch as no longer required.
- Eliminate cmake build folder warning.


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

[Bug 2093024] perl-Date-Manip-6.88 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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



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

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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

Re: Installing ffmeg-free degrades firefox video support

[Michael Catanzaro]

On Mon, Jun 6 2022 at 11:58:45 PM +0200, Kevin Kofler via devel 
 wrote:

for no practical benefit whatsoever because
everyone can just install the codecs from RPM Fusion.


Kevin, I care about users who do not know about rpmfusion, or have 
enough technical experience to enable it. Everything you've said only 
makes sense if users are smart enough to figure out how to install and 
use rpmfusion. But based on the number of "how do I multimedia?" posts 
I see on reddit (and the fact that 80% of the answers in those topics 
involve installing random unnecessary packages), I'm confident that 
users are not that smart. We've got to make multimedia as easy as 
possible, and that means ensuring it works as possible out-of-the-box.


Your arguments are failing to persuade me because you expect users are 
able to use rpmfusion, while I expect users are not.


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

Re: Installing ffmeg-free degrades firefox video support

[Kevin Kofler via devel]

Dominik 'Rathann' Mierzejewski wrote:
> Could it be https://bugzilla.redhat.com/show_bug.cgi?id=2089986 ?
> 
> There's an update fixing it, so please test:
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-e3c5f45422

That bug is a direct result of the downstream-only hack to dlopen 
libopenh264 in FFmpeg (which is necessary because of the ugly way OpenH264 
is shipped to Fedora users), and shows exactly why FFmpeg upstream will most 
likely never accept that patch.

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

Re: Installing ffmeg-free degrades firefox video support

[Kevin Kofler via devel]

Dominik 'Rathann' Mierzejewski wrote:

> On Sunday, 05 June 2022 at 19:15, Kevin Kofler via devel wrote:
>> It is common knowledge that Fedora is/was effectively useless for
>> anything remotely related to multimedia without RPM Fusion packages.
> 
> That's entirely false. There are many multimedia-related uses which are
> covered solely by the package set shipped in Fedora repositories. For
> example, a DLNA server on my home LAN works just fine with minidlna and
> ffmpeg-free. You can use ffmpeg-free to manipulate videos encoded with
> royalty-free codecs. Most videos on YouTube are also available in either
> VP9 or AV1 and with Opus audio.

That is why I wrote "is/was": There is now indeed limited support for 
multimedia in stock Fedora, so the (outdated) expectation that nothing works 
at all without RPM Fusion has now become overly pessimistic. Still, it is 
the common expectation and everyone has learned to deal with it for years, 
so I do not see why changing that was worth doing at all.

(And the fact that almost all YouTube videos actually work without any 
H.264, AAC, or EME DRM support at all just proves that it was not necessary 
to add support for decoding H.264 and AAC to Fedora proper nor to allow 
browsers to easily download the Widevine blob.)

> Unless you're a lawyer, the above statement is false. Red Hat legal says
> the modified FDK-AAC is free and GPL-compatible, so there's no violation
> of licenses here.

Red Hat Legal's interpretation is in direct contradiction to the FSF's 
attestation that the FDK-AAC license is not compatible with the GPL. Red Hat 
Legal's claim that a license can be GPL-compatible or not depending on 
whether the code happens to implement some patents or not sounds highly 
dubious to me, and that view does not seem to be shared by the FSF nor by 
FFmpeg upstream, and it is their license (drafted by the FSF and applied by 
FFmpeg upstream to their code) that we must comply with.

It is particularly bizarre that Fedora is willing to put themselves at risk 
of a lawsuit over divergent license interpretations as a result of an 
effort, ironically, to ship something compliant with US law.

>> All these compromises:
>> * violate the core Freedom principle of Fedora, and
> 
> How?

Because the copy of OpenH264 shipped through that Cisco repository is not 
Free Software? (All the binaries covered by the patent license impose the 
non-Free restrictions of that patent license, see 
http://www.openh264.org/BINARY_LICENSE.txt .) Because we replaced an LGPL-
licensed AAC implementation with one that Debian considers non-Free? Because 
we ship a linked-together mix of code that FFmpeg upstream considers non-
redistributable (as a mix of GPL and GPL-incompatible code)? Because we 
allow browsers to download proprietary DRM blobs?

Plus, the compromises also violate the Features principle because Fedora 
deliberately ships incomplete implementations of H.264 and AAC.

>> * lead to a degraded user experience compared to just installing fully
>> functional multimedia codecs under Free copyright licenses from RPM
>> Fusion.
> 
> Which Fedora cannot legally ship.

But RPM Fusion can, so why not just let RPM Fusion do it?

Shipping the incomplete implementations just makes it harder to use the 
complete ones (because the FFmpeg-native implementations of H.264 and AAC 
(and libx264 for H.264 encoding) are not binary-compatible with OpenH264 and 
FDK-AAC that Fedora is pushing), for no practical benefit whatsoever because 
everyone can just install the codecs from RPM Fusion.

>> In some cases, concerns raised by RPM Fusion developers have been
>> deliberately ignored (e.g., in the AAC case).
> 
> It was not ignored. The case was referred to FESCo where it was
> discussed and a decision was made to go ahead with the limited decoder.

That is exactly my point: The concerns were ignored by FESCo.

> That is also blatantly false. The idea was posted by Andreas on
> rpmfusion-developers list in November 2021 and I (one of the FFmpeg
> maintainers) was the only one who responded. The other maintainers made
> no comments in that thread.

Yet, if you see the discussions on rpmfusion-devel about FFmpeg shortly 
before ffmpeg-free was introduced to Rawhide, nobody there was aware of the 
plans, at all. There was discussion on when to move to FFmpeg 5, but 
apparently nobody was aware (or those that were did not share the 
information) that an incomplete FFmpeg 5 was about to land in Fedora 
(forcing RPM Fusion to ship that version independently of whether that would 
have been the plan anyway or not, in order to be binary-compatible to the 
extent possible – note that software like Chromium hardcodes supported codec 
lists at compile time and hence it is absolutely impossible for FFmpeg 
builds built with different codec sets to be binary-compatible for those 
applications, a concern that I had pointed out in the 2021 thread and again 
this year and that was just blamed on the applications 

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Tom Stellard]

On 6/6/22 00:58, Panu Matilainen wrote:

On 6/3/22 13:43, Fabio Valentini wrote:

On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch  wrote:


BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be rather removed or not?


I agree that the "_flag_" prefix might be a little too generic, but
what would be a better alternative?
Maybe something like _optflag_, to match what they are "collected
into" (i.e. %optflags)?

Also, macro names with single leading underscores are *fine* (see also
%_bindir, %_libdir, %_datadir, etc.).
Those with *double* leading underscores are the ones that should be
considered "internal" implementation details.


Once upon a time in past I can still remember, the following rule of thumb for 
macro underscores was set [1]:

 Use %__foo to set, %foo to get.

To me it looks like the entire set of suggested flags is basically write-only 
values, and thus should have two leading underscores. So, 
%__build_flag_whatever. Usage should always happen through the non-underscored 
%build_cflags and friends, which can do their own internal logic around this 
stuff, use Y only if X is enabled.



I don't have a preference on one vs two underscore.  I chose one, because
that's what most of the existing compiler flag macros use.


Other misc comments:


%_flag_flto_auto   -flto=auto


Shouldn't this be %_flag_flto instead (or rather, %__build_flag_flto), just 
like %_flag_o does not carry the optimization level in the name?



OK, I think that makes sense.


 %_flag_werror_format_security  -Werror=format-security


...and ditto for this, %__build_flag_werror whose default value is 
-Werror=format-security ... except that unlike -flto, -Werror can appear 
multiple times. Dunno.

What I guess I'm after, having an actual rule for the parameter -> macro 
naming, one that could preferably be automated, would be beneficial. The -Wl and 
-Wp related macro naming would need further consideration wrt that.



I don't think there is a way to have the consistent naming that you
are looking for.  Even though -Werror= usage the same format as -flto=
and others, each -Werror= option is really its own separate option.

-Tom


%_flag_pipe seems like the odd man out there because it doesn't actually relate 
to code at all, but I guess consistency is the goal there.

[1] https://pagure.io/packaging-committee/issue/907

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

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

Re: F36 pvcs problem

[Roger Wells]

On 6/6/22 15:14, Florian Weimer wrote:

* Roger Wells:


we use pvcs here for CM and have for many years (~30).
Currently we are using it on RHEL 7 & Fedora.
On F35 (and earlier) no issues at all.
On F36 (installed end of last week) some programs are not recognized
and issue error message "not a dynamic executable" when examined with
"ldd":
any ideas?

Have you installed glibc.i686?


Genius, very good. That seems to be the cause. Plus a couple of others, 
eg libstdc++.i686.

Thank you very much



Thanks,
Florian

.

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

Re: F36 pvcs problem

[Hans de Goede]

Hi,

On 6/6/22 21:14, Florian Weimer wrote:
> * Roger Wells:
> 
>> we use pvcs here for CM and have for many years (~30).
>> Currently we are using it on RHEL 7 & Fedora.
>> On F35 (and earlier) no issues at all.
>> On F36 (installed end of last week) some programs are not recognized
>> and issue error message "not a dynamic executable" when examined with
>> "ldd":
>> any ideas?
> 
> Have you installed glibc.i686?

Yes that was what I was about to suggest to. The:

/home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory

Error means that the loader/dynamic-linker for the executable is
missing, which likely is /lib/ld-linux.so.2 which is part of glibc.i686 .

Recent Fedora-s no longer have any 32 bit support as part of
the default install (for 64 bit binaries, the loader is
/lib64/ld-linux-x86-64.so.2 instead).

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

Re: F36 pvcs problem

[Stephen Smoogen]

On Mon, 6 Jun 2022 at 15:50, Roger Wells  wrote:

>
> On 6/6/22 14:28, Stephen Smoogen wrote:
>
>
>
> On Mon, 6 Jun 2022 at 14:07, Roger Wells 
> wrote:
>
>> we use pvcs here for CM and have for many years (~30).
>> Currently we are using it on RHEL 7 & Fedora.
>> On F35 (and earlier) no issues at all.
>> On F36 (installed end of last week) some programs are not recognized and
>> issue error message "not a dynamic executable" when examined with "ldd":
>> any ideas?
>>
>>
> I would check to see if there is an security issue as it saying `bash:
> /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory`
> either means its not there, or something going on.
>
> thanks for responding,
>
> It's there, and when copied to a CentOS7 machine runs fine.
>
> 1. stat /home/roger/pvcs/vm/linux/bin/mlcproxy
> 2. ls -lZ /home/roger/pvcs/vm/linux/bin/mlcproxy
> 3. file /home/roger/pvcs/vm/linux/bin/mlcproxy
>
>
Could you answer the above. Without some more information about what is
seen on the disk, there isn't going to be much anyone can do to help.



> Also not sure if you are meaning the code is 30 years old, but if it is, I
> would wonder if it was an a.out binary which I think was dropped from the
> kernel recently.
> https://www.phoronix.com/scan.php?page=news_item=Linux-Remove-a.out
>
> pvcs was actually first released 37 years ago.  This release, 8.6.3 is
> just a year or so old.  It works fine on F35
>
>
>
>>
>> which mlcproxy
>> ~/pvcs/vm/linux/bin/mlcproxy
>> [roger@rwells-x280 linux]$ mlcproxy
>> bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory
>> [roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
>> not a dynamic executable
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 pvcs problem

[Roger Wells]

On 6/6/22 15:13, Sérgio Basto wrote:

Hi,

what is pvcs ?
an ancient commercial source code configuration management tool, first 
released 37 years ago



On Mon, 2022-06-06 at 14:05 -0400, Roger Wells wrote:

we use pvcs here for CM and have for many years (~30).
Currently we are using it on RHEL 7 & Fedora.
On F35 (and earlier) no issues at all.
On F36 (installed end of last week) some programs are not recognized
and
issue error message "not a dynamic executable" when examined with
"ldd":
any ideas?


which mlcproxy
~/pvcs/vm/linux/bin/mlcproxy
[roger@rwells-x280 linux]$ mlcproxy
bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or
directory
[roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
not a dynamic executable
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

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

Re: F36 pvcs problem

[Roger Wells]

On 6/6/22 14:28, Stephen Smoogen wrote:



On Mon, 6 Jun 2022 at 14:07, Roger Wells  
wrote:


we use pvcs here for CM and have for many years (~30).
Currently we are using it on RHEL 7 & Fedora.
On F35 (and earlier) no issues at all.
On F36 (installed end of last week) some programs are not
recognized and
issue error message "not a dynamic executable" when examined with
"ldd":
any ideas?


I would check to see if there is an security issue as it saying `bash: 
/home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory` 
either means its not there, or something going on.



thanks for responding,

It's there, and when copied to a CentOS7 machine runs fine.


1. stat /home/roger/pvcs/vm/linux/bin/mlcproxy
2. ls -lZ /home/roger/pvcs/vm/linux/bin/mlcproxy
3. file /home/roger/pvcs/vm/linux/bin/mlcproxy

Also not sure if you are meaning the code is 30 years old, but if it 
is, I would wonder if it was an a.out binary which I think was dropped 
from the kernel recently.
https://www.phoronix.com/scan.php?page=news_item=Linux-Remove-a.out 



pvcs was actually first released 37 years ago.  This release, 8.6.3 is 
just a year or so old.  It works fine on F35




which mlcproxy
~/pvcs/vm/linux/bin/mlcproxy
[roger@rwells-x280 linux]$ mlcproxy
bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or
directory
[roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
not a dynamic executable
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard 
battle. -- Ian MacClaren


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

Re: F36 pvcs problem

[Stephen Smoogen]

On Mon, 6 Jun 2022 at 15:14, Sérgio Basto  wrote:

> Hi,
>
> what is pvcs ?
>
>
https://en.wikipedia.org/wiki/PVCS


>
>
> On Mon, 2022-06-06 at 14:05 -0400, Roger Wells wrote:
> > we use pvcs here for CM and have for many years (~30).
> > Currently we are using it on RHEL 7 & Fedora.
> > On F35 (and earlier) no issues at all.
> > On F36 (installed end of last week) some programs are not recognized
> > and
> > issue error message "not a dynamic executable" when examined with
> > "ldd":
> > any ideas?
> >
> >
> > which mlcproxy
> > ~/pvcs/vm/linux/bin/mlcproxy
> > [roger@rwells-x280 linux]$ mlcproxy
> > bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or
> > directory
> > [roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
> > not a dynamic executable
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 pvcs problem

[Florian Weimer]

* Roger Wells:

> we use pvcs here for CM and have for many years (~30).
> Currently we are using it on RHEL 7 & Fedora.
> On F35 (and earlier) no issues at all.
> On F36 (installed end of last week) some programs are not recognized
> and issue error message "not a dynamic executable" when examined with
> "ldd":
> any ideas?

Have you installed glibc.i686?

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

Re: F36 pvcs problem

[Sérgio Basto]

Hi, 

what is pvcs ? 



On Mon, 2022-06-06 at 14:05 -0400, Roger Wells wrote:
> we use pvcs here for CM and have for many years (~30).
> Currently we are using it on RHEL 7 & Fedora.
> On F35 (and earlier) no issues at all.
> On F36 (installed end of last week) some programs are not recognized
> and 
> issue error message "not a dynamic executable" when examined with
> "ldd":
> any ideas?
> 
> 
> which mlcproxy
> ~/pvcs/vm/linux/bin/mlcproxy
> [roger@rwells-x280 linux]$ mlcproxy
> bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or
> directory
> [roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
> not a dynamic executable
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

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

Re: F36 pvcs problem

[Stephen Smoogen]

On Mon, 6 Jun 2022 at 14:07, Roger Wells  wrote:

> we use pvcs here for CM and have for many years (~30).
> Currently we are using it on RHEL 7 & Fedora.
> On F35 (and earlier) no issues at all.
> On F36 (installed end of last week) some programs are not recognized and
> issue error message "not a dynamic executable" when examined with "ldd":
> any ideas?
>
>
I would check to see if there is an security issue as it saying `bash:
/home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory`
either means its not there, or something going on.

1. stat /home/roger/pvcs/vm/linux/bin/mlcproxy
2. ls -lZ /home/roger/pvcs/vm/linux/bin/mlcproxy
3. file /home/roger/pvcs/vm/linux/bin/mlcproxy

Also not sure if you are meaning the code is 30 years old, but if it is, I
would wonder if it was an a.out binary which I think was dropped from the
kernel recently.
https://www.phoronix.com/scan.php?page=news_item=Linux-Remove-a.out



>
> which mlcproxy
> ~/pvcs/vm/linux/bin/mlcproxy
> [roger@rwells-x280 linux]$ mlcproxy
> bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory
> [roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
> not a dynamic executable
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 pvcs problem

[Roger Wells]

we use pvcs here for CM and have for many years (~30).
Currently we are using it on RHEL 7 & Fedora.
On F35 (and earlier) no issues at all.
On F36 (installed end of last week) some programs are not recognized and 
issue error message "not a dynamic executable" when examined with "ldd":

any ideas?


which mlcproxy
~/pvcs/vm/linux/bin/mlcproxy
[roger@rwells-x280 linux]$ mlcproxy
bash: /home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory
[roger@rwells-x280 linux]$ ldd /home/roger/pvcs/vm/linux/bin/mlcproxy
not a dynamic executable
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Florian Weimer]

* Ralf Corsépius:

> Am 06.06.22 um 16:38 schrieb Petr Pisar:
>
>> I believe that glibc payed a special attention to provide both
>> ABIs. But that does not apply to other libraries. Maybe it's not so
>> important problem.  Proprietary software tends to bundle the
>> libraries, externally relying only on kernel and glibc.

(X libraries, Motif, glib are usually not bundled, either, and there are
a couple mor examples.  It's likely that there is at least some time_t
or struct timeval/timespec exposre in all of these otherwise ABI-stable
libraries.)

> How about dlopened libraries? I'd assume these can become problematic.

dlsym calls need to be taught to use the time64 aliases.  Symbol
versioning isn't used.

Maybe we could add a time64 version of dlsym and dlvsym that knows about
the aliased symbols, but we really shouldn't be doing new development
work for 32-bit architectures.  It doesn't benefit Fedora, and most
embedded 32-bit users do not use glibc, either.  However, there was a
strong push from a few interested parties who funded the initial
development (and at least one party is still involved and addresses any
fallout from the changes).  I'm not really happy how things turned out,
but at least there is no immediate harm to Fedora's i686 compatibility
packages (beyond the occasional bug, but as I mentioned, someone is
still around to fix them).

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

Re: Installing ffmeg-free degrades firefox video support

[Neal Gompa]

On Mon, Jun 6, 2022 at 4:40 PM Leigh Scott  wrote:
>
>
> > That is also blatantly false. The idea was posted by Andreas on
> > rpmfusion-developers list in November 2021 and I (one of the FFmpeg
> > maintainers) was the only one who responded. The other maintainers made
> > no comments in that thread.
> >
> > In other words, Kevin, please stop spreading lies.
> >
> > Regards,
> > Dominik
>
> There was never a thread started by Andreas on rpmfusion mailing list.
> The fedora thread was only forwarded to rpmfusion by you!
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YPXQTK27622JHYOACVAWD4JR4BHNXZ2D/#YPXQTK27622JHYOACVAWD4JR4BHNXZ2D

That is not true. Andreas CC'd rpmfusion-developers@ on 2021-11-08 in
his original email. In fact, every email in that thread had
rpmfusion-developers@ as CC.

However, the mail was never archived by RPM Fusion's Mailman instance.




--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Ralf Corsépius]

Am 06.06.22 um 16:38 schrieb Petr Pisar:


I believe that glibc payed a special attention to provide both ABIs. But that
does not apply to other libraries. Maybe it's not so important problem.
Proprietary software tends to bundle the libraries, externally relying only on
kernel and glibc.


How about dlopened libraries? I'd assume these can become problematic.

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

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Vít Ondruch]

Dne 03. 06. 22 v 16:32 Tom Stellard napsal(a):

On 6/3/22 02:24, Vít Ondruch wrote:

Hi Tom,

Since you are looking into this and I like this proposal, have you 
considered to look alto into `%extension_*flags`:


https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_120-123 





I have not considered this.  Do you think there is some way this proposal
could be extended to help solve this problem as well?



I think the current struggle is that we have `%extension_cflags` and 
`%build_cflags`, while we would actually need the set of ``%build_cflags 
- %extension_cflags`. The problem is that the `%build_cflags` order is 
not necessarily followed in the resulting code, so if we need to modify 
the resulting code, we have no way to achieve this.



Vít




-Tom


This is longstanding issue:

https://bugzilla.redhat.com/1284684

Where we have several proposals for fix, but non of them is really 
appealing to me:


https://src.fedoraproject.org/rpms/ruby/pull-request/110

https://src.fedoraproject.org/rpms/ruby/pull-request/117


BTW isn't the `_flag_` prefix too generic? And also, the initial 
underscore implies that this is internal macro which should ideally 
not be used. So should it be rather removed or not?



Vít


Dne 02. 06. 22 v 21:27 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages.  There is currently no standard way to remove or add
to the set of default flags.  Most packages use a combination of echo
and sed to remove unwanted flags or add new ones.  Some examples:
 compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6 


global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
 julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267 


%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]

This change will add new macros which will make it easier for packages
to add and remove their own compiler flags.  This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.

The proposed macros for adding new flags are:

 %_pkg_extra_cflags
 %_pkg_extra_cxxflags
 %_pkg_extra_fflags
 %_pkg_extra_ldflags

These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.

 %build_cflags %{optflags} %{_pkg_extra_cflags}

The proposed new macros to represent existing flags are:

 %_flag_fstack_protector_strong -fstack-protector-strong
 %_flag_z_now   -Wl,-z,now
 %_flag_z_defs  -Wl,-z,defs
 %_flag_flto_auto   -flto=auto
 %_flag_ffat_lto_objects    -ffat-lto-objects
 %_flag_o   -O2
 %_flag_f_exceptions    -fexceptions
 %_flag_g   -g
 %_flag_grecord_gcc_switches    -grecord-gcc-switches
 %_flag_pipe    -pipe
 %_flag_wall    -Wall
 %_flag_werror_format_security -Werror=format-security
 %_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
 %_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
 %_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
 %_flag_fstack_clash_protection -fstack-clash-protection
 %_flag_fcf_protection  -fcf-protection
 %_flag_mbranch_protection_standard -mbranch-protection=standard

With these new macros, the examples from above could be re-written as:

 compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
 julia:   %global _flag_glibcxx_assertions %{nil}

For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags 


Prototype Implementation].

In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.


== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple 

[PATCH] chrpath: Bad assumption can corrupt shared libraries when setting RUNPATH

[Frank R Dana Jr.]

Hi all.

I know we're all busy people, but I'm hoping I can impose on someone with the 
necessary rights to take a look at this, as it's been in limbo for several 
months now.

Basically, I discovered a fairly nasty bug in chrpath — a package for which 
upstream has vanished, so we're pretty much on our own — which fortunately only 
occurs under rare circumstances. "Fortunately" because, when those 
circumstances arise and it DOES occur, using chrpath to set the RUNPATH for a 
shared library can instead corrupt (silently!) the library's dynamic string 
tables. While failing to actually modify the RUNPATH.

My bug report about the issue, with steps to reproduce, is here:
https://bugzilla.redhat.com/show_bug.cgi?id=2022931

A few months after reporting, I revisited the problem, isolated the bug, and 
fixed (at least in my testing) chrpath to no longer exhibit that buggy 
behavior. I submitted the patch as a PR against our chrpath package repo, since 
the upstream URL points to an unreachable host.

That PR can be found here:
https://src.fedoraproject.org/rpms/chrpath/pull-request/6

It's been open for five weeks now. As I said, the conditions that trigger the 
bug are fairly rare, so I wouldn't say it's URGENT per se. But it does feel 
like it should be addressed, and I even have a patch that (I believe) does so. 
Perhaps someone has a few minutes to look it over, verify that I haven't done 
anything stupid, and help move the process along? (Or provide some guidance on 
how I should go about doing so.)

Thanks!


(Everything past this point is additional detail for the morbidly curious. Bail 
out now if you don't want to end up getting bored to tears with very tedious 
details, or don't say I didn't warn you.)


Those fortunately-rare trigger conditions
---
The library being modified by chrpath will only be corrupted if its .dynstr 
section is located at an unexpected location in the ELF header. chrpath blindly 
assumes that the first section of type SHT_STRTAB it encounters when walking 
the headers must be the .dynstr table, into which the RUNPATH is to be placed 
at the offset 'rpathoff'.  The assumption chrpath makes APPEARS to be a correct 
one, 99% of the time. For all executables, and most if not all "normal" 
libraries, the header is laid out as it assumes and it can update RUNPATH 
strings without incident.

However, should that assumption turn out to be INCORRECT, chrpath will insert a 
RUNPATH string into the **wrong** table. Whichever section of type SHT_STRTAB 
it encounters first, that table gets the RUNPATH inserted into it. When it's 
not the .dynstr table, some other symbol name gets partly or completely 
overwritten with the new RUNPATH string. Meanwhile, the library's *actual* 
RUNPATH doesn't change, since the real, correct location in the .dynstr section 
still has the same value it did before running chrpath.

One of the ways a library with unexpected table ordering can be created is the 
series of events that led me to initially discover the bug: Using a different 
library-editing tool, patchelf, to insert a new RUNPATH into a library that 
previously lacked one, then subsequently running chrpath on that library.

(Adding a RUNPATH to a library is something patchelf can do that chrpath 
cannot. chrpath is limited to overwriting existing RUNPATH strings with one of 
the same length or shorter, using space that's already allocated in th header. 
It has no ability to allocate additional space for a RUNPATH where none 
previously existed. patchelf *can* carve out space for a RUNPATH string in a 
library without one — it rewrites the ELF headers to allocate additional space 
for the new string. In the process of doing so, it seems to relocate (or 
create?) the dynamic string (.dynstr) table in a header section located *after* 
the other, previously-allocated sections.)

So, when allocating new space to add a RUNPATH, patchelf places .dynstr 
somewhere that chrpath assumes it will never be located. A patchelf-modified 
shared library is effectively a trap waiting to be sprung by an unpatched 
chrpath, which will make a mess of its string tables the moment it tries to 
modify them.


My proposed fix, as implemented in the submitted PR
---
My patch is as simple as I could make it, and no simpler. It adds two functions 
to chrpath:

read_section_names() retrieves the names for all of the sections from the 
file's ELF header. The table contains the name for each section, located at an 
offset that's stored in the .sh_name member of the section header struct.

get_section_name() takes a .sh_name value, and returns the corresponding string 
located at that offset in the section names table.

Patched chrpath still walks the ELF headers to find the dynamic string table, 
when it needs to write a new RUNPATH into a binary. But instead of stopping at 
the first SHT_STRTAB section it finds 

[Bug 2092730] perl-Test-Compile-3.1.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 CC|jples...@redhat.com,|
   |mmasl...@redhat.com |
 Status|NEW |ASSIGNED




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

[Bug 2092660] perl-Log-Log4perl-1.55 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Log-Log4perl-1.55-1.fc
   ||37
 CC|jose.p.oliveira.oss@gmail.c |
   |om, jples...@redhat.com,|
   |ka...@ucw.cz,   |
   |mspa...@redhat.com, |
   |st...@silug.org |
 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
Last Closed||2022-06-06 14:56:02




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

[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo

[Stephen Smoogen]

On Mon, 6 Jun 2022 at 10:44, Patrick Riehecky via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> I realize this is a bit of a pipe dream, but is there "some way" to
> ship a repo file from EPEL that points to the crb repo(s)?  Folks not
> wanting it could block the package/not install weak deps.  Getting the
> right repos is a bit tricky but I figured I'd voice the idea...
>
>
Not really. The repo may be:
1. Upstream mirror system
2. Subscription tool CDN
3. Subscription local satellite
4. Subscription local repos.
5. Other proprietary software system which keeps track of repos
6. A system may not have access to CRB/Powertools for various reasons.
[This is common from lack of space or cost or 'meh'.
7. ... you get the idea that there are going to be more variations. Get 10
computer sites, and you will have 10! (328800) solutions in no time.

subscription-manager can deal with most of those variations and dnf can
deal with ones where a config file already exists.

Just for the record, dealing with the above variations was a continuing
problem for the repositories before EPEL (Dag and such), and for EL5 which
had repos which weren't generally shipped or available. It is only with EL6
and EL7, that we as a third party had an easy time of dealing with all the
parts being shipped with upstream EL.




>
> Pat
>
> On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
> > When I first created the EPEL issue to auto-enable crb repo[1] I was
> > only thinking of CAN we do it.  I wasn't thinking SHOULD we do it.
> > We've come to the point that we actually can do it.  But before we go
> > down that road, I wanted to take a step back and ask, should we do
> > it.
> >
> > The more I think about it, the more I think we shouldn't auto-enable
> > the crb repo for epel8 and epel9.  Here are my reasons why.
> >
> > 1 - The need to auto-enable crb isn't as big as it was before.
> > At the time that I wrote that issue, I was getting quite alot of bugs
> > / pings / emails about  epel packages not being installable.  I think
> > on average about 2 a month.
> > With epel being in fedora-docs, and with Carl's re-write of how to
> > enable epel, that number has dropped significantly.  I possibly still
> > average one a month, but that's an average over a year, with most of
> > them being last year.
> > In short, I believe the documentation is better, and easier to find,
> > allowing people to enable crb on their own, without automation.
> >
> > 2 - crb isn't an epel repo
> > We really shouldn't be messing with other repo's that we, epel, don't
> > own.
> >
> > 3 - We are taking the choice away from users
> > After I stopped and thought about it, there are plenty of scenarios
> > where people want epel for just one or two packages, which do not
> > require crb.
> >
> > 4 - All the many small side cases.
> > auto-enabling crb will have bugs.  RHEL and it's clones are in too
> > many odd places for us to not hit some odd use cases we didn't
> > expect.  We'd have to keep fixing the scripts.
> >
> > I could go into more explanation on each of those things, but in the
> > end, I've talked myself out of wanting to auto-enable crb for epel8
> > and epel9.
> > But I also wanted to get others' thoughts before I close the bug and
> > pull request.
> >
> > What do others think?
> >
> > Troy
> >
> >
> > [1] - https://pagure.io/epel/issue/128
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> > epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=d0B-lUzeMAZ-0S04uVby7ub-ORVZmAB6b5jp1yJRsuE=
> >
> > List Guidelines:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=KUWCI2iU_-iPDDRDPyScLagKSycsfAiarhiTHIQYPR0=
> >
> > List Archives:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=P7pankG6ADB2aNPcSpD1QIXMv1ATMhIvP4ovYevs5rU=
> >
> > Do not reply to spam on the list, report it:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=_cTkF9KBrWUy7DX9w20wQNnBshQg2EbgcQKLRhis6qY=
> >
>
> ___
> epel-devel mailing list -- 

[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo

[Patrick Riehecky via epel-devel]

I realize this is a bit of a pipe dream, but is there "some way" to
ship a repo file from EPEL that points to the crb repo(s)?  Folks not
wanting it could block the package/not install weak deps.  Getting the
right repos is a bit tricky but I figured I'd voice the idea...


Pat

On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
> When I first created the EPEL issue to auto-enable crb repo[1] I was
> only thinking of CAN we do it.  I wasn't thinking SHOULD we do it.
> We've come to the point that we actually can do it.  But before we go
> down that road, I wanted to take a step back and ask, should we do
> it.
> 
> The more I think about it, the more I think we shouldn't auto-enable
> the crb repo for epel8 and epel9.  Here are my reasons why.
> 
> 1 - The need to auto-enable crb isn't as big as it was before.
> At the time that I wrote that issue, I was getting quite alot of bugs
> / pings / emails about  epel packages not being installable.  I think
> on average about 2 a month.
> With epel being in fedora-docs, and with Carl's re-write of how to
> enable epel, that number has dropped significantly.  I possibly still
> average one a month, but that's an average over a year, with most of
> them being last year.
> In short, I believe the documentation is better, and easier to find,
> allowing people to enable crb on their own, without automation.
> 
> 2 - crb isn't an epel repo
> We really shouldn't be messing with other repo's that we, epel, don't
> own.
> 
> 3 - We are taking the choice away from users
> After I stopped and thought about it, there are plenty of scenarios
> where people want epel for just one or two packages, which do not
> require crb.
> 
> 4 - All the many small side cases.
> auto-enabling crb will have bugs.  RHEL and it's clones are in too
> many odd places for us to not hit some odd use cases we didn't
> expect.  We'd have to keep fixing the scripts.
> 
> I could go into more explanation on each of those things, but in the
> end, I've talked myself out of wanting to auto-enable crb for epel8
> and epel9.
> But I also wanted to get others' thoughts before I close the bug and
> pull request.
> 
> What do others think?
> 
> Troy
> 
> 
> [1] - https://pagure.io/epel/issue/128
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=d0B-lUzeMAZ-0S04uVby7ub-ORVZmAB6b5jp1yJRsuE=
>  
> List Guidelines:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=KUWCI2iU_-iPDDRDPyScLagKSycsfAiarhiTHIQYPR0=
>  
> List Archives:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=P7pankG6ADB2aNPcSpD1QIXMv1ATMhIvP4ovYevs5rU=
>  
> Do not reply to spam on the list, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza=_cTkF9KBrWUy7DX9w20wQNnBshQg2EbgcQKLRhis6qY=
>  

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

Re: Installing ffmeg-free degrades firefox video support

[Leigh Scott]

> That is also blatantly false. The idea was posted by Andreas on
> rpmfusion-developers list in November 2021 and I (one of the FFmpeg
> maintainers) was the only one who responded. The other maintainers made
> no comments in that thread.
> 
> In other words, Kevin, please stop spreading lies.
> 
> Regards,
> Dominik

There was never a thread started by Andreas on rpmfusion mailing list.
The fedora thread was only forwarded to rpmfusion by you!

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YPXQTK27622JHYOACVAWD4JR4BHNXZ2D/#YPXQTK27622JHYOACVAWD4JR4BHNXZ2D

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

Re: Archive value is out of time_t range

[Petr Pisar]

V Mon, Jun 06, 2022 at 02:40:50PM +0300, Panu Matilainen napsal(a):
> On 6/6/22 13:29, Petr Pisar wrote:
> > V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
> > > On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
> > > > $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
> > > > $ ./a.out
> > > > sizeof(time_t)=8
> > > > 
> > > > I recommend you to file a bug against tar in Fedora's Bugzilla. 
> > > > However, this
> > > > proposed solution would require rebuilding in the same way all 
> > > > libraries which
> > > > tar uses and which pass time_t and similar types in their interface. 
> > > > That
> > > > would probably break other packages.
> > > 
> > > Now that the kernel and glibc have this feature, would it make sense
> > > to change the global CFLAGS to build everything with 64-bit time_t on
> > > all currently supported 32-bit archs? If not now, how close to the
> > > 32-bit overflow in 2038?
> > > 
> > That would be ideal, but I worry that Fedora will rather drop i686 
> > archicture
> > than change ABI of all packages.
> > 
> > Most of the uses cases for i686 is a multilib for proprietary software.
> > Changing ABI would break it. How much of that software will be relevant in 
> > 15
> > years?
> 
> The way glibc compatibility works, existing binaries will continue to get
> the ABIs they were built with once upon a time and continue to work like
> nothing ever happened. Except of course that time will wrap around
> eventually.
> 
I believe that glibc payed a special attention to provide both ABIs. But that
does not apply to other libraries. Maybe it's not so important problem.
Proprietary software tends to bundle the libraries, externally relying only on
kernel and glibc.

> Or at least that's how the theory goes, IIRC the time_t transition has its
> own peculiarities that other similar transitions haven't had.
> 
> > 
> > We dropped 32-bit ARM because we were unable to build the software (in
> > a reasonable time). As software becomes hungrier (and less tested on 32 
> > bits), we
> > start observing the same problem in i686.
> 
> Yup, but i686 can be easily built on x86_64 which alleviates things quite a
> bit.
> 
Wasn't that also said about ARMv7 on AArch64?

-- Petr


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

Re: Perl 5.36 upgrade

[Jitka Plesnikova]

On 5/30/22 10:15, Jitka Plesnikova wrote:

Hello,

Perl 5.36 was released on May 28 2022 and Perl 5.36 change was approved
by FESCo [1].

I have required `f37-perl' build-root for this purpose [2] and it was
created.

I will start the rebuild later today and you can be notified via mail
about commits/builds in next days.

Please do not build anything into `f37-perl'. Boot-strapping core modules
is very peculiar. I also track all changes. You can do your upgrades into
rawhide freely in parallel.

You can check status on Perl 5.36 change page [3].

Regards,
Jitka Plesnikova

[1] https://pagure.io/fesco/issue/2791
[2] https://pagure.io/releng/issue/10771
[3] https://fedoraproject.org/wiki/Changes/perl5.36#Current_status


I have successfully built all packages except 14 of them. The f37-perl tag
was merged back into f37 tag [1].

Perl 5.36.0 is available in Fedora 37. You can look at final lists of
results [2]

I also rebuilt all updated packages with new Perl.

The release notes on thechange page will be updated probably tomorrow.

Regards,
Jitka

[1] https://pagure.io/releng/issue/10771#comment-800658
[2] https://jplesnik.fedorapeople.org/5.36/

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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-Math-NumSeq-75-1.fc37  |perl-Math-NumSeq-75-2.fc37



--- Comment #5 from Petr Pisar  ---
Rebuilt.


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

[Bug 2093024] perl-Date-Manip-6.88 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
F34 is EOL tomorrow. Skipping it.
F37 built was built against perl 5.34. After perl 5.36 appears a build root, it
will need rebuilding.


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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-0fd21fb373 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0fd21fb373


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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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



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


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

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Math-NumSeq-75-1.fc37
 Status|ASSIGNED|MODIFIED



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


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

Re: Firefox/nss behaviour change in F36?

[Bojan Smojver via devel]

Ah, cool. Totally missed that in release notes. 臘‍♂️

Thanks,
-- 
Bojan



6 June 2022 8:13:10 pm Alexander Sosedkin :

On Mon, Jun 6, 2022 at 12:03 PM Bojan Smojver via devel
 wrote:
> 
> Before I open a bug on this, the latest firefox/nss software that is in F36 - 
> is it not accepting SSL certificates without matching subjectAlternativeName 
> on purpose?
> 
> I still have to complete more tests, but it seems that if SSL certificate is 
> issued to CN abc.example.com and if that name is not mentioned in SAN, 
> Firefox complains that the certificate is not for the right domain. This is 
> all only with most recent updates.
> 
> Anyone else seeing similar stuff?


https://www.mozilla.org/en-US/firefox/101.0/releasenotes says:

> Removed "subject common name" fallback support from certificate validation.
> This fallback mode was previously enabled
> only for manually installed certificates.
> The CA Browser Forum Baseline Requirements
> have required the presence of the "subjectAltName" extension since 2012,
> and use of the subject common name was deprecated in RFC 2818.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 34 is going EOL in one day.

[Tomas Hrcka]

Hello all,

Fedora 34 will go end of life for updates and support on 2022-06-07
No further updates, including security updates, will be
available for Fedora 34 after the said date. All the updates of Fedora
34 being pushed to stable will be stopped as well.

Fedora 35 will continue to receive updates until approximately one
month after the release of Fedora 37. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
Fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Regards,
Fedora Release Engineering

[0]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades



-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 34 is going EOL in one day.

[Tomas Hrcka]

Hello all,

Fedora 34 will go end of life for updates and support on 2022-06-07
No further updates, including security updates, will be
available for Fedora 34 after the said date. All the updates of Fedora
34 being pushed to stable will be stopped as well.

Fedora 35 will continue to receive updates until approximately one
month after the release of Fedora 37. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
Fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Regards,
Fedora Release Engineering

[0]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades



-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2093567] perl-Math-NumSeq-75 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Re: Archive value is out of time_t range

[Panu Matilainen]

On 6/6/22 13:29, Petr Pisar wrote:

V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):

On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:

$ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
$ ./a.out
sizeof(time_t)=8

I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
proposed solution would require rebuilding in the same way all libraries which
tar uses and which pass time_t and similar types in their interface. That
would probably break other packages.


Now that the kernel and glibc have this feature, would it make sense
to change the global CFLAGS to build everything with 64-bit time_t on
all currently supported 32-bit archs? If not now, how close to the
32-bit overflow in 2038?


That would be ideal, but I worry that Fedora will rather drop i686 archicture
than change ABI of all packages.

Most of the uses cases for i686 is a multilib for proprietary software.
Changing ABI would break it. How much of that software will be relevant in 15
years?


The way glibc compatibility works, existing binaries will continue to 
get the ABIs they were built with once upon a time and continue to work 
like nothing ever happened. Except of course that time will wrap around 
eventually.


Or at least that's how the theory goes, IIRC the time_t transition has 
its own peculiarities that other similar transitions haven't had.




We dropped 32-bit ARM because we were unable to build the software (in
a reasonable time). As software becomes hungrier (and less tested on 32 bits), 
we
start observing the same problem in i686.


Yup, but i686 can be easily built on x86_64 which alleviates things 
quite a bit.


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

Re: Firefox/nss behaviour change in F36?

[Dominik 'Rathann' Mierzejewski]

On Monday, 06 June 2022 at 12:03, Bojan Smojver via devel wrote:
> Before I open a bug on this, the latest firefox/nss software that is
> in F36 - is it not accepting SSL certificates without matching
> subjectAlternativeName on purpose?
> 
> I still have to complete more tests, but it seems that if SSL
> certificate is issued to CN abc.example.com and if that name is not
> mentioned in SAN, Firefox complains that the certificate is not for
> the right domain. This is all only with most recent updates.
> 
> Anyone else seeing similar stuff?

It's not something recent. RFC2818 (HTTP over TLS) mandates this:

https://datatracker.ietf.org/doc/html/rfc2818#section-3.1

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Petr Pisar]

V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
> On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
> > $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
> > $ ./a.out
> > sizeof(time_t)=8
> > 
> > I recommend you to file a bug against tar in Fedora's Bugzilla. However, 
> > this
> > proposed solution would require rebuilding in the same way all libraries 
> > which
> > tar uses and which pass time_t and similar types in their interface. That
> > would probably break other packages.
> 
> Now that the kernel and glibc have this feature, would it make sense
> to change the global CFLAGS to build everything with 64-bit time_t on
> all currently supported 32-bit archs? If not now, how close to the
> 32-bit overflow in 2038?
> 
That would be ideal, but I worry that Fedora will rather drop i686 archicture
than change ABI of all packages.

Most of the uses cases for i686 is a multilib for proprietary software.
Changing ABI would break it. How much of that software will be relevant in 15
years?

We dropped 32-bit ARM because we were unable to build the software (in
a reasonable time). As software becomes hungrier (and less tested on 32 bits), 
we
start observing the same problem in i686.

-- Petr


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

Re: VirtualBox and HOST kernel-5.17.12 weirdness

[Paul Black via devel]

On Sat, 4 Jun 2022 at 05:17, Ian Laurie  wrote:

> Is anyone else seeing crashes and other strange events in VirtualBox
> 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running
> Fedora 36 with kernel-5.17.12?
>


I do and on two different machines (one a Lubuntu guest and the other with
CentOS 7). 5.17.11 works fine on both.

I tried 6.1.35 which has fixes for 5.18 -
https://www.virtualbox.org/ticket/20914 - but that was no different.

With 6.1.97, the problem seems harder to trigger but not impossible.

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

Re: Firefox/nss behaviour change in F36?

[Alexander Sosedkin]

On Mon, Jun 6, 2022 at 12:03 PM Bojan Smojver via devel
 wrote:
>
> Before I open a bug on this, the latest firefox/nss software that is in F36 - 
> is it not accepting SSL certificates without matching subjectAlternativeName 
> on purpose?
>
> I still have to complete more tests, but it seems that if SSL certificate is 
> issued to CN abc.example.com and if that name is not mentioned in SAN, 
> Firefox complains that the certificate is not for the right domain. This is 
> all only with most recent updates.
>
> Anyone else seeing similar stuff?


https://www.mozilla.org/en-US/firefox/101.0/releasenotes says:

> Removed "subject common name" fallback support from certificate validation.
> This fallback mode was previously enabled
> only for manually installed certificates.
> The CA Browser Forum Baseline Requirements
> have required the presence of the "subjectAltName" extension since 2012,
> and use of the subject common name was deprecated in RFC 2818.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Miroslav Lichvar]

On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
> $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
> $ ./a.out
> sizeof(time_t)=8
> 
> I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
> proposed solution would require rebuilding in the same way all libraries which
> tar uses and which pass time_t and similar types in their interface. That
> would probably break other packages.

Now that the kernel and glibc have this feature, would it make sense
to change the global CFLAGS to build everything with 64-bit time_t on
all currently supported 32-bit archs? If not now, how close to the
32-bit overflow in 2038?

It's not just about keeping current time and file timestamps. There
are applications/libraries that calculate future dates and overflows
can lead to serious issues.

Switching to 64-bit time_t may require some patching, e.g. when the
code assumes sizeof(long) == sizeof(time_t).

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

Firefox/nss behaviour change in F36?

[Bojan Smojver via devel]

Before I open a bug on this, the latest firefox/nss software that is in F36 - 
is it not accepting SSL certificates without matching subjectAlternativeName on 
purpose?

I still have to complete more tests, but it seems that if SSL certificate is 
issued to CN abc.example.com and if that name is not mentioned in SAN, Firefox 
complains that the certificate is not for the right domain. This is all only 
with most recent updates.

Anyone else seeing similar stuff?

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

Fedora-Cloud-34-20220606.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 06 June (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 6th
June(today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or
Matrix. The meeting is a public meeting, and open for everyone to
attend. You can join us over:

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 today'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20220606T13=%3A=1

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/fedora-neuro/2022-05-09/neurofedora.2022-05-09-13.00.html
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F36/F37: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org


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


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

Re: Installing ffmeg-free degrades firefox video support

[Dominik 'Rathann' Mierzejewski]

On Saturday, 04 June 2022 at 00:05, Otto Urpelainen wrote:
> I have discovered that installing the ffmpeg-free package degrades Firefox
> video support. Without any kind of ffmpeg installed, Firefox is able to play
> all the videos I want to watch. Installing RPM Fusion's ffmpeg package does
> not change this. But, installing ffmpeg-free from Fedora repositories causes
> some videos not to play.

Could it be https://bugzilla.redhat.com/show_bug.cgi?id=2089986 ?

There's an update fixing it, so please test:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e3c5f45422

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Dominik 'Rathann' Mierzejewski]

On Sunday, 05 June 2022 at 19:15, Kevin Kofler via devel wrote:
> Michael Catanzaro wrote:
> > P.S. Vitaly, your suggestions to enable rpmfusion are not helpful for
> > inexperienced Fedora users, who expect multimedia to work
> > out-of-the-box. Common multimedia needs like "play a video" absolutely
> > need to work without rpmfusion, and we need Fedora developers testing
> > this to make sure it works.
> 
> It is common knowledge that Fedora is/was effectively useless for anything 
> remotely related to multimedia without RPM Fusion packages.

That's entirely false. There are many multimedia-related uses which are
covered solely by the package set shipped in Fedora repositories. For
example, a DLNA server on my home LAN works just fine with minidlna and
ffmpeg-free. You can use ffmpeg-free to manipulate videos encoded with
royalty-free codecs. Most videos on YouTube are also available in either
VP9 or AV1 and with Opus audio.

> * and now shipping an incomplete version of FFmpeg in Fedora, even with at 
> least two non-upstream and non-upstreamable hacks (the one to dlopen 
> OpenH264 instead of linking it – FFmpeg upstream hates runtime dlopen –, and 
> the one to allow FDK-AAC without --enable-nonfree, so that it can even be 
> used together with --enable-gpl, in blatant violation of the upstream 
> licenses, which are incompatible with each other, as confirmed by the FSF).

Unless you're a lawyer, the above statement is false. Red Hat legal says
the modified FDK-AAC is free and GPL-compatible, so there's no violation
of licenses here.

> All these compromises:
> * violate the core Freedom principle of Fedora, and

How?

> * lead to a degraded user experience compared to just installing fully 
> functional multimedia codecs under Free copyright licenses from RPM Fusion. 

Which Fedora cannot legally ship.

> Also because non-upstream hacks such as relying on OpenH264 (dlopened, even) 
> for FFmpeg (instead of the superior and default native FFmpeg H.264 decoder 
> and libx264 H.264 encoder) confuse the heck out of applications such as 
> Firefox, as evidenced by this thread.

Firefox can be adapted if really necessary. Do you have a bug report to
refer to?

> There has also been little to no communication or coordination with RPM 
> Fusion on these points.

That's, to use your rhetoric, blatantly false.

> In some cases, concerns raised by RPM Fusion developers have been
> deliberately ignored (e.g., in the AAC case).

It was not ignored. The case was referred to FESCo where it was
discussed and a decision was made to go ahead with the limited decoder.
For the record, I was against it.

> In 
> others, one RPM Fusion maintainer was contacted, but neither the Fedora 
> maintainer nor the RPM Fusion maintainer has discussed the issue on the RPM 
> Fusion mailing list (where such a plan ought to be discussed IMHO) or even 
> with other RPM Fusion maintainers (e.g., in the FFmpeg case). This leaves a 
> bitter feeling with people involved with RPM Fusion that you are 
> deliberately sabotaging their years-long hard work, even if that was never 
> the intention.

That is also blatantly false. The idea was posted by Andreas on
rpmfusion-developers list in November 2021 and I (one of the FFmpeg
maintainers) was the only one who responded. The other maintainers made
no comments in that thread.

In other words, Kevin, please stop spreading lies.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Martin Stransky]

On 6/5/22 15:08, Michael Catanzaro wrote:
On Sat, Jun 4 2022 at 01:05:58 AM +0300, Otto Urpelainen  
wrote:

It seems clear that there is a bug somewhere, but I cannot decide,
where, hence this post to devel. Should Fedora's Firefox actually have
media.ffmpeg.enabled set to false by default, because Fedora's variant
of ffmpeg has this problem? Should upstream Firefox be smarted about
which decoder library it attempts to use? Or should ffmpeg-free package
do something to avoid this from happening. Any opinions are welcome!


Only the developers will be able to tell you for sure, but I would start 
with a Firefox bug report. That's the place where code changes are most 
likely to be required, and the Firefox developers can always punt the 
bug to ffmpeg if they think it is doing something wrong.


Our ffmpeg-free is supposed to support H264 via OpenH264.


From my understanding ffmpeg-free should work with Firefox regardless 
of actual codec name.


Firefox uses avcodec_find_decoder() to query supported formats and it 
uses AVCodecID. So as far as openh264 ffmpeg module claims support of 
AV_CODEC_ID_H264 it's supported (unless the decoder crashes later and 
it's disabled or so).


You can get exact info by running Firefox with

MOZ_LOG="PlatformDecoderModule:5"

env variable.

Firefox without ffmpeg-free package uses GMP interface to use OpenH264 
and you can find its status at about:plugins page.


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

[Test-Announce] [Call For Action] Fedora QA Onboading call Poll

[Sumantro Mukherjee]

Hey All,

First of all, I would like to thank all those who have shown interest
in testing Fedora and making it better.
We saw a lot of new faces in the test day(s) and introduction emails
to welcome you all,
here's is what we have for you.

We are going to have an onboarding call,
We will focus on helping the new contributors to start contributing right away.
The meeting will be a video call, with an 'Hackmd'[2] for text notes and agenda.

The agenda is will be shared in Etherpad and is designed to ensure
that newcomers
can follow along and make the most of the call without any pre-requisites.
But for that to happen, we need to fix a time and here's a poll link[1]
where we would like all the interested folks to vote in until 2022-06-10.

[1] https://whenisgood.net/mmwpzkh
[2] https://hackmd.io/3V3xwrEcRtyf381wJvZr1g

--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Dominik 'Rathann' Mierzejewski]

On Sunday, 05 June 2022 at 10:36, Neal Gompa wrote:
> On Sun, Jun 5, 2022 at 9:37 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 04/06/2022 22:43, Otto Urpelainen wrote:
> > > But the question is, what needs to be done so that ffmpeg-free will not
> > > suffer, either.
> >
> > ffmpeg-free is a special stripped version. Popular codecs H.264 and
> > H.265 were removed due to the legal reasons. You should always use the
> > fully featured version from the RPM Fusion repository.
> >
> 
> H.264 is supported through OpenH264, and H.265 is not a popular codec.
> Aside from Apple services (which are not available to Linux users
> anyway), nobody uses H.265 because of the patent situation with HEVC.

If you mean Apple TV+, it worked fine on Fedora under Firefox last year
when I was lured into subscribing for a month to see the mess they made
out of Foundation.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Panu Matilainen]

On 6/3/22 13:43, Fabio Valentini wrote:

On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch  wrote:


BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be rather removed or not?


I agree that the "_flag_" prefix might be a little too generic, but
what would be a better alternative?
Maybe something like _optflag_, to match what they are "collected
into" (i.e. %optflags)?

Also, macro names with single leading underscores are *fine* (see also
%_bindir, %_libdir, %_datadir, etc.).
Those with *double* leading underscores are the ones that should be
considered "internal" implementation details.


Once upon a time in past I can still remember, the following rule of 
thumb for macro underscores was set [1]:


Use %__foo to set, %foo to get.

To me it looks like the entire set of suggested flags is basically 
write-only values, and thus should have two leading underscores. So, 
%__build_flag_whatever. Usage should always happen through the 
non-underscored %build_cflags and friends, which can do their own 
internal logic around this stuff, use Y only if X is enabled.


Other misc comments:


%_flag_flto_auto   -flto=auto


Shouldn't this be %_flag_flto instead (or rather, %__build_flag_flto), 
just like %_flag_o does not carry the optimization level in the name?



 %_flag_werror_format_security  -Werror=format-security


...and ditto for this, %__build_flag_werror whose default value is 
-Werror=format-security ... except that unlike -flto, -Werror can appear 
multiple times. Dunno.


What I guess I'm after, having an actual rule for the parameter -> macro 
naming, one that could preferably be automated, would be beneficial. The 
-Wl and -Wp related macro naming would need further consideration wrt that.


%_flag_pipe seems like the odd man out there because it doesn't actually 
relate to code at all, but I guess consistency is the goal there.


[1] https://pagure.io/packaging-committee/issue/907

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

[EPEL-devel] Update pam_radius to v2.0

[Iker Pedrosa]

Hi,

I'd like to update pam_radius from v1.4 to v2.0 in EPEL9 and 8. The newer 
version includes several patches to make the PAM module thread-safe.

I've opened a ticket in the steering committee's repository 
(https://pagure.io/epel/issue/181) and I'd also like to hear the feedback from 
the broader community.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-36-20220606.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-36-20220604.0):

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure