devel-announce April 2023

devel-announce@lists.fedoraproject.org

8 participants
19 discussions

It’s time to transform the Fedora devel list into something new
by Matthew Miller 20 Apr '23

20 Apr '23

It’s time to transform the Fedora devel list into something new =============================================================== My first post on this list was over 19 years ago. (It was about Bugzilla. I was a fan!) Ever since those early days, devel list has been the heart and center of Fedora activity. Now, I hope to convince all of us here that it’s time for something different. As it is, devel list is too much for many people to follow — people we’d like to have around. It covers many different things at once, yet also drives us towards more scattered communications. Our infamous mega-threads are not really effective for getting to community consensus, and tend to bring out the worst in us. I propose that we transition devel list, and eventually most of our mailing lists, to Fedora Discussion (our Discourse-powered forum). I know this is a big change, but, hear me out… We’re missing people -------------------- A Mastodon post from long-time Fedora contributor Major Hayden got me thinking: > How do people make so much time available for mailing list > discourse? > > Once I ensure my team has the technical guidance they need > and I work through the tasks of work that I owe other > people, I take a look at the mailing list and say: "Oh my > gosh, what the heck happened here?" Then the discussion > goes further off the rails while I'm typing out a reply and > my reply is no longer relevant. > > — https://tootchute.com/@major/109666036733834421 I know many Fedora folks, old-school and new, for whom devel list is just too much. Some of it is the sheer volume, but this “off the rails” tendency is real — threads drift, get into back-and-forth debates about particular details, etc. And… some people aren’t here because — in contrast with our “Friends” foundation, it isn’t always a nice place to be (and mailing lists don’t provide many tools for moderation, except the big hammer of outright bans). Ben Cotton recently did some basic analysis on devel list traffic over time, and there’s a clear trend: fewer people are participating, even though the number of different threads goes up. I don’t think this is because of any decline in Fedora contributors overall — I think it’s that conversations are happening elsewhere. Big threads are … bad, actually ------------------------------- When we have something to talk about, it tends to explode into a big thread. The thing in January with FESCo’s frame pointers decision (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…) is a good example of things going badly. Most of the conversation was under the subject “Schedule for Tuesday's FESCo Meeting (2023-01-03)”, because everything started as a reply to that. That’s pretty easy to overlook. It’s possible for replies to change the subject when replying, but that can’t be done retroactively, and then isn’t consistent (and it breaks threading in Gmail, too). Then, things got rather hostile, making it hard to have a reasonable conversation about the issues (both technical and procedural). And then, things went in circles without adding anything new. This could have all gone a lot better. And that’s just one example. Take a look back at any mega-thread, and you’ll find similar — and worse. When things get heated, the only way to intervene is by adding more. There are often long subthreads of two people going back and forth on tangents. Then, other conversation branches duplicate that, or refer across. Classical email tools don’t actually handle this kind of thing very well at all. In my experience, it only really works if you keep up with the conversation in almost real time, which has its own problems even when that’s possible. We’re scattered in actual practice ---------------------------------- Devel list may be the center, but we have _hundreds_ of Fedora mailing lists. A dozen or so are reasonably active (Test, Legal, ARM…) but most are inactive or dead. Some are just meeting reminders over and over — for meetings that aren’t even active anymore. It’s easy to make but hard to _unmake_ a mailing list. For lists that are active, the split is confusing — when should something be on the packaging list rather than devel? What happens when something is related to both Cloud and Server, or Workstation and KDE? One can post to both lists, but if someone replies and isn’t subscribed to both, the conversation gets split. With “devel” as the main list, conversations about marketing, design, events, and so on don’t really have a central place. (The Mindshare list never really caught on.) That makes these important activities feel even more disconnected and secondary in status — and they shouldn’t be. Many groups have actually moved away from lists to using tickets for team conversations — both those non-engineering functions and development. Design Team has a mailing list, but mostly for announcements: the work happens in tickets. Workstation largely uses their Pagure tracker. And CoreOS conversations happen almost entirely in tickets on Github. Tickets are made for tracking specific, actionable tasks, and that kind of tracking is part of why teams use them over mailing lists — but Fedora teams use them for open development conversations too. I think that’s largely a symptom of mailing lists not being enough for what we need. The trackers have media support, editing for typos or updates, reactions for simple agreement, tagging people, and granular subscriptions. They are effectively “off-label use” mini-forums that teams can quietly move to using without the sort of conversation I expect this message to generate. Airplane diagram, survivorship bias ----------------------------------- Since I’m posting this to devel list, I do expect a lot of push-back. Maybe I’ll be surprised and more of y’all are already with me on this and just waiting for something to happen. But overall I expect a tough crowd. You’ve probably heard the story about bullet holes in airplanes returning from missions and the accompanying diagram — find it athere https://en.wikipedia.org/wiki/Survivorship_bias if that’s new to you. The set of remaining regular participants on this list is naturally biased towards those for whom it is working just fine. But, core Fedora development discussion can’t be limited to that ever-shrinking group. Consider who isn’t here. The problems are real, and the trend isn’t in a good direction. Devel List is too many different things! ---------------------------------------- We use it for Change discussion (resulting in those not-actually-so-great big threads). We use it for introductions and onboarding — we’re usually pretty good at that, actually (but it adds to the overall load of following the list). We’re not very consistent, though. We discuss packaging: guidelines, help on different topics, coordination on specific work. There’s unclear overlap with the packaging list, though, which is a bit confusing. We talk about higher-level Fedora OS development topics that don’t fit anywhere else. For example, this on installer environment size: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Sometimes, these are FESCo topics (which FESCo heroically struggles to keep here rather than on Pagure tickets…). Sometimes, people talk about a particular interest in the hopes of forming a Special Interest Group. Often that does result in a new SIG launching — sometimes with a brand-new mailing list which then ends up getting only a few posts ( and a whole lot of spam years later). But this really suffers from the survivorship problem: many people who might be interested will never notice. We have release process announcements — mostly to devel-announce, but then occasionally replies and discussion here. Blocker bugs and other test-list and QA topics are cross-posted, as part of the release cycle. And then there are a lot of robo-messages: reports, reminders, etc. These are really valuable to a few people, but add a lot more to wade through for everyone else trying to keep up. There are certainly others, as well. In short… there probably shouldn’t just be one thing. But, the cross-posting problem makes it hard to split up as a mailing list. Enter Discourse --------------- If you’ve talked with me about anything related to any of this in the past ten years, you probably already know that I like Discourse. It’s good software made by cool people. And, it’s entirely open source, with a SaaS business model but with real, usable releases. (No open core, no “open source theoretically but good luck”.) And, we have it in production in Fedora already, at https://discussion.fedoraproject.org, with categories for announcements, user help, project discussion, and social conversation — as well as special categories for dedicated workflows. In Project Discussion, each different Fedora team can have its own tag, and you can subscribe to those that you’re interested in. Cross-posting is easy: tag a post with multiple teams. Topics can be renamed, if needed, or split out into side-conversations. The long tangents from these conversations can actually be interesting on their own without distracting from the main topic. Moderation tools allow us to handle posts that are outside of expected Fedora contributor behavior, with varying levels of action as appropriate. You can use markdown formatting, including images (with easy addition of alt text for people for whom images are a barrier). You can edit your posts to fix typos or correct mistakes. There are polls and lots of other useful features. And, you can interact with it all by email. That interface isn’t perfect, but it’s way better than any other forum software I’ve seen. (I’ve written a guide: https://discussion.fedoraproject.org/t/25960) At the same time, your individual email address is hidden, so it won’t be a spam magnet (or a target for off-list harassment, a problem we unfortunately have with devel list). That said, it is web-first software. (Or mobile, if that’s your thing.) That requires some adjustment, I know. I hope opening up a Fedora Discussion tab – or keeping one open — becomes an easy habit. Not just Fedora --------------- There’s a big trend towards Discourse in open source projects overall. Python and Gnome have both migrated entirely from their mailing lists. Ansible is working on it. Plus, there’s Rust, Kubernetes, Nextcloud, Flathub, Grafana, Home Assistant, KDE, and I’m sure many others. Concrete proposal ----------------- I’m not suggesting we shut down devel list next week. And I think we’ll have some mailing lists for quite a long time. But, I think it’s time to start moving some specific things, with the eventual goal of closing every mailing list we can. First, I’d like to move the Changes discussion. They will still be posted to devel-announce, but responses directed to Project Discussion in a new #changes tag. Ben tells me that this is a FESCo decision, which seems reasonable. Second, I think other FESCo-related conversations should move. I hope this will reduce the urge to have back-and-forth exchanges in the tickets. For the Fedora Council, I set up a bot which automatically creates a discussion topic when a ticket is filed, leaving the ticket just for votes and recording of outcome. FESCo could use something similar. Third, I’ll add a tag for general Fedora OS development conversation. Maybe “#devel”, but if someone has more narrow suggestions, I’ll take them. Fourth, I’d like to update our documentation, process, and expectations for newcomers — say hello on Discussion (and Fedora Chat, if you like) rather than a mailing list. (I’d like to close the Fedora Join list at this point.) Fifth, all packaging-related discussions (including the separate packaging mailing list). We already have a #package-maintainers tag with some existing discussion. Sixth, automated posts, as much as we can. These should go to dedicated Workflow categories, where people who want can watch them but where they won’t overwhelm human interactions. People who want can watch them, and it’s easy to quote-reply into a new linked topic in the Project Discussions category. And finally… shut down the devel list itself. Perhaps at the end of 2023? We should also shut down all of the little lists that haven’t had anything but spam in the last two years. We could maybe do that sooner. We should stop creating new lists now — we can create new Discussion tags instead. I expect the announcement lists to stay for the foreseeable future (although we might feed them from Discourse rather than the other way around). Other lists which are patches, commit messages, and other automations might stick around for a while — but really might be better served by a log aggregation and analysis system or something else. Other teams who want to keep mailing lists can, but I’d like to move those too, and eventually I think we’ll want to shut them down too — or perhaps convert them to announcement lists. Next steps ---------- I know this is a big change. I’ve been thinking of writing this message for a long time. I’d really like to convince everyone that it’s the right thing — or at least, an acceptable one. What about specific decisions related to my proposal? For each: Because altering the Changes process is a FESCo decision, I’ll file a ticket about that shortly. FESCo moving their own other conversations is, of course, also a FESCo decision. Assuming the first moves forward, I will create the general #devel tag (or other name we come up with) when I create the #change-proposal tag. Moving the packaging list is a Packaging Committee decision. Automated posts can be moved at any time. I can work with the people who own the generation of those reports to figure out a good answer for each. The outcome for other team lists is up to each team. And, I think shutting down devel overall is ultimately a Fedora Council decision. For right now, though: let’s discuss — on the list! -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

