btrfs and default page sizes (4k vs 64k)

Given the plans to make btrfs the default, I'll share some of my own recent experiences, hopefully this can make it easier for the next person One issue I've come across is that a btrfs filesystem can only be used on hosts with the same page size as the host that created the filesystem E.g. x86

Re: Proposing an EPEL packaging SIG

Reading this proposal and with the EPEL8 experience, where there was not even wiki page, where I could state that I don't care about EPEL and I had to reply into every BZ independently, wouldn't it make sense to move EPEL into its own dist-git namespace? I guess that in the CVS days, having EPEL b

[Bug 1870746] EPEL8 Branch Request: perl-Test-TempDir

https://bugzilla.redhat.com/show_bug.cgi?id=1870746 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanu

Re: Proposing an EPEL packaging SIG

On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: > Reading this proposal and with the EPEL8 experience, where there was not > even wiki page, where I could state that I don't care about EPEL and I > had to reply into every BZ independently, wouldn't it make sense to move > EPEL into its

Re: Is there a Qt5 rebuild in progress?

On 14. 09. 20 7:51, Jan Grulich wrote: Hi, all qt5-* packages + all the packages using private API which needed rebuild were build in a side tag and tagged once the update was complete to make sure I don't break anything. Is this still an issue? No longer an issue. Thanks. -- Miro Hrončok -

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: >> Reading this proposal and with the EPEL8 experience, where there was not >> even wiki page, where I could state that I don't care about EPEL and I >> had to reply into ev

Re: Proposing an EPEL packaging SIG

On Mon, Sep 14, 2020, 10:35 Vít Ondruch wrote: > > Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: > >> Reading this proposal and with the EPEL8 experience, where there was not > >> even wiki page, where I could state

[Test-Announce] [Test Day] Fedora Media Writer 2020-09-18

Hey Testers, Friday, 2020-09-18 will be Fedora Media Writer Test Day[0]! This Test Day will focus on Fedora Media Writer. Fedora Media Writer is used for creating bootable flash drives on different operating systems and architectures. The tool is intended to be provided as the primary download op

Fedora-Cloud-32-20200914.0 compose check report

No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 664405 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/664405 Passed openQA tests: 6/7 (x86_64) -- Mail generated

Re: Proposing an EPEL packaging SIG

On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote: > > Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: > >> Reading this proposal and with the EPEL8 experience, where there was not > >> even wiki page, where I

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

On Fri, Sep 11, 2020 at 7:03 PM Michael Catanzaro wrote: > > > If it is, what is the proper way to revert back to upstream defaults > > in this case? Should I append "--force" to the command? (I don't want > > to destroy my system, that's why I'm not simply trying it. All of > > this seems awfull

Re: Proposing an EPEL packaging SIG

On 14. 09. 20 12:03, Pierre-Yves Chibon wrote: You're speaking about the bugzilla overrides, that in practice are entirely separated from granting access to the epel* branches to someone. If you go on the project's settings, click to add an user or group, you'll see the "collaborator" access leve

Fedora-Cloud-31-20200914.0 compose check report

No missing expected images. Passed openQA tests: 7/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedorap

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

On 9/14/20 12:11 PM, Kamil Paral wrote: On Fri, Sep 11, 2020 at 7:03 PM Michael Catanzaro > wrote: > If it is, what is the proper way to revert back to upstream defaults > in this case? Should I append "--force" to the command? (I don't want > to

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sun, 2020-09-13 at 16:47 +, Alexey Avramov wrote: > > So with > > applications started, you might get higher. > > I think we should protect only basic GUI. On computers with 16G+ RAM > locking 1G memory with apps should not be a problem if it helps to > improve responsiveness. Yup, fully a

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> may be different for GNOME with JIT'ed code > potentially getting swapped out How to recognize JIT'ed code? Do you mean that we shouldn't lock it? пн, 14 сент. 2020 г. в 20:17, Benjamin Berg : > On Sun, 2020-09-13 at 16:47 +, Alexey Avramov wrote: > > > So with > > > applications started,

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 2020-09-14 at 20:35 +0900, Alexey A. wrote: > > > may be different for GNOME with JIT'ed code > > potentially getting swapped out > > How to recognize JIT'ed code? Do you mean that we shouldn't lock it? I don't think you can protect it using your tool, as it lives in anonymous mappings.

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> memory is executable code, but it behaves like > other process memory such as the heap or the stack Seems like it is not a problem: with GNOME effect is the same as with other environments. пн, 14 сент. 2020 г. в 21:14, Benjamin Berg : > On Mon, 2020-09-14 at 20:35 +0900, Alexey A. wrote: > >

Fedora 33 compose report: 20200914.n.0 changes

OLD: Fedora-33-20200913.n.0 NEW: Fedora-33-20200914.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

On Mon, Sep 14, 2020 at 12:37 PM Pavel Březina wrote: > apply-changes only works if you have valid authselect configuration (no > manual changes) and you edit /etc/authselect/user-nsswitch.conf or one > of the selected profile template. > > If you need to restore previous configuration you can ei

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a): > On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote: >> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): >>> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: Reading this proposal and with the EPEL8 experi

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 15:01 Vít Ondruch napsal(a): > Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a): >> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote: >>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: >

