On 06/12/2022 16:37, Kevin Kofler via devel wrote:
Terry Barnaby wrote:
Well in this case I have created a suitable compat lib, all I did was
re-introduce the bits to the SPEC file that removed the building of the
compat lib and we are fine. I haven't separated it out from the main
ncurses
On 06/12/2022 17:40, Vít Ondruch wrote:
Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):
On 06/12/2022 15:56, Vít Ondruch wrote:
Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 06 December 2022 at 07:43, Ter
On 06/12/2022 20:21, Josh Boyer wrote:
On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen wrote:
On Tue, 6 Dec 2022 at 13:50, Josh Boyer wrote:
On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa wrote:
On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer wrote:
On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby
On 06/12/2022 15:56, Vít Ondruch wrote:
Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]
My view is that compat versions of the commonly used shared lib
On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]
My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not
On 05/12/2022 16:00, Jarek Prokop wrote:
On 12/5/22 14:57, Peter Robinson wrote:
On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
wrote:
On 05/12/2022 12:39, Terry Barnaby wrote:
I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly c
Hi,
With the latest release of Fedora37 we were hit with an issue where the
ncurses-compat-libs RPM had been depreciated. Due to this some of the
tools we use would no longer install from their respective RPM's or
their tar based installs would not run as they needed the
libncurses*5.so share
On 15/02/18 16:48, J. Bruce Fields wrote:
On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote:
The transaction system allows the write delegation to send the data to the
servers RAM without the overhead of synchronous writes to the disk.
As far as I'm concerned this probl
On 12/02/18 22:14, J. Bruce Fields wrote:
On Mon, Feb 12, 2018 at 08:12:58PM +, Terry Barnaby wrote:
On 12/02/18 17:35, Terry Barnaby wrote:
On 12/02/18 17:15, J. Bruce Fields wrote:
On Mon, Feb 12, 2018 at 05:09:32PM +, Terry Barnaby wrote:
One thing on this, that I forgot to ask
On 12/02/18 17:35, Terry Barnaby wrote:
On 12/02/18 17:15, J. Bruce Fields wrote:
On Mon, Feb 12, 2018 at 05:09:32PM +, Terry Barnaby wrote:
One thing on this, that I forgot to ask, doesn't fsync() work
properly with
an NFS server side async mount then ?
No.
If a server sets "
On 12/02/18 17:15, J. Bruce Fields wrote:
On Mon, Feb 12, 2018 at 05:09:32PM +, Terry Barnaby wrote:
One thing on this, that I forgot to ask, doesn't fsync() work properly with
an NFS server side async mount then ?
No.
If a server sets "async" on an export, there is absolu
On 12/02/18 17:06, J. Bruce Fields wrote:
On Mon, Feb 12, 2018 at 09:08:47AM +, Terry Barnaby wrote:
On 09/02/18 08:25, nicolas.mail...@laposte.net wrote:
- Mail original -
De: "Terry Barnaby"
If
it was important to get the data to disk it would have been using
fsync(
On 09/02/18 08:25, nicolas.mail...@laposte.net wrote:
- Mail original -
De: "Terry Barnaby"
If
it was important to get the data to disk it would have been using
fsync(), FS sync, or some other transaction based app
??? Many people use NFS NAS because doing RAID+Backup on ev
On 06/02/18 21:48, J. Bruce Fields wrote:
On Tue, Feb 06, 2018 at 08:18:27PM +, Terry Barnaby wrote:
Well, when a program running on a system calls open(), write() etc. to the
local disk FS the disk's contents is not actually updated. The data is in
server buffers until the next sync/
On 06/02/18 18:55, J. Bruce Fields wrote:
On Tue, Feb 06, 2018 at 06:49:28PM +, Terry Barnaby wrote:
On 05/02/18 14:52, J. Bruce Fields wrote:
Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a certain
NFS mounted directory over a slow link (NFS over Openvpn ov
On 05/02/18 23:06, J. Bruce Fields wrote:
On Thu, Feb 01, 2018 at 08:29:49AM +, Terry Barnaby wrote:
1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE call
all in one. This would reduce the latency of a small file to 1ms rather than
3ms thus 66% faster. Would require the
S is really broken performance wise these days and it "appears"
that significant/huge improvements are possible.
Anyone know what group/who is responsible for NFS protocol these days ?
Also what group/who is responsible for the Linux kernel's implementation of
it ?
--
Dr Terr
On 01/02/18 08:29, Terry Barnaby wrote:
On 01/02/18 01:34, Jeremy Linton wrote:
On 01/31/2018 09:49 AM, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton wrote:
Have you tried this with a '-o nfsvers=3' during mount? Did that help?
I noticed a large d
On 01/02/18 01:34, Jeremy Linton wrote:
On 01/31/2018 09:49 AM, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton wrote:
Have you tried this with a '-o nfsvers=3' during mount? Did that help?
I noticed a large decrease in my kernel build times across NFS/lan a
whi
On 30/01/18 21:31, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 07:03:17PM +, Terry Barnaby wrote:
It looks like each RPC call takes about 0.5ms. Why do there need to be some
many RPC calls for this ? The OPEN call could set the attribs, no need for
the later GETATTR or SETATTR calls
Being a daredevil, I have used the NFS async option for 27 years
without an issue on multiple systems :)
I have just mounted my ext4 disk with the same options you were using
and the same NFS export options and the speed here looks the same as I
had previously. As I can't wait 2+ hours so I'
On 30/01/18 17:54, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 12:31:22PM -0500, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 04:49:41PM +, Terry Barnaby wrote:
I have just tried running the untar on our work systems. These are again
Fedora27 but newer hardware.
I set one of the
On 30/01/18 16:22, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 03:29:41PM +, Terry Barnaby wrote:
On 30/01/18 15:09, J. Bruce Fields wrote:
By comparison on my little home server (Fedora, ext4, a couple WD Black
1TB drives), with sync, that untar takes is 7:44, about 8ms/file.
Ok, that
On 30/01/18 15:09, J. Bruce Fields wrote:
On Tue, Jan 30, 2018 at 08:49:27AM +, Terry Barnaby wrote:
On 29/01/18 22:28, J. Bruce Fields wrote:
On Mon, Jan 29, 2018 at 08:37:50PM +, Terry Barnaby wrote:
Ok, that's a shame unless NFSv4's write performance with small fil
On 29/01/18 22:28, J. Bruce Fields wrote:
On Mon, Jan 29, 2018 at 08:37:50PM +, Terry Barnaby wrote:
Ok, that's a shame unless NFSv4's write performance with small files/dirs
is relatively ok which it isn't on my systems.
Although async was "unsafe" this was not
On 29/01/18 19:50, Steve Dickson wrote:
On 01/29/2018 12:42 PM, Steven Whitehouse wrote:
Forwarded Message
Subject:Re: Fedora27: NFS v4 terrible write performance, is async
working
Date: Sun, 28 Jan 2018 21:17:02 +
From: Terry Barnaby
To: Steven
On 28/01/18 15:47, Richard W.M. Jones wrote:
Please post questions on the users list:
https://lists.fedoraproject.org/admin/lists/users.lists.fedoraproject.org/
Sorry, will move there. Thought developers may be more into NFS that
users in general these days there being no responses in the user
On 28/01/18 14:38, Steven Whitehouse wrote:
Hi,
On 28/01/18 07:48, Terry Barnaby wrote:
When doing a tar -xzf ... of a big source tar on an NFSv4 file system
the time taken is huge. I am seeing an overall data rate of about 1
MByte per second across the network interface. If I copy a single
When doing a tar -xzf ... of a big source tar on an NFSv4 file system
the time taken is huge. I am seeing an overall data rate of about 1
MByte per second across the network interface. If I copy a single large
file I see a network data rate of about 110 MBytes/sec which is about
the limit of th
I am trying to build a spin of Fedora18 for local use as I normally do with
Fedora releases using pungi. All has been built fine but the installation
fails with an Anaconda popup stating "The following error occurred ..." with
no information on the error at all and nothing in the various virtual te
On 03/29/2012 10:44 AM, Terry Barnaby wrote:
> On 03/28/2012 12:31 PM, Caterpillar wrote:
>>
>>
>> 2012/3/28 Terry Barnaby mailto:ter...@beam.ltd.uk>>
>>
>> On 03/26/2012 09:20 PM, J. Randall Owens wrote:
>> > On 03/26/2012 06:05 AM, Terry Ba
On 04/21/2012 08:38 AM, Terry Barnaby wrote:
> On 21/04/12 08:10, Terry Barnaby wrote:
>> Some update appears to have broken the operation of ypbind recently.
>> I have a F14 sever that serves /home and implements NIS services (ypserv)
>> and has been running fine for over
On 21/04/12 08:10, Terry Barnaby wrote:
Some update appears to have broken the operation of ypbind recently.
I have a F14 sever that serves /home and implements NIS services (ypserv)
and has been running fine for over a year.
The F16 clients use NetworkManager with wired Ethernet set to
Some update appears to have broken the operation of ypbind recently.
I have a F14 sever that serves /home and implements NIS services (ypserv)
and has been running fine for over a year.
The F16 clients use NetworkManager with wired Ethernet set to automatic/system
connection. Everything comes up
On 03/28/2012 12:31 PM, Caterpillar wrote:
>
>
> 2012/3/28 Terry Barnaby mailto:ter...@beam.ltd.uk>>
>
> On 03/26/2012 09:20 PM, J. Randall Owens wrote:
> > On 03/26/2012 06:05 AM, Terry Barnaby wrote:
> >> Hi,
> >>
> >&g
On 03/26/2012 09:20 PM, J. Randall Owens wrote:
> On 03/26/2012 06:05 AM, Terry Barnaby wrote:
>> Hi,
>>
>> I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
>> problems with a MicroSD card connected to a USB card reader. This has
>> been work
On 03/26/2012 02:05 PM, Terry Barnaby wrote:
> Hi,
>
> I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
> problems with a MicroSD card connected to a USB card reader. This has
> been working fine until recently (at least in F14 on the same hardware).
>
>
Hi,
I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
problems with a MicroSD card connected to a USB card reader. This has
been working fine until recently (at least in F14 on the same hardware).
The problem is that "umount" does not appear to be working correctly.
I have an
On 16/04/10 16:43, Adam Williamson wrote:
> On Fri, 2010-04-16 at 09:05 +0100, Terry Barnaby wrote:
>> I was going to try and participate in the Graphics test week
>> for ATI/Intel boards. However I can't download either:
>>
>> http://jlaska.fedorapeopl
I was going to try and participate in the Graphics test week
for ATI/Intel boards. However I can't download either:
http://jlaska.fedorapeople.org/2010-04-13-nouveau-testday/gfx_test_week_20100414_i686.iso
or
http://adamwill.fedorapeople.org/gfx_test_week_20100412/gfx_test_week_20100412_x86-64.i
On 27/03/10 15:08, Matthias Clasen wrote:
> On Sat, 2010-03-27 at 08:19 +0000, Terry Barnaby wrote:
>
>>
>> I'm not sure if your usage policy covers changes to Bodhi, but how about
>> the system emailing the upstream developers (direct and/or email lists)
>> w
On 27/03/10 04:12, Adam Williamson wrote:
> On Sat, 2010-03-27 at 03:50 +0100, Kevin Kofler wrote:
>
>> So I don't think blocking an update outright for having received type 2
>> feedback is sane at all.
>
> Sigh. That was why I said not to sidetrack the discussion because it was
> the least import
>
> This isn't really true. Or at least, not a productive perspective for
> improving Fedora. There are certainly a lot of bugs in the open drivers
> shipped with Fedora, and there's a lot of work to do to fix them all. I
> sent my own reply to Terry explaining how we're handling this at
> present
On 03/18/2010 09:00 PM, Adam Williamson wrote:
> .
> That's somewhat optimistic; no matter how much testing we do, we can
> only afford a certain amount of full-time developer muscle. The testing
> has helped to improve efficiency and direction of graphics development
> work, I think, but t
On 18/03/10 19:18, Adam Williamson wrote:
> On Thu, 2010-03-18 at 12:57 +0000, Terry Barnaby wrote:
>
>> As part of a Fedora release I would have thought that part of the
>> test schedule would be to load and view some test documents with
>> openoffice on a set number
On 03/18/2010 12:58 PM, Rahul Sundaram wrote:
> On 03/18/2010 06:27 PM, Terry Barnaby wrote:
>>
>> As part of a Fedora release I would have thought that part of the
>> test schedule would be to load and view some test documents with
>> openoffice on a set number of pl
On 03/18/2010 06:28 AM, David Tardon wrote:
> On Sat, Mar 13, 2010 at 07:58:03AM +0000, Terry Barnaby wrote:
>> Last night I was helping some school kids with a powerpoint presentation
>> they had written. They had, not un-reasoanbly, used FontWork titles.
>> Under F12 with O
On 03/16/2010 08:19 PM, Tom "spot" Callaway wrote:
> On 03/16/2010 08:27 AM, Alain Portal wrote:
>> Hi,
>>
>> I get some problem in packaging kicad.
>> Linking fails, and I don't know how to solve.
>> There is no problem if I compile without packaging.
>
> Well, I doubt that seriously. This code i
On 14/03/10 16:29, Kevin Kofler wrote:
> Terry Barnaby wrote:
>> Last night I was helping some school kids with a powerpoint presentation
>> they had written. They had, not un-reasoanbly, used FontWork titles.
>> Under F12 with OpenOffice 3.1 it took 3 minutes to load the
On 13/03/10 01:45, Kevin Kofler wrote:
> Al Dunsmuir wrote:
>> And turning all releases into rolling branches helps keep things
>> sane?
>>
>> Please call a spade a spade. Without a reduction in churn in the stable
>> releases that is what they become and remain until EOL - a rolling branch.
On 12/03/10 03:42, Kevin Kofler wrote:
> Chris Adams wrote:
>> There's a difference between not supporting third-party software (is
>> that actually documented somewhere or another Kevin Kofler rule?) and
>> intentionally breaking it.
>
> There's no policy saying we support it, ergo by default, we
On 03/09/2010 06:20 PM, Ewan Mac Mahon wrote:
> On Tue, Mar 09, 2010 at 05:55:33PM +0000, Terry Barnaby wrote:
>> On 09/03/10 16:50, Ewan Mac Mahon wrote:
>>> On Tue, Mar 09, 2010 at 09:33:45AM -0500, Al Dunsmuir wrote:
>>>>
>>>> I have limited
On 09/03/10 16:50, Ewan Mac Mahon wrote:
> On Tue, Mar 09, 2010 at 09:33:45AM -0500, Al Dunsmuir wrote:
>> Hello Seth,
>>
>> Tuesday, March 9, 2010, 9:23:00 AM, you wrote:
>>
>>> Your primary server runs fedora? May I ask why?
>>> -sv
>>
>> I have limited time to do system installs and maintenan
On 09/03/10 15:26, Seth Vidal wrote:
>
>
> On Tue, 9 Mar 2010, Konstantin Ryabitsev wrote:
>
>> On Tue, Mar 9, 2010 at 8:51 AM, Seth Vidal wrote:
>>> Here's the camps I see:
>>>
>>> 1. One group wants us to aim for mom/pop/grandma/desktop users - the
>>> apple market or what ubuntu aims for.
>>>
>
On 09/03/10 15:49, Matt Domsch wrote:
> On Tue, Mar 09, 2010 at 03:30:37PM +0000, Terry Barnaby wrote:
>> I personally thought the old 12 month RedHat Linux release cycle was about
>> right.
>
> RHL was also on a 6 month release cycle.
>
Shows how good my memory is :)
Min
On 03/09/2010 02:57 PM, Al Dunsmuir wrote:
> Hello Seth,
>
> Tuesday, March 9, 2010, 9:37:26 AM, you wrote:
>
>
>
>> On Tue, 9 Mar 2010, Al Dunsmuir wrote:
>
>>> Hello Seth,
>>>
>>> Tuesday, March 9, 2010, 9:23:00 AM, you wrote:
>>>
Your primary server runs fedora? May I ask why?
-sv
On 08/03/10 23:12, Matthew Garrett wrote:
> On Mon, Mar 08, 2010 at 11:21:45PM +0100, Sven Lankes wrote:
>>
>> If Fesco is aiming at getting rid of all the pesky packagers maintaining low
>> profile packages: You're well on your way.
>
> So, no, that's not the intent and it's realised that this is
On 28/02/10 08:02, Adam Williamson wrote:
> On Sun, 2010-02-28 at 07:44 +0000, Terry Barnaby wrote:
>> Hi,
>>
>> In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12,
>> that fixes an issue with lirc on 2.6.32 kernels that has been
>> subm
Hi,
In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12,
that fixes an issue with lirc on 2.6.32 kernels that has been
submitted to updates-testing.
This package does not seem to exist there and the link to its bodhi entry
from the bugzilla page links to an entry for bind ...
On 01/12/2010 09:16 AM, Jakub Jelinek wrote:
> Yes, the tokens are separated by whitespace, so it is sufficient if they are
> again separated by whitespace after preprocessing. See
> http://gcc.gnu.org/PR41445 for details why this changed, in short
> without the change the tokens have incorrect lo
I am trying to build OpenFOAM on F12 and have a problem with cpp.
In OpenFOAM cpp is used to pre-process Makefiles to create the build
environment (yuck). Some of the files contain backslash-newline
sequences for line continuations. F12's cpp seems to remove the
backslash but leave the newline in p
61 matches
Mail list logo
