Review swaps: clojure-spec-alpha and clojure-core-specs-alpha
Hi, anyone up for review swaps? I'm updating clojure and it requires two new dependencies, here are the review requests: https://bugzilla.redhat.com/show_bug.cgi?id=1821025 https://bugzilla.redhat.com/show_bug.cgi?id=1821026 Best wishes, Markku ___ 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
[389-devel] Please review; 51008 dbhome in containers
https://pagure.io/389-ds-base/pull-request/51010 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-04-06 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/04/06/report-389-ds-base-1.4.3.5-20200405git52e2894.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: v4l2loopback kernel module in Fedora?
On Sun, Apr 5, 2020 at 4:45 PM Iñaki Ucar wrote: > > On Sun, 5 Apr 2020 at 22:23, Christopher wrote: > > > > On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar wrote: > > > > > > On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > > > > > > > Aren't external kernel modules banned by fedora packaging rules? > > > > > > Yes, they are: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules > > > > > > > According to those guidelines, they can't be packaged outside the main > > kernel package. But, they can still be included in the main kernel > > packaging. So, I guess I'm trying to reach out to whoever's involved > > in packaging that. > > You can try contacting the Kernel Team, but the upstream maintainer > doesn't seem to be actively pushing for merging this into Linus' tree, > so it's hard to make a case for it in its current status [1]. RPM > Fusion and Copr are better targets for this. > > [1] https://fedoraproject.org/wiki/KernelDriverPolicy The previous packaging was on COPR, but it appears abandoned, probably because it's kind of worthless if it's not signed. And, it's a lot of manual work to self-sign and register the key with mokutil, and even more effort to figure out how to get DKMS to automatically sign after building, on kernel updates. I don't know enough about RPMFusion packaging. I use RPMFusion, but haven't looked into the contribution process. In particular, I wonder if their modules are signed by a key that's already trusted in Fedora. My guess is not, and then it's the same problem as with COPR. I'm probably going to abandon the effort anyway. obs-studio in Fedora crashes constantly every time I try to change the settings and save, so I couldn't figure out how to get it to work with v4l2loopback. I also couldn't figure out how to get Slack or Chrome (Hangouts) to even recognize the second v4l device. Only cheese saw the new video device at all, but it couldn't display it, for some unknown reason. Thanks for the advice, but I think I've reached the end of what I can figure out or champion on my own. ___ 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
Re: bodhi: Failed to talk to Greenwave.
On Sat, Apr 04, 2020 at 12:55:40PM +0200, Marius Schwarz wrote: > > Hi, > > ATM the Tab "Automated Test Results" shows just is message: > > Failed to talk to Greenwave. There was a greenwave outage around the time you posted this. It should have long since cleared up, but if you are still seeing it, please do file a ticket on it and we can investigate. kevin signature.asc Description: PGP signature ___ 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
[EPEL-devel] Re: Extras not enabled on koji?
On Sun, Apr 05, 2020 at 03:37:29PM -0500, Richard Shaw wrote: > On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen > wrote: > > > OK so swig3 seems to just be in CentOS extras and not in RHEL extras. > > > > Is this the way it should be? All the EPEL test instances are CentOS, > right? If I run mock it uses CentOS extra. So why would the official > builders be different? EPEL has always built against RHEL. Unfortunately we can't simply provide RHEL free to everyone that wants to test against it, but you can get a free developer subscription and use that. > This doesn't make for a good packager experience :) Well, not sure how to make it better. We could move to building against CentOS, but that would be a big undertaking and some folks would like that and some would not. We could perhaps advertise the developer rhel subscription more for testing? Open to other ideas... kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Putting qt5 srpm macro into epel-rpm-macros
On Fri, Apr 03, 2020 at 09:59:24AM -0700, Troy Dawson wrote:
> RHEL 8.2 will have a newer qt5 (qt5-5.12.5).
> They have also cleaned up their qt5-srpm-macros, to remove a macro for
> a package they do not support, nor plan on supporting. I have
> verified this was their intention and they do not plan on putting it
> back.
>
> %qt5_qtwebengine_arches %{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el
>
> The problem is that this is in all the KDE spec files for EPEL8 that
> depend on qtwebengine. It's essentially telling them to not build on
> s390x.
>
> I've look at all the alternatives, and putting that macro into
> epel-rpm-macros solves the problem.
> I have verified that rpmfusion doesn't build on s390x, so they will
> not be affected by this problem.
>
> I'll be putting that in today, and letting it sit testing for the
> usual time. If anyone has any problems, please let me know before the
> two weeks are up.
Seems fine to do to me...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Fedora-IoT-32-20200405.0 compose check report
No missing expected images. Failed openQA tests: 2/8 (x86_64) New failures (same test not failed in Fedora-IoT-32-20200404.0): ID: 567430 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/567430 Old failures (same test failed in Fedora-IoT-32-20200404.0): ID: 567434 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/567434 Passed openQA tests: 6/8 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
- Original Message -
> From: "Stephen Gallagher"
> To: devel-annou...@lists.fedoraproject.org, "Development discussions related
> to Fedora"
>
> Sent: Tuesday, March 31, 2020 5:31:38 PM
> Subject: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
>
> I sent out the V2 version of the Change on Friday and then promptly
> managed to injure myself and be away from email until today. I've read
> through the email threads again this morning and I decided that,
> rather than try to address them one by one, I'd try again with a V3
> that hopefully answers some of the repeated questions and concerns on
> that list.
>
> Please see the newly-updated
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> for more details[1].
>
>
> [1]
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569904=569809
> ___
> 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
>
Ok I took the time to read all the previous threads and the proposal as well as
the clarifications.
In general I am in favor of the idea, however I concur with my fellow
packagers, that the current proposal is having some serious issues, and I'm
very reluctant in agreeing with the given rationale of various details.
I also feel that I am iterating a lot of the feedback that was given already
however I believe it was neither heard nor taken into account.
So to start:
> ELN (Enterprise Linux Next) is going to be that place. What we want to do is
> establish a set of RPM conditionals that can be used for the set of packages
> that may need to be built differently for a RHEL-like target as compared to
> a Fedora one. (For example, Fedora often ships with experimental or
> less-commonly-used features enabled for packages that Red Hat would not want
> to support for Enterprise Linux customers).
Some packagers are fine with adding conditionals in their SPECs and that is ok.
However as one of the maintainers of the main python interpreter as well as
various alternative ones, and hundreds of libraries, not only throughout Fedora
but across the RHEL ecosystem, I can say that this change vastly complicates my
work. As a team we maintain approximately 35+ different branches of various
python interpreters and if it was making sense to have single SPECs by using
conditionals, we would pretty much do it without hassle. Different
projects/products have differents needs and different goals (and different
branches but more on that later).
I could just add RHEL and SCL conditionals however not only it would clutter
the SPEC file to insane amounts of unnecessary craft, the only people who would
know how to work with it, would be me and my team. I want to encourage
contributions from the community at my packages, not make them more complex and
deter others from contributing.
So in that respect, in Fedora I wouldn't personally add any RHEL (or ELN)
conditionals, as our RHEL work can vary significantly. And it would drive
potential collaborators away if every change visible in Fedora, would also have
an effect on a black box that would be ELN. Why would they even bother if they
don't have access to that? And what's their motivation to even work with those
conditionals? Am I supposed, for example, to reject PR's that could break ELN
due to its different compiler flags, but have no effect on Fedora, from a user
and a contributor working to better a package on our OS?
Also contributors *are* users of Fedora and driving them away, may very well
drive a portion of our userbase away as well.
"""
As a sister effort to this, the OSCI team will also be implementing automated
tests that will run against ELN composes and provide non-blocking feedback to
the package maintainers about potential issues in the Enterprise Linux
configuration.
"""
I don't like this part either. Feedback is still feedback blocking or not.
Seeing a big red sign that a change broke ELN is just nagging people to fix
issues that might not even affect them in any significant way. I would like the
ELN testing feedback to be opt-in for packagers who do not maintain something
in ELN or RHEL and only the actual RHEL maintainer to get the notification. If
not, that is unnecessary noise.
"""
The reasoning behind this approach is so that we break as little as possible
when we implement this new build and compose. Existing packages that are using
conditionals such as if 0%{?rhel} > 7 will transition over to building "like
RHEL" automatically. Any packages that do not have a shared Fedora/RHEL
specfile will
NeuroFedora review swap: python-steps
Hello, Would anyone like to swap a review please? I'd like to get "STEPS" reviewed for inclusion in NeuroFedora: https://bugzilla.redhat.com/show_bug.cgi?id=1821069 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
Re: v4l2loopback kernel module in Fedora?
On Sun, 5 Apr 2020 at 22:23, Christopher wrote: > > On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar wrote: > > > > On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > > > > > Aren't external kernel modules banned by fedora packaging rules? > > > > Yes, they are: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules > > > > According to those guidelines, they can't be packaged outside the main > kernel package. But, they can still be included in the main kernel > packaging. So, I guess I'm trying to reach out to whoever's involved > in packaging that. You can try contacting the Kernel Team, but the upstream maintainer doesn't seem to be actively pushing for merging this into Linus' tree, so it's hard to make a case for it in its current status [1]. RPM Fusion and Copr are better targets for this. [1] https://fedoraproject.org/wiki/KernelDriverPolicy -- Iñaki Úcar ___ 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
Re: v4l2loopback kernel module in Fedora?
On Sun, Apr 5, 2020 at 12:13 PM stan via devel wrote: > > On Sun, 5 Apr 2020 02:56:08 -0400 > Christopher wrote: > > > Has anyone tried packaging v4l2loopback into Fedora? I'd really like > > to set up a screen capture device for video conferencing stuff, but I > > keep running into problems with SecureBoot. I don't really know what > > I'm doing with mokutil or DKMS and I'm generally uncomfortable > > building kernel modules myself. I would be far more comfortable simply > > installing directly from a Fedora RPM that contains the signed kernel > > module needed. > > Have you looked at OBS? It's actually a tool to create streaming > content, but it performs screen capture, and has key mappings so it can > be started and stopped without switching to the gui. It is on > rpmfusion. tl;dr - OBS requires v4l2loopback to do what I need to do. And, even without OBS, all the instructions out there to capture and share specific screens (or portions of screens) in Linux using apps like Slack describe using v4l2loopback. I'm already using OBS. I use OBS to prepare the scene by combining all the sources into the scene layout I want, but then I need to expose that result into an output stream that can be used in Slack or other apps. There are OBS plugins to emit the scene to a virtual video capture device, and it works on Windows just fine, but for it to work on Linux, I need to use the v4l2loopback module to create a virtual camera that can be used in those streaming apps. As I understand it, v4l2loopback is already available on Ubuntu. There was a COPR package for it, but it hasn't been maintained in some time, and even when bringing it up-to-date, it uses DKMS to build an unsigned kernel module, which won't load. I'm not comfortable messing with mokutil and SecureBoot configuration, and don't think it should be necessary to get this functionality. ___ 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
Re: v4l2loopback kernel module in Fedora?
On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar wrote: > > On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > > > Aren't external kernel modules banned by fedora packaging rules? > > Yes, they are: > https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules > According to those guidelines, they can't be packaged outside the main kernel package. But, they can still be included in the main kernel packaging. So, I guess I'm trying to reach out to whoever's involved in packaging that. ___ 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
[Bug 1820788] perl-Rose-DB-Object-0.817 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1820788 --- Comment #5 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Rose-DB-Object-0.817-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=43046241 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1820788] perl-Rose-DB-Object-0.817 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1820788 --- Comment #4 from Upstream Release Monitoring --- Created attachment 1676421 --> https://bugzilla.redhat.com/attachment.cgi?id=1676421=edit [patch] Update to 0.817 (#1820788) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1820788] perl-Rose-DB-Object-0.817 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1820788 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Rose-DB-Object-0.816 |perl-Rose-DB-Object-0.817 |is available|is available --- Comment #3 from Upstream Release Monitoring --- Latest upstream release: 0.817 Current version/release in rawhide: 0.815-17.fc33 URL: http://search.cpan.org/dist/Rose-DB-Object/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3299/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: v4l2loopback kernel module in Fedora?
On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > Aren't external kernel modules banned by fedora packaging rules? Yes, they are: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules -- Iñaki Úcar ___ 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
Re: v4l2loopback kernel module in Fedora?
On Sun, Apr 5, 2020 at 9:03 AM Leigh Scott wrote: > Aren't external kernel modules banned by fedora packaging rules? My recollection (from some time ago) was there was a process to request a (short term) exception to allow one to ship a kernel module if the kernel module developer (not the packager) would document the plans (and commit) to upstreaming with a reasonable date attached. I don't recall such a process being used any time recently, and I am not even sure the process is still considered operational (lots of policies get retired). RPMFusion, of course, does ship kernel modules, so there is that if someone wants to go that route. ___ 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
Fedora 32 compose report: 20200405.n.0 changes
OLD: Fedora-32-20200404.n.0 NEW: Fedora-32-20200405.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 15 Dropped packages:1 Upgraded packages: 42 Downgraded packages: 0 Size of added packages: 49.80 MiB Size of dropped packages:52.37 KiB Size of upgraded packages: 2.13 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 116.15 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-32-20200404.n.0.ppc64le.tar.xz = ADDED PACKAGES = Package: ffuf-1.0.2-1.fc32 Summary: Fast web fuzzer written in Go RPMs:ffuf golang-github-ffuf-devel Size:13.41 MiB Package: gobuster-3.0.1-1.fc32 Summary: Directory/File, DNS and VHost busting tool written in Go RPMs:gobuster golang-github-oj-gobuster-devel Size:13.40 MiB Package: mkdocs-1.1-4.fc32 Summary: Python tool to create HTML documentation from markdown sources RPMs:mkdocs mkdocs-docs Size:4.55 MiB Package: protonvpn-cli-2.2.2-7.fc32 Summary: Linux command-line client for ProtonVPN written in Python RPMs:protonvpn-cli Size:62.70 KiB Package: python-adb-shell-0.1.3-1.fc32 Summary: Python implementation for ADB shell and file sync RPMs:python3-adb-shell Size:44.31 KiB Package: python-aiopg-1.0.0-2.fc32 Summary: Postgres integration with asyncio RPMs:python3-aiopg Size:64.48 KiB Package: python-aiostream-0.4.1-2.fc32 Summary: Generator-based operators for asynchronous iteration RPMs:python3-aiostream Size:57.13 KiB Package: python-boxsdk-2.7.1-1.fc32 Summary: Python wrapper for the Box API RPMs:python3-boxsdk Size:178.03 KiB Package: python-cloudant-2.12.0-2.fc32 Summary: Cloudant/CouchDB Client Python library RPMs:python3-cloudant Size:99.00 KiB Package: python-itanium_demangler-1.0-1.fc32 Summary: Pure Python parser for mangled itanium symbols RPMs:python3-itanium_demangler Size:22.49 KiB Package: python-mulpyplexer-0.08-1.fc32 Summary: Module that multiplexes interactions with lists of Python objects RPMs:python3-mulpyplexer Size:13.12 KiB Package: python-nessus-file-reader-0.2.0-1.fc32 Summary: Python file reader for nessus files RPMs:python3-nessus-file-reader Size:29.66 KiB Package: python-xpath-expressions-1.0.2-1.fc32 Summary: Treat XPath expressions as Python objects RPMs:python3-xpath-expressions Size:14.69 KiB Package: rust-afterburn-4.3.2-1.fc32 Summary: Simple cloud provider agent RPMs:afterburn afterburn-dracut Size:7.71 MiB Package: rust-askalono-cli-0.4.2-3.fc32 Summary: Tool to detect the contents of license files RPMs:askalono-cli Size:10.16 MiB = DROPPED PACKAGES = Package: golang-github-nats-io-streaming-0.4.4-2.fc31 Summary: NATS Streaming System RPMs:golang-github-nats-io-streaming-devel Size:52.37 KiB = UPGRADED PACKAGES = Package: alt-ergo-2.0.0-10.fc32 Old package: alt-ergo-2.0.0-9.fc32.1 Summary: Automated theorem prover including linear arithmetic RPMs: alt-ergo alt-ergo-gui Size: 34.22 MiB Size change: 112.41 KiB Changelog: * Tue Mar 24 2020 Jerry James - 2.0.0-10 - Rebuild for ocaml-menhir 20200211 Package: argbash-2.8.1-4.fc32 Old package: argbash-2.8.1-3.fc32 Summary: Bash argument parsing code generator RPMs: argbash Size: 53.47 KiB Size change: -2.20 KiB Package: coccinelle-1.0.9-0.2.111d328fee1303f14a5b9def835301d849e41331.fc32 Old package: coccinelle-1.0.8-5.fc32 Summary: Semantic patching for Linux (spatch) RPMs: coccinelle coccinelle-bash-completion coccinelle-doc coccinelle-examples Size: 37.18 MiB Size change: 218.61 KiB Changelog: * Wed Mar 25 2020 Richard W.M. Jones - 1.0.9-0.1 - Package pre-release version which supports OCaml 4.10 (RHBZ#1817182). * Wed Mar 25 2020 Jerry James - 1.0.9-0.2 - Rebuild for ocaml-menhir 20200211 Package: coq-8.11.0-1.fc32 Old package: coq-8.9.1-13.fc32 Summary: Proof management system RPMs: coq coq-coqide coq-doc Dropped RPMs: antlr4-python3-runtime Size: 426.51 MiB Size change: 43.82 MiB Changelog: * Wed Mar 25 2020 Jerry James - 8.11.0-1 - Version 8.11.0 - Drop upstreamed 0002-fix-signal-polling-for-OCaml-4.10.patch - Stop bundling the python3 runtime for antlr4 Package: dillo-3.0.5-8.fc32 Old package: dillo-3.0.5-6.fc31 Summary: Very small and fast GUI web browser RPMs: dillo Size: 3.31 MiB Size change: -46.94 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 3.0.5-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Mar 27 2020 Artem Polishchuk - 3.0.5-8 - Fix/workaround FTBFS | RHBZ#1799282 - Packaging improvements Package: eog-3.36.1-2.fc32 Old package: eog-3.36.1-1.fc32 Summary: Eye
Fedora rawhide compose report: 20200405.n.0 changes
OLD: Fedora-Rawhide-20200404.n.0 NEW: Fedora-Rawhide-20200405.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 5 Dropped packages:5 Upgraded packages: 92 Downgraded packages: 0 Size of added packages: 287.87 KiB Size of dropped packages:405.51 KiB Size of upgraded packages: 1.50 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -147.35 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.qcow2 Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.vmdk = DROPPED IMAGES = = ADDED PACKAGES = Package: golang-github-eclipse-paho-mqtt-1.2.0-1.fc33 Summary: Eclipse Paho MQTT Go client RPMs:golang-github-eclipse-paho-mqtt-devel Size:59.02 KiB Package: golang-github-influxdata-promql-2.12.0-1.fc33 Summary: Pruned version of the native Prometheus promql package RPMs:golang-github-influxdata-promql-devel Size:50.34 KiB Package: golang-github-nats-io-stan-0.6.0-1.fc33 Summary: Performant, lightweight reliable streaming platform RPMs:compat-golang-github-nats-io-streaming-devel golang-github-nats-io-stan-devel Size:62.26 KiB Package: golang-github-otiai10-copy-1.1.1-1.fc33 Summary: Golang copy directory recursively RPMs:golang-github-otiai10-copy-devel Size:12.35 KiB Package: golang-github-viant-afs-0.16.1-1.fc33 Summary: Abstract File Storage RPMs:golang-github-viant-afs-devel Size:103.91 KiB = DROPPED PACKAGES = Package: golang-github-nats-io-streaming-0.4.4-2.fc31 Summary: NATS Streaming System RPMs:golang-github-nats-io-streaming-devel Size:52.37 KiB Package: php-Analog-1.0.10-6.fc32 Summary: PHP micro logging package RPMs:php-Analog Size:29.26 KiB Package: php-nikic-fast-route-1.3.0-5.fc32 Summary: Fast implementation of a regular expression based router RPMs:php-nikic-fast-route Size:20.65 KiB Package: php-slim3-3.12.1-3.fc32 Summary: PHP micro framework RPMs:php-slim3 Size:58.23 KiB Package: rubygem-simple-rss-1.3.3-1.fc33 Summary: A simple, flexible, extensible, and liberal RSS and Atom reader for Ruby RPMs:rubygem-simple-rss rubygem-simple-rss-doc Size:245.00 KiB = UPGRADED PACKAGES = Package: blender-1:2.82a-2.fc33 Old package: blender-1:2.82a-1.fc33 Summary: 3D modeling, animation, rendering and post-production RPMs: blender blender-fonts blender-rpm-macros Size: 171.86 MiB Size change: -38.34 KiB Changelog: * Sat Apr 04 2020 Simone Caronni - 1:2.82a-2 - Remove unfinished RHEL 7 support in SPEC file. - Move desktop file validation to check section. - Fix FFmpeg conditional. - Explicitly declare version in patch, hopefully it does not require an udpate. - Trim changelog. Package: bluedevil-5.18.4.1-1.fc33 Old package: bluedevil-5.18.4-1.fc33 Summary: Bluetooth stack for KDE RPMs: bluedevil Size: 2.33 MiB Size change: 558 B Changelog: * Sat Apr 04 2020 Rex Dieter - 5.18.4.1-1 - 5.18.4.1 Package: breeze-gtk-5.18.4.1-1.fc33 Old package: breeze-gtk-5.18.4-1.fc33 Summary: Breeze widget theme for Gtk2 and Gtk3 RPMs: breeze-gtk Size: 1.47 MiB Size change: 455 B Changelog: * Sat Apr 04 2020 Rex Dieter - 5.18.4.1-1 - 5.18.4.1 Package: buildah-1.15.0-0.25.dev.git31a01b4.fc33 Old package: buildah-1.15.0-0.24.dev.gite9a6703.fc33 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 87.57 MiB Size change: -11.67 KiB Changelog: * Sat Apr 04 2020 RH Container Bot - 1.15.0-0.25.dev.git31a01b4 - autobuilt 31a01b4 Package: clojure-1:1.9.0-0.alpha15.1.fc33 Old package: clojure-1:1.8.0-2.fc32 Summary: A dynamic programming language that targets the Java Virtual Machine RPMs: clojure Size: 3.60 MiB Size change: 532.83 KiB Changelog: * Sat Apr 04 2020 Markku Korkeala - 1:1.9.0-0.alpha15.1 - Update to upstream release 1.9.0-alpha15 - Update to require JDK 1.8 Package: clojure-maven-plugin-1.8.1-5.fc33 Old package: clojure-maven-plugin-1.8.1-4.fc32 Summary: Clojure plugin for Maven RPMs: clojure-maven-plugin Size: 80.66 KiB Size change: 1.92 KiB Changelog: * Sat Apr 04 2020 Markku Korkeala - 1.8.1-5 - Rebuilt for Fedora 33 rawhide Package: desktop-backgrounds-32.0.0-4.fc33 Old package: desktop-backgrounds-32.0.0-3.fc33 Summary: Desktop backgrounds RPMs: desktop-backgrounds-basic desktop-backgrounds-compat desktop-backgrounds-gnome desktop-backgrounds-waves Size: 13.37 MiB Size change: 564 B Changelog: * Thu Apr 02 2020 Bj??rn Esser - 32.0.0-4 - Fix
Re: v4l2loopback kernel module in Fedora?
On Sun, 5 Apr 2020 02:56:08 -0400 Christopher wrote: > Has anyone tried packaging v4l2loopback into Fedora? I'd really like > to set up a screen capture device for video conferencing stuff, but I > keep running into problems with SecureBoot. I don't really know what > I'm doing with mokutil or DKMS and I'm generally uncomfortable > building kernel modules myself. I would be far more comfortable simply > installing directly from a Fedora RPM that contains the signed kernel > module needed. Have you looked at OBS? It's actually a tool to create streaming content, but it performs screen capture, and has key mappings so it can be started and stopped without switching to the gui. It is on rpmfusion. > Does anybody have the requisite knowledge to create Fedora packaging > of v4l2loopback and is willing to package for F31? I'd be happy to > test... and possibly co-maintain, if the package maintenance were > sufficiently simple. Not me. This is the procedure I used to create a local key in order to sign custom compiled kernels. So, if you decide to plow on through, you should be able to adapt it for your purposes. Though, if Leigh is right, and out of tree modules are forbidden as Fedora packages, you will have to keep the module rpm on your system only. https://bugzilla.redhat.com/show_bug.cgi?id=1719930 ___ 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
Re: Updating MUMPS/Sundials/PETSc
On 04/04/20 19:23, David S wrote: > On 4/4/20 4:38 PM, Antonio Trande wrote: >> Hi all. >> >> `MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming >> on Rawhide; these updates will need rebuilds of dependent packages: >> > [:snip:] > > > Thanks a lot for updating PETSc, I know PETSc is quite challenging to > package. > > I tried to build BOUT++ against PETSc, using pkg-config. > the pkg-config files are installed to petsc/ subdirectory, but it seems > the pc files are not adjusted for this. > > Further, I have been using petsc --with superludist without issues, can > you tell why this was disabled, so I can test whether this was fixed in > the mean time? `superludist` support is reactivated; please, test petsc-3.13.0 again: https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1328023/ >> >> [1] >> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327044/ >> >> [2] >> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327319/ >> >> [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=43020532 >> >> >> ___ >> 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 >> >> -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
On Sat, Apr 4, 2020 at 8:32 PM Miro Hrončok wrote:
...
> >> For the stated reasons I am *-1 for this change in its current form*.
> >
> > That is your privilege as a member of FESCo. As I've said, however, I
> > think you've misunderstood the situation.
>
> Do you want to leave it at "this is your privilege" or would you rather try to
> lower the level misunderstanding? In other words, do you think it is still
> worth
> it to have this conversation?
>
I do think it is still worth it. I suspect that in some places we are
just talking past one another. It's possible that we would be able to
get a majority vote in FESCo, but I would much prefer if we could get
to *consensus* instead. I'm trying to incorporate suggestions, but
some of them (like requiring ELN to be a completely separate branch of
dist-git) interferes with our intended goals. And (though I haven't
been able to communicate this well, I fear) we really do intend for
conditionals to be uncommon (and ELN-specific conditionals limited to
places where it is absolutely necessary). I think using the
"pre-generated documentation" example was probably a bad one, because
that's a case that implies a much wider scope than intended. Or at the
least, I should have described it better from the beginning. What I
think is most likely is that we'd look into adding %{bcond_with docs}
in more places in Fedora (and default to that being false in ELN).
Then, later in the RHEL process we could introduce such pre-generated
docs as a downstream-only change after we break inheritance from
Fedora.
If we went that route (not just for docs, but as a model for
conditionals in general), would that address some of your
reservations?
> >> As said on the mailing list, I'd appreciate if you take the feedback
> >> provided by
> >> the packagers more seriously and adjust the proposal accordingly.
> >
> > I have read and responded to the feedback as best I know how. Please
> > do not confuse "I disagree and here are my reasons" with not listening
> > to the feedback.
>
> I've asked you to take it more seriously, I was not accusing you for not
> listening to it. I guess what I meant to say is "give the people who provided
> the feedback some benefit of a doubt and some merit and work with them to
> understand their concerns better" -- but I realize there will always be some
> level of disagreement.
There will be, but I really am trying to identify the problems and
find common ground. As I said above, I think I'm probably
misunderstanding what you're advocating for rather than ignoring it.
> > Lastly, I don't know if you reread the latest updates (that I made
> > around three hours ago to the Change Proposal), but I *did*
> > acknowledge that we are going to incorporate the possibility of
> > maintaining separate specs for ELN and Rawhide for any maintainer who
> > absolutely wants to do more manual work. The exact mechanism is going
> > to at least partly depend on the results of the dist-git forge move,
> > so I haven't incorporated that into the proposal. Functionally, it
> > will be very similar to maintaining a separate branch, though.
>
> Well, sadly I had not, because I was writing that thing for more than 3 hours
> trying to not sound like a demanding passive aggressive naysayer :(
Email is hard. I understand.
> If I had reread the latest version, my reply would be different. (Although
> there
> are far too many open questions in this ML thread, I won't be changing my vote
> to +1 yet, you can consider my -1 withdrawn for now.)
>
> Thank You for adding that \o/ -- this is precisely what I meant by "taking the
> feedback more seriously".
I appreciate that.
> I could imagine this latest addition incorporated into the proposal better,
> would you like to "meet" and discuss that?
I'll see if I can find some time ahead of the FESCo meeting to talk
with you tomorrow. I think it's definitely worth talking it over.
___
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
Re: F32: System hangs when using mock
On Sat, Apr 04, 2020 21:37:05 -, Artem Tim wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1754807 That does look like it. I'll go through the comments and see if I can help with more info. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
Re: F32: System hangs when using mock
On Sat, Apr 04, 2020 15:33:57 -0600, Chris Murphy wrote: > On Sat, Apr 4, 2020 at 3:13 PM Ankur Sinha wrote: > > > > Hello, > > > > I've had my system hang up a few times when running mock this evening. > > I've got to power it off and restart it using the switch. Is anyone else > > seeing this? > > After the hang, are you able to switch to a vt or login remotely via ssh? I wasn't able to switch to a vt. I'll test ssh the next time it happens. > If not, two options for getting more information: remotely login via > ssh, and use 'journalctl -fk' to follow kernel messages as they > happen; it might get out by sshd before it gets committed to disk. > More likely successful is switching to a vt, and running mock there, > and seeing if you get a stack trace. Capture with a cell phone. > *shrug* > > What's the exact command? I might try to reproduce if I get a moment, > I have those same versions. It's just a standard mock build for a new package I'm working on: https://pagure.io/neuro-sig/steps So, something simply like: mock -r fedora-rawhide-x86_64 rebuild steps-3.5.0-1.fc32.src.rpm -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
Fedora-Cloud-31-20200405.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
[Bug 1820924] perl-Test-Most-0.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1820924 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Test-Most-0.37-1.fc33 Resolution|--- |RAWHIDE Assignee|jples...@redhat.com |p...@city-fan.org Doc Type|--- |If docs needed, set a value Last Closed||2020-04-05 10:30:21 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=43033721 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Heads-up: RPM 4.16 alpha coming to rawhide
On Thu, Apr 02, 2020 at 09:43:35AM +0100, Richard W.M. Jones wrote: > On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote: > > On 4/1/20 8:40 PM, Richard W.M. Jones wrote: > > > > > >This is _only_ going into Rawhide / F33? It looks like the change to > > >the new OCaml dependency generator will require a complete rebuild of > > >all OCaml packages. > > > > > >https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1 > > >https://github.com/rpm-software-management/rpm/issues/913 > > > > > > > Oh, bollocks. I totally forgot, and failed to realize the impact of > > that. Sorry! Should I revert that in rawhiede, until an explicit > > "go" signal from you? That's perfectly fine by me. > > > > And yes this is only going to rawhide/f33, only micro version > > updates are pushed to stable releases. > > No, don't do anything now. I'm doing an OCaml rebuild of all OCaml > rawhide packages into a side tag. If that works then we can just fold > that side tag into Rawhide and it's all good. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 Only one package failed to build (out of 130) which is pretty good. The dependencies seem OK, as in, packages were able to be installed when rebuilding the later packages, and the expected ocaml(...) and ocamlx(...) deps seem to be present, at least for a small handful of packages that I looked at. Rich. > > This is also just further proof that these things need to be in > > hands of language SIGs, not rpm upstream. Perl and Python dependency > > generation was already "outsourced" to respective > > lang-macros/generators packages, I'd recommend doing the same with > > OCaml to put the right people in control of things like this. > > I can't remember but isn't that how it originally worked for OCaml > and then it was added to RPM? In any case there's probably some value > in sharing this code across RPM-based distributions. (Note this code > came directly from SUSE, derived from work I originally did for Fedora). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > ___ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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
Re: v4l2loopback kernel module in Fedora?
Aren't external kernel modules banned by fedora packaging rules? ___ 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
[Bug 1820127] perl-Mojolicious-8.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1820127 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.36-1.fc3 ||3 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-04-05 07:54:37 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1489758 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1817204] perl-Search-Elasticsearch-6.80 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817204 Emmanuel Seyman changed: What|Removed |Added Fixed In Version|perl-Search-Elasticsearch-6 |perl-Search-Elasticsearch-6 |.00-8.fc33 |.80-1.fc33 --- Comment #2 from Emmanuel Seyman --- make that: https://koji.fedoraproject.org/koji/buildinfo?buildID=1489766 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Fedora-Cloud-30-20200405.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
v4l2loopback kernel module in Fedora?
Hi, Has anyone tried packaging v4l2loopback into Fedora? I'd really like to set up a screen capture device for video conferencing stuff, but I keep running into problems with SecureBoot. I don't really know what I'm doing with mokutil or DKMS and I'm generally uncomfortable building kernel modules myself. I would be far more comfortable simply installing directly from a Fedora RPM that contains the signed kernel module needed. Does anybody have the requisite knowledge to create Fedora packaging of v4l2loopback and is willing to package for F31? I'd be happy to test... and possibly co-maintain, if the package maintenance were sufficiently simple. Thanks, Christopher ___ 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
