Re: how long does dnf system-upgrade take?

2024-04-15 Thread Tim via users
Tim:
>> Let's be clear, we're not talking about annoying changes to how the
>> desktop looks, that can be put up with.  But when you find essential
>> software and/or hardware doesn't work anymore, or doesn't exist
>> anymore, and support libraries are incompatible, that's a deal-breaker.
>>
>> It's a part of the reasons Linux gets minimal support with hardware
>> (printers, graphics cards, scanners, whatever).  Those manufacturers
>> don't want to be dealing with ever-changing infrastructure where
>> someone else is making all these changes.  And there's every chance
>> that by the time they've developed their gadget and software for it, a
>> Linux distro has changed OSs twice.


Samuel Sieb:
> The only reason this is a problem for some manufacturers is because they 
> want to keep it proprietary.  Printers and scanners (and any other 
> hardware) that use open standards or provide open-source drivers work 
> great with Linux.  Compare the difference between NVidia and AMD or 
> Intel.  How often do you see people having issues with AMD or Intel 
> graphics compared to the never-ending issues with NVidia drivers?

I don't agree.  It's a PART of the reason, sure.  But not the only
reason.  When you're developing anything computing or electronics,
there's often years between conception of the idea and (allegedly)
finished product.

That's hard to do when you're trying to fit into someone else's product
that keeps changing.  You have to learn how it works before you can
develop for it, but then *it* changes and you have to start again. 
Certainly, open standards help, but many of them don't exist when you
start, and others come into being in the middle.

In both electronics and computing you have developers who want things
done their way, and rival techniques vie for pole position.  Linux
seems very bad at continually re-inventing the wheel.  How many
different sound systems have we had over the years?

-- 
 
uname -rsvp
Linux 3.10.0-1160.114.2.el7.x86_64 #1 SMP Wed Mar 20 15:54:52 UTC 2024 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: crippling nvidia display issue.

2024-04-15 Thread John Pilkington

On 15/04/2024 20:02, home user wrote:

On 4/11/24 11:19 AM, home user wrote:

After a few days of being seriously side-tracked, I can try to get back 
to this.


Those who explained the kernel numbering: thank-you.

(f-38; stand-alone work station; nvidia graphics card; dual monitor; 
kmod 4xx driver)


I just finished doing a "dnf upgrade" as a prerequisite step to 
upgrading from f-38 to f-39.
There were no hints of any problems.  The kernel and the graphics 
driver were replaced during this "dnf upgrade".

The akmods did finish before I rebooted.
The shutdown took 5 minutes because it ran akmods (a second time?!).
During the boot-up, there was a message that it was failing back to 
nouveau.
The display is not working properly; only one monitor is being used 
and everything is oversized in the display.
I am not comfortable proceeding with the f-38 to f-39 upgrade with the 
work station in this condition.


Important: I have only one old kernel.  I have no rescue kernel.

How do I get this workstation working properly?


A. nvidia's proprietary drivers.

There's
1.
(Thomas)
I finally just nuked all the RPMFusion packages and downloaded the 
drivers directly from https://www.nvidia.com/download/index.aspx and 
ran the installer from there. It works fine again.


(Todd)

I can tell you that building the 2 or 3 nvidia 470xx packages
works well for the later 6.7 and current 6.8 kernels.


and there's
2.
(John)
AIUI we are moving from X11 graphics towards Wayland, which the nvidia 
driver will not support...


(Michael)
So, not sure if this is a kernel issue, or the driver issue, but seems 
neither rpmfusiong or nvidia's driver will work any longer?


These seem to me to be inconsistent with each other.  What am I missing?

B. nvidia and Fedora.

 From posts in this thread, I gather that
1. nvidia users can no longer use Fedora, and
2. Fedora users can no longer use nvidia.
Is this correct?



I don't think your summaries are correct.   But although technical fixes 
may exist for the immediate problems the situation at rpmfusion looks 
more difficult.  See this Bugzilla and in particular Comment 5.


https://bugzilla.rpmfusion.org/show_bug.cgi?id=6904

John P
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: crippling nvidia display issue.

2024-04-15 Thread Thomas Cameron


On 4/15/24 14:02, home user wrote:

On 4/11/24 11:19 AM, home user wrote:





There's
1.
(Thomas)
I finally just nuked all the RPMFusion packages and downloaded the 
drivers directly from https://www.nvidia.com/download/index.aspx and 
ran the installer from there. It works fine again.


(Todd)

I can tell you that building the 2 or 3 nvidia 470xx packages
works well for the later 6.7 and current 6.8 kernels.


and there's
2.
(John)
AIUI we are moving from X11 graphics towards Wayland, which the nvidia 
driver will not support...


(Michael)
So, not sure if this is a kernel issue, or the driver issue, but seems 
neither rpmfusiong or nvidia's driver will work any longer?


These seem to me to be inconsistent with each other.  What am I missing?

