On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson said:
> > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW
> > dnf system-upgrade fails on some RPi4 due to system boot date that pre-
> > dates gpg key
> >
> > We're still kinda kicking ar
I was asked about the topic in the subject, and I think it's not very
well known. The news is that since Fedora 38, whole system
performance analysis is now easy to do. This can be used to identify
hot spots in single applications, or what the (whole computer) is
really doing during lengthy opera
On Sat, Oct 21, 2023 at 9:35 AM Tomasz Torcz wrote:
> We already have systemd-timesyncd. On startup, it syncs the time to
> the mtime of:
> - /var/lib/systemd/timesync/clock file; or
> - /usr/lib/clock-epoch file; or
> - a time derived from the source tree at build time
>
> timesyncd is mention
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote:
> On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote:
> > Once upon a time, Adam Williamson said:
> > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW
> > > dnf system-upgrade fails on some RPi4 due to system boot date th
On 20-10-2023 15:52, Ben Beasley wrote:
For next time, this seems to work for me:
for p in petsc{,64,-openmpi,-mpich} libpetsc.so; do repoquery -q
--repo=rawhide{,-source} --whatrequires "$p"; done | sort -u
An alternative to above, using gotmax23's excellent fedrq [1], you'd get
the same re
On Sat, Oct 21, 2023 at 8:12 AM Adam Williamson
wrote:
>
> On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote:
> > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote:
> > > Once upon a time, Adam Williamson said:
> > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW
> >
Once upon a time, Gary Buhrmaster said:
> Personally, I have been using systemd-timesyncd for
> quite some time on the vast majority of my systems
> and am quite satisfied with it, but I believe that
> changing from chrony to systemd-timesyncd was
> considered too big of a last minute change since
On Sat, Oct 21, 2023 at 4:08 PM Chris Adams wrote:
> Certainly - I was just looking for a more general solution to non-RTC
> systems going forward. Ideally, there could be something triggered by a
> lack of an RTC, but it looks like systemd path units cannot work based
> on a path (e.g. /dev/rtc
On 10/20/23 13:23, Richard W.M. Jones wrote:
Today I've read (twice) that the overhead of frame pointers on the
runtime of the compiler, GCC, is 10%. This number is nonsense. The
actual overhead is 1%, and I have done the tests that show this.
Both the 1% and the 10% results can be valid. In
On Sat, Oct 21, 2023 at 12:35:30PM -0700, John Reiser wrote:
> On 10/20/23 13:23, Richard W.M. Jones wrote:
> >Today I've read (twice) that the overhead of frame pointers on the
> >runtime of the compiler, GCC, is 10%. This number is nonsense. The
> >actual overhead is 1%, and I have done the tes
On Sat, Oct 21, 2023 at 12:35:30PM -0700, John Reiser wrote:
> Because of the impact of data cache performance, it is important to
> state the CPU, RAM, and cache characteristics when measuring performance.
> Such as: the beginning of /proc/cpuinfo:
I ran the tests a number of times to attempt to
On Fri, Oct 20, 2023, 16:56 Adam Williamson wrote:
> We're still kinda kicking around ideas for "fixing" this, but I think
> if push comes to shove, we'll wind up revoting or waiving it as not
> practically fixable.
How about something of the form of an ExecStartPre expression
(or script) that t
12 matches
Mail list logo
