On 11/9/24 3:59 PM, home user via users wrote:
On 11/8/24 10:53 PM, Samuel Sieb wrote:
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was
displaying the name of the owned file. So I was expecting a file name to
appear o
On 15/11/24 9:00 am, Stephen Morris wrote:
On 13/11/24 15:50, fed...@eyal.emu.id.au wrote:
On 5/11/24 4:32 am, Tim via users wrote:
On Mon, 2024-11-04 at 23:03 +1100, fed...@eyal.emu.id.au wrote:
Note the fact that these messages are NOT junked when they arrive,
but rather a significant time l
On 14/11/24 09:30, Patrick O'Callaghan wrote:
Try this:
sudo dnf --enablerepo=updates-testing update tracer
I ran that command and it updated python3-tracer and tracer-common to
1.2 (the command in the link you provided did nothing for me) and it
also updated python3-libdnf5
After the update
On 13/11/24 15:50, fed...@eyal.emu.id.au wrote:
On 5/11/24 4:32 am, Tim via users wrote:
On Mon, 2024-11-04 at 23:03 +1100, fed...@eyal.emu.id.au wrote:
Note the fact that these messages are NOT junked when they arrive,
but rather a significant time later, when the folder is opened.
Are the o
Hi Everyone,
I attempted a dnf-system-upgrade on an old server (F40) to match the
new server (F41) I've been setting up for the migration. The
dnf-system-upgrade on the old server went sideways after step 3: `dnf
system-upgrade reboot`. On the old server, it appears the upgrade
partially happened.
On Thu, Nov 14, 2024 at 09:07:49AM +1100, Stephen Morris wrote:
On 13/11/24 14:38, Tim wrote:
If you can't see any tangible differences between old and new
configuration files, then there's a reasonable argument to switch over
to the new one, so it's the version designed to go with the current
On Thu, Nov 14, 2024 at 12:23 PM Patrick Dupre via users <
users@lists.fedoraproject.org> wrote:
> Hello,
>
> I am sorry, but I think that I solved the issue by running a make clean
> Now the generated code is the same on both machines.
>
> Probably I have an object from a previous version of gsl
>
> On Wed, Nov 13, 2024 at 11:21:46PM +0100, Patrick Dupre wrote:
> > > Subject: Re: gcc/gsl
> > >
> > > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote:
> > > > >
> > > > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users
> > > > > > wrote:
> > > > > >
> > > > > > Why
On Thu, Nov 14, 2024 at 09:25:40AM +0100, Patrick Dupre wrote:
> No, I do not use such options
Then I don't believe you can get different assembly from the same compiler
same source same options. GCC ought to produce the same output
reproduceably (unless the source uses __DATE__, __TIME__ or __TI
#include
#include
int main () {
printf ("Double: %d %d\n", sizeof(double), sizeof(double_t)) ;
printf ("Float: %d %d\n", sizeof(float), sizeof(float_t)) ;
return 0 ;
}
provides
Double: 8 8
Float: 4 4
on both machines
> Sent: Thursday, November 14, 2024 at 3:46 AM
> From: "Michael Hen
On Wed, Nov 13, 2024 at 3:58 PM Jeffrey Walton wrote:
> On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users
> wrote:
> >
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > Which one is the good one?
> > Why this behavior?
>
Some
Hello,
I am sorry, but I think that I solved the issue by running a make clean
Now the generated code is the same on both machines.
Probably I have an object from a previous version of gsl which was not
recompiled
at the same time on both machines.
My Makefile is probably not optimum.
How can I
12 matches
Mail list logo
