https://bugzilla.redhat.com/show_bug.cgi?id=2083360
--- Comment #7 from Fedora Update System ---
FEDORA-2022-ceaddf5e41 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
--- Comment #6 from Fedora Update System ---
FEDORA-2022-9acd402526 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
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
https://bugzilla.redhat.com/show_bug.cgi?id=2076894
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Status|ON_QA
Ben Cotton wrote:
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
>
> This
On Tue, May 10, 2022 at 11:51 PM Neal Gompa wrote:
>
> On Tue, May 10, 2022 at 5:20 PM Robert Relyea wrote:
> >
> > On 5/10/22 6:29 AM, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> > >
> > > This document represents a proposed Change. As part of
On Tue, May 10, 2022 at 12:28 PM Vitaly Zaitsev via devel
wrote:
>
> On 10/05/2022 18:00, Ben Beasley wrote:
> > Could you please elaborate on why this form is better?
>
> For building on RHEL without EPEL being enabled.
>
> > At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
On Tue, May 10, 2022 at 5:20 PM Robert Relyea wrote:
>
> On 5/10/22 6:29 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order
On 5/10/22 6:29 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
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
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
--- Comment #3 from Fedora Update System ---
FEDORA-2022-9acd402526 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-9acd402526
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
--- Comment #4 from Fedora Update System ---
FEDORA-2022-ceaddf5e41 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-ceaddf5e41
--
You are receiving this mail because:
You are on the CC list
> Are you manually editing the "sources" file?
No, why would I?
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Neal Gompa kirjoitti 10.5.2022 klo 2.10:
On Mon, May 9, 2022 at 7:00 PM Kevin Fenzi wrote:
On Mon, May 09, 2022 at 01:21:53PM -0400, Neal Gompa wrote:
On Mon, May 9, 2022 at 1:13 PM Kevin Fenzi wrote:
On Wed, May 04, 2022 at 09:45:55PM +0300, Otto Urpelainen wrote:
Ondrej Nosek kirjoitti
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
Hi,
Ben Cotton writes:
> According to short investigations, there are already precedents, where
> certification is a reason to build once, certificate, and repack.
This sounds fascinating. Can anyone share details about this? On the
surface, building something once and packaging that up for
* Vitaly Zaitsev via devel:
> On 10/05/2022 15:29, Ben Cotton wrote:
>> This is initial step to move JDKs to be more like other JDKs, to build
>> proper transferable images, and to lower certification burden of each
>> binary.
>
> Strongly -1. Bundled versions are always outdated and may be even
mspacek merged a pull-request against the project: `perl-libwww-perl` that you
are following.
Merged pull-request:
``
6.65 bump
``
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/34
___
perl-devel mailing list --
mspacek opened a new pull-request against the project: `perl-libwww-perl` that
you are following:
``
6.65 bump
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/34
___
perl-devel mailing list --
mspacek merged a pull-request against the project: `perl-libwww-perl` that you
are following.
Merged pull-request:
``
6.65 bump
``
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/33
___
perl-devel mailing list --
Thank you very much Mattia!
On 10 May 2022, at 11:36, Mattia Verga via devel wrote:
> Il 10/05/22 18:30, Mattia Verga ha scritto:
>> Il 09/05/22 22:28, Mikel Olasagasti ha scritto:
>>> Hi Ron,
>>>
>>> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022
>>> mai. 9, al. (22:15)):
Il 10/05/22 18:30, Mattia Verga ha scritto:
> Il 09/05/22 22:28, Mikel Olasagasti ha scritto:
>> Hi Ron,
>>
>> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022
>> mai. 9, al. (22:15)):
>>> Hi all-
>>>
>>> I got several strange messages on my update here:
>>>
>>>
Il 09/05/22 22:28, Mikel Olasagasti ha scritto:
> Hi Ron,
>
> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022
> mai. 9, al. (22:15)):
>> Hi all-
>>
>> I got several strange messages on my update here:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf60d68bdc
>>
>>
On 10/05/2022 18:00, Ben Beasley wrote:
Could you please elaborate on why this form is better?
For building on RHEL without EPEL being enabled.
At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
“%if 0%{?rhel} == 8”.
Double checks are preferable, because "%if 0%{?rhel}
On Mon, May 02, 2022 at 11:53:12PM -0400, Chris Murphy wrote:
> On Mon, May 2, 2022 at 5:29 PM Jeremy Linton wrote:
> > And of
> > course it also requires disabling swap on zram (which was nonsense on
> > the machine anyway, given the disks are faster than it can
> > compress/decompress pages).
>
mspacek opened a new pull-request against the project: `perl-libwww-perl` that
you are following:
``
6.65 bump
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/33
___
perl-devel mailing list --
Hello,
On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote:
> > This is a continuation of the discussion from F36 Change: GNU Toolchain
> > Update.
>
> snip.
>
> > He talks about -ftrivial-auto-var-init=zero being used
mspacek merged a pull-request against the project: `perl-libwww-perl` that you
are following.
Merged pull-request:
``
6.65 bump
``
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/32
___
perl-devel mailing list --
On Tue, May 10, 2022 at 11:42 AM Ron Olson wrote:
>
> No, it’s not available in RHEL nor in CentOS 8 and Stream 8; if I used the
> rhel tag would that include those?
>
Either is fine. %rhel and %el8 are both defined for all EL8 platforms.
Using %rhel is mostly useful if you want to handle
Could you please elaborate on why this form is better? I would have
thought they were more or less equivalent, but it’s very possible that
there is some non-obvious difference I don’t know about.
At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
“%if 0%{?rhel} == 8”.
–
Dear all,
You are kindly invited to the meeting:
EPEL Steering Committee on 2022-05-11 from 16:00:00 to 17:00:00 US/Eastern
At fedora-meet...@irc.libera.chat
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#meetingname
On 10/05/2022 17:01, Ron Olson wrote:
|%if 0%{?el8}|
Better fix:
%if 0%{?rhel} && 0%{?rhel} == 8
...
%else
...
%endif
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
mspacek opened a new pull-request against the project: `perl-libwww-perl` that
you are following:
``
6.65 bump
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/32
___
perl-devel mailing list --
There is no agenda for the FESCo meeting today, so I decided to cancel it.
If we have a volunteer chair for next week, that would be nice, as I am not
sure I will be able to attend.
= Discussed and Voted in the Ticket =
Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms
No, it’s not available in RHEL nor in CentOS 8 and Stream 8; if I used the rhel
tag would that include those?
On 10 May 2022, at 10:24, Neal Gompa wrote:
> On Tue, May 10, 2022 at 11:01 AM Ron Olson wrote:
>>
>> Hey all-
>>
>> I got a bug report about installing Swift on RHEL 8 where nothing
On Tue, May 10, 2022 at 11:01 AM Ron Olson wrote:
>
> Hey all-
>
> I got a bug report about installing Swift on RHEL 8 where nothing provides
> binutils-gold. I think this will fix it:
>
> %if 0%{?el8}
> Requires: binutils
> %else
> Requires: binutils-gold
> %endif
>
> But was hoping
Hey all-
I got a bug report about installing Swift on RHEL 8 where nothing
provides binutils-gold. I _think_ this will fix it:
```
%if 0%{?el8}
Requires: binutils
%else
Requires: binutils-gold
%endif
```
But was hoping for some confirmation about this being the right way to
mspacek merged a pull-request against the project: `perl-libwww-perl` that you
are following.
Merged pull-request:
``
6.65 bump
``
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/31
___
perl-devel mailing list --
On 10/05/2022 14:57, Dusty Mabe wrote:
On 5/10/22 02:05, Tom Hughes via devel wrote:
On 10/05/2022 03:12, Dusty Mabe wrote:
Just wanted to point interested people in the direction of an upstream
discussion about how (by default) the MAC address should get set for
bond and bridge devices.
A ter, 10-05-2022 às 10:22 +0200, Vít Ondruch escreveu:
> Ok, now I see commits such as:
>
> https://src.fedoraproject.org/rpms/ffmpeg/c/70ecae14df6b89cbd269778fc6808eb6e51e141e?branch=rawhide
>
> which is awful that we need something like this. But @Neal, wouldn't
> it
> be better if your
On 5/10/22 02:05, Tom Hughes via devel wrote:
> On 10/05/2022 03:12, Dusty Mabe wrote:
>
>> Just wanted to point interested people in the direction of an upstream
>> discussion about how (by default) the MAC address should get set for
>> bond and bridge devices.
>>
>>
On 10/05/2022 15:29, Ben Cotton wrote:
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary.
Strongly -1. Bundled versions are always outdated and may be even
vulnerable.
--with-zlib="bundled"
On 5/10/22 09:29, Ben Cotton wrote:
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
Might be a copy-paste error there, the last sentence is incomplete.
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
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
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
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
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 2/15 (x86_64), 2/15 (aarch64)
ID: 1262511 Test: x86_64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1262511
ID: 1262514 Test: x86_64 IoT-dvd_ostree-iso
Missing expected images:
Minimal raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
19 of 43 required tests failed, 13 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 92/231 (x86_64), 53/161 (aarch64)
New failures
mspacek opened a new pull-request against the project: `perl-libwww-perl` that
you are following:
``
6.65 bump
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/31
___
perl-devel mailing list --
On Mon, May 9, 2022 at 10:54 PM Ron Olson wrote:
>
> It was successful, apparently:
>
> ➜ ~ koji tag-build f36-updates-candidate swift-lang-5.6-1.fc36
> Created task 86848500
> Watching tasks (this may be safely interrupted)...
> 86848500 tagBuild (noarch): free
> 86848500 tagBuild (noarch):
> Am 10.05.2022 um 12:16 schrieb Miroslav Suchý :
>
> The workflow exists:
>
> The Change proposal guide you how to suggest release notes. E.g. I have one
> change in this release and I wrote
Yes, I know that. But, as far as I oversee, it’s not a (publication) workflow.
E.g. there is no
On Thu, May 05, 2022 at 11:27:45AM +0200, Fabio Valentini wrote:
On Thu, May 5, 2022 at 11:11 AM Ewoud Kohl van Wijngaarden
wrote:
On Thu, May 05, 2022 at 08:39:27AM -, Artur Frenszek-Iwicki wrote:
>git-up has been retired for over a year now. Packages that have been
>retired for over 8
No missing expected images.
Failed openQA tests: 3/15 (aarch64)
New failures (same test not failed in Fedora-IoT-36-20220505.0):
ID: 1261934 Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/1261934
ID: 1261940 Test: aarch64 IoT-dvd_ostree-iso
On 10/05/2022 10:23, Artur Frenszek-Iwicki wrote:
2. Edit the spec file in a way that changes which sources are used (say, update
to a new version)
3. Do not run "fedpkg new-sources" to upload the new tarballs
4. The "sources" file now lists files that are not actually used by the spec
Are
Dne 10. 05. 22 v 11:40 Peter Boy napsal(a):
Additionally, as fas as I see, docs team has no ==contentwise== workflow either
(and can’t provide one because it doesn’t govern the process). There is a
technical workflow, though, to ensure there is a file to be the next release
notes and a way to
https://bugzilla.redhat.com/show_bug.cgi?id=2083360
Michal Josef Spacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
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-20220509.0):
ID: 1261845 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
> Am 10.05.2022 um 10:47 schrieb Miro Hrončok :
>
> On Mon, May 9, 2022 at 11:17 PM Ben Cotton wrote:
>>
>> The #docs tag on Fedora Discussion is a better place to ask this
>> question
>
> Noted. It's quite confusing to me to see that parts of our workflow
> are not discussed here.
V Tue, May 10, 2022 at 08:23:17AM -, Artur Frenszek-Iwicki napsal(a):
> > I somehow don't understand why there should be anything like "unused
> > source files". Why is something like this even possible?
> 1. Grab a package
> 2. Edit the spec file in a way that changes which sources are used
> I very likely have the files listed in sources
> around from previous attempts
Well, yeah, but it's also likely that someone:
1. Has multiple machines, hadn't done any work on this package on the current
machine, and did a fresh "fedpkg clone"
2. Got fed up with clutter in the directory and
On Mon, May 9, 2022 at 11:17 PM Ben Cotton wrote:
>
> The #docs tag on Fedora Discussion is a better place to ask this
> question
Noted. It's quite confusing to me to see that parts of our workflow
are not discussed here.
> but the F36 docs will be published to the website prior to
> the
Dne 10. 05. 22 v 10:23 Artur Frenszek-Iwicki napsal(a):
I somehow don't understand why there should be anything like "unused
source files". Why is something like this even possible?
1. Grab a package
2. Edit the spec file in a way that changes which sources are used (say, update
to a new
* Florian Weimer:
* Richard Shaw:
I added the following to the libmqttc library and verified -fPIC -pie
is in the build flags[1] per the recommendation from the hardening
page[2] but the error remains.
Code that is linked into a shared object (with -shared) must be compiled
as PIC, not PIE.
> I somehow don't understand why there should be anything like "unused
> source files". Why is something like this even possible?
1. Grab a package
2. Edit the spec file in a way that changes which sources are used (say, update
to a new version)
3. Do not run "fedpkg new-sources" to upload the
Ok, now I see commits such as:
https://src.fedoraproject.org/rpms/ffmpeg/c/70ecae14df6b89cbd269778fc6808eb6e51e141e?branch=rawhide
which is awful that we need something like this. But @Neal, wouldn't it
be better if your `ffmpeg_gen_free_tarball.sh` simply updated the hashes
in `sources`
* Richard Shaw:
> I added the following to the libmqttc library and verified -fPIC -pie
> is in the build flags[1] per the recommendation from the hardening
> page[2] but the error remains.
Code that is linked into a shared object (with -shared) must be compiled
as PIC, not PIE.
Thanks,
Florian
I somehow don't understand why there should be anything like "unused
source files". Why is something like this even possible? It seems
strange that this was not questioned originally and it seems still
strange nobody questions this in this thread.
Vít
Dne 04. 05. 22 v 17:01 Ondrej Nosek
On 5/10/22 06:21 UTC, Mamoru TASAKA wrote:
Richard Shaw wrote on 2022/05/10 12:07:
I'm working on some IIoT related packages in my COPR where I have a dynamic
library linking to a static library and getting the following error:
/usr/bin/ld:
https://bugzilla.redhat.com/show_bug.cgi?id=2078127
--- Comment #4 from Stefano Biagiotti ---
Works for me.
Thanks Jitka.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2078127
Richard Shaw wrote on 2022/05/10 12:07:
I'm working on some IIoT related packages in my COPR where I have a dynamic
library linking to a static library and getting the following error:
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o):
warning: relocation
https://bugzilla.redhat.com/show_bug.cgi?id=2083127
Jitka Plesnikova changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|NEW
On 10/05/2022 03:12, Dusty Mabe wrote:
Just wanted to point interested people in the direction of an upstream
discussion about how (by default) the MAC address should get set for
bond and bridge devices.
https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html
A few of us
https://bugzilla.redhat.com/show_bug.cgi?id=2083124
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
71 matches
Mail list logo
