Re: Builder hosts CA file
On 5/22/24 9:15 AM, Michael Cronenworth via rpmfusion-developers wrote: If there is no quick solution I may disable package verification until this can be fixed. I ended up disabling verification until the build hosts can be fixed. Then ran into a new NodeJS arch specific dependency... but it is now resolved. Jellyfin 10.9.4 is also now out. Pushing that version out now. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Builder hosts CA file
On 5/22/24 8:30 AM, Nicolas Chauvet via rpmfusion-developers wrote: I've updated the ca-certificates package from the koji host, but I don't get why this bundle would be used into the buildroot rather than the one from the buildroot I don't get why my resubmit of your same job went later (and stopped with a crash), while It could be because we are using a old fedora host as builder, but it's still weird. Can we track this on a dedicated bugzilla infra ticket ? I will have to escalate this to mock maintainers... https://bugzilla.rpmfusion.org/show_bug.cgi?id=6944 I tried a new build but the CA bundle is still not the correct file. If there is no quick solution I may disable package verification until this can be fixed.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Builder hosts CA file
On 5/22/24 1:06 AM, Nicolas Chauvet via rpmfusion-developers wrote: I'm not sure why the CA from the koji builder host should be used, compared to the CA of the fedora buildroot populated for the given target ? Is this because, in some context, the digicert root ca could only be provided in the tls and email bundles and not the objsign ? Is the installed packages set from koji mock and your local mock are the same ? Thanks for the report. The installed package name is the same, but the package contents are being modified on the build host. https://koji.rpmfusion.org/koji/taskinfo?taskID=640941 Package (same for all hosts, F40+): ca-certificates-2023.2.62_v7.0.401-6.fc40.noarch Koji build host: -r--r--r--. 1 root root 497544 May 22 08:23 objsign-ca-bundle.pem Local host: -r--r--r--. 1 root root 503463 Apr 20 23:08 objsign-ca-bundle.pem Local mock: -r--r--r--. 1 root root 503463 Apr 20 23:08 objsign-ca-bundle.pem I'm not sure what would be modifying the ca-certificates contents on the Koji build hosts. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Builder hosts CA file
On 5/21/24 5:27 PM, Frank Dana wrote: ls -l /etc/pki/ca-trust/extracted/pem/ rpm -vV ca-certificates I added those commands and the files are definitely being modified. https://koji.rpmfusion.org/koji/taskinfo?taskID=640941 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Builder hosts CA file
Hi all, I am attempting to build Jellyfin 10.9 for Rawhide, but I am running into an error[1] with dotnet unable to verify the package signatures of the build modules. The package signatures can be verified on my local system with mock (Rawhide) but fail on the RPMFusion Koji build hosts. I added a grep command[2] to see if the CA exists in the Koji build host, and surprisingly it does not exist. It does exist on my local copy. Are the Koji builders CA files being modified? Thanks, Michael [1] https://koji.rpmfusion.org/koji/taskinfo?taskID=640879 [2] https://koji.rpmfusion.org/koji/taskinfo?taskID=640911 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Jellyfin 10.9
On 5/13/24 12:44 AM, Michael Cronenworth via rpmfusion-developers wrote: I have pushed the 10.9.1 update for Jellyfin to Rawhide. Can someone regenerate the rawhide-free metadata? The build is failing due to out of date metadata. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Jellyfin 10.9
Hello all, I have pushed the 10.9.1 update for Jellyfin to Rawhide. I've tested it locally on a test F40 system and it upgraded from 10.8 without any issues. I have not upgraded my production system (yet). Please test it and provide feedback. I plan on upgrading F39/F40 soon. I don't believe the 10.8 branch will receive any further updates. Thanks, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/18/24 2:29 PM, Michael Cronenworth via rpmfusion-developers wrote: The update has now been pushed to F40: kodi, kodi-pvr-hdhomerun, and kodi-inputstream-adaptive have been pushed. Please update other addons. Some may work without recompiling as not all of the API requirements changed between v20 and v21. I've been running Kodi 21 on my Fedora 39 HTPC for a month without a problem. With F40 out this week I plan on updating F39 to v21. The update delta is small and there don't appear to be any add-on or other problems typically seen in a major version update of Kodi. Unless there are any objections I will announce when I push the update out later this week. Thanks to everyone for their contributions on this. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/20/24 3:06 AM, Nicolas Chauvet via rpmfusion-developers wrote: Yes, according to groups: pkgs01 $ groups mooninite mooninite : mooninite cla_done cla_fpca cla_rpmfusion packager provenpackager rpmfusionbugs ... What was the exact error ? are you using the appropriate remote to write to ? git remote -v ? It looks like I needed to wait longer than 24 hours. It is working now. Thanks. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/18/24 2:55 PM, Nicolas Chauvet via rpmfusion-developers wrote: Please do whatever rebuilt is needed, I've just sponsored both of you to provenpackager to do so. Thanks for the work on that. I am trying to push to kodi-inputstream-rtmp or kodi-peripheral-joystick but I am getting rejected. Did the provenpackager group not get correctly applied? ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/18/24 2:55 PM, Nicolas Chauvet wrote: Please do whatever rebuilt is needed, I've just sponsored both of you to provenpackager to do so. Thanks for the work on that. Thanks, Nicolas. I'll work on them as time allows.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/16/24 3:21 PM, Nicolas Chauvet via rpmfusion-developers wrote: Thanks for rising theses. It looks good points for updating by default then... The update has now been pushed to F40: kodi, kodi-pvr-hdhomerun, and kodi-inputstream-adaptive have been pushed. Please update other addons. Some may work without recompiling as not all of the API requirements changed between v20 and v21. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/14/24 2:02 AM, Tomasz Torcz via rpmfusion-developers wrote: This is very suprising to me. I was under impression GNOME/Wayland is a long way away from any HDR capabilities. KDE Plasma 6 is supposed to have some rudimentary support. How does this work? And what's the line with "GBM window" mean? The Kernel has supported HDR metadata pass-through for some time, but X.org or Wayland didn't have a way of sending it on. When you use Kodi with the GLES renderer it can use windowing with GBM (Generic Buffer Management) to draw a GUI without X11 or Wayland. Kodi can then send HDR metadata through GLES/GBM and the Kernel receives it and passes it through the HDMI connector. Kodi may also send HDR through Plasma/Wayland but I have not tested it and it would not surprise me if it is not supported. I am not familiar enough with the low-level functionality of Plasma or Wayland to know. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/13/24 3:37 PM, Nicolas Chauvet via rpmfusion-developers wrote: I see little point to update Kodi to a New version for F40 unless WE are sure that no regression occured ... Specially not until thé full set of Kodi modules are fully validated Not having newer Kodi in F40 means having a way for end -users to downgrade to the GA version. To the contrary, I have no problem to have newer Kodi as a 0 day update for f40. I've upgraded my everyday F39 system to v21 and so far so good. HDHomeRun, YouTube, Netflix still work as expected. I will wait until Mohamed has time to update all of the PVR addons before pushing to F40. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/12/24 1:30 PM, Michael Cronenworth via rpmfusion-developers wrote: I have the kodi, kodi-inputstream-adaptive, and pvr.hdhomerun changes queued up and ready to commit to F40+. I'll commit them in a few hours unless there are objections. The update has been pushed to Rawhide (F41) and all three packages successfully built. I'll push to F40 tomorrow. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Kodi 21
On 3/12/24 3:36 AM, Leigh Scott via rpmfusion-developers wrote: +1 for new kodi for f40+, maybe f39 can be added later. -1 for adding GLES I have the kodi, kodi-inputstream-adaptive, and pvr.hdhomerun changes queued up and ready to commit to F40+. I'll commit them in a few hours unless there are objections. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Kodi 21
Hi all, Kodi 21 has its first release candidate now available. Key features: - HDR (It works, I've tested it!) - Better Pipewire support - Works better with FFMpeg 6 / Python 3.12+ Requirements: - Addon rebuilds (such as Inputstream Adaptive) - Compile time only requirement on apache-groovy (binary Java Jar) HDR requirements: - GLES renderer (we do not ship this today, should we? other distros do) - GBM window (no X11, no Wayland compositor) Caveats so far: My test system is running a AMD Ryzen 5 3400G CPU and when using the GLES renderer it appears frame limited to 18-19 FPS. This is less then ideal when almost all media is ~24 FPS. I have not spent any troubleshoot time yet on why the FPS is low. This is a general announcement. I'd like to introduce Kodi 21 RC1 to Rawhide ASAP. I would also like to propose to push it into Fedora 40. Thoughts? Regards, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Mass rebuild results for F39
On 8/3/23 9:15 PM, Sérgio Basto via rpmfusion-developers wrote: Failed builds: 17 I think that low number is pretty impressive. Thanks, Sérgio. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Koji builders cannot build Wine Mono
On 6/25/23 3:06 PM, Kevin Fenzi wrote: Do you have any idea what the bug might be here? All builders are now on 6.3.8-200.fc38. The "mono-sgen" process is crashing on kernel 6.2. Not every time either so it would take some time to debug. I have not narrowed it down further. Koji builders successfully built Wine Mono 8.0.0. Thank you for the quick update, Kevin. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Koji builders cannot build Wine Mono
On 6/20/23 12:21 AM, Michael Cronenworth wrote: The builds fail in similar ways but in different places. If anyone has a minute could they review the build logs and offer a clue as to what may be the cause? I had some time to debug today and came up with a possible answer I feel is the solution. I was able to locally reproduce the issue seen on the Koji builders. Working local system: AMD 5800X3D Fedora 38 - Kernel 6.3.7-200.fc38.x86_64 Broken local system: Intel Xeon E-2288G Fedora 38 - Kernel 6.2.15-300.fc38.x86_64 I was able to "coax" the broken system along by running "make" multiple times. It would error, but a second make run would succeed but error later in the compile. I upgraded the "broken" system to kernel 6.3.9-200.fc38.x86_64 and now it successfully builds Wine Mono on the first try. It appears there is a kernel bug in 6.2 that is fixed in 6.3. I noticed the Koji builders are running kernel 6.2.x... When will the Koji builders be upgraded next? :) Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Koji builders cannot build Wine Mono
Hi, I was attempting to push a Wine Mono update today but ran into a problem with all versions of Fedora when building in Koji. The Wine Mono update successfully compiles on my local system using "fedpkg mockbuild" for all versions of Fedora. The builds fail in similar ways but in different places. If anyone has a minute could they review the build logs and offer a clue as to what may be the cause? F39 build attempts: - https://koji.fedoraproject.org/koji/taskinfo?taskID=102372408 (x86_64) - https://koji.fedoraproject.org/koji/taskinfo?taskID=102373027 (aarch64) - https://koji.fedoraproject.org/koji/taskinfo?taskID=102373207 (x86_64) F38 build attempt: https://koji.fedoraproject.org/koji/taskinfo?taskID=102372475 (aarch64) F37 build attempt: https://koji.fedoraproject.org/koji/taskinfo?taskID=102372473 (x86_64) Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Plans for dhclient / ISC dhcp?
On 5/31/23 3:15 PM, Dominique Martinet wrote: Could that be the ipv6 "privacy" features? No, it is not an issue with privacy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Plans for dhclient / ISC dhcp?
On 5/31/23 9:18 AM, Peter Robinson wrote: NetworkManager has defaulted to it's own dhcp client by default for some time and systemd-networkd has it's own as well, I suspect actual users are quite minimal. I'm not sure if anything like cloud-init uses it but I also doubt it. I'll come out of my shell to cough up as one of those "minimal" users. I'm using it only on a single server that is still using "network-scripts" for network management. Yes, I know they are deprecated. I wouldn't be surprised if there are a few other "network-scripts" users. The scripts call dhclient. It would be nice if a change notice went out about it. This email is not intended to be a "-1" or other negative response. I will end up changing network management to something else. I'm not using NetworkManager due to an issue with IPv6 and SLAAC. Clients under the server get an initial SLAAC IP from NetworkManager, but after the IP expires they never get a new IP. I've asked upstream about it and didn't get anywhere. Granted, this was 3 years ago now. Maybe things are better and I can try NetworkManager again... or systemd-networkd. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On 4/25/23 1:34 PM, Neal Gompa wrote: Maybe we can talk to the folks in the Wine community about what we should do to support their needs better within Fedora? If we don't want to go to the max (ish), maybe we can find a middle ground that makes games work on Fedora better. I agree. While Valve is doing a great job they're also keeping themselves isolated more than I know we'd all like. I think a compromise could be made between Wine and the kernel folks on what the best action is to take. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [kodi-inputstream-adaptive] Fix sources
On 3/27/23 12:34 PM, Mohamed El Morabity wrote: Hello Michael, the "Provides" was present since this library was bundled: https://pkgs.rpmfusion.org/cgit/free/kodi-inputstream-adaptive.git/tree/kodi-inputstream-adaptive.spec#n33 Apologies, I was just looking at the commit message. :( Thanks for pushing an update. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [kodi-inputstream-adaptive] Fix sources
On 3/27/23 5:59 AM, Mohamed ElMorabity wrote: +SHA512 (Bento4-1.6.0-639-6-Nexus.tar.gz) = 08c359fb75f42d095ae040fb4dff020c902ba24677a95360fb845245ba3881423961bff6c8f0d2a791d387aa58ebe50b4998bedb866e0b7b58321bf8cdd4b1c3 Can you add a "Provides" line to declare this C++ library has been added? https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling Provides: bundled(Bento4) = 1.6.0 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: f38-free-build repo
On 1/27/23 11:29 AM, Leigh Scott via rpmfusion-developers wrote: You dropped the annobin fix when you rebased. Fixed. Thanks. It built successfully on x86 so I assumed it wasn't needed any longer. I will add a note to the patch that it is required for ARM. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: LLVM support for '-Wl,-WX'
On 1/17/23 10:15 AM, Tom Stellard wrote: It sounds like the option is not relevant for Windows. See https://reviews.llvm.org/D116484 Thanks, Tom. Do you think modifying the wine configure to not use -Wl,WX is the best option? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: f38-free-build repo
On 1/17/23 11:14 AM, Michael Cronenworth via rpmfusion-developers wrote: The ARM build failed with a strange linker failure. Is the ARM builder out of disk space? Storage: Filesystem Size Used Avail Use% Mounted on /dev/vda2 127G 7.9G 114G 7% / I guess it isn't a disk space issue. It looks like an ARM specific issue. Something has changed with GCC 13. I'll keep looking into it. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: f38-free-build repo
On 1/16/23 10:09 PM, Michael Cronenworth via rpmfusion-developers wrote: Can someone kick off a newRepo task for f38-free-build? Kodi 20.0 was released today and the build is pending for Rawhide. Thanks, Nicholas, I have fixed the build and x86_64 is successfully building. The ARM build failed with a strange linker failure. Is the ARM builder out of disk space? ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: LLVM support for '-Wl,-WX'
On 1/16/23 11:30 PM, Tom Stellard wrote: -WX means treat warnings as errors. It's possible the configure check is failing for other reasons. Is that the first check run with -target aarch64-windows? Do you have the full config.log? Yes. I do not have the full log. This is from a Koji ARM builder. Here's the parent Koji task: https://koji.fedoraproject.org/koji/taskinfo?taskID=96232039 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
LLVM support for '-Wl,-WX'
Hi, Wine 8.0 is checking for support for the '-Wl,-WX' flag in LLVM and it is showing as not supported in Rawhide (LLVM 15). LLVM is used to cross-compile ARM 64-bit binaries of Wine. Wine 7.22 configure check: checking whether clang supports -target aarch64-windows -fuse-ld=lld -Wl,-subsystem:console... yes Wine 8.0 configure check: checking whether clang supports -target aarch64-windows -fuse-ld=lld -Wl,-subsystem:console -Wl,-WX... no Is there anyone that might help me understand what that flag is and if it is something we should support? Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
f38-free-build repo
Hi, Can someone kick off a newRepo task for f38-free-build? Kodi 20.0 was released today and the build is pending for Rawhide. Thanks, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: intel-media-driver performance fix for gen8/9/10
On 1/13/23 1:55 PM, Nicolas Chauvet via rpmfusion-developers wrote: Seems like the patch has landed in master (but not in 22.6.6). Can you apply the patch in fedora branches (and eventually update 22.6.6 in rawhide only for now). I've added you as co-maintainer, it should be live in the next 12 hours. I have the commits queued up once git permissions allow me to push. I'll try tomorrow. Thanks, Nicolas. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: ImageMagick 7 is landing in Rawhide
On 1/6/23 3:34 PM, Neal Gompa wrote: * autotrace (contacting upstream planned) Any update on this one? It is blocking wine. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: intel-media-driver performance fix for gen8/9/10
On 1/10/23 9:30 AM, Nicolas Chauvet wrote: I expect this bug occured as early as the begin of iHD driver (over using the legacy i965 vaapi driver for theses gen). Once the MR is approved, can you assist with the backport of the patch in branches ? I would prefer a conservative approach on this vaapi stack. Yes, I tested this on F37 / 22.5.4 and the patch applied cleanly so it should be an easy patch to apply to all branches. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Retiring libwebcam
On 1/10/23 2:25 PM, Hans de Goede wrote: ATM there is no replacement for uvcdynctrl which is still necessary for some Logitech webcams. uvcdynctrl uses a userspace database to map some Logitech custom control GUIDs to standard v4l2-controls. This allows various extra functionality on Logitech webcams, like adjusting the image (auto-exposure algorithm) for backlight conditions. But also controlling the focus on some Logitech models with a manual controlled electronic focus lens (instead of auto-focus) and I have 1 Logitech model with a motorized stand with electronic tilt / swivel controls which needs this. I dusted off my original Logitech webcam I used libwebcam with and plugged it in today and the controls all showed up in guvcview so I assumed there would not be any missing functionality. Have you tried the latest verison of guvcview? I actually recently discussed what to do with this with the kernel UVC driver maintainer. When the discussion was made many years ago to put the mapping of vendor specific GUIDs in userspace the thought was that there would be many many vendor specific controls and that we did not want to have to add all those to the kernel. But other then the Logitech custom controls set no support for other custom controls was ever added to uvcdynctrl-data. So the UVC driver maintainer said that he would be ok with just adding these mappings directly to the kernel. Once someone finds the time to actually add these mappings to the kenrel libwebcam can be retired but until then it would be nice if we can keep it around for uvcdynctrl. I guess I'll keep it around a few more Fedoras. Luckily it doesn't cause any FTBFS bugs on mass rebuilds. Thanks for the note, Hans. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Retiring libwebcam
Hi all, Unless someone speaks up in the next week I am going to retire the libwebcam[1] package. Background: Some of the first USB web cameras using the "UVC" protocol needed a user-space driver for controlling the hardware features. Logitech developed the libwebcam library as an interface for users. Around 2014 Logitech stopped development on it and it is now abandoned. I have seen replacements pop up with the 'v4l-utils' package and the v4l2-ctl CLI tool and guvcview graphical tool. Both receive modern care so I don't see a need to continue shipping the libwebcam package. There are no known (reqoquery) dependencies on libwebcam. Thanks, Michael [1] https://src.fedoraproject.org/rpms/libwebcam ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
intel-media-driver performance fix for gen8/9/10
Hi all, I'd like to bring to attention an issue in the 'intel-media-driver' package that now has an upstream fix. TLDR: This affects the 'iHD' VAAPI driver for Gen 8 - Gen 10 iGPU video transcoding. Bug: Performance below 60 frames per second. Fix: Restores full performance of iGPU. More than triples performance. Upstream bug: https://github.com/intel/media-driver/issues/925 Upstream fix: https://github.com/intel/media-driver/pull/1589 Thanks, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Policy on supporting old and external software packages and compat RPMS
On 12/5/22 5:39 AM, Terry Barnaby wrote: With the latest release of Fedora37 we were hit with an issue where the ncurses-compat-libs RPM had been depreciated. Due to this some of the tools we use would no longer install from their respective RPM's or their tar based installs would not run as they needed the libncurses*5.so shared libraries. If anyone has a support contact with the following hardware vendors could you tell them this? - Canon Their 'ufr2' driver for CUPS depends on ncurses-compat-libs. They push updated versions as of February 2022 that still depend on it. - Western Digital / HGST Their 'hugo' tool depends on libtinfo.so.5 and the tool is currently maintained and shipped to customers today. The latest version I have from 2021 still depends on it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
On 12/6/22 8:31 AM, Neal Gompa wrote: There's a very important difference between September 2017 and now: we know someone else already did it! Great. Good luck. As an aside: I don't appreciate the "high horse" comment, considering during most of this discussion, I was doing the work and evaluating things. It's unfortunate you feel this way. Maybe we cannot work together. Take care. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
On 12/5/22 5:41 PM, Neal Gompa wrote: But in general, it looks like an upgrade to ImageMagick 7 will be rather easy to do. Hi Neal, I appreciate your eagerness here, but it is a little misled. Version 7 is radically different than version 6. Most (I don't have an exact figure) packages in Fedora are *only* compatible with version 6. Why do I know this? Check out the ImageMagick git history around September 2017. :) I think you need to back off the high horse here wanting version 7 as a primary package and version 6 as a compat package, but I've relinquished my ImageMagick duties as it takes too much time and energy, and Sergio is doing a great job taking over. Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Refresh build repo cache in Koji
On 12/1/22 10:34 AM, Sérgio Basto wrote: done , I also resubmit your build koji-rpmfusion resubmit 574799 Thank you! F36 build also submitted. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Refresh build repo cache in Koji
Hi, Can someone kick off a refresh of the external repo cache for both F36 and F37 in Koji? The dotnet packages were updated yesterday to finally let me build out the newest version of Jellyfin. Thanks, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Upcoming changes to domoticz
Hi all, The 'domoticz' package has a major change coming in the next release. Current version: 2022.1 Next version: 2022.2 This change only affects Z-Wave users. Upstream has decided to deprecate OpenZWave support and will instead support ZWave-JS through MQTT. There is a documentation page[1] that describes the changes and recommendations on migrating[2] your old Z-Wave device entries in Domoticz. Luckily you don't have to re-program the Z-Wave devices themselves as their configuration is held entirely on each device and in the Z-Wave controller. This will be a one-time pain, but the good thing is that ZWave-JS has more features and has lots of upstream activity. OpenZWave appears to be dead. If you're interested in testing this with 2022.1 you can do so today as MQTT support exists and I've tested it myself. Download the ZWave-JS-UI binary[3] and start it up. Then start up the MQTT service and follow the Domoticz wiki instructions. Regards, Michael [1] https://www.domoticz.com/wiki/Zwave-JS-UI [2] https://www.domoticz.com/wiki/Zwave-JS-UI#Migrating_from_OpenZwave [3] https://github.com/zwave-js/zwave-js-ui/releases ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: New package: jellyfin
On 11/23/22 10:24 AM, Nicolas Chauvet wrote: Error: Transaction test error: file /usr/lib/firewalld/services/jellyfin.xml from install of jellyfin-firewalld-10.8.7-2.fc37.noarch conflicts with file from package firewalld-1.2.1-1.fc37.noarch Thanks for the message. Firewalld upstream decided to import the entire world's worth of service files instead of letting the individual projects maintain their own file. I'll drop the firewalld sub-package. ___ rpmfusion-users mailing list -- rpmfusion-users@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-users-le...@lists.rpmfusion.org
Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On 11/16/22 3:18 AM, Dominik 'Rathann' Mierzejewski wrote: Actually, it's either one or the other as they don't support the same CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for older ones (Ice Lake is the first one it doesn't support). To be pedantic there is some overlap in support in iHD and i965. What will also rock your noggin is that i965 is faster than iHD. https://github.com/intel/media-driver/issues/925 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On 9/28/22 6:45 PM, David Airlie wrote: Please take a look at the rawhide changes I just pushed. This should split things out sufficiently. Thanks, Dave. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On 9/27/22 2:36 PM, David Airlie wrote: The implicit IANAL is very clear here. I wish you had started the discussion the legal list yourself prior to the git commit. A certain website that monitors this mailing list is probably already preparing to post how Fedora 37 is no longer going to work with popular video codecs. Once that post is made the Internet will take that story and bend it a few ways to make us look bad. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On 9/27/22 1:56 PM, David Airlie wrote: The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented functionality. If simply handling the bitstream is a violation like you say then glibc/kernel could be patent infringing with an open() call. Let's not get that silly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Beta Cannot Install KODI
On 9/26/22 9:38 AM, stan via test wrote: I don't use kodi, but I think that in this case the fedora firewalld should have precedence. Thus, I would suggest you open a bug against kodi at rpmfusion. Please don't. This was already done and closed. https://bugzilla.rpmfusion.org/show_bug.cgi?id=6405 The correct bug report has now been opened. https://bugzilla.redhat.com/show_bug.cgi?id=2129946 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Beta Cannot Install KODI
On 9/23/22 3:46 PM, Earnest Henderson wrote: Apparently that has not made it into Fedora 37 yet? Upstream has removed it, but they have also not released a new version that includes the change. The Fedora firewalld package maintainer needs to either remove the file or apply the patch that removes the file in the mean time. I have requested that from the package maintainer. https://bugzilla.redhat.com/show_bug.cgi?id=2129946 Thanks, Michael ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 9/1/22 4:25 PM, Richard Shaw wrote: Let me rephrase, is the mingw package going to be built on ALL arches with the expectation that they are the same (like -data packages)? If so, that seems like a huge waste of resources. The MinGW packages would build on all arches. I believe the original designation of 'noarch' is due to the cross-compile aspect as you can build these on any arch and that end users would only use them for development and not runtime. That has changed recently now that Wine builds most of itself as Windows PE binaries and depends on .dll files from mingw32/64 packages. If you want this to change then you'll need to start with the Packaging Guidelines. Sandro may have his own opinion on it, too. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 8/25/22 11:42 AM, Sandro Mani wrote:
You might also want to add the mingw debuginfo packages to those.
Ah, thanks. I'm used to the debuginfo packages being automatically added thanks to
%{mingw_package_header}.
I wonder if we could have the install macros updated to handle this in a native
package scenario.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 8/25/22 1:33 AM, Marián Konček wrote: I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? FAudio vkd3d ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swaps
Hi, I have three reviews I would like to offer a review swap for. One or all. I'll order them by priority (first to last). * jellyfin (Media server) https://bugzilla.rpmfusion.org/show_bug.cgi?id=6335 *kodi-visualization-matrix (Kodi Music Visualization plugin) https://bugzilla.rpmfusion.org/show_bug.cgi?id=6171 *kodi-visualization-projectm (Kodi Music Visualization plugin) https://bugzilla.rpmfusion.org/show_bug.cgi?id=6172 Thanks, Michael ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Adding mingw64-gtk4 and mingw64-libadwaita
On 6/21/22 2:39 PM, Sim Tov wrote: First question is - how far is what I've found from what is needed? Can it be uploaded as is or not? Hi Sim, No. Fedora compiles its packages from source code. It's a hard requirement. Other distros like Arch or Ubuntu are a little more lenient if you are coming from them. The links you provided are to binary (already compiled) packages, but you could use their PKGBUILD file as a pointer to translate into a RPM SPEC file. Before you continue any further you will need to become a Fedora packager to import the packages. This requires a sponsor to approve you to become a packager. Once approved you can look for approval of a review request for a new package. After the package has been reviewed you can then import it into Fedora, build it, and push it out to the Fedora repos. See the packager documentation for more information: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ Thanks, Michael ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Media codecs big SONAME bump
On 6/20/22 6:08 AM, Robert-André Mauchin wrote: I would like to have RPMFusion maintainers help to be able to update them in a RPMFusion side tag too. I will specify to you when the Fedora side tag has been merged. Hopefully, with your cooperation, everything will go smoothly. Thanks for the heads-up. I'll look out for a message. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: HEADS UP: mingw-w64-10.0.0 coming to rawhide
On 4/27/22 6:47 AM, Sandro Mani wrote: I'll be updating to mingw-w64-10.0.0 in rawhide over the next day or two. I did an initial test-run here [1] and everything worked smoothly. The real test will be if wine-gecko still builds. :) ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Wine MinGW system libraries
On 4/10/22 8:28 PM, Zebediah Figura wrote: The first problem is that the location of runtime DLLs varies wildly between distributions, and there's no common independent way to detect it. We could potentially hardcode a few "guesses" at the runtime path into Wine's configure script, but that brings us to the second problem: there's no way to verify the presence of runtime DLLs. We *are* the loader and lower-level APIs and would have to bootstrap ourselves first, and this is pretty much infeasible. What does that variance between distros look like? Why can't we (or others) standardize a location? Fedora/RHEL and Debian/Ubuntu are upstreams for a majority of distributions. If we create a standard they'll fall in line. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/31/22 9:15 AM, Michael Cronenworth wrote: I think this will get us a working build for x86 and ARM arches. Almost. x86 and ARM64 build now. ARM 32-bit has a few issues that neither upstream nor I have time to address. I may end up dropping ARM 32-bit from current Fedora releases seeing it is going away anyway. Building with gcc: https://koji.fedoraproject.org/koji/taskinfo?taskID=85021941 https://bugs.winehq.org/show_bug.cgi?id=52708 Building with clang: https://koji.fedoraproject.org/koji/getfile?taskID=85059169=DEFAULT=build.log=-4000 ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/31/22 9:15 AM, Michael Cronenworth wrote: I think this will get us a working build for x86 and ARM arches. Almost. x86 and ARM64 build now. ARM 32-bit has a few issues that neither upstream nor I have time to address. I may end up dropping ARM 32-bit from current Fedora releases seeing it is going away anyway. Building with gcc: https://koji.fedoraproject.org/koji/taskinfo?taskID=85021941 https://bugs.winehq.org/show_bug.cgi?id=52708 Building with clang: https://koji.fedoraproject.org/koji/getfile?taskID=85059169=DEFAULT=build.log=-4000 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/31/22 7:43 AM, Mamoru TASAKA wrote: Actually it seems --target=foo, not -target foo Both argument types work. I had just ignored the "ignoring..." text. I'll have to use the bundled libs on only ARM arches. We don't have MinGW for ARM in Fedora. I think this will get us a working build for x86 and ARM arches. ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/31/22 7:43 AM, Mamoru TASAKA wrote: Actually it seems --target=foo, not -target foo Both argument types work. I had just ignored the "ignoring..." text. I'll have to use the bundled libs on only ARM arches. We don't have MinGW for ARM in Fedora. I think this will get us a working build for x86 and ARM arches. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 11:04 PM, Tom Stellard wrote: $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed This path is the Fedora MinGW path: /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v Try using -target x86_64-w64-mingw32 to match gcc. Doesn't help. $ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list. The "/usr/include" path is a terrible choice. Time to open a bug report? ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 11:04 PM, Tom Stellard wrote: $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed This path is the Fedora MinGW path: /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v Try using -target x86_64-w64-mingw32 to match gcc. Doesn't help. $ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list. The "/usr/include" path is a terrible choice. Time to open a bug report? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:33 PM, Tom Stellard wrote: Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system? You may have looked at an older build as that is pointing to the bundled MinGW zlib. My latest build points to the Fedora mingw-zlib package instead. The zlib.h file lives in the root /$MINGW_ROOT/usr/include path. MinGW gcc knows to look there first without needing an extra "-I" parameter. $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include End of search list. ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:33 PM, Tom Stellard wrote: Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system? You may have looked at an older build as that is pointing to the bundled MinGW zlib. My latest build points to the Fedora mingw-zlib package instead. The zlib.h file lives in the root /$MINGW_ROOT/usr/include path. MinGW gcc knows to look there first without needing an extra "-I" parameter. $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include End of search list. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 11:36 AM, Mamoru TASAKA wrote: ar is failing so the fault is in binutils at the first look. By the way: - First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed (i.e. are static archives needed in wine binary rpm)? If not, just remove static archives. Wine offers the ability to compile against it to develop "wine" programs. - If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so as a workaround, I think - adding "%global _lto_cflags %nil" This was already added a few years ago. - and adding "%global __brp_llvm_compile_lto_elf %nil" should work here. Thanks. Added. Now I'm running into another problem[1] with Clang. The MinGW-w64 GCC compiler knows the include search path for MinGW headers. Clang is not finding MinGW headers. Is there a missing environment variable or something that Clang needs to be told where they are? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077 ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 11:36 AM, Mamoru TASAKA wrote: ar is failing so the fault is in binutils at the first look. By the way: - First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed (i.e. are static archives needed in wine binary rpm)? If not, just remove static archives. Wine offers the ability to compile against it to develop "wine" programs. - If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so as a workaround, I think - adding "%global _lto_cflags %nil" This was already added a few years ago. - and adding "%global __brp_llvm_compile_lto_elf %nil" should work here. Thanks. Added. Now I'm running into another problem[1] with Clang. The MinGW-w64 GCC compiler knows the include search path for MinGW headers. Clang is not finding MinGW headers. Is there a missing environment variable or something that Clang needs to be told where they are? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:51 AM, Michael Cronenworth wrote:
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all
targets enabled on Fedora:
https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
https://bugzilla.redhat.com/show_bug.cgi?id=2070151
After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to
resolve the configure test issue.
The build[1] now fails in a post-compile LLVM rpm script.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard -fasynchronous-unwind-tables
-Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld
Checking for LLVM bitcode artifacts
Unpacking ar archive
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a
to check for LLVM bitcode components.
/tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5
Repacking ./dbghelp.dll into
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation
fault (core dumped) ar r ${archive} ${archived_file}
Who is at fault? Binutils? LLVM?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:51 AM, Michael Cronenworth wrote:
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all
targets enabled on Fedora:
https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
https://bugzilla.redhat.com/show_bug.cgi?id=2070151
After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to
resolve the configure test issue.
The build[1] now fails in a post-compile LLVM rpm script.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard -fasynchronous-unwind-tables
-Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld
Checking for LLVM bitcode artifacts
Unpacking ar archive
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a
to check for LLVM bitcode components.
/tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5
Repacking ./dbghelp.dll into
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation
fault (core dumped) ar r ${archive} ${archived_file}
Who is at fault? Binutils? LLVM?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:42 AM, Neal Gompa wrote: That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52 OK, bug filed. https://bugzilla.redhat.com/show_bug.cgi?id=2070151 ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:42 AM, Neal Gompa wrote: That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52 OK, bug filed. https://bugzilla.redhat.com/show_bug.cgi?id=2070151 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 8:26 AM, Neal Gompa wrote: The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this. The configure test in Wine disagrees: checking for clang... clang checking whether clang works... yes checking whether the cross-compiler supports -target aarch64-windows -fuse-ld=lld -Wl,-subsystem:console... no ...snip... configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw. https://koji.fedoraproject.org/koji/buildinfo?buildID=1940475 https://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 7:38 AM, Sandro Mani wrote: Hi What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package. Thanks Sandro It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain. [1] https://github.com/mstorsjo/llvm-mingw [2] https://www.mingw-w64.org/downloads/#llvm-mingw ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/30/22 7:38 AM, Sandro Mani wrote: Hi What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package. Thanks Sandro It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain. [1] https://github.com/mstorsjo/llvm-mingw [2] https://www.mingw-w64.org/downloads/#llvm-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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dropping wine from ARM
Hi, Fedora currently ships Wine 7.3 released February 25th, 2022. Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64 builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does not bundle one and does not allow for an alternative compiler. I will need to drop ARM from Wine in order to continue shipping new updates. I do not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have the time right now to discuss this with upstream. Thanks, Michael ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dropping wine from ARM
Hi, Fedora currently ships Wine 7.3 released February 25th, 2022. Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64 builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does not bundle one and does not allow for an alternative compiler. I will need to drop ARM from Wine in order to continue shipping new updates. I do not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have the time right now to discuss this with upstream. Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linking fails with 32-bit vulkan libs
On 3/14/22 4:55 PM, Sandro Mani wrote: Odd, working fine here, though had to add -lpathcch: i686-w64-mingw32-gcc -o test test.c -lvulkan-1 -lpathcch Adding that didn't help. It also fails on Koji builders when I tried a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=84509668 ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Linking fails with 32-bit vulkan libs
Hi,
In trying to prepare the vkd3d library for cross-compiling I ran into a gcc/linker
error.
Reproducer:
char main(void)
{
char vkGetInstanceProcAddr ();
return vkGetInstanceProcAddr ();
}
$ i686-w64-mingw32-gcc -o test test.c -lvulkan-1
/usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/ld:
/tmp/ccvsAL1c.o:test.c:(.text+0xc): undefined reference to `vkGetInstanceProcAddr'
collect2: error: ld returned 1 exit status
The x86_64 compile works. This is on Rawhide.
mingw32-gcc-11.2.1-7.fc37.x86_64
mingw32-vulkan-loader-1.3.204.0-1.fc37.noarch
mingw64-gcc-11.2.1-7.fc37.x86_64
mingw64-vulkan-loader-1.3.204.0-1.fc37.noarch
Has anyone seen this type of issue?
Thanks,
Michael
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Latest kernel update can cause NFS mount failures
On 3/14/22 12:09 PM, Dusty Mabe wrote: Fortunately this bug was caught in our `testing` stream. Unfortunately, we do need to proceed promoting this kernel into our `stable` stream because the update will fix CVE-2022-0847 (known as "dirty pipe"). This CVE should have been fixed in 5.16.11. https://bugzilla.redhat.com/show_bug.cgi?id=2060795#c16 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? Upstream wine has begun to depend on .dll files. Wine 7.3 bundles vkd3d[1][2], but will also look for it if provided with a location for the .dll files. Currently, Wine 7.2 and lower look for the native vkd3d files. [1] https://source.winehq.org/git/vkd3d.git/ [2] https://src.fedoraproject.org/rpms/vkd3d ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? Upstream wine has begun to depend on .dll files. Wine 7.3 bundles vkd3d[1][2], but will also look for it if provided with a location for the .dll files. Currently, Wine 7.2 and lower look for the native vkd3d files. [1] https://source.winehq.org/git/vkd3d.git/ [2] https://src.fedoraproject.org/rpms/vkd3d ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 3/8/22 4:08 PM, Kevin Fenzi wrote: Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64? Yes, wine.i686 is still important in the year 2022. While I don't have a comprehensive list of all use cases stashed somewhere one area I can think of is the fact that Windows application installers may be 32-bit yet carry 64-bit binaries. Examples: 7Zip, Firefox, VirtualBox - Download the .exe files and run "file" on them. There could also be a game or two that is still 32-bit only. I believe most are transitioning to 64-bit, but I remember a few times with Blizzard games (Starcraft 2, Diablo 3) where the 64-bit binary doesn't work under Wine and the 32-bit version works. I haven't checked lately, but the Windows Steam client may also be 32-bit only. The Linux client is 32-bit. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 3/7/22 2:03 PM, Neal Gompa wrote: A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf If Fedora wants to adopt "default i686 off" I am OK with that. I will gladly add an "IncludeArch" or whatever macro to wine, mingw-wine-gecko, wine-mono, wine-dxvk, and vkd3d to keep building Wine on Fedora. Yes, it is more than just the 'wine' package that is affected by this. P.S. (this is directed at the mailing list): I have built wine for years. I've submitted wine patches. I engage with upstream. Please engage *me* when it comes to changes affecting wine. I'll be happy to answer questions and work with any changes required. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora_36_Mass_Rebuild results
On 2/19/22 3:17 AM, Leigh Scott wrote: I have done the changes needed so kodi can build on f36+ https://pkgs.rpmfusion.org/cgit/free/kodi.git/commit/?id=a3ea17aead50b566f627e6b58d83415b45c8cdcc Thanks, Leigh. It looks like kodi is really lagging behind on ffmpeg support. https://github.com/xbmc/xbmc/commit/9796ac2795da7234e3144f3c88becc8d9ddf68a2 Not surprising when they are either Windows or Ubuntu developers. :) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Fedora_36_Mass_Rebuild results
On 2/10/22 5:33 AM, Sérgio Basto wrote: meanwhile mass rebuild was done You skipped kodi, which is currently built against ffmpeg-4.4. Do you need me to kick off a rebuild or are you still working towards it? ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On 2/4/22 7:20 AM, Marc-André Lureau wrote: But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko. I saw a reference[1] to a 32-bit UCRT build so it may be possible to switch over, but it may require some work. [1] https://github.com/msys2/MINGW-packages/issues/6901 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ucrt plans ?
On 1/14/22 8:03 AM, Sandro Mani wrote: If memory serves me right, there were still some use-cases for mingw32, perhaps mingw-gecko/wine? Michael can you add more maybe? Sorry for the late reply. Yes, mingw32 would still be needed to build wine-gecko. ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPM Fusion update report 2022-01-09
On 1/9/22 9:36 AM, nore...@rpmfusion.org wrote: RPM Fusion update report ... mpv-0.34.1-1.fc35 What happened to this update? This fixes the OpenGL context that is opened, which allows hdr-compute-peak to work. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/7/22 2:41 AM, Zbigniew Jędrzejewski-Szmek wrote: Would the RA support in systemd-networkd work for your case? I don't know much more about than that various improvements have been done recently with renewing and propagating of the ipv6 routing info, and would be very interested if it's enough to serve your usecase. https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv6AcceptRA= https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv6SendRA= https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BIPv6SendRA%5D%20Section%20Options https://www.freedesktop.org/software/systemd/man/systemd.network.html#Examples After a quick glance it looks like that would work. Thanks! I'll try it out next time I have some downtime. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/6/22 7:53 AM, Chris Adams wrote: ifcfg scripts don't run an RA server. You can set signaling radvd, which can also be done with NM dispatcher scripts (which would be much more flexible, since it wouldn't be hard-coded to just radvd like the ifcfg scripts). Do you use this in real-life? How do you get the PD address into the radvd config using NM dispatcher? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 5:21 PM, Neal Gompa wrote: I am, however, curious what functionality exists in network-scripts that doesn't in NetworkManager, since most of the newer networking features were only implemented in ifcfg-rh on NetworkManager. One case is a reliable IPv6 RA server. The last time I tried to use it it works for initial assignment but never renews addresses so devices fall off the network after their address expires. [1] [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/475 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote: I'd say we want to get rid of both;) There are use-cases that NetworkManager just doesn't support that network-scripts does. If network-scripts is orphaned I'll probably pick it up. I have raised the use cases with upstream, but they haven't had time to address them. I suspect they won't unless I pony up patches, which I cannot commit the time. There's nothing inherently wrong with network-scripts. They call the latest and greatest network command tools. I'd love to switch to NetworkManager, but we're not there yet. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
On 12/17/21 8:11 PM, Michael Berteaux wrote: On top of what others said, I add that there is also the nvidia-settings GUI that does not work on Wayland. I don't use it personally, but other people can use, for example, application/game profiles. It is also something to consider... The nvidia-settings app requires some support from NVIDIA to work under Wayland. There is nothing Fedora can do to make it work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On 12/2/21 6:46 PM, Michael Cronenworth wrote: Could this be directly added to rpm instead of an external tool set? I see you did. It helps to read the Change link... Sorry. :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On 12/2/21 4:32 PM, Davide Cavalca via devel wrote: There's support in robosignatory to ask to sign files (used for the short lived IMA stuff), but I suspect it would need a new ability for this. Finally who is going to write this? Change owners? Or do you expect robosignatory maintainers to do so? Thanks for clarifying! Yes, I think robosignatory is likely what we want here. We (the Change owners) expect to do the work, though we'll likely need some advice/help around code review, testing and deployment. Could this be directly added to rpm instead of an external tool set? rpm --addsign ./$RPM to rpm --addsign --addfsverity ./$RPM I'm thinking about those who might also want to use it... end-users and third-party repos such as RPMFusion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
On 11/17/21 8:26 AM, PGNet Dev wrote: On 11/16/21 22:48, Michael Cronenworth wrote: On 11/15/21 12:03 PM, PGNet Dev wrote: launch @ shell VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox I think you mean: LIBVA_DRIVER_NAME=nvidia firefox nope. Take a closer look at all of those links you threw at me. :) VDPAU is not VA-API. Setting VDPAU_DRIVER means nothing to Firefox because it is not using VDPAU. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
On 11/15/21 12:03 PM, PGNet Dev wrote: launch @ shell VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox I think you mean: LIBVA_DRIVER_NAME=nvidia firefox I gave this a shot today, but running a video crashes the tab. Yes, we are almost there, but the VA-API / VDPAU driver has not seen that much love. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
