Fedora rawhide compose report: 20230304.n.0 changes
OLD: Fedora-Rawhide-20230303.n.0 NEW: Fedora-Rawhide-20230304.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 9 Dropped packages:1 Upgraded packages: 168 Downgraded packages: 0 Size of added packages: 8.25 MiB Size of dropped packages:381.11 KiB Size of upgraded packages: 4.59 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 19.04 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230303.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230303.n.0.iso = ADDED PACKAGES = Package: lujavrite-1.0.2-1.fc39 Summary: Lua library for calling Java code RPMs:lujavrite Size:67.29 KiB Package: python-reactivex-4.0.4-1.fc39 Summary: API for asynchronous programming with observable streams RPMs:python3-reactivex Size:480.28 KiB Package: rubygem-sys-filesystem-1.4.3-2.fc39 Summary: Interface for gathering filesystem information RPMs:rubygem-sys-filesystem rubygem-sys-filesystem-doc Size:337.75 KiB Package: rust-faccess-0.2.4-5.fc39 Summary: Simple file accessibility checks RPMs:rust-faccess+default-devel rust-faccess-devel Size:22.09 KiB Package: rust-imagequant-sys-4.0.1-1.fc39 Summary: Convert 24/32-bit images to 8-bit palette with alpha channel RPMs:libimagequant libimagequant-devel rust-imagequant-sys+capi-devel rust-imagequant-sys+default-devel rust-imagequant-sys+threads-devel rust-imagequant-sys-devel Size:1.66 MiB Package: rust-servo-fontconfig-sys-5.1.0-7.fc39 Summary: Font configuration and customization library RPMs:rust-servo-fontconfig-sys+default-devel rust-servo-fontconfig-sys+force_system_lib-devel rust-servo-fontconfig-sys-devel Size:1.47 MiB Package: rust-test-case-macros-2.2.2-1.fc39 Summary: Procedural macro attribute for generating parametrized test cases RPMs:rust-test-case-macros+default-devel rust-test-case-macros+with-regex-devel rust-test-case-macros-devel Size:33.78 KiB Package: rust-test-case1-1.2.3-1.fc39 Summary: Procedural macro attribute for generating parametrized test cases RPMs:rust-test-case1+allow_result-devel rust-test-case1+default-devel rust-test-case1+hamcrest_assertions-devel rust-test-case1-devel Size:42.81 KiB Package: tss2-1:1.6.0-6.fc39 Summary: IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities RPMs:tss2 tss2-devel Size:4.16 MiB = DROPPED PACKAGES = Package: libimagequant-2.17.0-4.fc38 Summary: Palette quantization library RPMs:libimagequant libimagequant-devel Size:381.11 KiB = UPGRADED PACKAGES = Package: Box2D-2.4.1-10.fc39 Old package: Box2D-2.4.1-9.fc38 Summary: A 2D Physics Engine for Games RPMs: Box2D Box2D-devel Size: 1.70 MiB Size change: -3.32 KiB Changelog: * Fri Mar 03 2023 Gwyn Ciesla - 2.4.1-10 - migrated to SPDX license Package: GeoIP-1.6.12-14.fc39 Old package: GeoIP-1.6.12-13.fc38 Summary: Library for country/city/organization to IP address or hostname mapping RPMs: GeoIP GeoIP-devel Size: 656.92 KiB Size change: 1.37 KiB Changelog: * Fri Mar 03 2023 Paul Howarth - 1.6.12-14 - Use SPDX-format license tag - Package LICENSE file Package: GeoIP-GeoLite-data-2018.06-12.fc39 Old package: GeoIP-GeoLite-data-2018.06-11.fc38 Summary: Free GeoLite IP geolocation country database RPMs: GeoIP-GeoLite-data GeoIP-GeoLite-data-extra Size: 29.74 MiB Size change: -50.46 KiB Changelog: * Fri Mar 03 2023 Paul Howarth - 2018.06-12 - Use SPDX-format license tag Package: R-dbplyr-2.3.1-1.fc39 Old package: R-dbplyr-2.3.0-1.fc38 Summary: A 'dplyr' Back End for Databases RPMs: R-dbplyr Size: 1.17 MiB Size change: 42.62 KiB Changelog: * Fri Mar 03 2023 Tom Callaway - 2.3.1-1 - update to 2.3.1 Package: R-dtplyr-1.3.0-1.fc39 Old package: R-dtplyr-1.2.2-2.fc38 Summary: Data Table Back-End for 'dplyr' RPMs: R-dtplyr Size: 394.27 KiB Size change: 27.71 KiB Changelog: * Fri Mar 03 2023 Tom Callaway - 1.3.0-1 - update to 1.3.0 Package: R-fastmap-1.1.1-1.fc39 Old package: R-fastmap-1.1.0-7.fc38 Summary: Fast Data Structures RPMs: R-fastmap Size: 337.16 KiB Size change: 14.25 KiB Changelog: * Fri Mar 03 2023 Tom Callaway - 1.1.1-1 - update to 1.1.1 Package: R-haven-2.5.2-2.fc39 Old package: R-haven-2.5.1-2.fc38 Summary: Import and Export 'SPSS', 'Stata' and 'SAS' Files RPMs: R-haven Size: 1.59 MiB Size change: 23.25 KiB Changelog: * Fri Mar 03 2023 Tom Callaway - 2.5.2-1 - update to 2.5.2 * Fri Mar 03 2023 Tom Callaway - 2.5.2-2 - ppc64le is being weir
Re: Fedora Linux 38 blocker status summary
On Fri, Mar 03, 2023 at 04:02:43PM -0500, Stephen Smoogen wrote: > On Fri, 3 Mar 2023 at 15:56, Ben Cotton wrote: > > 2. crypto-policies — Insecure installed RPMs (like Google Chrome) > > prevent system updates in F38, can't be removed — NEW > > ACTION: Upstream to implement MR #129 > > > > > > 2. crypto-policies — https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > > — NEW > > Insecure installed RPMs (like Google Chrome) prevent system updates in > > F38, can't be removed > > > > Some third-party repos (including Google Chrome) that sign packages > > with SHA-1 cannot be uninstalled, which breaks upgrades. This was > > designated a blocker by FESCo. Work is in progress upstream to allow > > RPM to permit SHA-1 in the default policy while third-party repos > > update to a supported hash function: > > > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 > > I think the issue is 'larger' than SHA-1. Google Chrome and some other 3rd > party software seem to be signed with keys which are both SHA1 and DSA > keys. Either one of these would cause the problem with not being able to > update/uninstall/etc and since one is a checksum and the other is an > encryption type need possibly different solutions. Yes. People are aware of this. Merge request 129 had to go as far as allowing DSA1024 :( Zbyszek ___ 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 libunicode and contour-terminal
Hi, I made the two review requests of libunicode and contour-terminal in order to add them to Fedora official repo. Does anyone can help me review the two packages? Any review swap will be fine if I can. Thanks. ref: libunicode: https://bugzilla.redhat.com/show_bug.cgi?id=2174383 contour-terminal: https://bugzilla.redhat.com/show_bug.cgi?id=2174384 ___ 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
Fedora 38 compose report: 20230304.n.0 changes
OLD: Fedora-38-20230303.n.0 NEW: Fedora-38-20230304.n.0 = SUMMARY = Added images:1 Dropped images: 0 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: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-38-20230304.n.0.iso = DROPPED IMAGES = = 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging portmidi versions: devel conflicts OK?
Il 03/03/23 19:00, Michael J Gruber ha scritto:
> SHORT VERSION
>
> The portmidi library in Fedora is at version 217, which is quite old.
> Upstream changed to a new version scheme, currently at 2.0.4, and
> dumped some subpackages. To serve the needs of different other
> packages, it would be easiest for me (as the portmidi maintainer in
> Fedora) and them to:
>
> - create a new package portmidi2
> - avoid any file conflicts between subpackages of portmidi and portmidi2
> except:
> - allow file conflicts between portmidi{,2}-devel (.so, headers)
>
> This would allow to build packages against both versions (just not in
> the same container) by simply requiring the right devel package, and
> the libraries could coexist. Is this allowed by the packaging
> guidelines?
>
What about:
- create a compat-portmidi0 package and move current portmidi there
(bonus: mark it as deprecated)
- change frescobaldi to require the compat package until a fix is available
- update current portmidi package to v2
BTW, this is not the first time such a discussion arise and I think
FESCo / Packaging Guidelines must provide a definitive answer for this.
Mattia
___
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: Packaging portmidi versions: devel conflicts OK?
> Il 03/03/23 19:00, Michael J Gruber ha scritto: > What about: > > - create a compat-portmidi0 package and move current portmidi there > (bonus: mark it as deprecated) > - change frescobaldi to require the compat package until a fix is available > - update current portmidi package to v2 That is possible in the long term, anyway. But it takes time unless you do this on released Fedoras, too. > BTW, this is not the first time such a discussion arise and I think > FESCo / Packaging Guidelines must provide a definitive answer for this. Thanks to Sergio I know a precedent know. I'll take another look at pm2 to see if can somehow avoid the conflicts without creating hardships for depending packages, and otherwise go for the middleground plan which will require a review for te "new" package in any case. ___ 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
Heads-up: flatbuffers 23.3.3 coming to F39/Rawhide and F38/Branched
In one week (2023-03-11), or slightly later, I plan to update flatbuffers to 23.3.3 in F39/Rawhide and F38/Branched[1]. This is an incompatible update because the libraries offer no ABI stability—the .so version is bumped to 23.3.3—and because the --proto option was removed from the flatc compiler. This is now a “semi-leaf” package; hyperhdr BuildRequires flatbuffers-compiler for code generation, but does not link any flatbuffers library at runtime. I have verified that hyperhdr *can* be rebuilt with flatbuffers 23.3.3, but actually rebuilding it is optional. [1] https://src.fedoraproject.org/rpms/flatbuffers/pull-request/6 ___ 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
Firecracker microVM manager
Hi, Firecracker[0] is a minimal virtual machine manager (a la QEMU) written in Rust that uses KVM to start Linux VMs extremely quickly and securely. It is used by AWS Lambda and Fargate among other things to make VM startup time comparable to containers. I've built it for Fedora x86_64 and shared it in a Copr repository[1] which includes some example commands for starting VMs. Making it build for Fedora required changes across a few components, so I'm writing to ask if this is acceptable for inclusion in Fedora. The Copr specs are all dumped in a Git repository[2] for readability. Changes include: - The musl package adds /usr paths for compatibility with the compiler --sysroot option. - The rust compiler adds musl target subpackages. - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be usable as a guest. - About two dozen Rust crates must be added to Fedora (but a handful are just new versions of existing packages). - Unrelated, but in the Copr repo anyway: The musl package is fixed to allow multilib installs, and Rust includes both 32- and 64-bit targets. I used upstream-preferred settings when adding things, but they may be in conflict with Fedora guidelines. Here are some concerns: - Firecracker can be built with Fedora's libc (glibc), but it is officially unsupported upstream[3]. Functionality would be harmed by not using musl, e.g. seccomp filters are not used. - Upstream Rust wants musl targets to be statically linked by default[4]. It can be changed by patching (Gentoo does this) if dynamic linking is still a priority with Rust binaries, but I haven't tested that. - Firecracker uses two crates forked from crates.io, but they are not vendored/bundled nor published to a registry. I'm currently manually bundling them as if they were vendored to avoid package name conflicts since nothing else uses them, but I don't know the preferred way to deal with those. So does any of that sound like a showstopper for being included in Fedora? Is there any other interest in the project from the community? Thanks. David [0] https://firecracker-microvm.github.io/ [1] https://copr.fedorainfracloud.org/coprs/dm0/Firecracker [2] https://github.com/dm0-/copr-firecracker [3] https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/tools/release.sh#L145 [4] https://github.com/rust-lang/rust/blob/1.67.1/compiler/rustc_target/src/spec/linux_musl_base.rs#L13 ___ 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: gnutls time_t breakage on i686
Florian Weimer wrote: > And I thought Wine can run 32-bit Windows applications against 64-bit > system libraries these days? Or at least it's getting there. Then Wine > wouldn't be a reason to keep 32-bit builds around. > > | *** WoW64 > | > | - The 64-bit Windows-on-Windows (WoW64) architecture is implemented, and > | supports running a 32-bit Windows application inside a 64-bit Unix > | host process, using thunks to map 32-bit NT system calls to the 64-bit > | NTDLL. > | > | - WoW64 thunks are implemented for most Unix libraries, enabling a > | 32-bit PE module to call a 64-bit Unix library. Once the remaining > | modules are converted to PE, this will make it possible to run 32-bit > | applications without installing 32-bit Unix libraries. "Once the remaining modules are converted to PE" should be now: https://www.winehq.org/news/2023012401 | Wine 8.0 Released | January 24, 2023 [snip] | The main achievement is the completion of the conversion to PE format. Kevin Kofler ___ 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: Firecracker microVM manager
On Sat, Mar 4, 2023 at 12:41 PM David Michael wrote: > > Hi, > > Firecracker[0] is a minimal virtual machine manager (a la QEMU) > written in Rust that uses KVM to start Linux VMs extremely quickly and > securely. It is used by AWS Lambda and Fargate among other things to > make VM startup time comparable to containers. I've built it for > Fedora x86_64 and shared it in a Copr repository[1] which includes > some example commands for starting VMs. > > Making it build for Fedora required changes across a few components, > so I'm writing to ask if this is acceptable for inclusion in Fedora. > The Copr specs are all dumped in a Git repository[2] for readability. > Changes include: > > - The musl package adds /usr paths for compatibility with the > compiler --sysroot option. As the musl package maintainer, I don't particularly want Fedora packages depending on it unless they absolutely have to. I originally maintained it in Copr, but brought it into Fedora for the Enarx folks. I still maintain that generally you don't want to use this unless you *really* know what you're doing and can deal with the consequences of using an alternative libc. That said, the changes you make are not currently compatible with the packaging guidelines. Can't you just use --prefix /usr/ instead? > - The rust compiler adds musl target subpackages. This will require discussion with the Fedora Rust SIG. > - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be > usable as a guest. This will require talking to the kernel maintainers to add the flag. > - About two dozen Rust crates must be added to Fedora (but a handful > are just new versions of existing packages). > - Unrelated, but in the Copr repo anyway: The musl package is fixed > to allow multilib installs, and Rust includes both 32- and 64-bit > targets. > > I used upstream-preferred settings when adding things, but they may be > in conflict with Fedora guidelines. Here are some concerns: > > - Firecracker can be built with Fedora's libc (glibc), but it is > officially unsupported upstream[3]. Functionality would be harmed by > not using musl, e.g. seccomp filters are not used. Why not drive this to be fixed upstream? Also, openSUSE builds Firecracker against glibc and I see the seccomp stuff is also produced and shipped[1]. I am not sure whether this means openSUSE's package is broken or something else. [1]: https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec > - Upstream Rust wants musl targets to be statically linked by > default[4]. It can be changed by patching (Gentoo does this) if > dynamic linking is still a priority with Rust binaries, but I haven't > tested that. As in musl is statically linked into the binaries? Or the Rust code is statically linked. The former is not okay, the latter is what we do already. > - Firecracker uses two crates forked from crates.io, but they are > not vendored/bundled nor published to a registry. I'm currently > manually bundling them as if they were vendored to avoid package name > conflicts since nothing else uses them, but I don't know the preferred > way to deal with those. > That's probably the right way to deal with it. > So does any of that sound like a showstopper for being included in > Fedora? Is there any other interest in the project from the > community? > It'd be interesting to have in Fedora, for sure, but this should be done as an opportunity to bring our integration concerns upstream. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Firecracker microVM manager
David Michael wrote: > - Firecracker can be built with Fedora's libc (glibc), but it is > officially unsupported upstream[3]. Functionality would be harmed by > not using musl, e.g. seccomp filters are not used. Upstream's refusal to write seccomp filters that work with glibc should be a red flag. It is definitely possible to sandbox glibc applications with seccomp, e.g., Chromium does it. It does need updates/fixes to the seccomp rules with almost every new version of glibc, but it is possible. Kevin Kofler ___ 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: Firecracker microVM manager
On Sat, Mar 4, 2023 at 6:18 PM Kevin Kofler via devel wrote: > > David Michael wrote: > > - Firecracker can be built with Fedora's libc (glibc), but it is > > officially unsupported upstream[3]. Functionality would be harmed by > > not using musl, e.g. seccomp filters are not used. > > Upstream's refusal to write seccomp filters that work with glibc should be a > red flag. It is definitely possible to sandbox glibc applications with > seccomp, e.g., Chromium does it. It does need updates/fixes to the seccomp > rules with almost every new version of glibc, but it is possible. > That is not a glibc specific problem, since glibc API churn is often the result of changes in the kernel UAPI. It happens with musl too, just less frequently. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Firecracker microVM manager
On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa wrote: > On Sat, Mar 4, 2023 at 12:41 PM David Michael wrote: > > Hi, > > > > Firecracker[0] is a minimal virtual machine manager (a la QEMU) > > written in Rust that uses KVM to start Linux VMs extremely quickly and > > securely. It is used by AWS Lambda and Fargate among other things to > > make VM startup time comparable to containers. I've built it for > > Fedora x86_64 and shared it in a Copr repository[1] which includes > > some example commands for starting VMs. > > > > Making it build for Fedora required changes across a few components, > > so I'm writing to ask if this is acceptable for inclusion in Fedora. > > The Copr specs are all dumped in a Git repository[2] for readability. > > Changes include: > > > > - The musl package adds /usr paths for compatibility with the > > compiler --sysroot option. > > As the musl package maintainer, I don't particularly want Fedora > packages depending on it unless they absolutely have to. I originally > maintained it in Copr, but brought it into Fedora for the Enarx folks. > I still maintain that generally you don't want to use this unless you > *really* know what you're doing and can deal with the consequences of > using an alternative libc. It sounds like there are enough issues with musl in Fedora that glibc will have to be used. > That said, the changes you make are not currently compatible with the > packaging guidelines. Can't you just use --prefix /usr/ > instead? It was for using --sysroot directly on gcc calls. > > - The rust compiler adds musl target subpackages. > > This will require discussion with the Fedora Rust SIG. > > > - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be > > usable as a guest. > > This will require talking to the kernel maintainers to add the flag. Okay, I'll ask about getting this applied even if Firecracker is not included in Fedora. It still might be useful to use for a quick guest kernel, and the option is just to support a command-line parameter[0], so it shouldn't be disruptive. [0] https://github.com/torvalds/linux/blob/v6.2/Documentation/admin-guide/kernel-parameters.txt#L6697 > > - About two dozen Rust crates must be added to Fedora (but a handful > > are just new versions of existing packages). > > - Unrelated, but in the Copr repo anyway: The musl package is fixed > > to allow multilib installs, and Rust includes both 32- and 64-bit > > targets. > > > > I used upstream-preferred settings when adding things, but they may be > > in conflict with Fedora guidelines. Here are some concerns: > > > > - Firecracker can be built with Fedora's libc (glibc), but it is > > officially unsupported upstream[3]. Functionality would be harmed by > > not using musl, e.g. seccomp filters are not used. > > Why not drive this to be fixed upstream? Also, openSUSE builds > Firecracker against glibc and I see the seccomp stuff is also produced > and shipped[1]. I am not sure whether this means openSUSE's package is > broken or something else. > > [1]: > https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec I can look into what they're doing more thoroughly later, but I would assume they are just running with the empty seccomp filter. I am aware of two issues with glibc: The jailer program allegedly does not work with non-musl (although it builds) and is disabled upstream[1], and there is no non-musl seccomp filter[2][3]. [1] https://github.com/firecracker-microvm/firecracker/pull/2125 [2] https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/src/vmm/build.rs#L25 [3] https://github.com/firecracker-microvm/firecracker/tree/v1.3.0/resources/seccomp > > - Upstream Rust wants musl targets to be statically linked by > > default[4]. It can be changed by patching (Gentoo does this) if > > dynamic linking is still a priority with Rust binaries, but I haven't > > tested that. > > As in musl is statically linked into the binaries? Or the Rust code is > statically linked. The former is not okay, the latter is what we do > already. The former, the musl targets produce static binaries by default. > > - Firecracker uses two crates forked from crates.io, but they are > > not vendored/bundled nor published to a registry. I'm currently > > manually bundling them as if they were vendored to avoid package name > > conflicts since nothing else uses them, but I don't know the preferred > > way to deal with those. > > > > That's probably the right way to deal with it. > > > So does any of that sound like a showstopper for being included in > > Fedora? Is there any other interest in the project from the > > community? > > > > It'd be interesting to have in Fedora, for sure, but this should be > done as an opportunity to bring our integration concerns upstream. Okay, thanks for all the feedback. I interpret this as essentially requiring the use of the glibc Rust target for inclusion in Fedora, so the changes on the Fedora side would b
Re: Firecracker microVM manager
On Sat, Mar 4, 2023 at 7:31 PM David Michael wrote: > > On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa wrote: > > On Sat, Mar 4, 2023 at 12:41 PM David Michael wrote: > > > Hi, > > > > > > Firecracker[0] is a minimal virtual machine manager (a la QEMU) > > > written in Rust that uses KVM to start Linux VMs extremely quickly and > > > securely. It is used by AWS Lambda and Fargate among other things to > > > make VM startup time comparable to containers. I've built it for > > > Fedora x86_64 and shared it in a Copr repository[1] which includes > > > some example commands for starting VMs. > > > > > > Making it build for Fedora required changes across a few components, > > > so I'm writing to ask if this is acceptable for inclusion in Fedora. > > > The Copr specs are all dumped in a Git repository[2] for readability. > > > Changes include: > > > > > > - The musl package adds /usr paths for compatibility with the > > > compiler --sysroot option. > > > > As the musl package maintainer, I don't particularly want Fedora > > packages depending on it unless they absolutely have to. I originally > > maintained it in Copr, but brought it into Fedora for the Enarx folks. > > I still maintain that generally you don't want to use this unless you > > *really* know what you're doing and can deal with the consequences of > > using an alternative libc. > > It sounds like there are enough issues with musl in Fedora that glibc > will have to be used. > > > That said, the changes you make are not currently compatible with the > > packaging guidelines. Can't you just use --prefix /usr/ > > instead? > > It was for using --sysroot directly on gcc calls. > > > > - The rust compiler adds musl target subpackages. > > > > This will require discussion with the Fedora Rust SIG. > > > > > - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be > > > usable as a guest. > > > > This will require talking to the kernel maintainers to add the flag. > > Okay, I'll ask about getting this applied even if Firecracker is not > included in Fedora. It still might be useful to use for a quick guest > kernel, and the option is just to support a command-line parameter[0], > so it shouldn't be disruptive. > > [0] > https://github.com/torvalds/linux/blob/v6.2/Documentation/admin-guide/kernel-parameters.txt#L6697 > > > > - About two dozen Rust crates must be added to Fedora (but a handful > > > are just new versions of existing packages). > > > - Unrelated, but in the Copr repo anyway: The musl package is fixed > > > to allow multilib installs, and Rust includes both 32- and 64-bit > > > targets. > > > > > > I used upstream-preferred settings when adding things, but they may be > > > in conflict with Fedora guidelines. Here are some concerns: > > > > > > - Firecracker can be built with Fedora's libc (glibc), but it is > > > officially unsupported upstream[3]. Functionality would be harmed by > > > not using musl, e.g. seccomp filters are not used. > > > > Why not drive this to be fixed upstream? Also, openSUSE builds > > Firecracker against glibc and I see the seccomp stuff is also produced > > and shipped[1]. I am not sure whether this means openSUSE's package is > > broken or something else. > > > > [1]: > > https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec > > I can look into what they're doing more thoroughly later, but I would > assume they are just running with the empty seccomp filter. I am > aware of two issues with glibc: The jailer program allegedly does not > work with non-musl (although it builds) and is disabled upstream[1], > and there is no non-musl seccomp filter[2][3]. > > [1] https://github.com/firecracker-microvm/firecracker/pull/2125 > [2] > https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/src/vmm/build.rs#L25 > [3] > https://github.com/firecracker-microvm/firecracker/tree/v1.3.0/resources/seccomp > > > > - Upstream Rust wants musl targets to be statically linked by > > > default[4]. It can be changed by patching (Gentoo does this) if > > > dynamic linking is still a priority with Rust binaries, but I haven't > > > tested that. > > > > As in musl is statically linked into the binaries? Or the Rust code is > > statically linked. The former is not okay, the latter is what we do > > already. > > The former, the musl targets produce static binaries by default. > > > > - Firecracker uses two crates forked from crates.io, but they are > > > not vendored/bundled nor published to a registry. I'm currently > > > manually bundling them as if they were vendored to avoid package name > > > conflicts since nothing else uses them, but I don't know the preferred > > > way to deal with those. > > > > > > > That's probably the right way to deal with it. > > > > > So does any of that sound like a showstopper for being included in > > > Fedora? Is there any other interest in the project from the > > > community? > > > > > > > It'd be interesting to have in Fedora, for sure, b
Re: Packaging portmidi versions: devel conflicts OK?
On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber wrote: > > Il 03/03/23 19:00, Michael J Gruber ha scritto: > > What about: > > > > - create a compat-portmidi0 package and move current portmidi there > > (bonus: mark it as deprecated) > > - change frescobaldi to require the compat package until a fix is > available > > - update current portmidi package to v2 > > That is possible in the long term, anyway. But it takes time unless you do > this on released Fedoras, too. > Compatibility packages do not get a "compat-" prefix any more; they only get a version suffix. The old portmidi could be portmidi217 (to match the old versioning) or possibly portmidi0 (to match the soversion). It's also preferred (but I'm not sure that it's written down or is just a discussion within the FPC right now) that the un-suffixed version is the latest one. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple > > BTW, this is not the first time such a discussion arise and I think > > FESCo / Packaging Guidelines must provide a definitive answer for this. > > Thanks to Sergio I know a precedent know. I'll take another look at pm2 to > see if can somehow avoid the conflicts without creating hardships for > depending packages, and otherwise go for the middleground plan which will > require a review for te "new" package in any case. > Compatibility packages do not need a review. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process -- Elliott ___ 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
libavcodec-free x86_64 5.1.2-12.fc39 rawhide 4.1 M
sudo dnf up --refresh [sudo] password for you: Fedora rawhide openh264 (From Cisco) - x86_64 3.4 kB/s | 989 B 00:00 Fedora - Rawhide - Developmental packages for t 58 kB/s | 21 kB 00:00 Fedora - Modular Rawhide - Developmental packag 113 kB/s | 22 kB 00:00 RPM Fusion for Fedora Rawhide - Free9.2 kB/s | 4.1 kB 00:00 RPM Fusion for Fedora Rawhide - Nonfree 24 kB/s | 6.9 kB 00:00 RPM Fusion for Fedora rawhide - Nonfree - Steam 22 kB/s | 6.1 kB 00:00 Dependencies resolved. Problem 1: package libchromaprint-1.5.1-7.fc38.x86_64 requires libavcodec.so.59()(64bit), but none of the providers can be installed - package libchromaprint-1.5.1-7.fc38.x86_64 requires libavcodec.so.59(LIBAVCODEC_59)(64bit), but none of the providers can be installed - cannot install both ffmpeg-libs-6.0-2.fc39.x86_64 and ffmpeg-libs-5.1.2-9.fc38.x86_64 - package ffmpeg-libs-6.0-2.fc39.x86_64 conflicts with libavcodec-free provided by libavcodec-free-5.1.2-12.fc39.x86_64 - cannot install the best update candidate for package libchromaprint-1.5.1-7.fc38.x86_64 - cannot install the best update candidate for package ffmpeg-libs-5.1.2-9.fc38.x86_64 Problem 2: problem with installed package libchromaprint-1.5.1-7.fc38.x86_64 - package libchromaprint-1.5.1-7.fc38.x86_64 requires libavcodec.so.59()(64bit), but none of the providers can be installed - package libchromaprint-1.5.1-7.fc38.x86_64 requires libavcodec.so.59(LIBAVCODEC_59)(64bit), but none of the providers can be installed - cannot install both ffmpeg-libs-6.0-2.fc39.x86_64 and ffmpeg-libs-5.1.2-9.fc38.x86_64 - package ffmpeg-libs-6.0-2.fc39.x86_64 conflicts with libavcodec-free provided by libavcodec-free-5.1.2-12.fc39.x86_64 - package ffmpeg-6.0-2.fc39.x86_64 requires libavutil.so.58()(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libavutil.so.58(LIBAVUTIL_58)(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libavformat.so.60()(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libavformat.so.60(LIBAVFORMAT_60)(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libswscale.so.7()(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libswscale.so.7(LIBSWSCALE_7)(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libavfilter.so.9()(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libavfilter.so.9(LIBAVFILTER_9)(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libpostproc.so.57()(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires libpostproc.so.57(LIBPOSTPROC_57)(64bit), but none of the providers can be installed - package ffmpeg-6.0-2.fc39.x86_64 requires ffmpeg-libs(x86-64) = 6.0-2.fc39, but none of the providers can be installed - cannot install the best update candidate for package ffmpeg-5.1.2-9.fc38.x86_64 PackageArch Version Repository Size Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ffmpeg-libsx86_646.0-2.fc39rpmfusion-free-rawhide8.0 M libavcodec-freex86_645.1.2-12.fc39 rawhide 4.1 M Skipping packages with broken dependencies: ffmpeg x86_646.0-2.fc39rpmfusion-free-rawhide1.7 M Transaction Summary Skip 3 Packages Nothing to do. Complete! Waiting for https://src.fedoraproject.org/rpms/ffmpeg to be updated. ___ 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: libavcodec-free x86_64 5.1.2-12.fc39 rawhide 4.1 M
On 05/03/2023 04:16, Reon Beon via devel wrote: Problem 1: package libchromaprint-1.5.1-7.fc38.x86_64 requires libavcodec.so.59()(64bit), but none of the providers can be installed RPM Fusion has ffmpeg 6.x in Rawhide and Fedora is still on 5.1. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
