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 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
Re: [Bug 6426] Review request: mesa-freeworld - Mesa graphics libraries
On Mon, Jan 2, 2023 at 9:55 AM RPM Fusion Bugzilla
wrote:
>
> Comment # 91 on bug 6426 from Thorsten Leemhuis
>
> (In reply to Luya Tshimbalanga from comment #90)
> > I updated the spec file adding conflicts condition
>
> Thx for this. I noticed you increased %release when you did so, which is thus
> now out of sync with Fedora. Wont this blow up, as mesa-freeworld.spec has…
>
> Provides: %{srcname}-va-drivers%{?_isa} =
> %{?epoch:%{epoch}:}%{version}-%{release}
>
> …while mesa.spec has this?
>
> Recommends: %{name}-va-drivers%{?_isa} =
> %{?epoch:%{epoch}:}%{version}-%{release}
>
> Would it maybe be better if fedora dropped the "-%{release}" part? Or am I
> missing something (does dnf handle this?)
I suspect in this case the most viable (although
very ugly) solution is for the freeworld packager(s)
to request the rpmfusion admins untag the
22.3.2-1 and 22.3.2-2 freeworld builds (since
they should still be in candidate mode), and do
an ugly (usually strongly not recommended)
commit to revert the release number to -1
(while leaving the Conflicts in place), and
then build again (with appropriate approvals,
of course; I am not sure who would have to
approve such an ugly approach).
And this is yet another example that trying
to partially replace fedora packages with
rpmfusion is problematic. Perhaps just
better to require that the entire mesa stack
is swap(ed).
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: About el9 and el9-next
On Tue, Sep 6, 2022 at 7:24 PM Nicolas Chauvet wrote:
> Hope this helps.
With almost any good, comes some bad ("Well, that's
interesting!"). Thanks for the work to make this a reality.
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Mythtv and mythweb el9 branch request
On Tue, Jul 26, 2022 at 3:27 PM Andrew Bauer wrote: > > Thanks for the heads up, Gary. > > According to that bug report, there is movement to retire python-mysql and > use python-mysqlclient instead. The latter has already been built for el9. I > am currently out of town for work and will look into how this affects mythtv > when I return. > The package naming in fedora for the various python mysql clients is somewhat different than some other distros (and upstream), so I have lost track of which library supports what functionality, but I seem to recall that the python-mysql package has an upstream of mysqlclient-python, while the python-mysqlclient package has an upstream of mysqlclient. Similar but different. In order to try to get out of mysql/mariadb confusions there was an (abortive) attempt to move to the pure python mysql client a number of years ago now for MythTV, but at the time the MythTV python bindings used/depended on some less common feature that did not work with the different implementation for some specific thing, and there was some effort put in by a few devs to create a test harness to identify the functionality that was different and therefore broken during runtime with different implementations. You may wish to work with the project devs to get that test harness to validate changes to the support library used to avoid runtime issues (or work to replace the specific thing that MythTV was using; or just volunteer to build python-mysql in epel9). Good luck. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Mythtv and mythweb el9 branch request
On Tue, Jul 26, 2022 at 2:52 PM Andrew Bauer wrote: > > Would one of the admins please approve the el9 branch requests I submitted > last week through pkdb, for mythtv and mythweb packages. Thank you. > Be aware that one of the el9 dependencies for mythtv's python bindings (python-mysql) is still not built for epel9 (or at least the ticket is still open): https://bugzilla.redhat.com/show_bug.cgi?id=2033144 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [chromium-freeworld] Exclude aarch64
On Wed, May 25, 2022 at 7:54 PM Dominik 'Rathann' Mierzejewski wrote: > I assume this is due to > https://koji.rpmfusion.org/koji/taskinfo?taskID=544892 failure, but why > did it fail? I don't see any errors in the build.log. It just stops in > the middle of the build. My guess (and it is just a guess) would be the oom killer. Chromium has a (very) long history of needing a lot of memory to compile which (on various shared builders) can get killed (with the logs just ending). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion el8 buildroot broken?
On Tue, Feb 1, 2022 at 5:21 PM Xavier Bachelot wrote: > There are missing dependencies for a lot of RPM Fusion packages in EPEL > 9, but I've been filling a lot of bugs for dependencies of the high > profile packages or packages I care about, and even if there's quite a > lot of work remaining, this is not that bad currently. Thanks for the opening of the dependency bugs. I have also been filing bugs (in a number of cases others got there first with the request, but in a few I got there first) and I concur that things are getting better. There is likely to be a long tail for some packages for the reasons you mention. The copr I have been using for building the missing EPEL9 packages for the builds I care about is now down to a half dozen packages, where it started closer to two dozen (some were build dependencies for the others, of course, but they all count(ed) in my mind). Progress! > ... or even worst > when hitting a missing -devel package from Stream. That is one of the painful issues (it is not new, el8 had similar issues, but before the centos 8 vaulting at least the -devel packages were mostly available in the [devel] repo). I, too, have had to open a bug on a missing -devel package and we shall see where it goes. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion el8 buildroot broken?
On Tue, Feb 1, 2022 at 3:15 PM Andrew Bauer wrote: > hi Gary, > I think Nicolas is referring to fixing the perl-XML-TreeBuilder runtime > requirement for mythtv. Until recently, it was missing from el8. > > I am not sure if this is needed for xmltv or not. Haven't looked. Not in any direct usage (there may be some transitive usage deep in the perl Use/Requires chain, but the package build itself tries to make sure those dependencies will resolve). The only xmltv grabber that is not built for Fedora is the one that depends on a perl module that no one has ever packaged for Fedora (and since I have no way to even test that module (perl-Linux-DVB-DVBT) I am unlikely to take it on. And, in addition, the PVR package I use already supports EPG collection via direct tuner acquisition, so I am less motivated). If someone else wants to package (and presumably test) that perl module for Fedora (and the EL's), I will gladly add a BR. And even more OT FWIW for EL9 (the future) there are some missing dependencies for both xmltv and mythtv in EPEL9. I believe there are open bugzillas with requests for branching for most/all of the known missing packages. But all that is for the future. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion el8 buildroot broken?
On Tue, Feb 1, 2022 at 3:52 PM Kevin Kofler via rpmfusion-developers wrote: > > Nicolas Chauvet wrote: > > CentOS has moved the content to vault, so I've found a more suitable > > mirror until we migrate to rhel/Stream kind of repos. > > Why not use Alma or Rocky? I will note that while I have not tested in the past few months, I have experienced certain artifacts(*) when trying to use mock builds with Alma (their use of modularity breaks some existing dependency resolution for existing package builds) and Rocky (when using gcc-toolset-10 the annobin invocation results in numerous build errors for a package I have). Both may be partially a packaging (spec file) issue, but neither problem exists with centos stream 8, so there are some differences in the distribution layouts/builds between the various clones. As always, those issues may be able to be worked around, but in my experience those clones are not always just a drop-in replacement, so some testing (probably a mass rebuild) would need to be performed just to be sure. Ultimately, the centos 8 support pivot in the middle of the lifecycle of el8 has just made things far more complicated than I believe most (and certainly I) wanted, and the resulting additional workloads that has imposed on Nicolas and colleagues are certainly an unexpected (and likely un-resourced) support burden. (*) When I have some free time to look at the root causes, and they are indeed bugs in the distros (rather than my own packaging issue) I'll open bugs in their trackers, but since centos stream 8 works, I have not been especially motivated to this point. And then there is the ability to get a (free) redhat subscription for at least some use cases (although I have no idea whether that free subscription can be used for the rpmfusion koji builders). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion el8 buildroot broken?
On Tue, Feb 1, 2022 at 3:52 PM Kevin Kofler via rpmfusion-developers wrote: > > Nicolas Chauvet wrote: > > CentOS has moved the content to vault, so I've found a more suitable > > mirror until we migrate to rhel/Stream kind of repos. > > Why not use Alma or Rocky? I will note that while I have not tested in the past few months, I have experienced certain artifacts(*) when trying to use mock builds with Alma (their use of modularity breaks some existing dependency resolution for existing package builds) and Rocky (when using gcc-toolset-10 the annobin invocation results in numerous build errors for a package I have). Both may be partially a packaging (spec file) issue, but neither problem exists with centos stream 8, so there are some differences in the distribution layouts/builds between the various clones. As always, those issues may be able to be worked around, but in my experience those clones are not always just a drop-in replacement, so some testing (probably a mass rebuild) would need to be performed just to be sure. Ultimately, the centos 8 support pivot in the middle of the lifecycle of el8 has just made things far more complicated than I believe most (and certainly I) wanted, and the resulting additional workloads that has imposed on Nicolas and colleagues are certainly an unexpected (and likely un-resourced) support burden. (*) When I have some free time to look at the root causes, and they are indeed bugs in the distros (rather than my own packaging issue) I'll open bugs in their trackers, but since centos stream 8 works, I have not been especially motivated to this point. And then there is the ability to get a (free) redhat subscription for at least some use cases (although I have no idea whether that free subscription can be used for the rpmfusion koji builders). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion el8 buildroot broken?
On Tue, Feb 1, 2022 at 7:52 AM Nicolas Chauvet wrote: > CentOS has moved the content to vault, so I've found a more suitable > mirror until we migrate to rhel/Stream kind of repos. > I hope to work on this with el9, then adapt el8 as appropriate on a next > step... Ok, thanks. I'll wait for an announcement. > Btw, xmltv still has few missing perl deps, I know some improvements > was made recently for mythtv, is there any chance to have them in ? The spec file has (almost always?) been taking advantage of rpms perl dependency generator, but we all know such dependency generators can occasionally miss things. I'll take a look as time permits. Although, perhaps, I am misunderstanding the question, since you mention a mythtv improvement. Is there some reference? ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
RPMFusion el8 buildroot broken?
I am getting an error from koji when trying to build for el8: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information The mock_output.log shows: Error: Error downloading packages: Status code: 404 for http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/bash-4.4.20-2.el8.x86_64.rpm (IP: 192.168.182.1) Relevant task example: https://koji.rpmfusion.org/koji/taskinfo?taskID=522207 I am presuming that this is an infrastructure issue somewhere, and all I can do is wait for the project system admins to resolve this issue. If there is something I can do, please let me know. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RHEL 9 beta
On Sat, Dec 25, 2021 at 6:17 PM Sérgio Basto wrote: > > On Fri, 2021-12-24 at 23:20 +, admin.tsurobilt wrote: > > > Are there plans to release configurations for RHEL 9 beta on rpmfusion? > > > yes of course , work still in progress I always presumed as such, and understood that there are many pieces that need to be accomplished. Thanks for your efforts! FWIW, I have been (slowly) opening Fedora EPEL9 branch and build requests for the packages of interest to me in RPMFusion that have (what will be) EPEL9 packages as build requirements, to try to minimize the future delays (the slowly part is to sometimes also run down the BR dependency chains so that others can start their works in parallel). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Push new unifi to stable for log4j CVE?
On Wed, Dec 15, 2021 at 4:50 PM Gary Buhrmaster wrote: > Apache talks about non-default configurations > as being required to be able to . It is not clear > if the unifi network app is vulnerable. There > is not yet a response by the ubnt team. Never mind, 6.5.55 is now out in the RC channel to address this. More work for Richard (sorry). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Push new unifi to stable for log4j CVE?
On Wed, Dec 15, 2021 at 3:56 PM Vitaly Zaitsev via rpmfusion-developers wrote: > Btw, there is another CVE in log4j: > https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html Apache talks about non-default configurations as being required to be able to . It is not clear if the unifi network app is vulnerable. There is not yet a response by the ubnt team. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: can we clarify where are the irc channels
On Sun, Jul 11, 2021 at 6:04 PM Sérgio Basto wrote: > and send a email announcement that > rpmfusion moved to https://libera.chat/ The rpmfusion web pages were updated to mention libera.chat, I guess the person who did that did not send out a formal email at the same time (or at least I do not recall it, but I do admit I just presumed when Fedora moved, rpmfusion would likely move too after the initial settling period). I will note that you did say (back on May 20th): On Thu, May 20, 2021 at 10:32 AM Sérgio Basto wrote: > I think we should move although for other reasons (matrix, etc.). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31 Don't require lame binary on el8
On Tue, Jun 29, 2021 at 4:19 PM Nicolas Chauvet wrote: > > Le mar. 29 juin 2021 à 18:06, Sérgio Basto a écrit : > > Only epel 8 is missing but we could ask for it . > No we can't (at least not easily). Well, technically, the asking is easy :-) > As the lame package is in RHEL but > only the libs- and (devel) are distributed. > So we can't have it in EPEL easily. But as you say, actually getting it in is not easy (the same thing has happened with some other packages where RH distributed only part of the package with EL8). > Also having a lame binary is totally spurious. Which is why I would think that the entire Requires: lame should be entirely removed. While I have no doubt someone has written some external script that uses the lame binary, that does not make it a responsibility of the package to install it (and if it is already installed, it will (probably) get updated by the user during the normal course of events). If someone really believes it should remain in the spec, at least downgrade it to a Suggests (or Recommends) for EL8(+) and Fedora. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: NVIDIA 470 Series To Be The Last Supporting GTX 600/700 Series Kepler.
On Sat, May 22, 2021 at 9:02 AM Kevin Kofler via rpmfusion-developers wrote: > > Those cards are well-supported by the Nouveau driver by now, aren't they? > Perhaps the largest shortcoming is that there is no automated voltage and re-clocking (for the core and/or memory) support based on GPU requirements and thermal headroom (the GPU and memory start at lower power base clock speeds). Manual adjustments are reasonably well supported via debugfs, but it is still a manual process at this point and last I looked is still marked as "incomplete" and "experimental" by the developers (and apparently certain combinations of settings can result in GPU hangs/corruption or even overheating damage). There has been repeated talk about someone (i.e. the random someone else who does not actually exist) writing some sort of GPU governor, but it has never happened. That certainly makes the experience of using those cards far less than optimal for some, driving those to the proprietary driver (they want something that just work). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: NVIDIA 470 Series To Be The Last Supporting GTX 600/700 Series Kepler.
On Sat, May 22, 2021 at 9:02 AM Kevin Kofler via rpmfusion-developers wrote: > > Those cards are well-supported by the Nouveau driver by now, aren't they? > Perhaps the largest shortcoming is that there is no automated voltage and re-clocking (for the core and/or memory) support based on GPU requirements and thermal headroom (the GPU and memory start at lower power base clock speeds). Manual adjustments are reasonably well supported via debugfs, but it is still a manual process at this point and last I looked is still marked as "incomplete" and "experimental" by the developers (and apparently certain combinations of settings can result in GPU hangs/corruption or even overheating damage). There has been repeated talk about someone (i.e. the random someone else who does not actually exist) writing some sort of GPU governor, but it has never happened. That certainly makes the experience of using those cards far less than optimal for some, driving those to the proprietary driver (they want something that just work). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: IRC channel
On Thu, May 20, 2021 at 12:21 PM Tomasz Torcz wrote: > If we decide to move out of freenode, we should decide if sticking > with IRC is worth. Nothing beats irssi, but nowadays I would prefer > new channels to be created on Matrix network. There will always be those who prefer IRC (for one reason or another). Obligatory xkcd: https://xkcd.com/1782/ Matrix does allow an irc bridge (although the non-paid version is apparently not especially performant for a large number of users or conversations, along with a bridge not being able to properly represent the rich communications functionality of a modern app) for those that feel irc is the way they wish to continue to communicate. There is the argument that while irc has served the foss community well, it no longer is especially inviting to new users and groups, and something better is the way forward. Obviously Fedora is moving towards matrix (with their own homeserver to provide FAS identity management linkage) which would seem to be the path rpmfusion would logically follow. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
On Mon, Mar 1, 2021 at 2:05 AM Sérgio Basto wrote: > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches Thank you for confirming that the current practice (patches in dist-git) is an approved one (in fact even the default one), and while one MAY choose to do things differently to deal with others poor MUA or editor choices, or the emails that certain processes create, it is not a requirement, nor should it become one(*). (*) Until/unless there is a consensus of a change in guidelines, were perhaps some MAYs could turn into MUSTs, which you have suggested you intend to propose. I look forward to the discussion on the formal proposal. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
On Sun, Feb 28, 2021 at 4:14 AM Sérgio Basto wrote: > Maybe we should change the guidelines. I suspect your formal proposal will generate some interesting discussion. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Update to latest fixes/31.
On Fri, Feb 26, 2021 at 11:49 PM Sérgio Basto wrote: > IMHO, Please use `rfpkg new-sources v31.0..b6ddf202a4.patch` to avoid > at least send 28K bytes of text in email I'll point out that having the patch files included this way (and in the emails) has been standard procedure for quite some time for at least this package. I do wonder, however, that given that for this package one is simply using the upstream repo at a more recent commit that one should not at least consider pulling the git archive at that newer commit and new-sources(ing) that new tarball and eliminating some part of the existing workload (replacing it with different packaging workload of course). Last I read the packaging guidelines (admittedly a long time ago) nuanced cases such as this did not seem to be clearly spelled out as to the right or wrong approaches (and I would expect that some packager discretion should be continued). > btw sometimes it breaks my gnome evolution I would hope you have opened bugs upstream with the evolution folk, as I would hate to think future packaging approaches/guidelines are based on what does not break specific MUAs. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Fix for rfbz #5843
On Mon, Dec 7, 2020 at 4:12 PM Mohamed El Morabity wrote: > > > -Requires: mariadb > > +Requires: mariadb-server > > MythTV can use a remote DB server. I really don't think a hard > dependency on the MariaDB server is justified or necessary here. It possibly should be a Recommends (or even a Suggests?), as while it is possible to use a remote DB, admittedly the common use case is a local DB server, but certainly those that do not want a local DB server should not be forced to have it installed. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Moving fdk-aac to -free?
On Wed, Sep 30, 2020 at 9:35 AM Leigh Scott wrote: > > The fedora fdk free package isn't equal to the rpmfusion package. > > They use a different source code which has the patented code removed. > It was my interpretation that the request (from rpmfusion-nonfree to rpmfusion-free) had to do with the source license (and did not address the entire IP minefield regarding usage that many codecs live in). So the library with full capabilities would presumably have to stay in rpmfusion (at least until the remaining patents expire, which I last saw estimated to be around 2025/6), and the question on the table is the group (nonfree vs free). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Moving fdk-aac to -free?
On Wed, Sep 30, 2020 at 7:03 AM Nicolas Chauvet wrote: > Also can you clarify why you need this over using the internal ffmpeg > AAC codec ? The Fraunhofer AAC library supports capabilities that FFmpeg itself (if not compiled with the fdk library) does (did?) not support, such as HEv1/2. And, of course, it is a different library API from FFmpeg itself. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Please tests your packages in rawhide
On Wed, Aug 5, 2020 at 4:20 AM FeRD wrote: > I haven't merged my changes back beyond master yet, but the impression I got > was, at least once F33 is released, I could. No? Your interpretation is the same as mine. Changes to support compatibility were stated to be intended to be backported (at some point) to f32/f31 (although I suppose f31 could end up going out of scope before the backport depending on the exact date things get accomplished). Given the number of FTBFS issues that the change owners are working on to clean up f33, I suspect the schedule may end up getting shuffled a bit now that the change owners better understand the scope. The current state (f33/rawhide/master being different than the others) is unfortunate for those (including myself) whose practice is to generally just merge master into the previous branches (because it mostly worked). Cherry picking specific commits is not all that hard in the abstract, but can rapidly lose its appeal in the real world. > ... I guess maybe not el8, reading that again, but F32/F31 at least. In another thread the change owner said there were, indeed, updates for el8, and I believe el7, primarily due to the number of requests (by people like you) but the Fedora change owner were waiting on the owner of the package in el8 that owns the macros.cmake file to concur and accept the changes (in el7, the macros are in epel, but in el8 the macros are part of the rh appstream repo (which obviously has various rh enterprise stability requirements). I don't think any specific timeframe has been offered for when the el updates might land. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Please tests your packages in rawhide
On Tue, Aug 4, 2020 at 12:53 AM Leigh Scott wrote: > > I decided to disable LTO for x86 ffmpeg > In the past I have managed to get FFmpeg to compile with LTO even when embedded in another app, but it required some somewhat fragile hoop jumping, and is likely a bridge too far for this release cycle in many cases. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 19 Rawhide build
On Wed, Jul 8, 2020 at 3:36 PM Michael Cronenworth wrote: > The 32-bit ARM build couldn't link. "Out of memory" would suggest that this is a build infrastructure issue (whether the VM memory allocation needs to be bigger or more disk swap needs to be assigned are all various trade-offs for builders, and none are ever perfect). The reality is large(r) projects often need more memory to build (I have experienced some larger projects fail to build on 32-bit ARM due to lack of memory), and when something like LTO becomes the new normal the memory requirements are likely to go up even further for a large project. > Do we want to drop 32-bit ARM starting with Kodi 19? While I don't use Kodi, I suspect that 32-bit ARM is going to be a popular platform. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: mythtv for el8 - gonna happen??
On Fri, Jun 5, 2020 at 11:07 PM Andrew Bauer wrote: > > I am planning to overhaul my htpc box and am curious if a mythtv 31 build on > el8 is near. > Richard's specific dependencies are a problem for providing the exact same functionality in el8 as the existing fedora and el7 builds. That said, I do know that outside of rpmfusion itself, MythTV builds on el8 fairly easily(*), but to do so with full functionality requires a couple of external epel8 copr repos of packages in fedora that I build for my own use because the upstream packagers have chosen not to build epel8 versions to this point (note that external copr repos are not useful to building packages for rpmfusion, but work fine for private builds). FD: While I build MythTV regularly for el8, I run on Fedora (latest) as that is the place to be for my use cases. Gary (*) I build MythTV regularly on el8 for testing purposes with my own personal rpm packaging (not rpmfusion). And the MythTV projects CI farm builds el8 (along with many other distros) at every commit. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
rpmfusion repo not available?
I am getting responses from the metalink that include the following line: # Bad Request [Errno 28] No space left on device The target IP for the request was both 158.69.195.211 and 2607:5300:201:3000::278c ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [unifi] Change requirement from policycoreutils-python to policycoreutils-python-utils so Python 3 is used
On Fri, Oct 4, 2019 at 11:49 PM Kevin Kofler wrote: > I think mongodb should be packageable in RPM Fusion nonfree. Not taking sides, but Björn 'besser82' Esser said that it (probably cannot be packaged in RPMFusion for the unifi controller in a previous discussion. https://lists.rpmfusion.org/archives/list/rpmfusion-developers@lists.rpmfusion.org/message/BPKDVFJENHUFC4RQMRNZVN6U4AFEXXAU/ ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [unifi] Change requirement from policycoreutils-python to policycoreutils-python-utils so Python 3 is used
Some background FD: I have no specific standing, as I don't use the package, and am unlikely to ever do so, so whatever happens is unlikely to matter to me. On Thu, Oct 3, 2019 at 1:10 PM Nicolas Chauvet wrote: > > Hi there, > > > Requires: /usr/bin/mongod > > Requires: java-1.8.0-openjdk-headless > > Can you also fix theses requirements? mongod isn't in the default > repositories so you cannot break dependencies that way (and make > repoclosure to complain) IRT mongod, see the discussion in https://bugzilla.rpmfusion.org/show_bug.cgi?id=5252 which would appear to leave Richard between a rock and a hard place as mongoDB is no longer packageable by Fedora/EL due to the license changes. Not including a Requires: that forces one to install the mongoDB upstream package will result in a RPMFusion package that is no longer complete (and usable) either causing different confusion (bugzilla's about "it does not start!" seem likely). I would guess if a Requires is not allowed it would be better to not include unifi at all to minimize the confusion? > Another point is that It seems unlikely that one is enforced to have > the unifi service and mongod on the same server, so enforcing the > dependency looks incorrect to me. Only somewhat recently has it been possible to use a remote mongoDB instance, but it requires using some configurations that are (for all practical purposes) undocumented (only if you know mongoDB you know what to change in a specific config file inside the application properties files, which is, to say the least, somewhat user unfriendly). Are you aware of any other RPMFusion package using mongoDB, and what they have done/are doing now that mongo is no longer in Fedora/EL? FWIW, there have been requests to Ubiquiti to replace the mongoDB dependency by numerous others due to the monogoDB licensing changes which has had much fallout, and Ubiquiti has hinted they are looking at doing so(*), but have not (yet) released anything. Ubiquiti seems to have mostly focused on their newer management framework which (unfortunately) does not yet replace the unifi controller functionality. (*) Even for their embedded products, they have an issue as the mongoDB version they have embedded ended support in September. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Dropping i686 userspace by default for f31+
On Mon, Sep 2, 2019 at 11:59 AM Nicolas Chauvet wrote: > Any feedback ? Short answer: Thanks for letting us know the plans. They work for me. Much longer answer: i686 is dead, long live i686. The writing was on the wall for some time regarding i686, and with Fedora finally dropping the i686 repo (and dealing with the limited multilib needs using a koji buildroot), I was actually wondering when RPMFusion would announce the equivalent thing for F31. I happen to currently provide a 32-bit Fedora builder for a OSS project that uses some bits from RPMFusion, but I was paying a bit of attention, and warned them in late June (maybe early July?) that if FESCo approved the changes that that builder would be shutdown sometime in 2020 when F30 finally goes final EOL. They were OK with that (not that they really had a lot of choice). Thanks for letting us know the plans. They work for me. Off topic: I do wonder a bit as to what will be the reaction of those using Fedora as their daily driver, but otherwise do not closely follow the development process, when they find out they can't upgrade to F31 on their trust old 32-bit only device (FD: I still have a 32-bit only laptop sitting on a shelf, but I have not actually turned it on for a while now). Probably about the same as when Ubuntu users try to upgrade to 19.10 (and beyond) in the same situation. Or for that matter those intending to upgrade to macOS catalina which is also putting the final nail in 32-bit apps (which will, of course, also impact steam and wine on that platform). 5 stages of grief? Containerization may only take one so far. 2019 may be remembered as the year that 32-bit died? ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mythtv] Use Python3 on Fedora 31+
On Sun, Aug 11, 2019 at 2:13 PM Nicolas Chauvet wrote: > There is a need to dive into upstream source code, and actually move > the python2->python3 code or ask upstream to do so if one cannot help. I happen to have some familiarity with that project. Some of the python code is version agnostic, but a lot is not, and AFAIK there has been no effort to do a complete inventory of which is which, nor the implications for any particular functionality. The upstream is aware of the python3 schedules, and has (over the past few years) had both requests for, and a few offers to assist in, a conversion, but as of now some things will no longer work without python2 and core libraries. I'll ping the upstream developers again on their plans and schedules. For all I know some core dev has a stash sitting around in their repo with all the necessary updates. FWIW, the historical primary python developer in that project who would have been the natural person to have probably taken on the updates years ago has not been active in the project for some time now, and the other core devs with any admitted python expertice have been focusing their efforts in other areas of the code. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: About the i686 kernel/repository drops for f31
On Sun, Jul 14, 2019 at 3:35 PM Nicolas Chauvet wrote: > Any though ? The x86 32-bit architecture has been a secondary architecture since F26. The writing has been on the wall for all to see (and a lack of volunteers to do the (very very very) hard work of validating/maintaining 32-bit kernels has been a repeated refrain for quite some time not just in the Fedora community). As I understand it, the Fedora i686 repo will likely be removed as of F31 (although technically I did not believe that decision had yet been made) as a follow-on to dropping the building of 32-bit kernels. I would suggest RPMFusion should follow the decision for F31 (there appears to be little benefit to creating a repo that (in practice) depends on a Fedora i686 repo which will (likely) no longer exist). Also (again, as I understand it), a i686 buildroot is intended to continue to be available to build multilib packages for the x86_64 architecture. That should provide the needed 32-bit libraries for *this* stage of x86 32-bit obsolescence, as, AFAIK, Fedora is not yet scheduling a bulk removal of 32-bit libraries (for which Canonical got some push-back when they made such an announcement). Longer term, of course, there will be the continued push to have projects move to native architecture, and wine and steam (and others) that have a need for 32-bit libraries may need to figure out their way forward (perhaps via flatpaks (winepak)?), but that is a discussion for another day (or at least F32?) That all said, since I am not the one doing the hard work of supporting the build infrastructure, I defer to those who do the actual work. I'll work to adapt to what is decided (if I need to change at all). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: arm-builder11.home.rpmfusion.net having problems?
It would seem that arm-builder11.home.rpmfusion.net is having various issues. A couple of abortive builds have recently ended with messages of the form: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1295, in runTask response = (handler.run(),) File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 311, in run return koji.util.call_with_argcheck(self.handler, self.params, self.opts) File "/usr/lib/python2.7/site-packages/koji/util.py", line 263, in call_with_argcheck return func(*args, **kwargs) File "/usr/sbin/kojid", line 963, in handler h = self.readSRPMHeader(srpm) File "/usr/sbin/kojid", line 1048, in readSRPMHeader with koji.openRemoteFile(relpath, **opts) as fo: File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1613, in openRemoteFile src = six.moves.urllib.request.urlopen(url) File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python2.7/urllib2.py", line 429, in open response = self._open(req, data) File "/usr/lib/python2.7/urllib2.py", line 447, in _open '_open', req) File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 1230, in http_open return self.do_open(httplib.HTTPConnection, req) File "/usr/lib/python2.7/urllib2.py", line 1200, in do_open raise URLError(err) URLError: http://koji.rpmfusion.org/koji/taskinfo?taskID=325692 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [xmltv] Fix el6 dependencies by not building tv_grab_zz_sdjson_sqlite on el6
On Fri, May 24, 2019 at 4:06 AM Sérgio Basto wrote: > > On Mon, 2019-05-13 at 23:34 +, Gary Buhrmaster wrote: > > Thanks! As soon as it hits, I'll update the xmltv package > > to build the grabber in el7. > > > I Just receive [1] tomorrow should be available on RPMFusion repos . Thanks, I saw that (I presume you mean the EPEL repos), and have an update ready for rpmfusion xmltv (but since it had not yet made its way to all the mirrors (I got a 50/50 split at my initial test build), I figured waiting a day was a good plan). ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Fwd: [Fedora-legal-list] MPEG-1 and MPEG-2 Video
On Sat, Apr 13, 2019 at 2:03 PM Xavier Bachelot wrote: A couple of observation regarding lack of viability for some packages being moved to Fedora (I have not actually looked at the code bases to know if there are any more subtle issues involved). > Here's an hopefully more accurate list: > dvbcut: Clip and convert DVB transport streams to MPEG2 program streams requires ffmpeg > libfame: Fast Assembly MPEG Encoding library Claims to also do MPEG4 > mjpegtools: Tools to manipulate MPEG data requires ffmpeg ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