F39 proposal: Remove standard storage option from Fedora EC2 images (Self-Contained Change proposal)
by Ben Cotton 17 Apr '23

17 Apr '23

https://fedoraproject.org/wiki/Changes/CloudEC2ImagesNoStandardStorage This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == AWS offers multiple [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html types of block storage] depending on the needs of the individual user. Fedora images are uploaded with `standard` and `gp2` currently (`gp3` will replace `gp2` very soon with another [https://fedoraproject.org/wiki/Changes/CloudEC2gp3 approved change]). The `standard` storage is a previous generation storage option with less performance and less consistent performance than the other storage types. It also causes some confusion when AWS customers look through the list of Fedora cloud images in the EC2 console because now they see '''four''' images (aarch64 + x86_64, both with `standard` and `gp2` storage). Removing the `standard` storage option would reduce the amount of images that appear in the console, but AWS customers could still provision Fedora on standard storage during the instance creation process if they really want that storage option. == Owner == * Name: [[User:mhayden| Major Hayden]] * Email: major(a)redhat.com == Detailed Description == The scripts that upload images to AWS will be adjusted so that they do not include the creation of an AMI with standard storage. AWS customers could still choose that option at instance creation time if needed. == Feedback == No alternatives have been proposed yet. == Benefit to Fedora == This would reduce the amount of Fedora AMIs that appear in the EC2 console by half and it would ensure that Fedora lands on AWS' best performing storage (soon to be `gp3`) by default. It avoids a situation where an AWS customer (without a strong knowledge in block storage types) starts a Fedora instance on standard storage and gets a low performance experience. It would have no effect on running instances or existing AMIs. == Scope == * Proposal owners: This is an isolated change that should be made within `fedimg` and it affects only the AMI creation process. * Other developers: Should not require work from other developers. * Release engineering: No work should be required from releng for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: Should make it easier to display Fedora AWS images on the Fedora Cloud page. == Upgrade/compatibility impact == Existing systems will not be affected by this change. Customers launching new instances will get better performing storage by default but will still have the option to select standard storage if they really need it. == How To Test == 1. The updated version of fedimg should create only `gp2` (soon to be `gp3`) AMIs. 2. We can verify that the latest image upload from rawhide (after the fedimg change is made) will only include a gp2/gp3-backed image. == User Experience == AWS customers who are not familiar with different block storage types should always land on high performance storage. They still have the option to choose other storage types at instance creation time. == Dependencies == Only fedimg needs to be updated. There are no other dependencies. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora AMIs for EC2 now default to the latest `gp2/3` storage option. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F39 proposal: Remove webkit2gtk-4.0 API Version (System-Wide Change proposal)
by Ben Cotton 17 Apr '23

