Orphaned emacs-htmlize
Hello everybody, I have orphaned the emacs-htmlize [1,2] package. In its current state, the RPM doesn't work with any non-ancient version of GNU Emacs. This needs to be fixed by updating it to a non-ancient upstream release of emacs-htmlize [3]. I haven't used it for more than a decade, and don't have any time or motivation to give it the attention that it needs. Feel free to pick it up if you want to. Cheers, Rishi [1] https://www.emacswiki.org/emacs/Htmlize [2] https://src.fedoraproject.org/rpms/emacs-htmlize [3] https://bugzilla.redhat.com/show_bug.cgi?id=2270140 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)
Hey Neal,
On Mon, 2023-11-06 at 22:33 -0500, Neal Gompa wrote:
> On Thu, Nov 2, 2023 at 9:43 PM Neal Gompa wrote:
> >
> > Hey folks,
> >
> > As part of the work to upgrade to KDE Plasma 6, appstream is being
> > upgraded to a snapshot release as 1.0.0 is arriving soon. There are
> > some consequences for this change:
> >
> > [...]
> >
> > I've built appstream in a side-tag, and I'd appreciate it if folks
> > could help by adapting their packages and submitting builds into
> > it.
> >
> > This can be done with the following command: fedpkg build
> > --target=f40-build-side-76936
> >
> > My simple query of the consumers of the libraries in question
> > resulted in this:
> > ngompa@fedora ~> sudo dnf repoquery -q --whatrequires
> > "libappstream.so.4()(64bit)" --qf "%{SOURCE_NAME}"
> > appstream
> > appstream-generator
> > flatpak
> > gnome-software
> > libadwaita
> > malcontent
>
> I've handled appstream, appstream-generator, and appstream-data
> already.
>
> * Flatpak has an upstream change that needs backporting[1] or a new
> release.
I am working on the Flatpak backport.
Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey, I wanted to wrap up this sub-thread on-list, after Owen and I chatted about it off-list. I am fine with having the fedora-toolbox OCI images being defined as kickstart files in the Fedora infrastructure and built by ImageFactory and published as another base image, just like the fedora base image currently is. This means that the downstream sources of the images in Fedora that are actually used to make them available to users will differ from the upstream sources that are used for testing and CI and are currently represented as Containerfiles. If we can't use ImageFactory for upstream testing and CI, we will have to carefully keep them synchronized whenever there are changes. If this is the price to pay for making the fedora-toolbox images release-blocking deliverables, then so be it. :) That said, my understanding is that Owen is still not settled on all the tooling changes for building Fedora Flatpaks. So, we may or may not end up using ImageFactory for the fedora-toolbox images in the end. Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey Owen, On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote: > On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel > wrote: > > > > My main concern, which I had brought up in the Release Engineering > > tickets before [1,2] is whether the fedora-toolbox images would > > continue to be defined as a Docker/Containerfile. I am asking > > because the fedora base images are defined as kickstart files [3]. > > > > There's some value in continuing to use a Docker/Containerfile > > because it's widely known and leads to a common workflow. It is > > used for the official Toolbx images for other distributions like > > Arch Linux, RHEL and Ubuntu, and a growing list of third-party > > Toolbx images [4]. A Docker/Containerfile is easy to use with > > 'podman build' as part of the upstream CI, which makes it easier to > > test all the different parts. > > Unfortunately, if we switched to using ImageFactory or pretty much > anything other than OSBS, we'd no longer be able to define the Fedora > toolbox image as a Dockerfile. It certainly is a disadvantage that > it's no longer connected to the way that the other toolbox images are > defined, It's an advantage to have the Fedora images be defined in the same source language as the Arch Linux and Ubuntu images, and certainly the RHEL images. However, ultimately, I see it only as a convenience. Folks can take the Fedora images as a reference and tweak them to fit their own distribution, or copy paste the files across Git repositories, etc.. If we lose that, then I would learn to live with it. :) If we do move away from Container/Dockerfiles, then my main question would be whether it'll still be easy to locally build the images. Will we need something a lot more elaborate than the simplicity of a 'podman build'? Toolbx has two parts. A somewhat distro-agnostic toolbox(1) binary, and an OCI image for a distribution. Both work together to provide an interactive CLI environment, and hence both should be tested together. If a contributor attempts to change one or both of those two, then it should be easy for them to verify whether both would continue to work together. Currently, they can do that by doing a local 'podman build' on the image definitions in toolbox.git and try to use them with their modified toolbox(1) binary. I want to formalize this by making the upstream CI run against both: (a) images that are currently published on the OCI registries and (b) images that are built on-the-fly from the sources in toolbox.git ... so that it will validate any changes to the image sources in toolbox.git, and alert us to any changes in the underlying distribution (eg., packages, dependencies, base images, etc.) that could break future image rebuilds. Currently, the upstream CI runs only against (a). If we lose the simplicity of a 'podman build' then we lose the testing. That's my main worry. If the new set-up offers a similarly simple way of building the images from source, then I am happy. > but maybe that's bearable if we can substantially improve the > workflow? The phrase "we can substantially improve the workflow" makes me curious. Any details or pointers? > With some refactoring of the kickstarts for Fedora containers, we > could also remove some of the hackiness in the Dockerfile where it is > undoing choices in the base image. *nod* > When I ask this question, I do have a hidden agenda - I'm thinking > that it might be possible to move Flatpak generation to a Koji plugin > that runs directly on the builders, but that would leave the toolbox > as the sole user of the OSBS cluster, which seems dubiously > sustainable. So maybe we can take Toolbox off of OSBS as well and > retire OSBS? Yes, I saw you mention this elsewhere. I totally understand and agree with your motivation. Trying to consolidate the infrastructure does sound like a good idea. > Now, if we could instead move to OSBS 2 and have that actively > maintained and across architecture, that could be better, but I don't > really see where the resources are going to come from to do that. *nod* Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey Owen, On Wed, 2023-05-24 at 13:50 -0400, Owen Taylor wrote: > > What if we made the Toolbox container image just one more base image > and built it with ImageFactory? > > - Integrated into the compose process > - Across all architectures > - No OSBS dependency > > The main disadvantage is that it is no longer layered, so *if* you > happen to have the exact same Fedora image version around for some > other reason (a big if), you save a fraction of space: > > Fedora 38 container - 71M compressed, 201M uncompressed > Toolbox add-on layer - 232M compressed, 753M uncompressed > Toolbox squashed - 291M compressed, 884M uncompressed I am not too attached to the bandwidth or space savings due to the fedora-toolbox image being a layered image. [ In future, I would like to explore if we can ship the fedora-toolbox image as part of the Silverblue and Workstation ISOs, to avoid the need for a sizable download just to set up the default Toolbx. That could unlock things like defaulting to a Toolbx shell or generally help promoting Toolbx as a primary interactive CLI environment. Anyway, that's a big 'if'. ] My main concern, which I had brought up in the Release Engineering tickets before [1,2] is whether the fedora-toolbox images would continue to be defined as a Docker/Containerfile. I am asking because the fedora base images are defined as kickstart files [3]. There's some value in continuing to use a Docker/Containerfile because it's widely known and leads to a common workflow. It is used for the official Toolbx images for other distributions like Arch Linux, RHEL and Ubuntu, and a growing list of third-party Toolbx images [4]. A Docker/Containerfile is easy to use with 'podman build' as part of the upstream CI, which makes it easier to test all the different parts. Currently the Fedora and RHEL images that are shipped to users aren't built straight from the upstream Git repository, but from the separate copies on Fedora and Red Hat dist-git. Even then, it's a lot easier to manage two copies of the sources in the same format, as opposed to one using Docker/Containerfiles and the other something else like kickstart files. Cheers, Rishi [1] https://pagure.io/releng/issue/11399#comment-853047 Attached to this Change proposal [2] https://pagure.io/releng/issue/11189#comment-840689 Past discussion that led to this Change [3] https://pagure.io/fedora-kickstarts [4] https://github.com/toolbx-images/images ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned gnome-valgrind-session
Hello everybody, I have orphaned the gnome-valgrind-session [1, 2] package. It's last release was in 2006, and it doesn't know about Wayland sessions. I haven't used it for more than a decade, and don't have any time or motivation to give it the attention that it needs. Feel free to pick it up if you want to. Cheers, Rishi [1] http://hp.cl.no/proj/gnome-valgrind-session/ [2] https://src.fedoraproject.org/rpms/gnome-valgrind-session ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Wed, 2023-05-10 at 21:35 +0200, Clement Verna wrote: > > On Tue, 9 May 2023, 15:42 Debarshi Ray via devel, > wrote: > > > > On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote: > > > > > > If we do this, we should also make the container base images > > > release blocking since AFAIK they are currently not release > > > blocking. > > > > Yes, that's a good point. > > > > The OCI base images aren't currently listed as release-blocking > > deliverables: > > https://docs.fedoraproject.org/en-US/releases/f39/blocking/ > > > > ... but if this Change goes through, then they will implicitly > > become release-blocking deliverables because the fedora-toolbox > > images are based on them. > > > > Should we explicitly mention this in the Change? Or, something > > else? Or, is it fine as it is? > > I think mentioning explicitly in this change is good enough :) > Okay! I add a note to the Detailed Description section of the Change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: disabling yum modular repos by default?
Hey Jens, On Tue, 2023-05-09 at 12:31 +0800, Jens-Ulrik Petersen wrote: > ps I think it would be a good idea to disable the cisco-h264 repo too > by default in the fedora container image, and maybe also for headless > Fedora editions. If we do decide to disable the fedora-cisco-openh264 repository on the base fedora OCI image, then we might have to enable it separately for the fedora-toolbox images, because the OpenH264 codec is something that applications running inside the container might want to use. Coincidentally, changes like these is one of the motivations for: https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker :) Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey Kevin, On Mon, 2023-05-08 at 09:24 -0700, Kevin Fenzi wrote: > I'm broadly in favor here, some comments in line... > > ...snip... > > It will be beneficial to consider the > > [https://src.fedoraproject.org/container/fedora-toolbox > > fedora-toolbox] images as release-blocking deliverables because > > Fedora's [https://opencontainers.org/ OCI] infrastructure is often > > broken. Here are [https://pagure.io/releng/issue/11092 two] > > [https://pagure.io/releng/issue/11367 recent] examples of > > fedpkg > > container-build not working. In the second case, it was > > preventing the images from being rebuilt to pull in an > > [https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important] > > bug-fix. The broken infrastructure prevents regular Fedora > > contributors from jumping in to rebuild and publish the images at > > critical points in the development schedule. Making them > > release-blocking deliverables would attract greater attention and > > scrutiny from release engineering and ensure that a Fedora > > development > > cycle does not proceed with broken or outdated or missing > > fedora-toolbox images. > > I'd like to note that making this blocking doesn't waive any kind of > magic wand that makes our infrastructure more reliable. ;) > The container build pipeline is a long collection of fragile things. > It may well result in us slipping more based on things not working. > ;( Yes, I understand. Currently, what happens is that someone (very often Jens) jumps in to update the fedora-toolbox images from time to time, sometimes because users started to complain about missing images after branching or some other problem, then it turns out that Fedora's OCI infrastructure is broken, then it leads to a pagure.io/releng issue, and then someone (very often you, Kevin) jumps in to frantically debug and get things going again. I was hoping that by making the fedora-toolbox images release-blocking deliverables, we will avoid some of the ad-hoc frantic last-minute fire-fighting and get more eye balls on this part of the Fedora infrastructure. Most importantly, Fedora users would get a more robust and smoother user experience because they won't have to scream and yell on bug trackers to get new images pushed out the door. Also, it's not really possible to test the toolbox(1) binary unless the corresponding fedora-toolbox images are updated and published reliably. In practical terms, if this means that the Toolbx developers need to get involved to help out with Fedora's OCI infrastructure, then so be it. :) Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey Zbigniew, On Mon, 2023-05-08 at 19:57 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > > I'm broadly in favor here, some comments in line... > > > > ...snip... > > > First, we want to ensure that there are up to date > > > [https://src.fedoraproject.org/container/fedora-toolbox > > > fedora-toolbox] OCI images published on > > > [https://registry.fedoraproject.org/ registry.fedoraproject.org] > > > as > > > release-blocking deliverables at critical points in the > > > development > > > schedule, just like the installation ISOs for the Editions from > > > [https://download.fedoraproject.org/pub/fedora/linux/releases/ > > > download.fedoraproject.org]. This must at least happen when an > > > upcoming Fedora release is branched from Rawhide, and for the > > > Beta and > > > Final release candidates. If possible, they should be updated > > > more > > > frequently as part of the nightly composes. We do not expect > > > this to > > > happen after a Fedora release has gone GA. > > I think we need some clarity wrt. to the dependency order here. > Let's say we: > > In order to do this at branch point, we will need to move building > > this > > image into the compose process and mark it blocking. > OK, so we build things, but then we need to publish to registry.fp.o, > which is asynchrounous (?). When we test the newly built ISOs, do > we test them also with the latest image that we get from > registry.fp.o? > And if we find a bug anywhere in this pipeline, we respin everything? That's our expectation, yes. When we apply the test criteria to a compose, if the freshly composed fedora-toolbox OCI images don't meet the test criteria on hosts running the freshly composed Fedora ISOs, then we track down the bugs, get them fixed, re-compose, and try again. Currently, this will happen for the Beta and Final release candidates. Cheers, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
Hey Clement, On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote: > > > On Mon, 8 May 2023 at 22:11, Kevin Fenzi wrote: > > On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski- > > Szmek wrote: > > > > > > I think we need some clarity wrt. to the dependency order here. > > > Let's say we: > > > > In order to do this at branch point, we will need to move > > > > building this > > > > image into the compose process and mark it blocking. > > > OK, so we build things, but then we need to publish to > > > registry.fp.o, > > > which is asynchrounous (?). When we test the newly built ISOs, do > > > > No, it happens at the end of the compose (if no blocking > > deliverables failed causing the compose to fail) > > If we do this, we should also make the container base images release > blocking since AFAIK they are currently not release blocking. Yes, that's a good point. The OCI base images aren't currently listed as release-blocking deliverables: https://docs.fedoraproject.org/en-US/releases/f39/blocking/ ... but if this Change goes through, then they will implicitly become release-blocking deliverables because the fedora-toolbox images are based on them. Should we explicitly mention this in the Change? Or, something else? Or, is it fine as it is? Thanks, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned GNOME Online Accounts and some related packages
Hello everybody, Due to lack of time and interest, I have orphaned these packages: * gfbgraph * gnome-online-accounts * gnome-online-miners * libzapojit Feel free to pick them up. Thanks, Rishi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