B. nvidia and Fedora.

 From posts in this thread, I gather that
1. nvidia users can no longer use Fedora, and


That's not AT ALL what I said. I was able to use the NVidia drivers from 
NVidia's web site just fine. Others mentioned they did the same.



2. Fedora users can no longer use nvidia.


Again, I didn't see ANYTHING that intimated that.


Is this correct?


Nope. I've been using Linux since 1995. NVidia drivers have ALWAYS been 
problematic. RPMFusion has done amazing work trying to make it less 
onerous, but often times NVidia makes changes that catch third parties 
like RPMFusion unawares. I *feel* like this is just another case of 
this. It stinks, but it's not the end of the world. Either wait til this 
gets fixed by the volunteer developers at RPMFusion (and be cool to 
them, most are working out of love for the community), or install the 
NVidia drivers from NVidia web site. You'll be fine.


--
Thomas
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: crippling nvidia display issue.

2024-04-15 Thread home user

On 4/11/24 11:19 AM, home user wrote:

After a few days of being seriously side-tracked, I can try to get back to this.

Those who explained the kernel numbering: thank-you.


(f-38; stand-alone work station; nvidia graphics card; dual monitor; kmod 4xx 
driver)

I just finished doing a "dnf upgrade" as a prerequisite step to upgrading from 
f-38 to f-39.
There were no hints of any problems.  The kernel and the graphics driver were replaced 
during this "dnf upgrade".
The akmods did finish before I rebooted.
The shutdown took 5 minutes because it ran akmods (a second time?!).
During the boot-up, there was a message that it was failing back to nouveau.
The display is not working properly; only one monitor is being used and 
everything is oversized in the display.
I am not comfortable proceeding with the f-38 to f-39 upgrade with the work 
station in this condition.

Important: I have only one old kernel.  I have no rescue kernel.

How do I get this workstation working properly?


A. nvidia's proprietary drivers.

There's
1.
(Thomas)
I finally just nuked all the RPMFusion packages and downloaded the 
drivers directly from https://www.nvidia.com/download/index.aspx and ran 
the installer from there. It works fine again.


(Todd)

I can tell you that building the 2 or 3 nvidia 470xx packages
works well for the later 6.7 and current 6.8 kernels.


and there's
2.
(John)

AIUI we are moving from X11 graphics towards Wayland, which the nvidia driver 
will not support...


(Michael)
So, not sure if this is a kernel issue, or the driver issue, 
but seems neither rpmfusiong or nvidia's driver will work any 
longer?


These seem to me to be inconsistent with each other.  What am I missing?

B. nvidia and Fedora.

From posts in this thread, I gather that
1. nvidia users can no longer use Fedora, and
2. Fedora users can no longer use nvidia.
Is this correct?
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[389-users] Re: Permission of log files

2024-04-15 Thread Rob Murray
Julian

The ldif below will do the trick,  replace the add: with replac;e if the 
attributes already exist.

Rob


dn: cn=config
changetype: modify
add: nsslapd-accesslog-mode
nsslapd-accesslog-mode: 644
-
add: nsslapd-errorlog-mode
nsslapd-errorlog-mode: 644



-Original Message-
From: Julian Kippels  
Sent: Monday, April 15, 2024 4:51 AM
To: General discussion list for the 389 Directory server project. 
<389-users@lists.fedoraproject.org>
Subject: [389-users] Permission of log files

✉External message: Use caution.


Hi,

I am looking for a way to configure the default permission of the log files in 
/var/log/dirsrv//* All the files there belong to dirsrv:dirsrv with 
the permission of 0600.
I would like to have the default permission to be 0644 so that my external 
log-monitoring can access the files.

Julian
--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[389-users] Re: Permission of log files

2024-04-15 Thread Julian Kippels

Welp, just call for help and you find a way to help yourself.

I was only looking in the cockpit-webinterface for an option. I just 
found out that there is a configuration parameter I can set with dsconf 
in the cli called nsslapd-{access,error,…}log-mode= where I can do the 
exact thing I want to do.


Julian

Am 15.04.24 um 09:50 schrieb Julian Kippels:

Hi,

I am looking for a way to configure the default permission of the log 
files in /var/log/dirsrv//*
All the files there belong to dirsrv:dirsrv with the permission of 0600. 
I would like to have the default permission to be 0644 so that my 
external log-monitoring can access the files.


Julian

--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



--
-
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-


smime.p7s
Description: Kryptografische S/MIME-Signatur
--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[389-users] Permission of log files

2024-04-15 Thread Julian Kippels

Hi,

I am looking for a way to configure the default permission of the log 
files in /var/log/dirsrv//*
All the files there belong to dirsrv:dirsrv with the permission of 0600. 
I would like to have the default permission to be 0644 so that my 
external log-monitoring can access the files.


Julian


smime.p7s
Description: Kryptografische S/MIME-Signatur
--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue