RPMFusion for EL 10 schedule?
What is the current thinking on a schedule for RPMFusion to create the initial infrastructure for the EL 10 distribution? Fedora has opened EPEL10 koji targets, and there has been some activity getting packages built in EPEL10. From my observation here are still a lot of packages that need to be built for EPEL10 to make it a viable base for some packages in RPMFusion (I have opened Bugzillas for some packages I will be needing) but it might be nice for the RPMFusion packagers to be able to test, request additional EPEL10 branches and builds, and build their RPMFusion packages before C10S is expected to be available (2024Q4?). Thanks for any insight you can offer. Gary ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Mass rebuild results for F41
On Wed, Aug 7, 2024 at 4:17 PM Sérgio Basto via rpmfusion-developers wrote: > > Hi, > > Mass rebuild for F39 is finished . > Thanks for doing the work, and taking the additional step above and beyond the rebuilds themselves to fix all the %patch cases yourself, rather than asking the packagers to do so. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Koji scratch build
On Wed, Mar 1, 2023 at 11:29 AM Vascom via rpmfusion-developers wrote: > > How to make scratch build? > > I have an error: > $ koji-rpmfusion build rawhide-nonfree megasync-4.8.8.0-1.fc39.src.rpm > --scratch > Uploading srpm: megasync-4.8.8.0-1.fc39.src.rpm > [] 100% 00:00:05 20.84 MiB 3.91 MiB/sec > 2023-03-01 14:25:31,801 [ERROR] koji: GenericError: invalid channel policy According to a thread on this email list from around a month ago on the topic of scratch builds, it was stated that scratch builds are disabled on rpmfusion koji. Sometimes (but not always) a local mockbuild can perform an adequate test build ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: xmltv in Fedora? (was: [xmltv] Update to xmltv 1.2.0 release)
On Tue, Feb 21, 2023 at 9:04 PM Dominik 'Rathann' Mierzejewski wrote: > > Is the original reason for this package being in RPM Fusion instead of > Fedora even valid? https://bugzilla.rpmfusion.org/show_bug.cgi?id=34#c0 > said: > > This package cannot be allowed in Fedora since it retrieve information > from websites and thus could possibly violate EULA. > > I'm not entirely sure what the above means EULA = End User License Agreement. As you may be aware, some of the grabbers depended on screen scraping that may (and did?) intentionally ignored the EULA of the site(s) in question in regards to (not) screen scraping, or scraped content that had other IP associated with it (some/all of the descriptions were asserted to be copyrighted in some jurisdictions), and some sites have explicit statements that the content may not be used outside of the site itself for other purposes. I also believe one/more grabbers used sources that stated it was only for use by people using a certain service or living in a certain area. At least one grabber appeared to work to bypass the requirement that use was strictly authorized/limited to subscribers of the underlying service. These latter issues would be "fields of use" restrictions that Fedora legal has mostly strictly prohibited. I don't know if any of those are still true for any/all the grabbers in question, nor if any of the current EULA restrictions or copyright claims or fields of use restrictions are valid in any/all jurisdictions, but someone would have to do that research, grabber by grabber, as any grabber that violates the various EULA/T&Cs may not have any possible "non-infringing" use, which is how youtube-dl attempts to thread the legal needle. > and I can't find anything > that would forbid packaging website grabbers at > https://fedoraproject.org/wiki/Forbidden_items or > https://docs.fedoraproject.org/en-US/legal/ . > > I'd say youtube-dl or yt-dlp set a precedent here and xmltv could be > moved to Fedora proper. A subset of the grabbers could, as they clearly use non-infringing APIs from paid guide service providers. However, having only a subset of grabbers in Fedora would likely mean yet another set of fedora/rpmfusion base and freeworld rpms, which is not really something I would like to see proliferate without good cause, and in this case, I am not sure it is useful to exclude some/many/most of the grabbers just to get a subset into Fedora if the legal issues would preclude allowing all of the existing grabbers. > What do you think? If you want to take the issue to Fedora Legal to evaluate the compliance of each and every grabber with Fedora compliance you are free to do so. I have no interest in going down that particular path, since I strongly suspect that not all existing grabbers are "legal" in all jurisdictions, and I really really do not want a base/freeworld bifurcation that are due to the legal requirements in the most litigious country in the world. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
rfpkg mock buildroot init error
I am going to presume that the error during the mock buildroot init: Error: Error downloading packages: Status code: 404 for http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/c/curl-7.88.0-2.fc39.x86_64.rpm (IP: 192.168.182.1) while trying to do a rfpkg build on rawhide is not something I am responsible for, and will just need to wait a bit while the various infrastructure buildroot caches get updates. Koji task reference: https://koji.rpmfusion.org/koji/taskinfo?taskID=584798 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
On Sun, Feb 19, 2023 at 11:05 PM Leigh Scott via rpmfusion-developers wrote: > > I don't think a +2 release upgrade is a valid test case, I believe f37 > is SHA256 signed. > Fedora officially supports a +2 release upgrade, and for reasons[0][1], some people only upgrade to N when N-2 is about to go off support, since there is a one month overlap, so some people will want to upgrade from F36 to F38 (more than 2, it is recommended to go in smaller steps). [0] I am guessing they want something approaching stability without being willing to go to the centos level of stability. [1] I might be the exception, but I tend to upgrade a few of my systems to N-next as soon as the beta is released, and the rest of my systems at about the time of the final N compose packages make it to the mirrors, so I don't need to worry about +2 upgrades, only +1 upgrades. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
