search for: debrand

The subscription-manager dnf plugin is disabled by default as part of our debranding in both CentOS Linux and CentOS Stream. c8: https://git.centos.org/rpms/subscription-manager/blob/580aca8629536c64577e6a443b9349ecb629cc17/f/SPECS/subscription-manager.spec#_850 c8s: https://git.centos.org/rpms/subscription-manager/blob/603dc4a304e237a71a056f674378ff5113a7f710/f/SPECS/subscript...

...latest update (as far as I can tell, anyway). > Yes .. the announcements were stuck in the outbound queue .. and the CentOS-7 one had to be regenerated. The actual RPMs where released last week when they were built. (The announcements were delayed). When the CentOS team changes a package for debranding, except the kernel which has to have the exact same name for 3rd Party Modules or Drivers, we change the dist tag to .el7.centos (or .el6.centos or .el5.centos). We do this to denote that the package has been modified. We only modify packages in the BASE operating system for debranding to meet...

...ontinue as a #rebuilder / #freeloader, > writing software is a hard work. > #offensive terms to the community :-), hide hat wrote it. No, they didn't. That term was bandied about on social media by people who were speculating about the reasoning behind discontinuing the practice of debranding and publishing packages from RHEL minor releases. Mike McGrath responded to the use of that term by social media personalities to explain that the only group that Red Hat (for better or worse) considers freeloaders are large businesses who keep a small number of licensed RHEL systems so that...

...it.centos.org, and the yum repo there doesn?t seem to have an upstream RHEL7 branch. So, I started poking around in the yum.spec file history, and indeed, the oldest yum.spec file on the c7 branch doesn?t have that Requires line! It was introduced in checkin f1c1b982, which claims all it does is ?debrand yum-3.4.3-132.el7?.[2] I realize it is in the CentOS project?s best interest if users always use the fastest mirror when downloading, but I claim that it is a bug to mark any plugin as Requires, particularly when upstream does not. [1]: https://lists.centos.org/pipermail/centos/2016-June/15993...

...Red Hat never published *all* of RHEL's package source code.? For the first six months of any release of RHEL, they would publish de-branded source by essentially taking one artifact from each build (the src.rpm), unpacking that in a git repository, removing the primary source code archive, debranding what was left, committing all of that, and then pushing the result.? It was basically git as a fancy FTP. They've stopped doing that, in favor of publishing the major-release branch of the git repos for the entire primary support lifecycle of the major release. > The spirit of GPL...

On Fri, 17 Jun 2016 07:32:19 +0100 Ned Slider wrote: > > Johnny's announcement refers to: > > firefox-45.2.0-1.el5.centos.src.rpm > > firefox-45.2.0-1.el6.centos.src.rpm > > firefox-45.2.0-1.el7.centos.src.rpm > > > > The linked rhel webpage refers to: > > firefox-45.2.0-1.el5_11.src.rpm > > firefox-45.2.0-1.el6_8.src.rpm > >

...> > writing software is a hard work. > > #offensive terms to the community :-), hide hat wrote it. > > > No, they didn't. > > That term was bandied about on social media by people who were > speculating about the reasoning behind discontinuing the practice of > debranding and publishing packages from RHEL minor releases. > > Mike McGrath responded to the use of that term by social media > personalities to explain that the only group that Red Hat (for better or > worse) considers freeloaders are large businesses who keep a small > number of licensed...

....org, and the yum repo there doesn?t seem to have an upstream RHEL7 branch. > > So, I started poking around in the yum.spec file history, and indeed, the oldest yum.spec file on the c7 branch doesn?t have that Requires line! It was introduced in checkin f1c1b982, which claims all it does is ?debrand yum-3.4.3-132.el7?.[2] > > I realize it is in the CentOS project?s best interest if users always use the fastest mirror when downloading, but I claim that it is a bug to mark any plugin as Requires, particularly when upstream does not. > Correct, the fastestmirror plugin is a requirement...

...ng what people's opinions are on running the CR repository on production systems? I'm currently predisposed to not do it since it indicates it hasn't fully gone through QA yet. But from my understanding except for the alt-arch systems these are just recompiles of the redhat RPMs after debranding right? I'm Curious how other people are treating this repository since, from the sounds of it, rpms are going to be in holding here between releases. So would you treat it as a production repository or for testing only? Do we know how it's actually intended to be treated? Any opinion...

On Tue, Aug 25, 2020 at 2:00 PM Carl George <carl at redhat.com> wrote: > The subscription-manager dnf plugin is disabled by default as part of > our debranding in both CentOS Linux and CentOS Stream. > > c8: > https://git.centos.org/rpms/subscription-manager/blob/580aca8629536c64577e6a443b9349ecb629cc17/f/SPECS/subscription-manager.spec#_850 > c8s > <https://git.centos.org/rpms/subscription-manager/blob/580aca8629536c64577e6a443b9349e...

> I can't predict the future but my feeling is that AlmaLinux has a good > chance to become the second Gold standard. I disagree with you. Both Rocky Linux and AlmaLinux are in a very comfortable position, and they will likely stay that way. my predict is that they will continue as a #rebuilder / #freeloader, writing software is a hard work. SuSe hardfork will probably be only an

Thanks for the replies. I understood that a major part of testing being done by Redhat. But after repackaging the sources how doest CentOS make sure the integrity of the product. Is it being done by a dedicated team or by community ? On Fri, Jun 12, 2015 at 8:37 PM, Jonathan Billings <billings at negate.org> wrote: > On Fri, Jun 12, 2015 at 09:49:42AM +0530, Sudhi wrote: > >

...blished *all* > of RHEL's package source code. For the first six months of any release > of RHEL, they would publish de-branded source by essentially taking one > artifact from each build (the src.rpm), unpacking that in a git > repository, removing the primary source code archive, debranding what > was left, committing all of that, and then pushing the result. It was > basically git as a fancy FTP. > > They've stopped doing that, in favor of publishing the major-release > branch of the git repos for the entire primary support lifecycle of the > major release....

Hi, I help run an NPR/PBS station. We were running ice cast before our most recent upgrade. However after the upgrade we have now been receiving sporadic reports of people being unable to connect. The only confirmed issue is with Saffari on Windows. We are working on that specific one. But I've also received sporadic reports from users on chrome, firefox, mac, and windows and various other

...hed *all* > of RHEL's package source code.? For the first six months of any > release of RHEL, they would publish de-branded source by essentially > taking one artifact from each build (the src.rpm), unpacking that in a > git repository, removing the primary source code archive, debranding > what was left, committing all of that, and then pushing the result.? > It was basically git as a fancy FTP. > > They've stopped doing that, in favor of publishing the major-release > branch of the git repos for the entire primary support lifecycle of > the major relea...

On Mon, 17 Aug 2020 17:49:29 -0500 Gregory P. Ennis wrote: > What appears is below. Removing dependent packages is required. Removing unused dependencies is optional. dnf remove *subscription* --noautoremove should remove the dependent packages but keep thee unused dependencies if you want them. There's also a setting in /etc/dnf/dnf.conf to set the default behaviour of the autoremove

On 7/22/23 02:29, Gordon Messmer wrote: > On 2023-07-21 00:30, Lee Thomas Stephen wrote: >> But for my business, I do not want to pay Red Hat, Zimbra, or Google >> Workspace. >> Why ? >> Because the general rule seems to be >> Oh! You are an individual, we will offer you affordable/free service >> What! You are a business, we will offer you extremely