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:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib6
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 nap
* 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
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` file?
> 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 n
* 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.
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 versi
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 release
> 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 sta
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
> 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.
Additiona
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: https://op
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
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 you
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 podma
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 we
> 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 date
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): free
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 (
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 iot_clevis@ue
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 Ste
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
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 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.
>>
>> https://lists.freedesktop.o
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 `ffmp
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.
ht
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
handle
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
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 pr
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 from
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
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”.
– B
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 multip
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 for
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).
>
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} <
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
>>
>> Th
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:
>>>
>>> https://bodhi.fe
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)):
>
* 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
>
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 all
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
> 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:
https://docs.fedoraproject.org/en-U
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 i
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 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 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 t
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
48 matches
Mail list logo