Fedora-33-20200914.n.0 compose check report

No missing expected images. Failed openQA tests: 2/181 (x86_64) New failures (same test not failed in Fedora-33-20200913.n.0): ID: 664573 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/664573 Old failures (same test failed in Fedora-33-20200913

Fedora-IoT-33-20200914.0 compose check report

No missing expected images. Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20200912.0): ID: 664594 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/te

F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches == Summary == This Change proposal aims to enable shipping Rust crate packages (rust-$CRATE_NAME) on release branches of fedora. Currently, they are only available for rawhide, which makes building Rust packages for r

Re: The Future of the Java Stack (also regarding ELN and RHEL)

On Fri, Sep 11, 2020 at 10:04 PM Hans de Goede wrote: > > Hi, > > On 9/11/20 6:08 PM, Fabio Valentini wrote: > > I can try to come up with a list of often-used-but-simple-to-maintain > > Java packages? > > Yes that sounds great. I would be happy to pick up a few of > those to help and if a bunch o

Re: [EPEL-devel] Proposing an EPEL packaging SIG

On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote: ...snip... > > EPEL packages are maintained in dist-git as additional branches on > Fedora packages; however, unlike with Fedora releases, where by default > a package gets branched for any new Fedora release, EPEL branches ar

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 10:11 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches > > == Summary == > > This Change proposal aims to enable shipping Rust crate packages > (rust-$CRATE_NAME) on release branches of fedora. > Currently, they are on

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 14. 09. 20 16:10, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches == Summary == This Change proposal aims to enable shipping Rust crate packages (rust-$CRATE_NAME) on release branches of fedora. Currently, they are only available for rawhide,

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, 2020-09-14 at 10:10 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches > > * Other developers: > > Initially, there is no impact on other developers. > However, as soon as fedora 34 is branched, building Rust applications > on that r

Re: [EPEL-devel] Re: Proposing an EPEL packaging SIG

On Mon, 2020-09-14 at 08:54 -0700, Kevin Fenzi wrote: ...snip... > I'll add that in addtion to some maintainers not wanting to maintain > their fedora packages also in epel, the timelines involved sometimes > make it so a package that was branched/maintained in epelX, makes no > sense in epelY. ie,

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches > > == Summary == > > This Change proposal aims to enable shipping Rust crate packages > (rust-$CRATE_NAME) on release branches of fedora. > Currently, the

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 2:34 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches > > > > == Summary == > > > > This Change proposal aims to enable shipping Rust cra

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 8:38 PM Neal Gompa wrote: > > On Mon, Sep 14, 2020 at 2:34 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches > > > > > > == Summa

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 11:40 AM, Fabio Valentini wrote: > On Mon, Sep 14, 2020 at 8:38 PM Neal Gompa wrote: >> >> On Mon, Sep 14, 2020 at 2:34 PM Zbigniew Jędrzejewski-Szmek >> wrote: >>> >>> On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Rust_Crate_Pa

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote: > > On 9/14/20 11:40 AM, Fabio Valentini wrote: > > I agree. The only thing to keep in mind for semver-incompatible -devel > > package updates is to check dependent packages, and either patch them > > to use the new version (like in rawhide), or cr

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: > On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote: > > > > On 9/14/20 11:40 AM, Fabio Valentini wrote: > > > I agree. The only thing to keep in mind for semver-incompatible -devel > > > package updates is to check dependent packages

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: >> On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote: >>> >>> On 9/14/20 11:40 AM, Fabio Valentini wrote: I agree. The only thing to keep in mind for semver-incompatible -

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On Mon, Sep 14, 2020 at 12:53:57PM -0700, Josh Stone wrote: > On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: > >> On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote: > >>> > >>> On 9/14/20 11:40 AM, Fabio Valentini wrote:

Unretire naga and jmol

The naga and jmol packages were retired a few months ago after being orphaned. This has turned out to be somewhat problematic for sagemath. For one thing, the lack of jmol is causing most of the documentation-building steps to error out, even for parts of the code that have nothing to do with jmo

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 1:14 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Sep 14, 2020 at 12:53:57PM -0700, Josh Stone wrote: >> On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote

Orphaned packages looking for new maintainers

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If

Paralel dependencyj (Re: kalev pushed to gnome-shell (master). "Add missing pipewire-gstreamer dependency for screen recorder (..more)")

On Wed, 9 Sep 2020 at 19:47, wrote: > @@ -90,6 +90,8 @@ Requires: gnome-desktop3%{?_isa} >= > %{gnome_desktop_version} > Requires: glib2%{?_isa} >= %{glib2_version} > Requires: gsettings-desktop-schemas%{?_isa} >= > %{gsettings_desktop_schemas_version} > Requires: gstre

Re: Orphaned packages looking for new maintainers

On 9/14/20 4:08 PM, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. rdesktop  alexl, caillon, caolanm, cra,    0 weeks ago   fab, gnome-sig,