17 Apr '23

https://fedoraproject.org/wiki/Changes/Remove_webkit2gtk-4.0_API_Version This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The webkit2gtk-4.0 API version will no longer be built. Packages that depend on it will fail to build from source and eventually be retired. == Owner == * Name: [[User:catanzaro|Michael Catanzaro]] * Email: <mcatanzaro(a)redhat.com> == Detailed Description == The webkitgtk source package currently provides three different API versions of WebKitGTK: * webkit2gtk-4.0: for GTK 3 and libsoup 2 * webkit2gtk-4.1: for GTK 3 and libsoup 3 * webkitgtk-6.0: for GTK 4 and libsoup 3 Building three different package versions is slow, and Red Hat does not wish to do so anymore. We will remove the webkit2gtk-4.0 API version, which is provided by the webkit2gtk4.0 and javascriptcoregtk4.0 packages. Everything that depends on these packages will fail to build from source and will eventually be removed from the distribution unless fixed. The good news is that updating your package to webkit2gtk-4.1 is probably easy because there are no API changes other than the version of libsoup that is linked to. If your package does not directly or indirectly depend on libsoup 2, then just change the API version number from 4.0 to 4.1 and you're done. [https://src.fedoraproject.org/rpms/emacs/c/1670e57f63e0897d6d6027826f247bb3… Here is a typical example of how easy this is.] However, if your package does directly or indirectly depend on libsoup 2, then you will need to eliminate that dependency, which will require more effort. If your application links to libsoup 2 via any dependency, it will crash if also linked to libsoup 3. This is a slimmed-down version of the [[Changes/libsoup_3:_Part_Two|libsoup 3: Part Two]] change proposal that was previously rejected by FESCo. Instead of removing all packages that depend on libsoup 2, packages will only be removed if they depend on both libsoup 2 and also WebKitGTK. No effort will be made to remove libsoup 2 from the distribution (though an obsolete HTTP library is a major security risk and packages really ought to stop using it). == Benefit to Fedora == libsoup 3 brings support for HTTP/2, whereas libsoup 2 supports only HTTP/1.1. Users will experience shorter load times and improved responsiveness in applications that use WebKitGTK. Users of applications that previously used webkit2gtk-4.0 will have one fewer massive package installed after this transition is completed. Additionally, the WebKitGTK package maintainer will be less grumpy because WebKitGTK will need to be built only twice for each supported version of Fedora, rather than three times. == Scope == * Proposal owners: ensure packages required by Fedora Workstation and ELN no longer depend on webkit2gtk-4.0 (already done) * Other developers: ensure other packages no longer depend on webkit2gtk-4.0 * Release engineering: [https://pagure.io/releng/issue/11368 #11368] * Policies and guidelines: no policies or guidelines would need to be updated * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: None == Upgrade/compatibility impact == To be determined. The newer packages can either Obsoletes the older ones, or not, since they are not compatible, it's probably not appropriate to use Obsoletes? == How To Test == Applications ported to webkit2gtk-4.1 need to be tested individually to ensure they still work. It's unlikely anything will go wrong for applications that do not directly or indirectly use libsoup 2. If an application or one of its dependencies needs to be ported to libsoup 3, then there is more potential for trouble. == User Experience == Users will experience shorter load times and improved responsiveness. Additionally, there will be one fewer huge package that might be installed on user systems. == Dependencies == $ dnf repoquery --whatdepends webkit2gtk4.0 --latest-limit 1 --arch 'noarch,x86_64' Last metadata expiration check: 0:00:31 ago on Thu 30 Mar 2023 03:07:12 PM CDT. apostrophe-1:2.6.3-6.fc38.noarch apvlv-0:0.4.0-2.fc38.x86_64 atril-libs-0:1.26.0-4.fc38.x86_64 badwolf-0:1.2.2-4.fc38.x86_64 balsa-0:2.6.4-2.fc38.x86_64 bookworm-0:1.1.3-0.9.20200414git.c7c3643.fc38.x86_64 cairo-dock-plug-ins-webkit-0:3.4.1-42.20210730gitf24f769.fc38.1.x86_64 claws-mail-plugins-fancy-0:4.1.1-5.fc38.x86_64 eclipse-swt-1:4.26-2.fc38.x86_64 emacs-1:28.2-4.fc38.x86_64 ephemeral-0:7.1.0-5.fc38.x86_64 exaile-0:4.1.2-2.fc38.noarch exfalso-0:4.5.0-5.fc38.noarch fapolicy-analyzer-0:1.0.0-1.fc38.x86_64 foliate-0:2.6.4-6.fc38.noarch gambas3-gb-gtk3-webview-0:3.18.1-1.fc38.x86_64 gamehub-0:0.16.3.2-6.fc38.x86_64 geany-plugins-markdown-0:1.38-9.fc38.x86_64 glade-libs-0:3.40.0-2.fc38.x86_64 gnucash-0:4.13-6.fc38.x86_64 gphotoframe-0:2.0.2-17.hg2084299dffb6.fc38.1.noarch gthumb-1:3.12.2-7.fc38.x86_64 liferea-1:1.14.1-1.fc38.x86_64 lutris-0:0.5.12-3.fc38.x86_64 marker-0:0.0.2020.04.04-10.fc38.x86_64 meteo-0:0.9.9.1-4.fc38.x86_64 midori-0:9.0-12.fc38.x86_64 minigalaxy-0:1.2.2-3.fc38.noarch notes-up-0:2.0.6-4.fc38.x86_64 osmo-0:0.4.4-2.fc38.x86_64 pdfpc-0:4.6.0-1.fc38.x86_64 perl-Gtk3-WebKit-0:0.06-27.fc38.noarch rednotebook-0:2.29.3-2.fc38.noarch rubygem-webkit2-gtk-0:4.1.2-1.fc38.noarch setzer-0:0.4.8-2.fc38.noarch sugar-0:0.120-2.fc38.noarch sugar-browse-0:207-6.fc38.noarch sugar-toolkit-gtk3-0:0.120-2.fc38.x86_64 surf-0:2.0-15.fc38.x86_64 ulauncher-0:5.15.2-1.fc38.noarch vfrnav-0:20201231-38.fc38.x86_64 webkit2-sharp-0:0-0.17.20170219gita59fd76.fc38.x86_64 webkit2gtk4.0-devel-0:2.40.0-2.fc38.x86_64 webkit2gtk4.0-doc-0:2.40.0-2.fc38.noarch wxGTK-webview-0:3.2.1-5.fc38.x86_64 wxGTK3-webview-0:3.0.5.1-10.fc38.x86_64 xiphos-0:4.2.1-18.fc38.x86_64 xreader-libs-0:3.6.3-1.fc38.x86_64 yad-0:9.3-5.fc38.x86_6 == Contingency Plan == * Contingency mechanism: Bring back the removed subpackages * Contingency deadline: F39 beta freeze * Blocks release? No == Documentation == * [https://webkitgtk.org/reference/webkit2gtk/stable/index.html WebKit2 - 4.1] * [https://webkitgtk.org/reference/webkit2gtk-web-extension/stable/index.html WebKit2WebExtension - 4.1] * [https://webkitgtk.org/reference/jsc-glib/stable/index.html JavaScriptCore - 4.1] * [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Soup - 3.0: Migrating from libsoup 2] == Release Notes == The webkit2gtk4.0 and javascriptcoregtk4.0 packages providing WebKitGTK for GTK 3 and libsoup 2 applications have been removed. Use the webkit2gtk4.1 and javascriptcoregtk4.1 packages instead, providing WebKitGTK for GTK 3 and libsoup 3 applications. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Upcoming Fedora Legal hackfest - converting to SPDX IDs
by David Cantrell 17 Apr '23

