I'm running for the EPEL Steering Committee. If I've ever helped you with EPEL, or you've enjoyed my conference presentations about EPEL, please consider voting for me.
Being on the west coast is weird. Most folks I usually talk too of an evening are asleep. I picked up a lovely stomach bug at LFNW last weekend and have spent much of today sleeping at the JB studio!
Heading from Seattle to Austin (again) tomorrow for #devopsdaysaustin
Obviously this is an excuse for more Terry Blacks.
@ironicbadger Oh dang, if I wasn't traveling to Denver for Summit I would totally head up there to hang with you at that conference and get some BBQ. You know I love Terry Black's, but you should branch out this trip and try some other places. Go check out La Barbecue and Micklethwait.
TIL Fedora is packaging a web browser app I developed for elementary OS, stopped updating over three years ago, and marked as end-of-life two years ago—yet it happily shows up in Fedora 40 if you search my name. It crashes on launch, so it doesn’t even work…
WHY??
Edit: I guess the package is being EOL'd in Fedora due to it no longer building and this thread, huzzah! My recommendation to distros: don’t package random apps and then not maintain them/communicate with upstream.
@cassidy@adamw You don't have to create a bugzilla account. You can email <package>-maintainers@fedoraproject.org to reach the maintainers of a package.
@cassidy@adamw Unfortunately none of those suggestions would have helped in this case. Fedora builds don't download upstream tarballs directly. The maintainer downloads the tarball from upstream once and uploads it to Fedora's "look aside cache", which is what the build system uses during package builds. The last time the package version was updated was in 2021, the day after the last tagged version, at which time I'm assuming the GitHub repo was not yet marked as archived.
@cassidy@adamw Future rebuilds for new Fedora versions continued to use the same cached tarball without checking GitHub. The builds kept passing until the F40 rebuild. That failed build was probably the first indication to the maintainer that something was awry, and it appears they just didn't have time to investigate it before the F40 release.
@cassidy@adamw As is usually the case, there just isn't a real substitute for upstream and downstream communicating, ideally in official channels like issue trackers, not on social media where it may or may not be seen.
Even short of that, an initial post on social media like "what's the best way to contact the maintainer of a Fedora package" would have been more appropriate than how this was handled.
"Against the wishes of the upstream" is not a fair statement. If the software is open source, distros can package it without permission. Upstreams can and do close bugs for platforms they don't care about.
@cassidy@adamw Venting on social media without communicating with the package maintainer first is not nice. It comes off as shaming the entire project, even if that wasn't your intent. You are of course free to use social media however you like, just as others are free to reply on social media that they don't like how you handled a situation.
Your excuse of "I wouldn’t have even known where to have this discussion on an issue tracker" is weak, which is why I mentioned doing a basic search.
#CentOS 7 Will go end of life in about 2 months, and this isn’t the usual EOL distribution: this time, it’s the entire distribution that is being shelved, without any upgrade path.
So I decided to take a look at why it’s a bigger deal than usual, and invited Joao Correia from TuxCare and the Enterprise Linux Podcast for an interview, to explain the issues in more detail, since they are experts about this.
@thelinuxEXP CentOS has never offered an official upgrade path between major versions. We did offer an official upgrade path from CentOS Linux 8 to CentOS Stream 8, because they're really two variants of the same distro, not an entirely different distro.
Have you reached out to anyone in the CentOS project (the actual experts on CentOS) to talk about CentOS?
@maxamillion It's weird to me how so many people (here and in other comment sections) want to outright dismiss the concerns raised in the article because of flaws in the writing. My guess is it was written by a non-native English speaker, which if true would make critiques of the writing kinda tacky IMO. But writing mistakes aside, the concerns raised are the important part, and no one has answers for those.
@maxamillion The most frustrating part to me is story 6, spreading FUD, which is still a rampant problem. I just recently got home from staffing the CentOS booth at SCALE. We had multiple attendees visit our booth and say "Wait, you have a booth? The Rocky booth just told me you don't exist anymore." This was among several other false/misleading claims they were pushing about CentOS, Red Hat, and even Alma, which people were happy to inform us about. It's demoralizing.
In case you haven't heard, @TexasLinuxFest is back this year, April 12-13 in Austin! We took a long hiatus during COVID, but everyone is excited to bring the show back. Get ready for two days of nerding out on Linux and open source topics.
The Redis thing underscores a key point: open source is not enough. We need community built software -- free and open source licenses are just one aspect of that.
If a company requires you to assign copyright (or equivalent re-licensing rights) in an asymmetrical way, they will inevitably eventually decide to take that option once they want to cash in on the goodwill you've built for them (let alone the code).
@mattdm The asymmetrical aspect of the SSPL is what bothers me the most. That license is extremely viral, but companies choosing it exclude themselves from those viral requirements. At its core that license is designed to provide an asymmetric advantage to a single company.
On more look back to CentOS at Flock while we look forward to CentOS Connect at FOSDEM. Troy Dawson took the stage yet again, this time with @carlwgeorge, to tell us the state of EPEL.
Someone is operating fuel powered leaf blowers, but it's in the quiet hours of 13:00-15:00; you are only allowed to operate them from 9-13 and 15-17 (15-19? I don't know), so I better call the authorities to fine them, but I don't know who they are and the authorities may not get here on time to catch them committing the offence.
@juliank Go ask for a business card or just the name of the business. If they hesitate you can lie and say you know someone looking for a new leaf blower company. Then report the business.
Here's a tip for those looking to upgrade to Fedora 39 before the official release: enable the updates-testing repo first. Due an extended release freeze, there are quite a few updates stacking up in the updates-testing repo that normally would have been pushed to stable by now. One of these updates was even necessary for me to complete my upgrade transaction.
Also you may want to set a reminder to turn updates-testing back off after the final release.
This is a short message from the openSUSE Board that we are posting on our communication channels and is a reminder that we ask each and every one of you to be kind, considerate and welcoming to people on all our communication channels. Let's foster a positive atmosphere for people on all of our communication channels. Our channels are a wonderful place for collaboration, but also remember that open-source is not about telling others what or how to build.
CentOS Stream wants it both ways. It wants to brand itself as a community distro like Fedora just with more QA and stricter stability guarantees. When your distribution is entirely developed by people working at Red Hat and the people with the most weight in decision making are RHEL customers and not the actual users/community of CentOS Stream, it's not a community distro.
@maxgot CentOS Stream is RHEL built in the open in collaboration with the community. Decisions are still made by Red Hat, so it's not community led, but it's more community oriented than classic CentOS ever was.
@maxgot This would be incredibly difficult to measure. The bulk of the dataset would come from GitLab merge requests. You would also have to go find bugzillas with patches attached, which was the workflow for CS8 before it was onboarded to the CS9 GitLab workflow.
@maxgot You'll have to identify the authors, not just as Hatters or not, but RHEL maintainers or not. I would argue that a MR from @Conan_Kudo working in a different department counts as community because working on RHEL is not his job. Or my submissions working in CPE to upstream debranding stuff for classic CentOS 8, or to resolve issues in support of EPEL. It gets even harder because I don't believe the maintainers are required to use their at-redhat-dot-com email addresses.
Just to recap the latest in the #Redhat RHEL vs downstreams not offering them any value drama:
Redhat publically states that downstream rebuilders offer them no value, and the RHEL community should all be working in the Centos-stream sandbox, because that's where the community is, because it has community right there in the name, and that's where the code fixes can land, and community is only about lines of code in the repo.
@almalinux goes "alright, no value in us being a 1:1 rebuild of RHEL, then we're cutting our own path while being based on Centos-stream, staying ABI compatible with RHEL, but we'll fix our own bugs when we find them"
Alma Linux then finds a CVE in the iperf3 server impacting everyone in the Enterprise Linux 9 ecosystem, so they release the fix for AlmaLinux, and then immediately open pull requests for Fedora and Centos-stream to land the fix upstream. Which would seem to be exactly what Redhat was asking for this whole time.
Redhat's response to the centos-stream pull request? "There is no current customer demand for this fix in RHEL, so we're not interested in this fix"
The astute will notice that the pull request is feeding into centos-stream, and not RHEL. But they're making merge decisions here based on immediate customer demand in RHEL.
So maybe this whole "Centos-stream is the community distro" line was bullshit and it really is just the beta testing ground for RHEL, just like all of us kind of thought it was while getting shouted down by the centos-stream advocates this whole time.
@kwf@almalinux
Merge decisions for CentOS Stream contributions are made by Red Hat. CentOS Stream is still more of a community-oriented distro than CentOS Linux. Both of these things are true.
I can't help but feel the "shouted down by the centos-stream advocates" is directed at me. If I've ever made you feel "shouted down", I truly apologize. I'm a believer in the strategic direction of the CentOS project. The execution is a work in progress.
@kwf On the third point, it's also no. Things are only merged into CentOS Stream if they are planned for the next minor version of the corresponding RHEL major version. Merging things that aren't intended for RHEL would be against what we've described CS as. It's not a sandbox to throw out new features/fixes to see if they work. It's the staging area for QA-tested, RHEL-compatible updates that are approved for the next minor version.
@kwf@almalinux I never said that community primarily translates into patch submissions. What I have said is that not being able to accept patches that change the OS is a critical flaw for a project that claims to be community oriented.
CentOS fixed this by moving upstream of RHEL.
Alma has now fixed this by dropping 1:1 and allowing some divergence from RHEL, while staying downstream of RHEL.
Both approaches are valid and should be celebrated.
