Re: Wine MinGW system libraries
On Mon, Sep 6, 2021 at 8:21 PM Zebediah Figura wrote: > > On 9/6/21 6:31 PM, Neal Gompa wrote: > > On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura > > wrote: > >> > >> Thanks everyone for their input. > >> > >> There seems to be a consensus that Fedora would prefer that we use their > >> MinGW dynamic libraries. However, this leaves a couple of questions: > >> > >> * As I described in [1], we *may* be able to hack things in the Wine > >> loader such that we can use unmodified dynamic libraries. However, it's > >> not fully clear yet that it's feasible. If it turns out to be > >> infeasible, what preferences does Fedora have? (Renamed dynamic > >> libraries shipped separately, shipped as part of Wine, static libraries, > >> etc...) > >> > > > > Would it be possible to use the MinGW static libraries to generate new > > Wine dynamic libraries? > > Yes, although I think this ends up being worse than renaming them. You'd > have to write some nontrivial linker scripts. > Also, most Fedora variants (especially the ones that Wine would be typically installed on) use Btrfs, which supports reflinks. I know that there is a patch set for implementing usage of reflinks for populating the Wine prefix used for running applications[1]. That patch set would probably help considerably for space efficiency of Wine installations on Fedora. Reflinks plus the renaming of libraries would probably mean we'd pay almost zero additional cost on-disk for the files for each Wine prefix. There's related work to also support reflinks in DNF and RPM directly[2], which should also help for deduplicating on upgrades and such (I imagine there's still some logic that needs to be done for the individual wine prefixes...). [1]: https://www.winehq.org/pipermail/wine-devel/2021-August/193357.html [2]: https://fedoraproject.org/wiki/Changes/RPMCoW -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Wine MinGW system libraries
On 9/6/21 6:31 PM, Neal Gompa wrote: On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura wrote: Thanks everyone for their input. There seems to be a consensus that Fedora would prefer that we use their MinGW dynamic libraries. However, this leaves a couple of questions: * As I described in [1], we *may* be able to hack things in the Wine loader such that we can use unmodified dynamic libraries. However, it's not fully clear yet that it's feasible. If it turns out to be infeasible, what preferences does Fedora have? (Renamed dynamic libraries shipped separately, shipped as part of Wine, static libraries, etc...) Would it be possible to use the MinGW static libraries to generate new Wine dynamic libraries? Yes, although I think this ends up being worse than renaming them. You'd have to write some nontrivial linker scripts. * Since most other distributions don't ship any mingw libraries (yet), and since Fedora doesn't ship all of the libraries we need yet either, we will probably need to include code in wine to fall back to imported sources or submodules. Is this acceptable to be used in Fedora, at least on a temporary basis? Yes, we have a policy that allows bundling for these circumstances, they just have to be declared: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling In the Fedora case, we'd simply force Wine to build using our system libraries. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Wine MinGW system libraries
On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura wrote: > > Thanks everyone for their input. > > There seems to be a consensus that Fedora would prefer that we use their > MinGW dynamic libraries. However, this leaves a couple of questions: > > * As I described in [1], we *may* be able to hack things in the Wine > loader such that we can use unmodified dynamic libraries. However, it's > not fully clear yet that it's feasible. If it turns out to be > infeasible, what preferences does Fedora have? (Renamed dynamic > libraries shipped separately, shipped as part of Wine, static libraries, > etc...) > Would it be possible to use the MinGW static libraries to generate new Wine dynamic libraries? > * Since most other distributions don't ship any mingw libraries (yet), > and since Fedora doesn't ship all of the libraries we need yet either, > we will probably need to include code in wine to fall back to imported > sources or submodules. Is this acceptable to be used in Fedora, at least > on a temporary basis? > Yes, we have a policy that allows bundling for these circumstances, they just have to be declared: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling In the Fedora case, we'd simply force Wine to build using our system libraries. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Wine MinGW system libraries
Thanks everyone for their input. There seems to be a consensus that Fedora would prefer that we use their MinGW dynamic libraries. However, this leaves a couple of questions: * As I described in [1], we *may* be able to hack things in the Wine loader such that we can use unmodified dynamic libraries. However, it's not fully clear yet that it's feasible. If it turns out to be infeasible, what preferences does Fedora have? (Renamed dynamic libraries shipped separately, shipped as part of Wine, static libraries, etc...) * Since most other distributions don't ship any mingw libraries (yet), and since Fedora doesn't ship all of the libraries we need yet either, we will probably need to include code in wine to fall back to imported sources or submodules. Is this acceptable to be used in Fedora, at least on a temporary basis? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LHHKBQMCAA4X3MVSVPJW5V7M6F5OQD27/ ___ 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: Boot menu always displayed again?
On 06/09/2021 17:13, Vít Ondruch wrote: Not sure if that is intentional, but if I am not mistaken, boot menu used to be hidden if there were no issues, but it seems to be always on ATM. Is this intentional? Btw, /boot on BTRFS with GRUB menu hiding will cause breakages with an "sparse file not allowed" error. Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1955901 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Boot menu always displayed again?
On Mon, Sep 6 2021 at 05:13:59 PM +0200, Vít Ondruch wrote: Is this intentional? No, please report a bug. Thanks. ___ 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
Fedora-35-20210906.n.0 compose check report
No missing expected images. Failed openQA tests: 16/205 (x86_64), 8/141 (aarch64) New failures (same test not failed in Fedora-35-20210904.n.0): ID: 970194 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/970194 ID: 970288 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/970288 ID: 970391 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/970391 ID: 970393 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/970393 ID: 970429 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/970429 ID: 970453 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/970453 ID: 970468 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/970468 ID: 970478 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/970478 ID: 970498 Test: aarch64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/970498 Old failures (same test failed in Fedora-35-20210904.n.0): ID: 970203 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/970203 ID: 970205 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/970205 ID: 970217 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/970217 ID: 970235 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/970235 ID: 970237 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/970237 ID: 970239 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/970239 ID: 970275 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/970275 ID: 970279 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/970279 ID: 970280 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/970280 ID: 970329 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/970329 ID: 970348 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/970348 ID: 970362 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/970362 ID: 970381 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/970381 ID: 970461 Test: x86_64 universal memtest URL: https://openqa.fedoraproject.org/tests/970461 ID: 970480 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/970480 Soft failed openQA tests: 22/205 (x86_64), 18/141 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-35-20210904.n.0): ID: 970416 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/970416 ID: 970441 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/970441 ID: 970451 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/970451 ID: 970487 Test: aarch64 universal upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/970487 ID: 970490 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/970490 ID: 970502 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/970502 ID: 970513 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/970513 Old soft failures (same test soft failed in Fedora-35-20210904.n.0): ID: 970184 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/970184 ID: 970185 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/970185 ID: 970186 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/970186 ID: 970199 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/970199 ID: 970236 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/970236 ID: 970244 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/970244 ID: 970250 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/970
Boot menu always displayed again?
Not sure if that is intentional, but if I am not mistaken, boot menu used to be hidden if there were no issues, but it seems to be always on ATM. Is this intentional? Vít ___ 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
No FESCo Meeting today (2021-09-06)
There is nothing on the agenda, so I'm canceling this week's meeting. I'll pick this up again next week if we have anything. = Discussed and Acted in the Ticket = #2656 Nonresponsive maintainer: Shawn Iwinski / siwinski https://pagure.io/fesco/issue/2656 -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: F35 3x slower boot than F34
Hi, On 05. 09. 21 15:29, Sam Varshavchik wrote: Vitaly Zaitsev via devel writes: On 05/09/2021 14:52, Sam Varshavchik wrote: if only a great, overwhelming majority of Fedora package maintainers were able to write policies for their own packages and maintain it themselves because SELinux documentation was ample and easy to fllow https://pagure.io/packaging-committee/issue/726 https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft Which parts of the above describe, and explain, how to write the SELinux policy itself? Once it's written that's a great piece of documentation to follow, to explain how to package this policy. But this is putting the cart before the horse. The package maintainers have to actually understand how to write SELinux policies, first. Yes, this is a valid point and we should definitely do something about it. There is quite a few sources and tools (arguably often not properly publicly documented) a policy developer can use. But we could use a single go-to place, that would get a new policy writer/maintainer started. SELinux notebook - https://github.com/SELinuxProject/selinux-notebook/ - something like the "Maximum RPM" you mentioned SELinux Project wiki - http://selinuxproject.org/page/Main_Page Tools: * sepolicy-generate - generates an initial SELinux policy module template * audit2allow - generates policy rules, or even interface calls covering given AVC messages * macro-expander - expands given macro/interface call into a list of policy rules - https://lukas-vrabec.com/index.php/2019/02/03/new-trick-macro-expander/ Again, I realize these can be hard to find/understand, which is why I appreciate this feedback and I'll do my best to act on it (we already discussed this within SELinux team and came up with some action items). The packaging guidelines draft referenced above is based on https://fedoraproject.org/wiki/SELinux/IndependentPolicy. This guideline is part of Decentralized SELinux Policy project, designed to help developers "adopt" a policy their package is using. As was already discussed in this thread, a few packages are already part of this project and more are on the way. Sincerely, Vit The problem isn't the technical details of how to package an SELinux policy with the packge. The problem is the domain knowledge needed to write that SELinux policy in the first place. It's siloed mostly in the selinux package itself. I assert that the documentation above is not going to be useful to 95% of the package maintainers. A few of them will know how to write a policy, and then follow the above wiki. The rest will not. Prove me wrong. I posted this link before: https://raw.githubusercontent.com/svarshavchik/libcxx/master/packaging/fedora/libcxx.te Where is the documentation that explains /all/ of the above, and what it means? I wrote that policy, of course, but even now, just a short time later, I can't for the life of me tell you where all that documentation is. Because there isn't, I had to figure out based on scraps of other selinux policies that I looked at, and based on my experience with other stuff that did NOT involve SELinux. You will not find any documentation that explains /all/ of that on https://selinuxproject.org And at most 5% of the above is explained in https://selinuxproject.org/page/RefpolicyWriteModule And until the state of the world is such that SELinux is not a siloed domain, that it's amply documented, and package maintainers have documentation that they can use to write their own policy, for the package that they fully understand and support, SELinux will continue to break random stuff, over and over again. ___ 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 ___ 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
Fedora 35 compose report: 20210906.n.0 changes
OLD: Fedora-35-20210904.n.0 NEW: Fedora-35-20210906.n.0 = SUMMARY = Added images:4 Dropped images: 6 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-35-20210906.n.0.iso Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20210906.n.0.x86_64.vagrant-libvirt.box Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20210906.n.0.x86_64.vagrant-virtualbox.box Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-35-20210906.n.0.iso = DROPPED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-35-20210904.n.0.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-35-20210904.n.0.iso Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-35-20210904.n.0.x86_64.tar.gz Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-35-20210904.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-35-20210904.n.0.iso Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-35-20210904.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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: Unannounced soname bump in gtest (1.10.0 -> 1.11.0)
The update was unpushed on everything but Rawhide.
Many (but not quite all) of these packages will use gtest-devel only to
build test executables and have no runtime/install-time dependency on
it. In my opinion, those can probably get by without rebuilding if desired.
- Ben Beasley
On 9/6/21 6:18 AM, Sérgio Basto wrote:
On Mon, 2021-09-06 at 07:23 +0100, Ankur Sinha wrote:
Hi folks,
We seem to have missed an announcement about the soname bump in gtest
from 1.10.0 to 1.11.0:
https://src.fedoraproject.org/rpms/gtest/c/b290e7d10ed5fd24b4e1e45f46ad4c15848c18a5?branch=rawhide
We ran into this because it broke python-steps for us, may affect other
packages too:
https://bugzilla.redhat.com/show_bug.cgi?id=2001356
ah is was unpushed on F34 and F34
https://bodhi.fedoraproject.org/updates/?packages=gtest
A lot of packages to rebuild
dnf repoquery --disablerepo='*' --enablerepo={rpmfusion-{non,}free-,}rawhide-source
--arch=src --whatrequires gtest-devel --qf "%{reponame} %{name}-%{version}" -q
rawhide-source InsightToolkit-4.13.3
rawhide-source Macaulay2-1.18
rawhide-source PDAL-2.3.0
rawhide-source abseil-cpp-20210324.2
rawhide-source android-tools-31.0.2
rawhide-source apitrace-10.0
rawhide-source apt-2.3.8
rawhide-source arbor-0.3
rawhide-source assimp-5.0.1
rawhide-source barrier-2.3.3
rawhide-source beanstalk-client-1.4.0
rawhide-source bloaty-1.1
rawhide-source cctz-2.3
rawhide-source ceph-16.2.5
rawhide-source cpp-httplib-0.9.3
rawhide-source deepin-dock-5.3.64
rawhide-source deepin-editor-5.9.0.24
rawhide-source deepin-launcher-5.3.0.45
rawhide-source deepin-network-utils-5.3.0.8
rawhide-source deepin-session-ui-5.3.35
rawhide-source deepin-terminal-5.4.0.6
rawhide-source dosbox-staging-0.77.0
rawhide-source dwgrep-0.4
rawhide-source elements-5.12
rawhide-source fawkes-1.3.1
rawhide-source fcitx5-mozc-2.17.2102.102.1
rawhide-source flann-1.9.1
rawhide-source gazebo-10.1.0
rawhide-source gfal2-2.19.2
rawhide-source gnucash-4.6
rawhide-source google-benchmark-1.5.6
rawhide-source google-cpu_features-0.6.0
rawhide-source gstreamermm-1.10.0
rawhide-source gumbo-parser-0.10.1
rawhide-source highway-0.14.1
rawhide-source jsonnet-0.17.0
rawhide-source kiwix-lib-9.4.1
rawhide-source klee-2.2
rawhide-source lib3mf-2.0.1
rawhide-source libecpint-1.0.6
rawhide-source libkml-1.3.0
rawhide-source libphonenumber-8.12.11
rawhide-source librime-1.7.2
rawhide-source libyuv-0
rawhide-source luminance-hdr-2.6.1.1
rawhide-source mathic-1.0
rawhide-source mathicgb-1.0
rawhide-source memtailor-1.0
rawhide-source mkvtoolnix-59.0.0
rawhide-source movit-1.6.3
rawhide-source msgpack-3.1.0
rawhide-source nativejit-0.1
rawhide-source ninja-build-1.10.2
rawhide-source oomd-0.5.0
rawhide-source openclonk-8.1
rawhide-source pcl-1.12.0
rawhide-source petpvc-1.2.4
rawhide-source phd2-2.6.10
rawhide-source pmemkv-1.5.0
rawhide-source proj-8.1.1
rawhide-source prusa-slicer-2.3.1
rawhide-source python-cartopy-0.19.0
rawhide-source python-html5-parser-0.4.9
rawhide-source python-steps-3.6.0
rawhide-source rapidjson-1.1.0
rawhide-source rlottie-0.2
rawhide-source root-6.22.08
rawhide-source sdformat-6.0.0
rawhide-source seqan3-3.1.0
rawhide-source sipp-3.6.0
rawhide-source snappy-1.1.9
rawhide-source sqlitecpp-3.1.1
rawhide-source srt-1.4.3
rawhide-source synergy-1.13.1.41
rawhide-source tiny-dnn-1.0.0
rawhide-source uriparser-0.9.5
rawhide-source wabt-1.0.24
rawhide-source wdt-1.32.1910230
rawhide-source wlcs-1.3.0
rawhide-source xeus-1.0.4
rawhide-source xsimd-7.6.0
rawhide-source xtensor-0.23.1
rawhide-source xtensor-python-0.24.1
rawhide-source xtl-0.7.2
rawhide-source zimlib-6.3.0
rawhide-source zstd-1.5.0
rpmfusion-free-rawhide-source kodi-19.1
rpmfusion-free-rawhide-source kodi-inputstream-adaptive-2.6.17
dnf repoquery --disablerepo='*' --enablerepo={rpmfusion-{non,}free-,}rawhide-source
--arch=src --whatrequires gmock-devel --qf "%{reponame} %{name}-%{version}" -q
rawhide-source abseil-cpp-20210324.2
rawhide-source bear-3.0.14
rawhide-source bloaty-1.1
rawhide-source cctz-2.3
rawhide-source ceph-16.2.5
rawhide-source deepin-editor-5.9.0.24
rawhide-source deepin-terminal-5.4.0.6
rawhide-source elements-5.12
rawhide-source gnucash-4.6
rawhide-source google-benchmark-1.5.6
rawhide-source google-cpu_features-0.6.0
rawhide-source intel-mediasdk-21.2.3
rawhide-source oomd-0.5.0
rawhide-source plug-1.4.2
rawhide-source proj-8.1.1
rawhide-source python-cartopy-0.19.0
rawhide-source root-6.22.08
rawhide-source sipp-3.6.0
rawhide-source sqlitecpp-3.1.1
rawhide-source srt-1.4.3
rawhide-source synergy-1.13.1.41
rawhide-source tiny-dnn-1.0.0
rawhide-source wlcs-1.3.0
___
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.fedoraproj
Re: Unannounced soname bump in gtest (1.10.0 -> 1.11.0)
On Mon, 2021-09-06 at 07:23 +0100, Ankur Sinha wrote:
> Hi folks,
>
> We seem to have missed an announcement about the soname bump in gtest
> from 1.10.0 to 1.11.0:
> https://src.fedoraproject.org/rpms/gtest/c/b290e7d10ed5fd24b4e1e45f46ad4c15848c18a5?branch=rawhide
>
> We ran into this because it broke python-steps for us, may affect other
> packages too:
> https://bugzilla.redhat.com/show_bug.cgi?id=2001356
>
ah is was unpushed on F34 and F34
https://bodhi.fedoraproject.org/updates/?packages=gtest
A lot of packages to rebuild
dnf repoquery --disablerepo='*'
--enablerepo={rpmfusion-{non,}free-,}rawhide-source --arch=src --whatrequires
gtest-devel --qf "%{reponame} %{name}-%{version}" -q
rawhide-source InsightToolkit-4.13.3
rawhide-source Macaulay2-1.18
rawhide-source PDAL-2.3.0
rawhide-source abseil-cpp-20210324.2
rawhide-source android-tools-31.0.2
rawhide-source apitrace-10.0
rawhide-source apt-2.3.8
rawhide-source arbor-0.3
rawhide-source assimp-5.0.1
rawhide-source barrier-2.3.3
rawhide-source beanstalk-client-1.4.0
rawhide-source bloaty-1.1
rawhide-source cctz-2.3
rawhide-source ceph-16.2.5
rawhide-source cpp-httplib-0.9.3
rawhide-source deepin-dock-5.3.64
rawhide-source deepin-editor-5.9.0.24
rawhide-source deepin-launcher-5.3.0.45
rawhide-source deepin-network-utils-5.3.0.8
rawhide-source deepin-session-ui-5.3.35
rawhide-source deepin-terminal-5.4.0.6
rawhide-source dosbox-staging-0.77.0
rawhide-source dwgrep-0.4
rawhide-source elements-5.12
rawhide-source fawkes-1.3.1
rawhide-source fcitx5-mozc-2.17.2102.102.1
rawhide-source flann-1.9.1
rawhide-source gazebo-10.1.0
rawhide-source gfal2-2.19.2
rawhide-source gnucash-4.6
rawhide-source google-benchmark-1.5.6
rawhide-source google-cpu_features-0.6.0
rawhide-source gstreamermm-1.10.0
rawhide-source gumbo-parser-0.10.1
rawhide-source highway-0.14.1
rawhide-source jsonnet-0.17.0
rawhide-source kiwix-lib-9.4.1
rawhide-source klee-2.2
rawhide-source lib3mf-2.0.1
rawhide-source libecpint-1.0.6
rawhide-source libkml-1.3.0
rawhide-source libphonenumber-8.12.11
rawhide-source librime-1.7.2
rawhide-source libyuv-0
rawhide-source luminance-hdr-2.6.1.1
rawhide-source mathic-1.0
rawhide-source mathicgb-1.0
rawhide-source memtailor-1.0
rawhide-source mkvtoolnix-59.0.0
rawhide-source movit-1.6.3
rawhide-source msgpack-3.1.0
rawhide-source nativejit-0.1
rawhide-source ninja-build-1.10.2
rawhide-source oomd-0.5.0
rawhide-source openclonk-8.1
rawhide-source pcl-1.12.0
rawhide-source petpvc-1.2.4
rawhide-source phd2-2.6.10
rawhide-source pmemkv-1.5.0
rawhide-source proj-8.1.1
rawhide-source prusa-slicer-2.3.1
rawhide-source python-cartopy-0.19.0
rawhide-source python-html5-parser-0.4.9
rawhide-source python-steps-3.6.0
rawhide-source rapidjson-1.1.0
rawhide-source rlottie-0.2
rawhide-source root-6.22.08
rawhide-source sdformat-6.0.0
rawhide-source seqan3-3.1.0
rawhide-source sipp-3.6.0
rawhide-source snappy-1.1.9
rawhide-source sqlitecpp-3.1.1
rawhide-source srt-1.4.3
rawhide-source synergy-1.13.1.41
rawhide-source tiny-dnn-1.0.0
rawhide-source uriparser-0.9.5
rawhide-source wabt-1.0.24
rawhide-source wdt-1.32.1910230
rawhide-source wlcs-1.3.0
rawhide-source xeus-1.0.4
rawhide-source xsimd-7.6.0
rawhide-source xtensor-0.23.1
rawhide-source xtensor-python-0.24.1
rawhide-source xtl-0.7.2
rawhide-source zimlib-6.3.0
rawhide-source zstd-1.5.0
rpmfusion-free-rawhide-source kodi-19.1
rpmfusion-free-rawhide-source kodi-inputstream-adaptive-2.6.17
dnf repoquery --disablerepo='*'
--enablerepo={rpmfusion-{non,}free-,}rawhide-source --arch=src --whatrequires
gmock-devel --qf "%{reponame} %{name}-%{version}" -q
rawhide-source abseil-cpp-20210324.2
rawhide-source bear-3.0.14
rawhide-source bloaty-1.1
rawhide-source cctz-2.3
rawhide-source ceph-16.2.5
rawhide-source deepin-editor-5.9.0.24
rawhide-source deepin-terminal-5.4.0.6
rawhide-source elements-5.12
rawhide-source gnucash-4.6
rawhide-source google-benchmark-1.5.6
rawhide-source google-cpu_features-0.6.0
rawhide-source intel-mediasdk-21.2.3
rawhide-source oomd-0.5.0
rawhide-source plug-1.4.2
rawhide-source proj-8.1.1
rawhide-source python-cartopy-0.19.0
rawhide-source root-6.22.08
rawhide-source sipp-3.6.0
rawhide-source sqlitecpp-3.1.1
rawhide-source srt-1.4.3
rawhide-source synergy-1.13.1.41
rawhide-source tiny-dnn-1.0.0
rawhide-source wlcs-1.3.0
--
Sérgio M. B.
___
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: F35 3x slower boot than F34
On Fri, 2021-09-03 at 15:57 -0600, Chris Murphy wrote:
> On Fri, Sep 3, 2021 at 1:32 PM Stephen Gallagher wrote:
>
> > So it appears to be an SELinux issue. I suspect but cannot prove that
> > it's related to a number of AVCs related to DBUS that I see in
> > selinux-troubleshooter.
>
> I'm only seeing two AVC's which repeat but not a lot...
>
> Sep 03 14:27:09 fovo.local audit[6300]: AVC avc: denied { write }
> for pid=6300 comm="fprintd" name="wakeup" dev="sysfs" ino=28044
> scontext=system_u:system_r:fprintd_t:s0
> tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0
> Sep 03 14:27:09 fovo.local audit[6300]: AVC avc: denied { write }
> for pid=6300 comm="fprintd" name="persist" dev="sysfs" ino=28037
> scontext=system_u:system_r:fprintd_t:s0
> tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0
>
> But enforcing=0 makes the boot time under 9s which is... awesome.
> Better than 34.
Those fprintd denials shouldn't cause any issues. It just means fprintd
cannot reconfigure the USB devices for its suspend/resume handling. It
would be nice if it worked, but it is *not* a regression if it doesn't
work.
The upstream bug for this is:
https://github.com/fedora-selinux/selinux-policy/issues/840
Benjamin
> I get more AVC's with enforcing=0, in fact... oh my that's a lot of
> selinux bugs reported already against 35
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=selinux-policy&list_id=12120743&product=Fedora&query_format=advanced&version=35
>
> But fprintd doesn't show up in any. So I will change the component to
> selinux-policy.
>
>
>
>
> --
> Chris Murphy
> ___
> 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
signature.asc
Description: This is a digitally signed message part
___
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
Fedora-Cloud-34-20210906.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210905.0): ID: 970096 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/970096 ID: 970102 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/970102 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 3x slower boot than F34
On Mon, 2021-09-06 at 02:08 -0400, Neal Gompa wrote: > On Sun, Sep 5, 2021 at 2:00 PM Neal Gompa wrote: > > > > clearly SELinux as a technology is a problem. > > > > I mean, of course, that it's *not* a problem. Though I guess you > could read the statement as sarcasm? I was about to ask you what you meant here, but I soon realized it was a typo. I don't think anyone have understood it other way. ___ 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: per-package selinux policies [was Re: F35 3x slower boot than F34]
> Am 05.09.2021 um 17:59 schrieb Matthew Miller : > > On Sun, Sep 05, 2021 at 09:19:20AM +0200, Peter Boy wrote: >> I think it is urgent that Fedora Council starts an initiative here (and I >> would not hesitate to contribute, not just ask others to do something). > > To be clear, the request is an initiative to get more per-package SELinux > policies? The first target is SELinux packaging, yes. And it is strategic in nature. Potentially every Fedora package is affected. And the question is whether a structure and strategy that worked effectively at the beginning needs adjustment after years of growth. But it radiates to other parts, especially documentation, at least technically and developmentally. So it may be dichotomous/bifurcated? > I think that's a good goal, but remember the Council can't assign > work. A Council objective generally means that we recognize an initiative > that people are already there to do as something that's strategically > important. This might meet the "strategically important" part, but in order > to be an initiative it needs interested people to drive and implement. > > If we _have_ those people, I'll be happy to support! I was thinking of actions like you successfully did for Fedora Server and Website Revamp. An initiative to mobilize and concentrate scattered and/or idle efforts. ___ 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: can we remove device-mapper-multipath from default desktop installs?
Hi, On 9/6/21 7:57 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Sep 05, 2021 at 04:43:01PM -0600, Chris Murphy wrote: >> On Fri, Sep 3, 2021 at 10:47 AM Chris Murphy wrote: >>> >>> systemd-udev-settle.service is deprecated. Please fix >>> multipathd.service not to pull it in. >>> https://bugzilla.redhat.com/show_bug.cgi?id=2001058 >>> >>> This is not a regression, it's been around for a while with bugs that >>> get no action. I'm wondering if we can just pull it out of the default >>> installations? The only thing I can think of that (conditionally) >>> needs it early on in a default case is Anaconda but only if there are >>> multipath devices, which is probably pretty rare in the Workstation >>> edition and desktop spins case? > > +1 to dropping it. I'm sure it sees very little usage in Fedora > installations. If somebody needs it, they can add it after installation. > >> It's in Fedora 34 and 35: >> https://pagure.io/fedora-comps/blob/main/f/comps-f35.xml.in#_59 >> >> And I think that's why it's being dragged in post-install with regular >> updates, even though it's not on the install media: > > Yes, I think it's only pulled in through comps. It can be uninstalled > without issue. Hmm, I already fixed this for F33: https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD And I just checked and in F34 device-mapper-multipath is still not part of the Workstation livecd. So at least for the livecd, which is the default download, this is already resolved. Regards, 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210906.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210905.0): ID: 969961 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/969961 ID: 969967 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/969967 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