17 Apr '23

Fedora Legal will be conducting a hackfest on April 26, 2023 during a four hour block. Information is on the SIGs calendar: https://calendar.fedoraproject.org/SIGs/2023/4/26/ We will be focusing on the ELN package set in Fedora and preparing pull requests for those packages to convert the License tag to a valid SPDX expression. There will be a short presentation and [hopefully] a video walking through an example package and the steps we want package maintainers to follow. If you can make it, great! We expect to do more of these events in the future. What Hackfest for updating the license field in ELN packages to SPDX license expressions. Date Wednesday, April 26, 2023 Time 10:00 - 14:00 US eastern time 18:00 - 22:00 Central European time Where Google Meet: https://meet.google.com/fiu-jdzq-mws (chat.fedoraproject.org information coming soon...awaiting new chat room) How There will be a short presentation for background and a demo on updating a package to start, then we'll work on packages and be available for questions and help. We plan to have more events like this to help package maintainers convert License tags in spec files to SPDX syntax. Thanks, -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 17 Apr '23

17 Apr '23

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/<pkgname> Full report available at: https://churchyard.fedorapeople.org/orphans-2023-04-17.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change ================================================================================ 7kaa orphan 5 weeks ago golang-github-exoscale-egoscale go-sig, orphan 2 weeks ago gstreamer1-plugins-bad-free orphan, uraeus, wtaymans 0 weeks ago kitty atim, orphan, salimma, 2 weeks ago zawertun perl-Debug-ShowStuff orphan 1 weeks ago perl-MemHandle orphan 1 weeks ago pluto orphan 5 weeks ago python-ssh-python orphan 0 weeks ago rocm-smi orphan 0 weeks ago studio-controls orphan 1 weeks ago vim-nerdtree-git-plugin atim, orphan 5 weeks ago wyhash orphan 0 weeks ago The following packages require above mentioned packages: Depending on: golang-github-exoscale-egoscale (4), status change: 2023-03-28 (2 weeks ago) golang-github-acme-lego (maintained by: eclipseo, go-sig) golang-github-acme-lego-4.4.0-8.fc37.src requires golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38 golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38 golang-github-acme-lego-3 (maintained by: eclipseo, go-sig) golang-github-acme-lego-3-3.9.0-7.fc37.src requires golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38 golang-github-acme-lego-3-devel-3.9.0-7.fc37.noarch requires golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38 golang-github-caddyserver-caddy-1 (maintained by: eclipseo, go-sig) golang-github-caddyserver-caddy-1-1.0.4-11.fc38.src requires golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37, golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37, golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37 golang-github-caddyserver-caddy-1-devel-1.0.4-11.fc38.noarch requires golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37, golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37, golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37 golang-github-coredns-corefile-migration (maintained by: eclipseo, go-sig) golang-github-coredns-corefile-migration-1.0.11-10.fc38.src requires golang(github.com/caddyserver/caddy-1/caddyfile) = 1.0.4-11.fc38 golang-github-coredns-corefile-migration-devel-1.0.11-10.fc38.noarch requires golang(github.com/caddyserver/caddy-1/caddyfile) = 1.0.4-11.fc38 Depending on: gstreamer1-plugins-bad-free (22), status change: 2023-04-13 (0 weeks ago) cheese (maintained by: amigadave, gnome-sig, jwrdegoede, mclasen, mcrha) cheese-2:44.0-1.fc39.src requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 cheese-2:44.0-1.fc39.x86_64 requires gstreamer1-plugins-bad-free(x86-64) = 1.22.2-1.fc39 cheese-libs-devel-2:44.0-1.fc39.i686 requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 cheese-libs-devel-2:44.0-1.fc39.x86_64 requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 cozy (maintained by: suve) cozy-1.2.1-3.fc39.noarch requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 farstream02 (maintained by: stefanb, uraeus) farstream02-0.2.9-11.fc38.i686 requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 farstream02-0.2.9-11.fc38.x86_64 requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 gnome-sound-recorder (maintained by: amigadave, gnome-sig) gnome-sound-recorder-43~beta-2.fc38.noarch requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 gnome-sound-recorder-43~beta-2.fc38.src requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39, pkgconfig(gstreamer-player-1.0) = 1.22.2 gnome-subtitles (maintained by: belegdol) gnome-subtitles-1.8-5.fc38.src requires pkgconfig(gstreamer-webrtc-1.0) = 1.22.2 gst-editing-services (maintained by: limb, wtaymans) gst-editing-services-1.22.2-1.fc39.src requires gstreamer1-plugins-bad-free-devel = 1.22.2-1.fc39 gstreamer1-vaapi (maintained by: farnz, kwizart, wtaymans) gstreamer1-vaapi-1.22.2-1.fc39.i686 requires libgstcodecparsers-1.0.so.0 gstreamer1-vaapi-1.22.2-1.fc39.src requires gstreamer1-plugins-bad-free-devel = 1.22.2-1.fc39 gstreamer1-vaapi-1.22.2-1.fc39.x86_64 requires libgstcodecparsers-1.0.so.0()(64bit) gtk4 (maintained by: gnome-sig, kalev, mclasen) gtk4-4.11.1-1.fc39.i686 requires libgstplayer-1.0.so.0 gtk4-4.11.1-1.fc39.src requires pkgconfig(gstreamer-player-1.0) = 1.22.2 gtk4-4.11.1-1.fc39.x86_64 requires libgstplayer-1.0.so.0()(64bit) nheko (maintained by: xvitaly) nheko-0.11.3-2.fc39.src requires pkgconfig(gstreamer-webrtc-1.0) = 1.22.2 nheko-0.11.3-2.fc39.x86_64 requires libgstwebrtc-1.0.so.0()(64bit) pidgin (maintained by: jskarvad, mcrha, nosnilmot) pidgin-2.14.12-3.fc38.x86_64 requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 libpurple-2.14.12-3.fc38.i686 requires libfarstream-0.2.so.5 libpurple-2.14.12-3.fc38.x86_64 requires libfarstream-0.2.so.5()(64bit) pidgin-2.14.12-3.fc38.src requires pkgconfig(farstream-0.2) = 0.2.9 pitivi (maintained by: company, ignatenkobrain, limb, wtaymans) pitivi-2023.03-2.fc39.src requires gstreamer1-plugins-bad-free-devel = 1.22.2-1.fc39 pitivi-2023.03-2.fc39.x86_64 requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 qt5-qtmultimedia (maintained by: jgrulich, jreznik, kde-sig, rdieter, than) qt5-qtmultimedia-5.15.9-1.fc39.i686 requires libgstphotography-1.0.so.0 qt5-qtmultimedia-5.15.9-1.fc39.src requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 qt5-qtmultimedia-5.15.9-1.fc39.x86_64 requires libgstphotography-1.0.so.0()(64bit) qt5-qtwebkit (maintained by: jgrulich, jreznik, kde-sig, rdieter, than) qt5-qtwebkit-5.212.0-0.75alpha4.fc39.src requires pkgconfig(gstreamer-mpegts-1.0) = 1.22.2 qt6-qtmultimedia (maintained by: jgrulich, kde-sig) qt6-qtmultimedia-6.5.0-1.fc39.i686 requires libgstphotography-1.0.so.0 qt6-qtmultimedia-6.5.0-1.fc39.src requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 qt6-qtmultimedia-6.5.0-1.fc39.x86_64 requires libgstphotography-1.0.so.0()(64bit) rust-gstreamer-player-sys (maintained by: atim, rust-sig) rust-gstreamer-player-sys-0.20.0-1.fc39.src requires pkgconfig(gstreamer-player-1.0) = 1.22.2 rust-gstreamer-player-sys+v1_16-devel-0.20.0-1.fc39.noarch requires pkgconfig(gstreamer-player-1.0) = 1.22.2 rust-gstreamer-player-sys+v1_18-devel-0.20.0-1.fc39.noarch requires pkgconfig(gstreamer-player-1.0) = 1.22.2 rust-gstreamer-player-sys+v1_20-devel-0.20.0-1.fc39.noarch requires pkgconfig(gstreamer-player-1.0) = 1.22.2 rust-gstreamer-player-sys+v1_22-devel-0.20.0-1.fc39.noarch requires pkgconfig(gstreamer-player-1.0) = 1.22.2 rust-gstreamer-player-sys-devel-0.20.0-1.fc39.noarch requires pkgconfig(gstreamer-player-1.0) = 1.22.2 sayonara (maintained by: martinkg) sayonara-1.8.0-0.2.beta1.fc38.x86_64 requires gstreamer1-plugins-bad-free = 1.22.2-1.fc39 webkitgtk (maintained by: catanzaro, gnome-sig) webkit2gtk4.0-2.41.2-1.fc39.i686 requires libgsttranscoder-1.0.so.0 webkit2gtk4.0-2.41.2-1.fc39.x86_64 requires libgsttranscoder-1.0.so.0()(64bit) webkit2gtk4.1-2.41.2-1.fc39.i686 requires libgsttranscoder-1.0.so.0 webkit2gtk4.1-2.41.2-1.fc39.x86_64 requires libgsttranscoder-1.0.so.0()(64bit) webkitgtk-2.41.2-1.fc39.src requires pkgconfig(gstreamer-plugins-bad-1.0) = 1.22.2 webkitgtk6.0-2.41.2-1.fc39.i686 requires libgsttranscoder-1.0.so.0 webkitgtk6.0-2.41.2-1.fc39.x86_64 requires libgsttranscoder-1.0.so.0()(64bit) budgie-control-center (maintained by: joshstrobl) budgie-control-center-1.2.0-1.fc38.src requires pkgconfig(cheese) = 44.0 budgie-control-center-1.2.0-1.fc38.x86_64 requires cheese-libs(x86-64) = 2:44.0-1.fc39, libcheese-gtk.so.25()(64bit), libcheese.so.8()(64bit) pidgin-chime (maintained by: dwmw2) pidgin-chime-1.4.1-8.fc38.src requires pkgconfig(farstream-0.2) = 0.2.9 purple-chime-1.4.1-8.fc38.i686 requires libfarstream-0.2.so.5 purple-chime-1.4.1-8.fc38.x86_64 requires libfarstream-0.2.so.5()(64bit) pidgin-sipe (maintained by: stefanb) pidgin-sipe-1.25.0-16.fc38.src requires pkgconfig(farstream-0.2) = 0.2.9 purple-sipe-1.25.0-16.fc38.x86_64 requires libfarstream-0.2.so.5()(64bit) telepathy-farstream (maintained by: kde-sig, rdieter) telepathy-farstream-0.6.1-24.fc38.i686 requires libfarstream-0.2.so.5 telepathy-farstream-0.6.1-24.fc38.src requires farstream02-devel = 0.2.9-11.fc38 telepathy-farstream-0.6.1-24.fc38.x86_64 requires libfarstream-0.2.so.5()(64bit) telepathy-farstream-devel-0.6.1-24.fc38.i686 requires farstream02-devel = 0.2.9-11.fc38, pkgconfig(farstream-0.2) = 0.2.9 telepathy-farstream-devel-0.6.1-24.fc38.x86_64 requires farstream02-devel = 0.2.9-11.fc38, pkgconfig(farstream-0.2) = 0.2.9 telepathy-qt (maintained by: jgrulich, jreznik, kde-sig, rdieter) telepathy-qt-0.9.8-10.fc36.src requires pkgconfig(farstream-0.2) = 0.2.9 Too many dependencies for gstreamer1-plugins-bad-free, not all listed here Depending on: kitty (16), status change: 2023-03-29 (2 weeks ago) golang-github-gdamore-tcell (maintained by: go-sig, qulogic) golang-github-gdamore-tcell-1.4.0-8.fc38.src requires kitty-terminfo = 0.26.5-4.fc38 golang-github-gdamore-tcell-2 (maintained by: go-sig, qulogic) golang-github-gdamore-tcell-2-2.6.0-1.fc39.src requires kitty-terminfo = 0.26.5-4.fc38 golang-github-hinshun-vt10x (maintained by: go-sig, jdoss, mikelo2) golang-github-hinshun-vt10x-0-0.7.20210109git52c1408.fc38.src requires golang(github.com/gdamore/tcell) = 1.4.0-8.fc38 golang-github-hinshun-vt10x-devel-0-0.7.20210109git52c1408.fc38.noarch requires golang(github.com/gdamore/tcell) = 1.4.0-8.fc38 aerc (maintained by: eclipseo, go-sig) aerc-0.14.0-5.fc38.src requires golang(git.sr.ht/~rockorager/tcell-term) = 0.4.0-2.fc38, golang(github.com/gatherstars-com/jwz) = 1.3.0-1.fc37, golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/gdamore/tcell/v2/views) = 2.6.0-1.fc39 fzf (maintained by: go-sig, qulogic) fzf-0.39.0-1.fc39.src requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/gdamore/tcell/v2/encoding) = 2.6.0-1.fc39 gh (maintained by: go-sig, mikelo2) gh-2.27.0-1.fc39.src requires golang(github.com/AlecAivazis/survey/v2) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/core) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/terminal) = 2.3.6-3.fc38, golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/rivo/tview) = 0-0.4.20220509git9994674.fc38 golang-github-cli-2-devel-2.27.0-1.fc39.noarch requires golang(github.com/AlecAivazis/survey/v2) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/core) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/terminal) = 2.3.6-3.fc38, golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/rivo/tview) = 0-0.4.20220509git9994674.fc38 glab (maintained by: go-sig, mikelo2) glab-1.28.0-1.fc39.src requires golang(github.com/AlecAivazis/survey/v2) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/core) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/terminal) = 2.3.6-3.fc38, golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/rivo/tview) = 0-0.4.20220509git9994674.fc38 golang-gitlab-org-cli-devel-1.28.0-1.fc39.noarch requires golang(github.com/AlecAivazis/survey/v2) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/core) = 2.3.6-3.fc38, golang(github.com/AlecAivazis/survey/v2/terminal) = 2.3.6-3.fc38, golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/rivo/tview) = 0-0.4.20220509git9994674.fc38 golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig) golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/rivo/tview) = 0-0.4.20220509git9994674.fc38 rclone (maintained by: eclipseo, go-sig) golang-github-rclone-devel-1.60.1-1.fc38.noarch requires golang(github.com/gdamore/tcell/v2/termbox) = 2.6.0-1.fc39 rclone-1.60.1-1.fc38.src requires golang(github.com/gdamore/tcell/v2/termbox) = 2.6.0-1.fc39 golang-github-rivo-tview (maintained by: eclipseo, go-sig) golang-github-rivo-tview-0-0.4.20220509git9994674.fc38.src requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39 golang-github-rivo-tview-devel-0-0.4.20220509git9994674.fc38.noarch requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39 golang-sr-rockorager-tcell-term (maintained by: go-sig, gotmax23) golang-sr-rockorager-tcell-term-0.4.0-2.fc38.src requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/gdamore/tcell/v2/views) = 2.6.0-1.fc39 golang-sr-rockorager-tcell-term-devel-0.4.0-2.fc38.noarch requires golang(github.com/gdamore/tcell/v2) = 2.6.0-1.fc39, golang(github.com/gdamore/tcell/v2/views) = 2.6.0-1.fc39 golang-github-alecaivazis-survey-2 (maintained by: go-sig, mikelo2) golang-github-alecaivazis-survey-2-2.3.6-3.fc38.src requires golang(github.com/hinshun/vt10x) = 0-0.7.20210109git52c1408.fc38 golang-github-msprev-fzf-bibtex (maintained by: dmoerner, go-sig) golang-github-msprev-fzf-bibtex-1.1-8.20220205gitd5df2c6.fc38.x86_64 requires fzf = 0.39.0-1.fc39 rust-navi (maintained by: jbtrystram, rust-sig) navi-2.20.1-4.fc38.x86_64 requires fzf = 0.39.0-1.fc39 rubygem-sugarjar (maintained by: jaymzh) rubygem-sugarjar-0.0.11-2.fc38.src requires gh = 2.27.0-1.fc39 sugarjar-0.0.11-2.fc38.noarch requires gh = 2.27.0-1.fc39 rclone-browser (maintained by: eclipseo) rclone-browser-1.8.0-8.fc38.x86_64 requires rclone = 1.60.1-1.fc38 Depending on: perl-MemHandle (1), status change: 2023-04-03 (1 weeks ago) perl-Debug-ShowStuff (maintained by: orphan) perl-Debug-ShowStuff-1.16-22.fc38.noarch requires perl(MemHandle) = 0.07 See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan Affected (co)maintainers (either directly or via packages' dependencies): amigadave: gstreamer1-plugins-bad-free atim: gstreamer1-plugins-bad-free, vim-nerdtree-git-plugin, kitty belegdol: gstreamer1-plugins-bad-free catanzaro: gstreamer1-plugins-bad-free company: gstreamer1-plugins-bad-free dmoerner: kitty dwmw2: gstreamer1-plugins-bad-free eclipseo: kitty, golang-github-exoscale-egoscale farnz: gstreamer1-plugins-bad-free gnome-sig: gstreamer1-plugins-bad-free go-sig: kitty, golang-github-exoscale-egoscale gotmax23: kitty ignatenkobrain: gstreamer1-plugins-bad-free jaymzh: kitty jbtrystram: kitty jdoss: kitty jgrulich: gstreamer1-plugins-bad-free joshstrobl: gstreamer1-plugins-bad-free jreznik: gstreamer1-plugins-bad-free jskarvad: gstreamer1-plugins-bad-free jwrdegoede: gstreamer1-plugins-bad-free kalev: gstreamer1-plugins-bad-free kde-sig: gstreamer1-plugins-bad-free kwizart: gstreamer1-plugins-bad-free limb: gstreamer1-plugins-bad-free martinkg: gstreamer1-plugins-bad-free mclasen: gstreamer1-plugins-bad-free mcrha: gstreamer1-plugins-bad-free mikelo2: kitty nosnilmot: gstreamer1-plugins-bad-free qulogic: kitty rdieter: gstreamer1-plugins-bad-free rust-sig: gstreamer1-plugins-bad-free, kitty salimma: kitty stefanb: gstreamer1-plugins-bad-free suve: gstreamer1-plugins-bad-free than: gstreamer1-plugins-bad-free uraeus: gstreamer1-plugins-bad-free wtaymans: gstreamer1-plugins-bad-free xvitaly: gstreamer1-plugins-bad-free zawertun: kitty -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2023-04-17 08:25:43 UTC

1 0

Fedora Linux 38 Final is GO
by Aoife Moloney 14 Apr '23

14 Apr '23

The Fedora Linux 38 Final RC 1.6 compose is GO and will be shipped on Tuesday, 18 April. For more information please check the Go/No-Go meeting minutes[1][2] or log[3][4]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-13/f38_final_gono-… [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-14/f38_final_gono-… [3] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-13/f38_final_gono-… [4] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-14/f38_final_gono-… -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA <https://www.redhat.com> Communications House Cork Road Waterford <https://www.redhat.com>

1 0

Fedora Linux 38 Final Go/No-Go meeting next week
by Ben Cotton 06 Apr '23

06 Apr '23

The Fedora Linux 38 Final Go/No-Go[1] meeting is scheduled for Thursday 13 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Final for the 18 April early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10487/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 38 final freeze
by Tomas Hrcka 04 Apr '23

04 Apr '23

Hi all, Today, 2023-04-04, is an important day on the Fedora Linux 38 schedule [1], with significant cut-offs. Today we have the Final Freeze [2] which starts at 14:00 UTC. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before the final release as zero day updates. [1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/38/final/buglist

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 04 Apr '23

04 Apr '23

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce April 2023