May 15, 2022 7:06:51 AM Nils Philippsen :
> It
> only matters that the package is available and installed on the build
> machines, not in the build roots.
Yeah, I'm aware. I just wasn't sure about local builds. I know it won't work at
all on an EL host, but what about EPEL mockbuilds run on a Fe
On Sat, May 14, 2022 at 11:40 AM Aurelien Bompard <
abomp...@fedoraproject.org> wrote:
> Hey folks!
>
> After spending some time evaluating our options, CPE's Advance
> Reconnaissance Team came up with this proposal for the next version of FMN:
>
> https://fedora-arc.readthedocs.io/en/latest/fmn/a
On Mon, 2022-05-16 at 07:06 +, Maxwell G via devel wrote:
>
> May 15, 2022 7:06:51 AM Nils Philippsen :
>
> > It
> > only matters that the package is available and installed on the
> > build
> > machines, not in the build roots.
> Yeah, I'm aware. I just wasn't sure about local builds. I know
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-20220515.0):
ID: 1268694 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
Dne 13. 05. 22 v 20:54 Jason L Tibbitts III napsal(a):
3) Is there any better way to handle a lack of space in /var during an
RPM transaction?
I very often mount /var/cache/dnf as tmpfs as servers have more memory/swap
than rootfs.
4) Can we estimate how large the file will grow, and refuse to
On 5/13/22 21:54, Jason L Tibbitts III wrote:
So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
as part of my usual testing. In the middle of the process, it appears
that /var filled up and that left the system in an unfortunate state.
Surprisingly (to me) it did boot with
On Fri, 2022-05-13 at 12:26 +, Artem Tim wrote:
> It works for me and really like this new approach. Switched couple of
> my packages and no issue so far with rpmautospec itself. But some
> 3rd-party tools requires some work and adaption. For example if you
> already switched to rpmautospec for
OLD: Fedora-Rawhide-20220515.n.0
NEW: Fedora-Rawhide-20220516.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 234
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
* Aurelien Bompard [14/05/2022 09:39] :
>
> Please check it out if you're interested, it has an analysis of the existing
> system and requirements for the next.
> And the best time for feedback is now, before the work actually starts :-)
One thing I've always wanted is to be able to have a daily/
On Mon, May 16, 2022 at 6:39 AM Panu Matilainen wrote:
>
> On 5/13/22 21:54, Jason L Tibbitts III wrote:
> > So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
> > as part of my usual testing. In the middle of the process, it appears
> > that /var filled up and that left the
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
On 5/16/22 15:06, Nico Kadel-Garcia wrote:
On Mon, May 16, 2022 at 6:39 AM Panu Matilainen wrote:
On 5/13/22 21:54, Jason L Tibbitts III wrote:
So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
as part of my usual testing. In the middle of the process, it appears
that /
> == Benefit to Fedora ==
> This simplifies our default code path by using the same partitioning
> scheme as UEFI systems and aligns us more to how Fedora variants that
> are delivered as disk images, which all use a similar setup. It also
> paves the way to implement hybrid BIOS+UEFI boot for lega
On Mon, May 16, 2022 at 9:25 AM Gerd Hoffmann wrote:
>
> > == Benefit to Fedora ==
> > This simplifies our default code path by using the same partitioning
> > scheme as UEFI systems and aligns us more to how Fedora variants that
> > are delivered as disk images, which all use a similar setup. It
Missing expected images:
Iot dvd x86_64
Iot dvd aarch64
Failed openQA tests: 2/15 (x86_64), 6/15 (aarch64)
ID: 1269419 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1269419
ID: 1269421 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignitio
Hi Steve,
On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote:
> On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> > Are you going to take this idea forward and make a formal change proposal
> > for Fedora to set -ftrivial-auto-var-init=zero by default in its default
> > RPM build
No missing expected images.
Failed openQA tests: 2/15 (x86_64), 3/15 (aarch64)
Old failures (same test failed in Fedora-IoT-36-20220514.0):
ID: 1269453 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1269453
ID: 1269455 Test: x86_64 IoT-
On 5/11/22 19:35, Steve Grubb wrote:
On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
[snip]
Fast-forward a few months and I see GCC 12.1 is released now with
-ftrivial-auto-var-init option support [2].
Are you going to take this idea forward and make a formal change proposal
On Mon, May 16 2022 at 07:23:20 AM -0700, John Reiser
wrote:
Zero is the worst possible auto-int value. It will hide the most
bugs.
That's true, but using zero also converts code execution
vulnerabilities into denial of service vulnerabilities. Dereference a
NULL pointer and you get a non-e
On 17:20 Wed 11 May , Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
> >> AFAIK, even if you rebuild the exact same sources with the exact same
> >> toolchain with the exact same compiler flags, you still can't claim TCK
> >> ce
On 10:37 Wed 11 May , Omair Majid wrote:
> Hi,
>
> Daniel P. Berrangé writes:
>
> > One way to reduce this burden is to not introduce new JDKs to all
> > existing Fedora streams, only add it to rawhide so certification is
> > only needed once.
> >
> > Having said that I'm still not clear on
Missing expected images:
Minimal raw-xz armhfp
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 22/161 (aarch64), 11/231 (x86_64)
New failures (same test not failed in Fedora-Rawhide-20220515.n.0):
ID: 1268871 Test: aarch64 Server-dvd-iso
instal
On 01:07 Wed 11 May , Kevin Kofler via devel wrote:
> 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://
On 16/05/2022 16:33, Andrew Hughes wrote:
These proposals do ask for exceptional treatment for the JDKs on
Fedora, but it's an attempt to move away from what is an exceptional
way of building the JDK that differs from other vendors and puts
the Fedora JDK at a disadvantage in many situations.
I
On Mon, 2022-05-16 at 02:05 +0100, Sérgio Basto wrote:
> On Fri, 2022-05-13 at 13:54 -0500, Jason L Tibbitts III wrote:
> > So I went to do a dnf system-upgrade from F35 to F36 on a test
> > machine,
> > as part of my usual testing. In the middle of the process, it
> > appears
> > that /var filled
On 5/16/22 07:33, Michael Catanzaro wrote:
On Mon, May 16 2022 at 07:23:20 AM -0700, John Reiser
wrote:
Zero is the worst possible auto-int value. It will hide the most bugs.
That's true, but using zero also converts code execution vulnerabilities into
denial of service vulnerabilities. De
Once upon a time, Andrew Hughes said:
> The idea here is that we'd do something similar in Fedora; build on
> the oldest supported release, but provide that version on all
> supported releases.
That would also mean that the JDKs would lag any other Fedora
system-wide changes, such as compiler/lib
On 16/05/2022 16:23, John Reiser wrote:
Please do not use zero as the default auto-init value. Use 0x818181..81
instead.
Fedora only cares about security issues, not about various logical
errors. Setting uninitialized variables to 0 is fine.
Also I think that every such implicit assignment
On 16/05/2022 16:53, Andrew Hughes wrote:
I expect JDK users would disagree with you. JDKs from other vendors
(Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and
likely other GNU/Linux distributions) are the exception here.
Because they build it for all available GNU/Linux distr
On Mon, May 16, 2022 at 07:23:20AM -0700, John Reiser wrote:
> On 5/11/22 19:35, Steve Grubb wrote:
> > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
>[snip]
> > > Fast-forward a few months and I see GCC 12.1 is released now with
> > > -ftrivial-auto-var-init option support [2
On Mon, May 16, 2022 at 7:18 PM Mark Wielaard wrote:
>
> Hi Steve,
>
> On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote:
> > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> > > Are you going to take this idea forward and make a formal change proposal
> > > for Fedora to set -
siddhesh wrote:
> [...] The ideal would be a rawhide-debug (or f37-build-debug,
> etc) target that disables trivial-auto-var-init and maybe also some
> other flags to improve debuggability, but that could be a separate
> proposal.
We don't build "debug" variants of the distro RPMs for a variety
With the release of ansible-collection-community-docker 2.5.1, the license has
changed from `GPLv3+` > `GPLv3+ and Python`.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
signature.asc
Description: This is a digitally signed message part.
___
d
On Fri, May 13, 2022 at 3:20 PM przemek klosowski via devel
wrote:
>
> I had issues with this for several releases now, although I never got a
> broken upgrade like you're reporting: every time so far I got a message
> 'you need additional 4GB on /' before the actual upgrade started. It
> would be
On Mon, May 16, 2022 at 8:07 AM Nico Kadel-Garcia wrote:
> An in-place system upgrade is not an "unexpected event". It is a risky
> transaction.
>
> The big space pig is not /var/lib/rpm: it's /var/cache/dnf, which can
> be quite flooded by updated packages tool suites such as openoffice
> or tet
If you missed the announcement at the release party, the F36 release
retrospective survey is now open:
https://fedoraproject.limequery.com/231354
It should only take a few moments of your time. No matter how you
participated in the development and release of F36, I'd like your
input. (Remember, th
On Mon, May 16, 2022 at 1:03 PM Ben Cotton wrote:
>
> If you missed the announcement at the release party, the F36 release
> retrospective survey is now open:
> https://fedoraproject.limequery.com/231354
Whoops! That's the F35 link. The correct survey link is
https://fedoraproject.limequery.com/3
On 5/16/22 12:10, Chris Murphy wrote:
> On Fri, May 13, 2022 at 3:20 PM przemek klosowski via devel
>
>
>> Unfortunately, I believe that the current upgrade workflow requires a
>> root disk three times the total installed package size: each package is
>> there as the original version, the RPM
Andrew Hughes wrote:
> On 01:07 Wed 11 May , Kevin Kofler via devel wrote:
>> Let me join the train of -1 votes. I consider this a step entirely in the
>> wrong direction. The JDK should be linked to system libraries wherever
>> possible just like our other packages. Language interpreters/JITs
Hello!
My apologies, I had accidentally dropped out of computer world for a while,
and here a world spins ahead! Thanx a lot for many valuable feedback!
see the clarifications of most concerns:
> Might be a copy-paste error there, the last sentence is incomplete.
ty, fixed: "We already made a h
> > I would rather have our shared maintenance and evolution of font stuff be
> reused in Java too...
>
> This is holy grail we have been pursuing for last 10 years. But now we gave
> up. To keep java alive in Fedora, we have to take this one step back.
Why did you give up?
> > This case ap
No missing expected images.
Failed openQA tests: 2/48 (x86_64)
ID: 1269729 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1269729
ID: 1269742 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1269742
Soft
On Mon, May 16, 2022 at 4:54 PM Andrew Hughes wrote:
>
> >
> > Let me join the train of -1 votes. I consider this a step entirely in the
> > wrong direction. The JDK should be linked to system libraries wherever
> > possible just like our other packages. Language interpreters/JITs are not
> > exem
On 5/16/22 05:06, Nico Kadel-Garcia wrote:
On Mon, May 16, 2022 at 6:39 AM Panu Matilainen wrote:
Rpm has had a heuristic on the rpmdb growth for years, but no heuristics
can help against unexpected events eating the space.
An in-place system upgrade is not an "unexpected event". It is a risk
On Mon, May 16, 2022 at 12:14 PM Chris Murphy wrote:
>
> On Mon, May 16, 2022 at 8:07 AM Nico Kadel-Garcia wrote:
> > An in-place system upgrade is not an "unexpected event". It is a risky
> > transaction.
> >
> > The big space pig is not /var/lib/rpm: it's /var/cache/dnf, which can
> > be quite
Jiri Vanek wrote:
> see the clarifications of most concerns:
Unfortunately, your mail does not clarify all that much for me. I actually
see several contradictions, e.g.:
> > Are people really installing OpenJDK RPM packages, taking the
> > "/usr/bin/java" binary, and putting it onto some other
On Mon, May 16, 2022 at 2:55 PM Dusty Mabe wrote:
>
>
>
> On 5/16/22 12:10, Chris Murphy wrote:
> > On Fri, May 13, 2022 at 3:20 PM przemek klosowski via devel
>
> >
> >
> >> Unfortunately, I believe that the current upgrade workflow requires a
> >> root disk three times the total installed packag
On Mon, May 16, 2022 at 6:55 PM Kevin Kofler via devel
wrote:
>
> Jiri Vanek wrote:
> > > This sounds fascinating. Can anyone share details about this? On the
> > I'm aware of some codecs, which are built in Fedora, then the binary is
> > sent to .. cisco(?), and if passed, they are repacked in
On 5/10/22 06:29, Ben Cotton wrote:
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
Similar to what Kevin has mentioned, I've also been using the Fedora
openjdk builds for work for many years with no issues in a very large
project
On Mon, May 16, 2022 at 8:27 PM Samuel Sieb wrote:
>
> On 5/10/22 06:29, Ben Cotton wrote:
> > According to developers, the non-portbale JDK is causing upredicted
> > behavior different from other JDK vendors
>
> Similar to what Kevin has mentioned, I've also been using the Fedora
> openjdk build
On 19:36 Tue 10 May , Florian Weimer wrote:
> * 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.
> >
> > Str
On Mon, May 16, 2022 at 9:54 PM Andrew Hughes wrote:
>
> On 19:36 Tue 10 May , Florian Weimer wrote:
> > * 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,
52 matches
Mail list logo
