Because my tests on AMD and Intel, I had to update the linux firmware. Update comes from the upstream fedora packet and also works on CentOS with new kernel.
Currently we are tracking the 4.9 LTS kernel branch and the fedora linux-firmware mentioned above.
This is also the kernel that we use in the armhfp (32 bit Arm) SIG.
Hallo Hughes,
thanks to let me know. It is good that you have a focus on LTS 4.9.
Unfortunately it is so that the new graphics cards from amd to today are not served in the opensource. That’s why I’m experimenting with the latest stable versions and what is so.
My laptop has done the linux-firmware update well, it is nevertheless one of the newest.
The kernel and appropriate firmware is unfortunately only the one side of a driver when it comes to graphics cards.
The hardware decoding works only sometimes. On CentOS in the moment not (Radeon / Intel), but that is not synonymous the focus of a server system. This happens to me also with the original packages.
I give my homework free in the thought that it might help somebody out there.
Sincerely
Andy
Am Samstag, den 10.06.2017, 05:52 -0500 schrieb Johnny Hughes:
No problem at all, and thanks for posting. It might indeed help others.
If you take a look at the git repo for the linux-firmware, you can see the actions that make that installable on both CentOS-7 and also for CentOS-6 in the xen kernel tree (a couple of obsoletes and some other minor changes).
Had experimental my gst-test installed ~ gstreamer 1.6.4
and there seems to be a hardware video playback function. By the wild gstreamer mix of course not stable.
Have only proven that the compilate for intel ok on my laptop.
Sincerely
Andy
Am Samstag, den 10.06.2017, 05:52 -0500 schrieb Johnny Hughes:
Sorry Hughes,
got some questions.
I have the feeling that I do a lot wrong. Today I sent a mailing post at fedora where it is also about btrfs under fedora.
In time when i write the mail i forward it my patch for fedora 25
pretransaction & snapper.yp, with the hope of feedback.
I release a ticket because snapper gui do not build on there repo. Local with mock or without it never fails. No response.
Since yesterday learned how to use snapper against the dbus api. What is the better way in my opinion. After some rest i will do it first on CentOS and it back into fedora “dnf” later on.
It looks to me as if in a Fedora release little movement. If someone wants to upgrade something you simply move it there gladly times on the next release. This generates a high unwilling something at all a working release to submit an improvement. This is a lot better under CentOS, although Redhat is very slow with its update cycles.
Too bad the feedback is not as good as under CentOS.
In principal there are to many ways to push errors or improvments on each (CentOS, redhat, fedora) distros.
Or am I doing something wrong. Is there anything I can do better?
It is hopefully not that I care 3 various Linux (This time Arch/Manjaro, Fedora, CentOS). It helps to get ideas.
Thanks for advice.
Sincerely
Andy
Well .. CentOS Linux (The os/, cr/ , fasttrack/ , and updates/ repos)
are exact rebuilds of upstream RHEL source code with only branding changes. We do no technical changes to this sorce code at all. We build it .. end of story.
If something does not work in CentOS Linux and it also does not work in RHEL .. then great. We want CentOS Linux to work exactly that way .. so we will NOT make technical changes to get it to work in CentOS Linux. The only exception: if the CentOS team introduced a bug in our rebuild that is not present in RHEL source code, we will not fix it. That is just what CentOS Linux is.
If you want to get something fixed in CentOS that is also broken in RHEL, you must submit the changes to Red Hat via either the Fedora or RHEL bug processes. Once those changes are in released into RHEL (and therefore into the public RHEL source code) they will rolled into CentOS
Linux.
For other CentOS repositories where we actually manage the content and DO make technical changes (extras/ , CentOSplus/ any of the SIG repos, etc), you can submit changes to CentOS to get things fixed.
Hopefully this clears up what CentOS Linux is defined as and why we don’t make technical changes.
I obviously meant if we introduced the issue, and it is NOT an issue in RHEL, we WILL fix it :)
Am Dienstag, den 27.06.2017, 11:08 -0500 schrieb Johnny Hughes:
Thanx for clear that up to me. I will follow “your” line up.
8 thoughts on - Test Builds On Private Server Updates (kernel)
If people want an experimental kernel and linux-firmware that lives in the CentOS namespace, we have this:
http://mirror.CentOS.org/altarch/7/experimental/
There are i386 and x86_64 kernels there.
Currently we are tracking the 4.9 LTS kernel branch and the fedora linux-firmware mentioned above.
This is also the kernel that we use in the armhfp (32 bit Arm) SIG.
Hallo Hughes,
thanks to let me know. It is good that you have a focus on LTS 4.9.
Unfortunately it is so that the new graphics cards from amd to today are not served in the opensource. That’s why I’m experimenting with the latest stable versions and what is so.
My laptop has done the linux-firmware update well, it is nevertheless one of the newest.
The kernel and appropriate firmware is unfortunately only the one side of a driver when it comes to graphics cards.
The hardware decoding works only sometimes. On CentOS in the moment not (Radeon / Intel), but that is not synonymous the focus of a server system. This happens to me also with the original packages.
I give my homework free in the thought that it might help somebody out there.
Sincerely
Andy
Am Samstag, den 10.06.2017, 05:52 -0500 schrieb Johnny Hughes:
No problem at all, and thanks for posting. It might indeed help others.
If you take a look at the git repo for the linux-firmware, you can see the actions that make that installable on both CentOS-7 and also for CentOS-6 in the xen kernel tree (a couple of obsoletes and some other minor changes).
https://git.CentOS.org/summary/sig-altarch!linux-firmware.git
Keep up the good work.
Hello Hughes,
Had experimental my gst-test installed ~ gstreamer 1.6.4
and there seems to be a hardware video playback function. By the wild gstreamer mix of course not stable.
Have only proven that the compilate for intel ok on my laptop.
Sincerely
Andy
Am Samstag, den 10.06.2017, 05:52 -0500 schrieb Johnny Hughes:
Sorry Hughes,
got some questions.
I have the feeling that I do a lot wrong. Today I sent a mailing post at fedora where it is also about btrfs under fedora.
In time when i write the mail i forward it my patch for fedora 25
pretransaction & snapper.yp, with the hope of feedback.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject
.org/thread/NLFYHW3IEJHSFBUOEAVHDHBVTL7TOHYZ/
Sometimes I don’t know where to push the information.
on https://copr.fedorainfracloud.org/coprs/andybe/CentOS7Python34/
I release a ticket because snapper gui do not build on there repo. Local with mock or without it never fails. No response.
Since yesterday learned how to use snapper against the dbus api. What is the better way in my opinion. After some rest i will do it first on CentOS and it back into fedora “dnf” later on.
It looks to me as if in a Fedora release little movement. If someone wants to upgrade something you simply move it there gladly times on the next release. This generates a high unwilling something at all a working release to submit an improvement. This is a lot better under CentOS, although Redhat is very slow with its update cycles.
Too bad the feedback is not as good as under CentOS.
In principal there are to many ways to push errors or improvments on each (CentOS, redhat, fedora) distros.
Or am I doing something wrong. Is there anything I can do better?
It is hopefully not that I care 3 various Linux (This time Arch/Manjaro, Fedora, CentOS). It helps to get ideas.
Thanks for advice.
Sincerely
Andy
Well .. CentOS Linux (The os/, cr/ , fasttrack/ , and updates/ repos)
are exact rebuilds of upstream RHEL source code with only branding changes. We do no technical changes to this sorce code at all. We build it .. end of story.
If something does not work in CentOS Linux and it also does not work in RHEL .. then great. We want CentOS Linux to work exactly that way .. so we will NOT make technical changes to get it to work in CentOS Linux. The only exception: if the CentOS team introduced a bug in our rebuild that is not present in RHEL source code, we will not fix it. That is just what CentOS Linux is.
If you want to get something fixed in CentOS that is also broken in RHEL, you must submit the changes to Red Hat via either the Fedora or RHEL bug processes. Once those changes are in released into RHEL (and therefore into the public RHEL source code) they will rolled into CentOS
Linux.
For other CentOS repositories where we actually manage the content and DO make technical changes (extras/ , CentOSplus/ any of the SIG repos, etc), you can submit changes to CentOS to get things fixed.
Hopefully this clears up what CentOS Linux is defined as and why we don’t make technical changes.
I obviously meant if we introduced the issue, and it is NOT an issue in RHEL, we WILL fix it :)
Am Dienstag, den 27.06.2017, 11:08 -0500 schrieb Johnny Hughes:
Thanx for clear that up to me. I will follow “your” line up.
Sincerely
Andy