Review swap: carbon-c-relay
Hello, Would appreciate anybody to take a look at a (re-)review of a carbon-c-relay package. https://bugzilla.redhat.com/show_bug.cgi?id=2303167 Happy to take some rust/python/c review in exchange. Thanks! -- — Igor Raits. -- ___ 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 18, 2023, 03:37 Smith, Stewart via devel < devel@lists.fedoraproject.org> wrote: > On Mar 5, 2023, at 10:19 AM, Kevin Kofler via devel < > devel@lists.fedoraproject.org> 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. > > I’m happy to engage with the Firecracker team and get everyone together to > talk through the issues. > > We did used to package Firecracker for Amazon Linux (in an AL2 Extra), but > it had literally zero users from our repos (lambda and others build their > own). This could be due to just Firecracker by itself isn’t too useful > without some other easy integration with something like containerd. That > being said, I’d be interested in what use cases people have for it packaged > in fedora. > We are using it internally at our company to spawn multiple VMs that emulate our platform and due to the memory footprint libvirt has and lot of unnecessary features, we use firecracker. And would prefer to have it already packaged so that we won't be doing that ourselves. That said, integration with some other tools (e.g. OpenStack or even some custom scheduler to implement things like simple Lambda) would be great. ___ 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: "Conditional recommends" for packages
Or exactly opposite: Supplements: (NetworkManager-sstp and gnome-shell) … from within NetworkManager-sstp-gnome subpackage On Sat, Apr 23, 2022 at 8:51 PM Neal Gompa wrote: > > On Sat, Apr 23, 2022 at 2:32 PM Marcin Zajączkowski wrote: > > > > Hi. My package sstp-client (a SSTP VPN client) can be used on it's own, > > but usually it is recommended to have also the NetworkManager-sstp > > plugin. "Recommends" seems to be a good idea here as NM is usually > > available by default. > > > > However, there is also NetworkManager-sstp-gnome which adds an applet > > for Gnome Shell. I'm reluctant to use "Recommends" here, as it would > > propose an user to install the whole GNOME ecosystem (assuming LXQT or > > something else it already used instead). > > > > Is there a way to use "conditional recommends" to only propose > > NetworkManager-sstp-gnome (e.g. when NetworkManager-sstp itself is > > installed) if gnome-shell is already installed? > > > > Recommends: (NetworkManager-sstp-gnome if (NetworkManager-sstp and > gnome-shell)) > > > > > -- > 真実はいつも一つ！/ 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 -- — Igor Raits. ___ 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
Does anybody still use `starship'?
Hello, I saw some recent discussions (yet another time) how packaging Rust / Go / Node.js is horrible, we should simply bundle everything and such. Let's not discuss this here, though. I'm interested to hear if there are any users of the `starship' application here in Fedora that consume it from the repositories. Please speak up if you do! As pointed out in the other places, I don't think we are able to update things like that as fast as releases popping out with just as few people working on the packaging Rust stack these days (I'm pretty much not contributing for last couple years due to the other work). And the question, if we want to keep packaging it (with some slower update cycle, as the time permits) or we want to retire it completely. Personally, I'd love to have more people working on packaging (and most importantly keeping up-to-date) Rust crates / apps but I think this is not so realistic :) -- — Igor Raits. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
Hello,
On Wed, Dec 29, 2021 at 4:04 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
>
> == Summary ==
> Changing the default fonts for various languages to Noto Fonts as much
> as possible, to make consistency on the text rendering.
>
> == Owner ==
> * Name: [[User:Tagoh|Akira TAGOH]]
> * Email:
>
>
> == Detailed Description ==
> For a long time we have used DejaVu fonts as the default font for
> European and other language scripts. On the other hand some language
> scripts are not covered by DejaVu and hence have other default fonts.
> (A few languages like Chinese, Japanese and Korean, as well as
> Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
> for some time.) This situation leads to inconsistencies in text
> rendering on applications and desktops, particularly when mixing
> different character sets. Further Noto fonts bring some further
> advantages: the fonts are generally higher quality and support
> variable fonts for most scripts, making them more compact.
>
> This change aims to provide better experience and consistent text
> rendering across more languages by replacing DejaVu with Noto as the
> general system default set of fonts.
>
> The following packages will be installed by default to replace
> DejaVu's coverage:
> * google-noto-sans-vf-fonts
> * google-noto-serif-vf-fonts
> * google-noto-sans-mono-vf-fonts
> * google-noto-sans-arabic-vf-fonts
> * google-noto-sans-cherokee-vf-fonts
> * google-noto-sans-thaana-vf-fonts
> * google-noto-sans-hebrew-vf-fonts
> * google-noto-rashi-hebrew-vf-fonts
> * google-noto-sans-math-vf-fonts
> * google-noto-sans-armenian-vf-fonts
> * google-noto-serif-armenian-vf-fonts
> * google-noto-sans-canadian-aboriginal-vf-fonts
> * google-noto-sans-georgian-vf-fonts
> * google-noto-serif-georgian-vf-fonts
> * google-noto-sans-lao-vf-fonts
> * google-noto-serif-lao-vf-fonts
> * google-noto-serif-gurmukhi-vf-fonts
> * google-noto-serif-sinhala-vf-fonts
Will all of them be installed by default or depending on langpacks selection?
> And you can check
> [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
> see what languages will be affected by this change.
>
>
> == Benefit to Fedora ==
> We would get better text rendering on applications and desktops. Also
> this change should save about 6MB on the fresh install.
>
>
> $ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
> | awk 'BEGIN{a=0}{a+=$5}END{print a}'
> 10789272
>
> $ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
> google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
> google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
> google-noto
> -sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
> google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
> onts google-noto-serif-armenian-vf-fonts
> google-noto-sans-canadian-aboriginal-vf-fonts
> google-noto-sans-georgian-vf-f
> onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
> google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
> google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
> a}'
> 4753340
>
>
> == Scope ==
> * Proposal owners:
> ** Update google-noto-fonts and dejavu-fonts to change the priority
> for fontconfig config.
> ** Update langpacks to update the dependency.
> ** Update comps to make Noto fonts default.
> ** Update lorax templates related to DejaVu.
> ** Update fontconfig to change the order of fonts in the builtin config.
>
> * Other developers:
> ** Packagers who owns packages implicitly expects DejaVu is installed
> by default will needs to update the dependency for them.
>
> * Release engineering: [https://pagure.io/releng/issue/10492 #10492]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> The migration will be done by updating langpacks. after upgrading and
> rebooting, the default font will be Noto instead of DejaVu.
Is it safe to delete DejaVu fonts assuming they are not used by any known app?
> Since this change aims to switch non-variable fonts to variable fonts,
> it may not works with legacy applications as expected such as missing
> some variants. in that case, you can install non-variable fonts
> packages. the package name will be similar and simply drop `-vf` from
> the variable fonts packages.
>
>
> == How To Test ==
> * This change can be simply tested by `fc-match` command like
> `fc-match sans:lang=`, `fc-match serif:lang= language>` and `fc-match monospace:lang=`. You can
> check the expected result from
> [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
> * Test the text rendering in your favorite application, which use the
> system default font.
I think this paragraph explains how to test already applied change,
but not really how to "test it before it lands"… Do
Re: What to do with Rust packaging in EPEL9?
On Mon, Nov 29, 2021, 20:47 Fabio Valentini wrote: > On Sat, Nov 27, 2021 at 10:36 AM Igor Raits > wrote: > > > > Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means > it is not possible to get them in EPEL9. That also means, they are already > outdated and do not support our latest greatest consistent packaging across > Fedora versions… Right now, I suppose it is still possible to get that > stuff updated in the Stream9, but later on it will be harder and harder I > suppose. > > > > So what should one do if they want up2date stuff through the whole EPEL9 > lifetime? > > I wonder, what Rust applications do you want to provide for EPEL 9? > (Because I hope you're not just importing *all* Rust packages from Fedora.) > Mainly I'm interested in ripgrep, fd-find, dua-cli and gitui. Possibly some other CLI apps. For sure no GUI! > Fabio > ___ > 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
HEADS UP: libgit2 1.1.0 → 1.3.0 update
Hi, This is an ABI-compatible change (should be still API-compatible), so I'm going to perform an update in the side tags for f34/f35/f36 including rebuild of all affected packages. I don't expect issues, so this is more like a FYI. ___ 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: sysusers scriptlets: what to do if upstream includes the config files?
On Sat, Nov 27, 2021 at 6:42 PM Matthew Miller wrote: > On Sat, Nov 27, 2021 at 09:10:13AM -0500, Neal Gompa wrote: > > > IMO this is ugly and unfortunate. > > The design around sysusers expects a model where files are unpacked > > and *then* scripts are run. RPM doesn't work that way, which makes all > > of this fall apart. In the ideal case, we could generate preinstall > > scriptlets for this stuff from detected sysusers files on the fly, but > > there's currently no way to do that. > > So not helping _currently_, but could we make rpm itself handle this in > a different way: stuff the systemd-sysusers files into metadata available > before anything is installed? > > > A more practical way to work around this is to always subpackage out > > sysusers and use dependencies to guarantee that it's installed before > > the package itself is. This would require the systemd file trigger to > > Uhh. That's practical but gross, unless there's some kind of > macro/automation for the subpackage. > https://github.com/rpm-software-management/rpm/pull/1485 > -- > Matthew Miller > > Fedora Project Leader > ___ > 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
Re: [EPEL-devel] Re: What to do with Rust packaging in EPEL9?
On Sat, Nov 27, 2021 at 2:51 PM Neal Gompa wrote: > On Sat, Nov 27, 2021 at 4:36 AM Igor Raits > wrote: > > > > Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means > it is not possible to get them in EPEL9. That also means, they are already > outdated and do not support our latest greatest consistent packaging across > Fedora versions… Right now, I suppose it is still possible to get that > stuff updated in the Stream9, but later on it will be harder and harder I > suppose. > > > > So what should one do if they want up2date stuff through the whole EPEL9 > lifetime? > > The macros and tools that power the rust packaging stuff (aside from > rust-srpm-macros) are not shipped in CentOS/RHEL 9, so we can ship it > in EPEL 9 if we want. > Hmm, so why does https://gitlab.com/redhat/centos-stream/rpms/rust-packaging exist? > > rust-srpm-macros has macros that haven't changed much in years, so I > don't think that'll be an issue. > I do think they changed a bit in the last couple releases (I'm not following it that much these days)… But at some point I'm hoping to make even more changes there and I'd like to avoid adding rust bits into the epel-rpm-macros (or others). > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > epel-devel mailing list -- epel-de...@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-de...@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
What to do with Rust packaging in EPEL9?
Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means it is not possible to get them in EPEL9. That also means, they are already outdated and do not support our latest greatest consistent packaging across Fedora versions… Right now, I suppose it is still possible to get that stuff updated in the Stream9, but later on it will be harder and harder I suppose. So what should one do if they want up2date stuff through the whole EPEL9 lifetime? ___ 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 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
It would be great if the "How to test" section would include some steps on how to switch to WirePlumber so that anything can be tested. On Mon, Jul 19, 2021 at 6:18 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/WirePlumber > > == Summary == > PipeWire currently uses a simple example session manager. This > proposal is to move to the more powerful WirePlumber session manager. > > == Owner == > * Name: [[User:Wtaymans| Wim Taymans]] > * Email: wim.taym...@gmail.com > > == Detailed Description == > PipeWire requires a session manager that at least needs to implements > the following features: > > * create and configure detected devices in the system. This includes > audio cards, video and bluetooth devices. > * configure applications and route audio/video to/from them to the > devices and filters. > * keep track of prefered devices and volumes. > * move audio/video streams when devices appear and disappear. > > PipeWire uses a simple example session manager with limited features > and configuration options. The proposal is to > move to WirePlumber. > > WirePlumber is built on GNOME (GObject) technologies and has bindings > for most languages using GObject introspection. > > WirePlumber allows one to implement many of the rules for setup and > configuration using small LUA scripts, which are > easier to maintain and customize. These are some of the functions that > are scriptable in LUA: > > * setup and configuration of the devices and streams. This includes > deciding if devices and streams need to operate in 5.1 or stereo mode, > depending on the available devices. > * routing of the streams based on metadata of the streams (Roles) and > overall state of the system. > * volume/mute restore of devices and streams > > > == Benefit to Fedora == > > PipeWire currently uses a simple example session manager with mostly > hardcoded logic and rules. This proposal wants to replace the session > manager with a more advanced session manager, called WirePlumber. > > WirePlumber brings to following improvements > > * Drop-in replacement session manager for PipeWire, implements the > exact same features as the example session manager > * built with GObject, which provides a richer development experience > and adds bindings for most languages > * extensible with loadable modules > * scriptable policy using small lua scripts > * better integration with desktop settings > > The main benefits will be that this session manager would allow for > more customization of the policy > and rules. Initially we aim for feature parity with the current > solution and work on more features > in the next releases. > > == Scope == > * Proposal owners: > This is a rather isolated changed. Instead of starting the > pipewire-media-session executable we would need to package > and start WirePlumber instead. > > WirePlumber has been kept up to data with the features in the example > session manager and would need testing. > > * Other developers: None. This is an isolated PipeWire change. > * Release engineering: A new systemd service will need to be activated > in the default install. > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == Upgrade/compatibility impact == > Should not cause any change. > > == How To Test == > > Experience should be the same as before. Retest all audio testcases. > > > == User Experience == > Should not cause any visible change. > > > == Dependencies == > None. > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?): If the > feature can not be completed we continue using the existing > pipewire-media-session. > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > > == Documentation == > [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) > > > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 o
Re: GNOME on Wayland does not work on latest Rawhide
Lovely, thank you (and to Carlos for suggesting a workaround)! It works fine here, so please post bugzilla once you create it. Thanks again, On Tue, Jun 22, 2021 at 9:49 PM Adam Williamson wrote: > On Tue, 2021-06-22 at 09:04 -0700, Adam Williamson wrote: > > On Tue, 2021-06-22 at 08:13 -0700, Kevin Fenzi wrote: > > > On Tue, Jun 22, 2021 at 08:08:36AM -0600, Chris Murphy wrote: > > > > On Tue, Jun 22, 2021 at 1:49 AM Igor Raits > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > Seems with some latest updates in Rawhide (tbh I haven't updated > for a ~month) I can't get Wayland working on my laptop anymore. I've tried > to downgrade mesa, mutter, gnome-shell, kernel and a few other packages but > no luck. > > > > > > > > > > Is it just my laptop that's somehow broken? > > > > > > > > I've got a similar regression where the session starts in X instead > of > > > > Wayland, with a huge stack trace in the journal. So I don't think > it's > > > > hardware related. > > > > > > Yeah, I tried to isolate this yesterday without much luck. ;( > > > > > > I tried downgrading: kernel, mutter, gnome-shell, glibc, mesa, > systemd. > > > > > > But I might have missed something. Unfortunately, last week was pretty > > > busy for me, so I didn't reboot until the weekend, so I had a pile of > > > updates in that transaction that broke things. :( > > > > > > Perhaps someone else has a smaller list of packages between the normal > > > and broken states? > > > > I'm seeing it too (Kevin and I talked about it last night, but couldn't > > work out the problem). My upgrade package set was: > > garnacho suggested setting MESA_LOADER_DRIVER_OVERRIDE=i965 in > /etc/environment, and that does indeed seem to work around the problem. > I have Wayland again now. Though it makes it even weirder that > downgrading mesa doesn't solve the problem, but it definitely doesn't, > I've tried twice. And I tried older mesa+older kernel as well, no dice. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > ___ > 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
Re: GNOME on Wayland does not work on latest Rawhide
I've tried now: kernel: 5.13.0-0.rc2.19.fc35 mesa: 21.1.1-2.fc35 Yes, I also have an Intel GPU. Different stacktrace, same issue… Stack trace of thread 1103: #0 0x7f7e87d6b819 type_iface_peek_holder_L.lto_priv.0 (libgobject-2.0.so.0 + 0x33819) #1 0x7f7e87d6159c check_add_interface_L.lto_priv.0 (libgobject-2.0.so.0 + 0x2959c) #2 0x7f7e87d6df49 g_type_add_interface_static (libgobject-2.0.so.0 + 0x35f49) #3 0x7f7e8701d68c meta_backend_x11_get_type_once (libmutter-8.so.0 + 0x8a68c) #4 0x7f7e8701d6f5 meta_backend_x11_get_type (libmutter-8.so.0 + 0x8a6f5) #5 0x7f7e8701d855 meta_backend_x11_cm_get_type_once (libmutter-8.so.0 + 0x8a855) #6 0x7f7e8701d8d5 meta_backend_x11_cm_get_type (libmutter-8.so.0 + 0x8a8d5) #7 0x7f7e87059af6 meta_get_x11_display_policy (libmutter-8.so.0 + 0xc6af6) #8 0x7f7e870b5e94 meta_wayland_compositor_setup (libmutter-8.so.0 + 0x122e94) #9 0x7f7e870061b2 meta_backend_initable_init (libmutter-8.so.0 + 0x731b2) #10 0x7f7e8705c957 meta_init (libmutter-8.so.0 + 0xc9957) #11 0x55c8e6e9c9c0 main (gnome-shell + 0x29c0) #12 0x7f7e86dc87e0 n/a (libc.so.6 + 0x2b7e0) #13 0x7f7e86dc888c n/a (libc.so.6 + 0x2b88c) #14 0x55c8e6e9cebe _start (gnome-shell + 0x2ebe) Stack trace of thread 1115: #0 0x7f7e86e25f2a n/a (libc.so.6 + 0x88f2a) #1 0x7f7e86e28690 n/a (libc.so.6 + 0x8b690) #2 0x7f7e6d31709b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x7f7e6d316b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x7f7e86e29207 n/a (libc.so.6 + 0x8c207) #5 0x7f7e86eabdd4 n/a (libc.so.6 + 0x10edd4) On Tue, Jun 22, 2021 at 6:15 PM Adam Williamson wrote: > On Tue, 2021-06-22 at 08:13 -0700, Kevin Fenzi wrote: > > On Tue, Jun 22, 2021 at 08:08:36AM -0600, Chris Murphy wrote: > > > On Tue, Jun 22, 2021 at 1:49 AM Igor Raits > > > wrote: > > > > > > > > Hello, > > > > > > > > Seems with some latest updates in Rawhide (tbh I haven't updated for > a ~month) I can't get Wayland working on my laptop anymore. I've tried to > downgrade mesa, mutter, gnome-shell, kernel and a few other packages but no > luck. > > > > > > > > Is it just my laptop that's somehow broken? > > > > > > I've got a similar regression where the session starts in X instead of > > > Wayland, with a huge stack trace in the journal. So I don't think it's > > > hardware related. > > > > Yeah, I tried to isolate this yesterday without much luck. ;( > > > > I tried downgrading: kernel, mutter, gnome-shell, glibc, mesa, systemd. > > > > But I might have missed something. Unfortunately, last week was pretty > > busy for me, so I didn't reboot until the weekend, so I had a pile of > > updates in that transaction that broke things. :( > > > > Perhaps someone else has a smaller list of packages between the normal > > and broken states? > > I'm seeing it too (Kevin and I talked about it last night, but couldn't > work out the problem). My upgrade package set was: > > Install glibc-gconv-extra-2.33.9000-23.fc35.x86_64 > @rawhide > Install kernel-5.13.0- > 0.rc6.20210617git70585216fe77.48.fc35.x86_64 @rawhide > Install kernel-core-5.13.0- > 0.rc6.20210617git70585216fe77.48.fc35.x86_64@rawhide > Install kernel-modules-5.13.0- > 0.rc6.20210617git70585216fe77.48.fc35.x86_64 @rawhide > Install systemd-resolved-249~rc1-2.fc35.x86_64 > @rawhide > Upgraded NetworkManager-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-adsl-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-bluetooth-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-config-connectivity-fedora-1:1.32.0- > 0.4.fc35.noarch @@System > Upgraded NetworkManager-libnm-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-ppp-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-team-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-wifi-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded NetworkManager-wwan-1:1.32.0-0.4.fc35.x86_64 > @@System > Upgraded apr-1.7.0-9.fc35.x86_64 > @@System > Upgraded autofs-1:5.1.7-15.fc35.x86_64 > @@System > Upgraded bind-libs-32:9.16.16-2.fc35.x86_64 > @@System > Upgraded bind-license-32:9.16.16-2.fc35.noarch > @@System > Upgraded bind-utils-32:9.16.16-2.fc35.x86_64 > @@System > Upgraded ca-certificates-2021.2.48-2.fc35.noarch > @@System > Upgraded cmake-filesystem-3.20.3-1.fc35.x86_64 > @@System > Upgraded
Re: GNOME on Wayland does not work on latest Rawhide
It seems that every reboot has different errors. https://paste.centos.org/view/514a7357 Now I get: Stack trace of thread 1167: #0 0x7f3272948f53 n/a (libc.so.6 + 0x8df53) #1 0x7f32728fb9e6 n/a (libc.so.6 + 0x409e6) #2 0x7f32728e5806 n/a (libc.so.6 + 0x2a806) #3 0x561611d481bc OsAbort (Xwayland + 0x16e1bc) #4 0x561611d4849c FatalError (Xwayland + 0x16e49c) #5 0x561611d3f764 OsSigHandler.lto_priv.0 (Xwayland + 0x165764) #6 0x7f32728fba90 n/a (libc.so.6 + 0x40a90) #7 0x7f3271ac9560 n/a (iris_dri.so + 0x15b4560) Jun 22 12:11:56 /usr/libexec/gdm-wayland-session[1437]: Unable to init Broadway server: Could not connect: No such file or directory On Tue, Jun 22, 2021 at 11:54 AM Igor Raits wrote: > Hi Florian, > > On Tue, Jun 22, 2021 at 10:38 AM Florian Weimer > wrote: > >> * Igor Raits: >> >> > Hello, >> > >> > Seems with some latest updates in Rawhide (tbh I haven't updated for a >> ~month) I can't get >> > Wayland working on my laptop anymore. I've tried to downgrade mesa, >> mutter, >> > gnome-shell, kernel and a few other packages but no luck. >> > >> > Is it just my laptop that's somehow broken? >> > >> > Stack trace looks like this: >> > >> > Stack trace of thread 1155: >> > #0 0x7ff4df0fdf53 n/a (libc.so.6 + 0x8df53) >> > #1 0x7ff4df0b09e6 n/a (libc.so.6 + 0x409e6) >> > #2 0x5586fdc10282 dump_gjs_stack_on_signal_handler (gnome-shell + >> 0x3282) >> > #3 0x7ff4df0b0a90 n/a (libc.so.6 + 0x40a90) >> > #4 0x7ff4df0fdf53 n/a (libc.so.6 + 0x8df53) >> > #5 0x7ff4df0b09e6 n/a (libc.so.6 + 0x409e6) >> > #6 0x7ff4df09a806 n/a (libc.so.6 + 0x2a806) >> > #7 0x7ff4dfeefd2c g_assertion_message.cold (libglib-2.0.so.0 + >> 0x1ed2c) >> > #8 0x7ff4dff4ad6f g_assertion_message_expr (libglib-2.0.so.0 + >> 0x79d6f) >> >> Do you know what assertion message has been printed here? Maybe it will >> give a hint. >> > > Good point, I did not realize this, I do believe it is this one: > > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: ** > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: > GLib-GObject:ERROR:../gobject/gtypemodule.c:499:g_type_module_add_interface: > assertion failed: (module_interface_info) > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: == Stack trace for context > 0x5586fe3ee190 == > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: #0 5586fe5ce8e0 i > resource:///org/gnome/shell/ui/extensionDownloader.js:250 (2349ad74bb00 @ > 31) > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: #1 5586fe5ce848 i > resource:///org/gnome/shell/ui/main.js:267 (dde24cd8bf0 @ 1031) > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: #2 5586fe5ce798 i > resource:///org/gnome/shell/ui/main.js:166 (dde24cd8d30 @ 324) > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: #3 5586fe5ce710 i > :1 (dde24c8bdd0 @ 48) > Jun 22 09:30:24 org.gnome.Shell.desktop[1155]: Bail out! > GLib-GObject:ERROR:../gobject/gtypemodule.c:499:g_type_module_add_interface: > assertion failed: (module_interface_info) > > >> >> Thanks, >> Florian >> > ___ 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
GNOME on Wayland does not work on latest Rawhide
Hello, Seems with some latest updates in Rawhide (tbh I haven't updated for a ~month) I can't get Wayland working on my laptop anymore. I've tried to downgrade mesa, mutter, gnome-shell, kernel and a few other packages but no luck. Is it just my laptop that's somehow broken? Stack trace looks like this: Stack trace of thread 1155: #0 0x7ff4df0fdf53 n/a (libc.so.6 + 0x8df53) #1 0x7ff4df0b09e6 n/a (libc.so.6 + 0x409e6) #2 0x5586fdc10282 dump_gjs_stack_on_signal_handler (gnome-shell + 0x3282) #3 0x7ff4df0b0a90 n/a (libc.so.6 + 0x40a90) #4 0x7ff4df0fdf53 n/a (libc.so.6 + 0x8df53) #5 0x7ff4df0b09e6 n/a (libc.so.6 + 0x409e6) #6 0x7ff4df09a806 n/a (libc.so.6 + 0x2a806) #7 0x7ff4dfeefd2c g_assertion_message.cold (libglib-2.0.so.0 + 0x1ed2c) #8 0x7ff4dff4ad6f g_assertion_message_expr (libglib-2.0.so.0 + 0x79d6f) #9 0x7ff4e0044d57 g_type_module_add_interface (libgobject-2.0.so.0 + 0x39d57) #10 0x7ff489c101a5 g_io_gnutls_load (libgiognutls.so + 0xf1a5) #11 0x7ff4e00df57a g_io_module_load_module (libgio-2.0.so.0 + 0x7957a) #12 0x7ff4e00448db g_type_module_use (libgobject-2.0.so.0 + 0x398db) #13 0x7ff4e00449b8 g_type_module_use_plugin (libgobject-2.0.so.0 + 0x399b8) #14 0x7ff4e0043e17 type_data_ref_Wm.part.0 (libgobject-2.0.so.0 + 0x38e17) #15 0x7ff4e0045e48 g_type_class_ref (libgobject-2.0.so.0 + 0x3ae48) #16 0x7ff4e002ec98 g_object_new_with_properties (libgobject-2.0.so.0 + 0x23c98) #17 0x7ff4e002f661 g_object_new (libgobject-2.0.so.0 + 0x24661) #18 0x7ff4e00dffa4 try_implementation (libgio-2.0.so.0 + 0x79fa4) #19 0x7ff4e00e6336 _g_io_module_get_default (libgio-2.0.so.0 + 0x80336) #20 0x7ff4e010ff35 g_tls_backend_get_default (libgio-2.0.so.0 + 0xa9f35) #21 0x7ff48a6d2c62 soup_session_set_property (libsoup-2.4.so.1 + 0x59c62) #22 0x7ff4e002d876 object_set_property (libgobject-2.0.so.0 + 0x22876) #23 0x7ff4e002dd78 g_object_new_internal (libgobject-2.0.so.0 + 0x22d78) #24 0x7ff4e002ec17 g_object_new_with_properties (libgobject-2.0.so.0 + 0x23c17) #25 0x7ff4df60abcc _ZN10ObjectBase12init_gobjectEP9JSContextjPN2JS5ValueE (libgjs.so.0 + 0x56bcc) #26 0x7ff4dc6e4ce8 _ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE (libmozjs-78.so.0 + 0x14dce8) #27 0x7ff4dc6e5172 _ZN2js4CallEP9JSContextN2JS6HandleINS2_5ValueEEES5_RKNS_13AnyInvokeArgsENS2_13MutableHandleIS4_EENS_10CallReasonE (libmozjs-78.so.0 + 0x14e172) #28 0x7ff4dc7587b7 _Z20JS_CallFunctionValueP9JSContextN2JS6HandleIP8JSObjectEENS2_INS1_5ValueEEERKNS1_16HandleValueArrayENS1_13MutableHandleIS6_EE (libmozjs-78.so.0 + 0x1c17b7) #29 0x7ff4df613cc4 _ZN13GIWrapperBaseI10ObjectBase15ObjectPrototype14ObjectInstanceE11constructorEP9JSContextjPN2JS5ValueE (libgjs.so.0 + 0x5fcc4) #30 0x7ff4dc6e5b11 _ZL17InternalConstructP9JSContextRKN2js16AnyConstructArgsE.lto_priv.0 (libmozjs-78.so.0 + 0x14eb11) #31 0x7ff4dc6d6e44 _ZL9InterpretP9JSContextRN2js8RunStateE (libmozjs-78.so.0 + 0x13fe44) #32 0x7ff4dc6e46ce _ZN2js9RunScriptEP9JSContextRNS_8RunStateE (libmozjs-78.so.0 + 0x14d6ce) #33 0x7ff4dc6e5d46 _ZN2js13ExecuteKernelEP9JSContextN2JS6HandleIP8JSScriptEENS3_IP8JSObjectEENS3_INS2_5ValueEEENS_16AbstractFramePtrENS2_13MutableHandleISA_EE (libmozjs-78.so.0 + 0x14ed46) #34 0x7ff4dc7e49b7 _Z20EvaluateSourceBufferIDsEbP9JSContextN2js9ScopeKindEN2JS6HandleIP8JSObjectEERKNS4_22ReadOnlyCompileOptionsERNS4_10SourceTextIT_EENS4_13MutableHandleINS4_5ValueEEE.lto_priv.0 (libmozjs-78.so.0 + 0x24d9b7) #35 0x7ff4dc7c994e _ZN2JS8EvaluateEP9JSContextNS_6HandleINS_13StackGCVectorIP8JSObjectN2js15TempAllocPolicyERKNS_22ReadOnlyCompileOptionsERNS_10SourceTextIDsEENS_13MutableHandleINS_5ValueEEE (libmozjs-78.so.0 + 0x23294e) #36 0x7ff4df62256c _ZN17GjsContextPrivate15eval_with_scopeEN2JS6HandleIP8JSObjectEEPKclS6_NS0_13MutableHandleINS0_5ValueEEE (libgjs.so.0 + 0x6e56c) #37 0x7ff4df626ac9 gjs_context_eval (libgjs.so.0 + 0x72ac9) #38 0x7ff4e02772e5 gnome_shell_plugin_start (libgnome-shell.so + 0x292e5) #39 0x7ff4df3066f4 meta_compositor_do_manage (libmutter-8.so.0 + 0xa06f4) #40 0x7ff4df33186a meta_start (libmutter-8.so.0 + 0xcb86a) #41 0x7ff4df331edd meta_run (libmutter-8.so.0 + 0xcbedd) #42 0x5586fdc0fca6 main (gnome-shell + 0x2ca6) #43 0x7ff4df09b7e0 n/a (libc.so.6 + 0x2b7e0) #44 0x7ff4df09b88c n/a (libc.so.6 + 0x2b88c) #45 0x5586fdc0febe _start (gnome-shell + 0x2ebe) Stack trace of thread 1161: #0 0x7ff4df1730af n/a (libc.so.6 + 0x1030af) #1 0x7ff4dff7a5bc g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa95bc) #2 0x7ff4dff25513 g_main_loop_run (libglib-2.0.so.0 + 0x54513) #3 0x7ff4e0176d5a gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x110d5a) #4 0x7ff4dff546a2 g_thread_proxy (libglib-2.0.so.0 + 0x836a2) #5 0x7ff4df0fc207 n/a (libc.so.6 + 0x8c207) #6 0x7ff4df17edd4 n/a (libc.so.6 + 0x10edd4) Stack trace of t
Re: Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)
On Fri, Jan 15, 2021 at 10:58 PM Neal Gompa wrote:
> On Fri, Jan 15, 2021 at 3:57 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Remove_Python2_RPM_Macros
> >
> >
> > == Summary ==
> > The {{package|python2-rpm-macros}} package (containing
> > `/usr/lib/rpm/macros.d/macros.python2`) will be removed from Fedora 34
> > and newer. The python2 RPM macros will ceases to exist. Python 2
> > packages are already not allowed. Around a dozen of packages use the
> > macros in Fedora and will need to be adjusted either by expanding them
> > or by no longer using Python 2. The `python2.7dist()` and
> > `python2dist()` automatic provides/requires will no longer be
> > automatically generated.
> >
> > == Owner ==
> > * Name: [[User:Churchyard|Miro Hrončok]]
> > * Email: mhron...@redhat.com
> >
> >
> > == Detailed Description ==
> > Python 2 is upstream dead, usage in Fedora packages is forbidden,
> > except for several package with an explicit FESCo approved exception.
> > The Python Maintenance team no longer wishes to support the python2
> > RPM macros from the {{package|python2-rpm-macros}} package (located at
> > `/usr/lib/rpm/macros.d/macros.python2`) and hence decided to remove
> > the package. The following macros will be undefined:
> >
> > %{python2_sitelib}
> > %{python2_sitearch}
> > %{python2_version}
> > %{python2_version_nodots}
> > %{python2_platform}
> > %{py2_shbang_opts}
> > %{py2_shbang_opts_nodash}
> > %{py2_shebang_flags}
> > %py2_shebang_fix
> > %py2_build
> > %py2_build_egg
> > %py2_build_wheel
> > %py2_install
> > %py2_install_egg
> > %py2_install_wheel
> >
> > The following macros will remain defined for the time being to not
> > break packages that are using Python 2 as build-time only dependency
> > (which is also not allowed, but happens more often):
> >
> > %{__python2}
> > %{python2}
> >
> > The [
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages
> > Python 2 section of Python packaging guidelines] will be removed.
> >
> > {{package|python2.7}} will no longer require
> > {{package|python2-rpm-macros}} and {{package|python3-rpm-generators}}.
> >
> > Provides/requires like this will no longer be automatically generated:
> >
> > python2dist(...)
> > python2.7dist(...)
> >
> > The changes will happen after the Fedora 34 mass rebuild and before
> branching.
> >
> > Packages that used to use those macros in Fedora will need to be
> > adapted to expand the macros or switch to Python 3. In January 2021,
> > we have:
> >
> > * several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
> > ** only those require `python2dist(...)`
> > * several Python 2 sugar packages, but they already don't build and/or
> > install as {{package|sugar}} uses Python 3 now
> > * 13 other affected packages in Fedora (some of them co-owned by Python
> Maint):
> > ** avahi
> > ** gimp-layer-via-copy-cut
> > ** gimp-resynthesizer
> > ** chromium
> > ** NFStest
> > ** offlineimap
> > ** pygobject2
> > ** pygtk2
> > ** python-psutil
> > ** python-six
> > ** python2-cairo
> > ** python2-dns
> > ** python2-setuptools
> >
> > Note: Many other packages use the macros in a disabled `%if` section.
> > Some of the listed ones might as well (and hence are not really
> > impacted), the list is an intersection of packages that (Build)Require
> > Python 2 and are greppable for the macros.
> >
> > The removed macros and migration plan:
> >
> > === %{python2_sitelib} ===
> >
> > Affected Fedora packages:
> >
> > * avahi
> > * NFStest
> > * offlineimap
> > * python2-dns
> > * python2-setuptools
> > * python-six
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use
> > `%{_prefix}/lib/python2.7/site-packages`.
> >
> > === %{python2_sitearch} ===
> >
> > Affected Fedora packages:
> >
> > * chromium
> > * offlineimap
> > * pygobject2
> > * pygtk2
> > * python2-cairo
> > * python-psutil
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use
> > `%{_libdir}/python2.7/site-packages`.
> >
> > === %{python2_version} ===
> >
> > Affected Fedora packages:
> >
> > * offlineimap
> > * pygtk2
> > * python2-setuptools
> >
> > Migration plan if not possible to switch to Python 3 / retire: Use `2.7`.
> >
> > === %{python2_version_nodots} ===
> >
> > No affected Fedora packages.
> >
> > Migration plan: Use `27`.
> >
> > === %{python2_platform} ===
> >
> > No affected Fedora packages.
> >
> > Migration plan: Use a glob like `linux-*`.
> >
> > === %{py2_shbang_opts}, %{py2_shbang_opts_nodash},
> > %{py2_shebang_flags}, %py2_shebang_fix ===
> >
> > Affected Fedora packages:
> >
> > * gimp-layer-via-copy-cut
> > * gimp-resynthesizer
> > * offlineimap
> >
> > All use `pathfix.py -pni "%{__python2} %{py2_shbang_opts}" ...`
> >
> > Migration plan: `pathfix.py -pni "%{_bindir}/python2" -kas ...`
> >
> > === %py2_build, %py2_install ===
> >
> > Affected Fedora packages:
> >
> > * NFStest
> > * offlineimap
> > * python2-cairo
>
[ELN] How to handle RHEL-specific changes when it fails in ELN?
Hello, My friendly co-maintainers pushed https://src.fedoraproject.org/rpms/stratisd/c/32d87697075a846f9a3feb9ee66058287a91ccde?branch=master that claims that it makes spec compatible with RHEL (ignore parts that they violate packaging guidelines). However, it might make it RHEL compatible but for sure not ELN compatible. Moreover, I am not aware of any announcements that ELN SIG wants to not have any rust-* packages for RHEL 9. Any suggestions how to deal with this? 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
[ELN] "eln-sig" group is missing from dist-git
I have a package where ELN SIG is supposed to be a co-maintainer because there is something specific to their needs but there is no such group on dist-git "@eln-sig". Can somebody add it there? 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
HEADS UP: libgit 1.1.0 update with SONAME bump (in Rawhide)
All packages were rebuilt successfully except julia. It is FTBFS due to the GCC 11.0 upgrade (so it is FTBFS for quite some time already). The update is on the way to Rawhide and I don't plan to push this update to stable releases (unless somebody asks for it). Have fun during these holidays! ___ 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
HEADS UP: dua-cli license change since 2.10.7
The crate(colored) dependency has been added that is extending the license list from MIT and BSD to MIT and BSD and MPLv2.0. Thanks for attention. ___ 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
HEADS UP: rust-clap license change
Since 3.0.0 (incl. beta versions) license changes from MIT to MIT or Apache-2.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > ignatenkobr...@fedoraproject.org> > wrote: > [..] > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > > > > Comparing the size of the executable files does not make any sense. > You should use the "size" command. Well, I'd use `size` command if I would care what section of a file takes what size. In this case, I don't really care which section it is. All I care is that with -ffat-lto-objects, binary becomes bigger. > kloczek > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9LnrEACgkQEV1auJxc Hh53yw//cmMnlkGgq0/BiSIv3SOAPhB786QkhnIGx9QhntOx/6akOFyxp4Td5xDB tb/tpoTaZUoDS0FMT03Q2+BVEC6aYnLU3Q/g8gSYrNi+Oyscd8PMztIS+XVnrAhy kb21ZrEkbhVP+tLGNqtpOjvBdkG6lEttDUAZLx2KGl8xBA+qcTWdnt2ZyvkYjQyj rNYM+yvN08phsk8JpEeb8yNwTzfy5FaPx+/TrFhNzCRgx68ttWckEfJqLn0RqIfU bdDw/pVYTW9WmZDzq8kBuBS3t1k/hs2/Jdyqs3NlfXIjBe4BaSJ17JqdwZIUaKnC c4m3Npl/U2ENJ8wHGNkZPF8BcJK29PlXU8BGGrfRADIzs2JjnFDHC6kuxScybfKI Reyhhp70U3mMWeuzoHvZO1hOW88gzqAVbO8bQWYzDzLGEim0Uwa738BuMIZeh5tN hJ2flGM2vve7u1jXNvdis/8WidkptPObis6egH82hoTtmp4KWhjKVEgU6NK9AYpI NurwZzdiMrYXdP0D9iAEYvTWuivi8nYIBLJ3P3AZGYKn+O790Mbv97emrSgxQdrf rK6KsIUbH+ggR+k91YoT1iZaITjrGKaQOb/YAfOytkxBXMK5B/xZ0dpnzUXBHdy+ OgJfeUx9rlrYwVUUpn2KxZSbM+KgF4/mWIgg/fyREoZYuMHeVuo= =sRls -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:32 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:30 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > > > Hi. In rare cases building packages with LTO producing > > > > > > binaries > > > > > > or > > > > > > libraries which have bigger size then if they have built > > > > > > without > > > > > > LTO. For example 'kitty' package: > > > > > > > > > > > > * with LTO: > > > > > > - koji task > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > > > 1.79 MB glfw-wayland.so > > > > > > 1.99 MB glfw-x11.so > > > > > > 4.78 MB fast_data_types.so > > > > > > 8.56 MB total > > > > > > > > > > > > * no LTO > > > > > > - koji > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > > > 1.65 MB glfw-wayland.so > > > > > > 1.84 MB glfw-x11.so > > > > > > 4.51 MB fast_data_types.so > > > > > > 8.00 MB total > > > > > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > > > disable > > > > > > LTO for such packages? Or there is still could be gains > > > > > > from > > > > > > faster > > > > > > code execution speed? > > > > > I'd tend to leave LTO on, but it's totally your call. > > > > > Without > > > > > looking at the > > > > > binaries, sources and compiler dumps I'd hazard a guess > > > > > you're > > > > > getting a lot of > > > > > cross module inlining, but very little identical code > > > > > folding. > > > > > THe > > > > > former tends > > > > > to make things bigger, but faster. The latter tends to > > > > > shrink > > > > > code > > > > > with little > > > > > impact on runtime performance. > > > > > > > > From what I see in this case, -ffat-lto-objects generates code > > > > that > > > > is > > > > bigger than without -flto. -flto alone generates smaller code > > > > than > > > > without -flto. > > > The fat-lto-objects bits are not used during an LTO link. They > > > exist > > > solely to > > > cover the case where there's a .o/.a that ends up installed. > > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > That's quite bizarre. I'll put it on the list of things to > investigate. Hi Jeff, Any news about this issue? > jeff > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9Li60ACgkQEV1auJxc Hh4q4A/6AyqFOE64rYb6gdhdlqJWKZovmucbeXMnpq6wD0zUqrpvaUyyAaSjGQ6D tLs+7RC8rFqErfPDUsnSll90+HiHqHRp1O6UOLjRQ8EwbSVZGQ0e0l5NfrktRy8i mjMG1r7KrKbuRQi3/4//lg8PQroVvXLqNIuwSpLYiDYA3loJAra0+pdP2mSdiWpk zAn8uAx5wOLNmWKqv+OS6SU3oiJXAOezBgDSoF70fgxAep7qgv6J+wjLrtkl2U1G 3atZ2r7+pfvI5UiFp9/0CXT0ZW9SQRoXMza0OURZpvUIk21f0nYjQgXv4gEWttf/ 7hOO4n+tg3xqurgb91j7WW9VNEiMbACYTidv/jxhAqOwBj6jeozh5e0YrmsRZ3Oa ZN74SWXl9k2Omh8By3EaNappHCLO9Oxr0DTkt+hc2JNTtmc9m5SPYnl4nd+N80wd iqv1Cg9wG46cL+Ofnz+L03F7rzsXN0ywwoKOZMGwkPsGrmOFcxko4iJ4j7tzUCiz K0iJFqeYoh6oPRGomZ1+KZP+mlKGaV9GZ0FhdIhCOB0MV0Yshk+4TdW5OQ5sYsby YLL12yN/WKCRsm16XH1bT8hu8Qu56bued0HOn9PrYDqz4txa2+d6QdOLUFTATiOY QfWO+31o236UkWSjxc+Wc34KHox5vr+ueNrnDUaKtwOc7jpqvJ0= =zrRd -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Switching package to fragmented default configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-08-29 at 11:02 -0700, John M. Harris Jr wrote: > On Saturday, August 29, 2020 1:00:17 AM MST Samuel Sieb wrote: > > On 8/28/20 9:40 PM, John M. Harris Jr wrote: > > > > > Please don't invent a new logic, especially the one that systemd > > > does. > > > This makes it very difficult to figure out where in the world the > > > configuration file for a given program is. With systemd, sure, > > > it's not > > > so bad, as the > > > > System defaults go in /usr/share/. Admin overrides go in > > /etc. > > If you're going to put defaults anywhere, /etc is the most logical > place. When > admins want to override, they'll modify the files that are there. > See, for > example, /etc/resolv.conf, the file used to tell the system resolver > what DNS > servers to use. By default, it's generated by your installer or by > NetworkManager. When modified, it's now using "admin overrides". And only way to get to the distribution defaults is to download RPM with matching version, unpack it and get its /etc/foo.conf. When default distribution configs are in /usr, then you can easily remove config from /etc and that's it. > > > command will tell you where the unit file is. There's no such > > > command for, > > > for example, chronyd, httpd or any other program that itself > > > isn't using > > > such a convoluted configuration system. Even systemd wouldn't > > > work if you > > > blew away / etc. > > > > > > It should. If not, that's where they want to get to. > > What is the actual benefit of this? Needlessly breaking existing > configuration, making it impossible to cleanly upgrade systems, > or write logic that takes into account the existing configuration of > a given > program? If you blow away /etc/, you will have a well and truly > broken system. > If you want to start a configuration from scratch, re-install. > There's nothing > wrong with that approach, and it works very well. This has been the > case for > nearly three decades now. First of all, as long as /etc/foo.conf location stays same, it takes precedence over the /usr configuration, so nothing will be broken on the update. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9KnEoACgkQEV1auJxc Hh7/lg/9HGg1AQL/xLQbYqq7iyta/dMxEoPslIMuMFo5q2Q5c4WkvIWRXBXTYdRU hPE9KeM2byOcQU6q3OVg6Rs6XsBDX9uCjPNYjLcMf/tOLBZ5YjGXqXcotbGRpj2q dJK4J8skSW2VybaFO0Gm7gygFZwJoWQqK/G/n3tfhNp4C2PFE//PJDzUP0hsZlgM S5K5qnpIW3JPIk9bnDBK8AUeJwZIXoDkzPX+rLUXv4RjmB+/vnNk5Qupbewq8uRT WHu+YdZNeFdq4PpUvb1zVZgbXBgg+kHpdd75Rmf2hgFsl33ZGTkjgNYFkSzxYaPt vY7728B5Y951dYASvlL/V0yWjtTplTOxySPTgCTMrOgBjvQQZW2cdGINSXT5UmHn tHlAGh+lrSIorLLN8tGHKr4nDAEv2VUIb87/K3rGABEQ41yXiSul+vDR/hdiXqai 3l5ksSu4hvNwU1R5kPjfFEW6soIjP8smplbyDXjSfzO5rUhZbxA+YjEcwOVBOtuv CJgKham4RXmVbPtXPHnsBL9YsDvhcH3SIzVZkpzPFCbJDYzJFbfI78n1J4cacxnF UWJN/+9HGvRSFAa9oiNR6Lprx3dX3Uo1DCT4+TL8aZsRFSd9UrblJ/loUALwxkpz QEYNRSH8c3SpPUhr8xsJZBKHbHQrX27L7Pyz1v9u/HoXBTb4HEQ= =mzaL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about FTBFS because auf cmake change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-08-06 at 07:48 +, Martin Gansser wrote: > what do I have to do if I want to keep the timestamp? > > %install > %make_install INSTALL="install -p" > > > %cmake_install INSTALL="install -p" did not work. Just use %cmake_install. > > Regards > Martin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8rvB4ACgkQEV1auJxc Hh7xsg/+PrEjTTlFRmEWY8p5bArXeK59vW8YF3XOvDUBXe8EoPbBmWkELwsSBlWS pJ7Hgn5o7vrygUW5LRjqEUoMomNIJ90PcuNo6N44wRRkTFC84geBvCFKfftZVdmZ UEt4HDksiwzEp0SrqTAYZ8GwiUZ9P0rdxSY3J1v9QYriWoms9oENi+e6vGq46Lnl S4BEgi3fEjXgr5xkiaLiUoDnDmIcRgJHVeyLAD4ydx2lq3Do857BJ2hUXOeRlJfq GaEBiVTauMRcB8dZXXmK+c39GRTscJ3evyfgh1Umt9gMJLc/+HYyhnZUpmuZ4BWO OtKSfw5vw7czMNWBm05zJTw5AiZhxUWvPep6/igCxytH2jE4hX5TZIamETgHab30 YtQXmlP3VJJA3/AOxl7BA1ZA2RK8/ueJMBMFgBxGakT9FHjZagWMULw2JQ38UasM dk5OXjAr0MB8mnACDdBeY5KhYs+LA/ZNKnOjcKEX/AOTIObY3peWoPXN862FUp8X KB/oSnW8ATu+5wOUPEqGwsEJvVg061V9doyYAnhBDDNQKHyxALuzNeZX0ztHvjO2 GHWJFU4wu/uzTO29dnHJaOrUCAGo/24nDGul2OknxKPLLPBlumRyChd7+TsvtPDD x2+i62NXNxNQF4C6pP1CzShfVtxIh17Uqh7g4R+tUl2ekavnCEE= =Quwo -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-08-03 at 22:14 -0500, Richard Shaw wrote:
> Sometimes you need to get into the build directory, in my case for
> OpenColorIO I use help2man to generate some of the man pages.
>
> I had to rely on the power of Google/Gmail to find Neal's response to
> one
> of my earlier emails to find the answer again...
https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/
%__cmake_in_source_build
Controls whether builds are done in-source (when defined) or out-
of-source (when undefined). See the Defining source and build
directories for more information.
Links to:
https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
Feel free to submit a PR to make it more visible.
>
> %{_vpath_builddir}
>
> But that begs the question, now that we have updated %cmake, and new
> %cmake_build & %cmake_install, why is it %_vpath_builddir and not
> %_cmake_builddir?
>
> Thanks,
> Richard
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8pECIACgkQEV1auJxc
Hh4L7Q/+M7N/MJg0od9JZ2ri3Kcd7dtzd7WzU6X6/MPtoTtnTYd5AlJQM8zZYrfj
jLFM6Hd9JdhReUodTeXYMzcuIRctjFNJv3ycI7E7pF5XvkQc6rnie6e/NwrUyCUG
b0/I4F4RUpHQfAbR/Pa05lbBfFb1pN0jCoXsc77dLWLZ//FefBYEVYTdzc44mKhx
TMOX8MPapBlu6P4XITajcI/cXMwecqgSfGPmiGwz2aqn9Ec4415khsKhjhT6CnaA
IkgLGPHZwrO1WwZXnOR+TLR6QBpGyna3xLOCE7VskH+WmsYgd6UGTm+t86BFbBDl
hThVdjK4I+uV0SU7qVq+NqtOIQRd014aKBGJpl1pmadjJhvBApJgZyC8e83OiOLm
FC1OziylaOsYvJuUIZzBG7VMyFNM4J7YR8CKD4r0CLkvkCTT0Re0jzxmXzvZzQd+
mmAsvehjIHPG0SDti8521l22dN7pvkvVO0OAfb0XDXKAdQaIQnosZyEi2G3Q4w1j
kRNLyKsIvLdHaXMqqQ/6T/O5zkaSdM7vdD54HebdzcR3iVqy3TyaI8TmMsSlA0jz
DfSd5/+W/dIen6lBOAwVO6R935Y9LCt5IdD5Szbs75wAJNOyRLnwHj2I8beNHxVi
iaUNm4KdaKxupzqwiQ9EPpClssNdkgEi2HQi/q3B+PXSu57RrOI=
=ZYgX
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > Hi. In rare cases building packages with LTO producing binaries > > > > or > > > > libraries which have bigger size then if they have built > > > > without > > > > LTO. For example 'kitty' package: > > > > > > > > * with LTO: > > > > - koji task > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > 1.79 MB glfw-wayland.so > > > > 1.99 MB glfw-x11.so > > > > 4.78 MB fast_data_types.so > > > > 8.56 MB total > > > > > > > > * no LTO > > > > - koji > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > 1.65 MB glfw-wayland.so > > > > 1.84 MB glfw-x11.so > > > > 4.51 MB fast_data_types.so > > > > 8.00 MB total > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > disable > > > > LTO for such packages? Or there is still could be gains from > > > > faster > > > > code execution speed? > > > I'd tend to leave LTO on, but it's totally your call. Without > > > looking at the > > > binaries, sources and compiler dumps I'd hazard a guess you're > > > getting a lot of > > > cross module inlining, but very little identical code folding. > > > THe > > > former tends > > > to make things bigger, but faster. The latter tends to shrink > > > code > > > with little > > > impact on runtime performance. > > > > From what I see in this case, -ffat-lto-objects generates code that > > is > > bigger than without -flto. -flto alone generates smaller code than > > without -flto. > The fat-lto-objects bits are not used during an LTO link. They exist > solely to > cover the case where there's a .o/.a that ends up installed. Well, I tell what I see :) Compiling kitty with settings below produces this big /usr/lib64/kitty/kitty/fast_data_types.so: * Without any LTO-related flags: 4.52 MB * With -flto: 4.30 MB * With -flto -ffat-lto-objects: 4.79 MB Well, I did not run compilation multiple times but don't think it will change much. > jeff > > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bROYACgkQEV1auJxc Hh6dsBAApNegXihpiJ3SVr5IiD4pypEUDUNyBTY+Tp+HINNWdQHVivs2jYWwfVpU rNokkpq6Crgj68wznNGnwq+/eSP7DQwP3rN0TsAsfVydO1w0xBkz3zC47Y/7NPRR Ceeoalajz6/EqN89LDyYT/aQbfT4zbOV0ZTnUQrOe21URg2L1mUBSjeCoDortkC+ 1um7lyexAFroXmU4fQSdUMNTLrSolfFJPlkqeaaiJorqMvzex08xrv1D3vRrIyBD 6Z0NdPjB1nMbIWdCwTATYkbARzBH/88AUE3RZbjvRakr1BTBmsye3XaFts3Gn4Q8 ykINe/ImL+sDxm+cxKEAzafnr2GZQPvxYbwPjF+CEwDsBhqn92goOewgrrxNh+sq e9yf0vpJhmJBIq/hwPgvTihn9vB7oqxjT2/CFjIlNFCc5FyZfuSJPsyE/8EA4Vb6 9b8vj/q+gAlt9Ty/aJ+yhxQsO8zT0ZrVOi4L1/5RQna9HGca3YyKH4v9exHRMSpo HtbacKKg+7zYvVif7go6ERGBM680Pi5t6ypaH2cWOg4lRX50BVNn5NDpvatnOD/L VxJ1p+LmhRaoXT1Kzb4P5bNaSl+o7lPAjIjRk8osVll7m2jxFJxKfMLvnUBUaROj 5mVGA2JgdgGXKOdeFLHPsDmxs9B+EdR+PMzhMkcbww+MbhPXOiM= =gRTO -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > Hi. In rare cases building packages with LTO producing binaries or > > libraries which have bigger size then if they have built without > > LTO. For example 'kitty' package: > > > > * with LTO: > > - koji task > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > 1.79 MB glfw-wayland.so > > 1.99 MB glfw-x11.so > > 4.78 MB fast_data_types.so > > 8.56 MB total > > > > * no LTO > > - koji > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > 1.65 MB glfw-wayland.so > > 1.84 MB glfw-x11.so > > 4.51 MB fast_data_types.so > > 8.00 MB total > > > > Difference is 7%. What we should do in such case? Should we disable > > LTO for such packages? Or there is still could be gains from faster > > code execution speed? > I'd tend to leave LTO on, but it's totally your call. Without > looking at the > binaries, sources and compiler dumps I'd hazard a guess you're > getting a lot of > cross module inlining, but very little identical code folding. THe > former tends > to make things bigger, but faster. The latter tends to shrink code > with little > impact on runtime performance. - From what I see in this case, -ffat-lto-objects generates code that is bigger than without -flto. -flto alone generates smaller code than without -flto. > Unfortunately comparing this stuff in an LTO world is much harder > than in a non- > LTO world. You can't just bisect it to a .o or function that's > larger :( > > > jeff > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bQ2cACgkQEV1auJxc Hh4KkA/+LfGfZGjkZZcgJfgRYhVGdjpFpjdEjwTPQh/75IFnkd0q0BAJlHAxuvKA HQ0z/EQH5dfXIXtKYzg8+t+EHYjABPio+BSllNtv8OOAFW55TsRgxHCq/vDDjugU gM9urFXTvYnK8P52/EFMmZoIcg0PiLEMDArsoeUmHxzBDLSi4755HAsz/dz0VWxa BpJWWavTDHSFgkjMbqsrU/E9n/N0WdRdhaG1vuYEc80OLuQxGA9wSyT8fCOauGGZ 6qg2l93gHmQQys/V1PDOup2Dpjgr/GFEN3H0Q55UhdszXhfYKmipA0gS+rX7evyH jj9bYN+VMm8Qq9i7wmwPHsa88kYztozsx3vXYebpnuxgzG0uq1F+A2WoxkECtztc n5Ug0wUbYZSEBbpzxt7Tr9zaYoJ+TzdT8Ce+doub+P2fmnGO3Rhz87V0MGyiYcSG siBdnMBh26MwkQxRJkb5oR7WwCDmde2Rt7SmkVQuBI4sIUN418tif+bJUV+PMeMJ Q2hvqZryKeMHqGx7QmoUqSr5dMcZaY4zvMVbWggn2+qphNyI7gdc+QZMmtJ+5xeG ZpgKjMDofW8PWgD8Pn3ToeN/pyIzFFd17vvYY1sFD1ZpKE229T58eP6kWiMOnGyL j2/BI5UGjH0s+bhiUDLvfyVregBJRSxTptP975HLjjiP4GWUYN0= =taI4 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: License change for rust-crossbeam-channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-22 at 11:41 -0700, Josh Stone wrote: > rust-crossbeam-channel-0.4.3-1.fc33 has changed its license from a > combined "(MIT or ASL 2.0) and BSD" to just "MIT or ASL 2.0". > See also: https://github.com/crossbeam-rs/crossbeam/issues/536 Cool! That means now we can remove `and BSD` from most of the binary crates. Though now there is some other dep now bringing up `zlib` license > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YkQQACgkQEV1auJxc Hh6VZg//V/rKB+YmP3oejChwllmhDQSziv4k/meAYVs00s+R5jgEeM3AfbYJRtoj AYZqiABSNhyGGUVNNZySrOLgjpomTYhFW1HGMW+4NB8FSTKO4PaHBVDP5oJkzlzH G0+PulqAxI3Xb74rYsTY5JA2TQMf77DTRzm1EfOCDHbwd1b20x86PQ5777qFVkfg EzuoaBaSaNVSzkAaMnx+EvioCbMZEACPgs4t8O0tDU6ewJHMDYamFcIhHPztEBin U+wP0rvdBssqrwCRayXd4fSWxG+MQRVVmpmSQm40GFc0yB960lX9kAikYHNGoXrI IyGcdyEIVVry9R1PQFjQ7DxyGfk7bh4FC1JfSMUVo9NMZgToNN42ou2hWu3YqlOk Tz1hbBPcURut0gsfVEzVYtIiee9M/QmY/plkFDluRkBikwkfRyTL1JcstXNLRwGf ZG8eaqrLeSEz1j5Cgkm9PIUmy00C1frCRg1v4K2ORZVDpwASr1u1quN1zLGRjT7u F1IBv/3AnLZhlUAJAEXVhYjcC0B8Ho1a33C6EkoeINZi3aZ2LNAhv9pq9v3pzgnY BSy6w75gFNEsl9yk17VIcPjA3kemubLRg3IpX7DS5fH7OWIgczXZ0oNonowV0EMj /MIYSnrRVthFOCC6BhbfpkQ5CFiCGzPsN/m33fbFkCjukfHq4k8= =pdiZ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Re-sending with the proper subject.. = #fedora-meeting-2: FESCO (2020-07-22) = Meeting started by ignatenkobrain at 14:01:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-22/fesco.2020-07-22-14.01.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:01:13) * #2448 F33 Self-Contained Change: PostgreSQL 13 (ignatenkobrain, 14:06:06) * AGREED: Give one more week for the change owners to respond (+7, 0, -0) (ignatenkobrain, 14:10:27) * #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs (ignatenkobrain, 14:10:35) * LINK: https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs#Fully_automated_packaging (King_InuYasha, 14:15:49) * LINK: https://github.com/rpm-software-management/rpm/pull/1239 (King_InuYasha, 14:39:43) * AGREED: Ask @nim to clarify the proposal on those questions, revisit when we have the answers (+6, 1, -0) (ignatenkobrain, 14:44:08) * Next week's chair (ignatenkobrain, 14:44:20) * ACTION: decathorpe will chair next meeting (ignatenkobrain, 14:46:55) * Open Floor (ignatenkobrain, 14:46:59) * #2445 Proposal: Make the "shortcut" decision process require a specific request and assent (ignatenkobrain, 15:02:12) * AGREED: APPROVED (+8, 0, -0), bcotton will squash commits (ignatenkobrain, 15:06:01) * Open Floor (ignatenkobrain, 15:06:10) * LINK: https://pagure.io/flock (King_InuYasha, 15:07:11) * ACTION: ignatenkobrain to submit FESCo session for Flock (ignatenkobrain, 15:08:30) Meeting ended at 15:11:52 UTC. Action Items - * decathorpe will chair next meeting * ignatenkobrain to submit FESCo session for Flock Action Items, by person - --- * decathorpe * decathorpe will chair next meeting * ignatenkobrain * ignatenkobrain to submit FESCo session for Flock * **UNASSIGNED** * (none) People Present (lines said) - --- * King_InuYasha (87) * ignatenkobrain (54) * sgallagh (37) * zbyszek (34) * decathorpe (32) * nirik (25) * zodbot (25) * bcotton (13) * mhroncok (11) * cverna (10) * cmurf (5) * RaphGro (3) * pingou (1) * Conan_Kudo (0) * Eighth_Doctor (0) * dcantrell (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YWHMACgkQEV1auJxc Hh43+w/6A3xlVj4XSbz8CrUct5fpk5Svj/GxHmxBwSYnW8/G3rrRt1xxx/9xi5WU pzenY8OUTtDZ8c/27BaPQb2GF019q7WXuo0Y86Wb9m5cVYUjpvDxhSr0tZwRqIvJ Yw5voPtJgalFEMDvkxAr3VAXoryh957ZYvs9HsTDpmM6GLHdsRhlp9secTgTz0Z9 R/SRrKiE4qvlh922leTs+RkkhKEVwQ6EVvqC7o1q7gB0b0Kas+Pt4CBTjMs1XQ7e /Tv7mamYvxiKJ5FR4uMcDPNWff0qupq7otXRPBfZHXhpR0Oed9Iku7AQUIUgWgoA yfhflXAG9f5QsTEsryA/OgC0x491gdSJei2SrewNSZjGpceh0vHYqjv6gR4gLrD+ 3A0UAV8ZLf8Iup/HbHg0oGnMniRtwxBn7wh+mECrl32b7K3e3Y89Z179Kzhu9r60 k4igSpE/gbW6408YwqoNx4hgBOSNrA7e3rM6pynUdbobQV08ySp5AlzcCknZWFz+ WZ3Jh4gJGZOgwD5Hw5JLIVAuHvsCIaCjqCju0hUJ+UPRAZPbZo+kVyfQjcDwAA5e Afkh5kCEm1N0YGRIwdPs8GBclCc9ooNS8KN9GKGTtMf+9Djrb808oc+CtmP4PRto zXStH18CxqEiGwPynQGOwEzu0HSsOlOkEo9yReeO+2GpVIpWK8k= =oeeH -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Wednesday's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = #fedora-meeting-2: FESCO (2020-07-22) = Meeting started by ignatenkobrain at 14:01:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-22/fesco.2020-07-22-14.01.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:01:13) * #2448 F33 Self-Contained Change: PostgreSQL 13 (ignatenkobrain, 14:06:06) * AGREED: Give one more week for the change owners to respond (+7, 0, -0) (ignatenkobrain, 14:10:27) * #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs (ignatenkobrain, 14:10:35) * LINK: https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs#Fully_automated_packaging (King_InuYasha, 14:15:49) * LINK: https://github.com/rpm-software-management/rpm/pull/1239 (King_InuYasha, 14:39:43) * AGREED: Ask @nim to clarify the proposal on those questions, revisit when we have the answers (+6, 1, -0) (ignatenkobrain, 14:44:08) * Next week's chair (ignatenkobrain, 14:44:20) * ACTION: decathorpe will chair next meeting (ignatenkobrain, 14:46:55) * Open Floor (ignatenkobrain, 14:46:59) * #2445 Proposal: Make the "shortcut" decision process require a specific request and assent (ignatenkobrain, 15:02:12) * AGREED: APPROVED (+8, 0, -0), bcotton will squash commits (ignatenkobrain, 15:06:01) * Open Floor (ignatenkobrain, 15:06:10) * LINK: https://pagure.io/flock (King_InuYasha, 15:07:11) * ACTION: ignatenkobrain to submit FESCo session for Flock (ignatenkobrain, 15:08:30) Meeting ended at 15:11:52 UTC. Action Items - * decathorpe will chair next meeting * ignatenkobrain to submit FESCo session for Flock Action Items, by person - --- * decathorpe * decathorpe will chair next meeting * ignatenkobrain * ignatenkobrain to submit FESCo session for Flock * **UNASSIGNED** * (none) People Present (lines said) - --- * King_InuYasha (87) * ignatenkobrain (54) * sgallagh (37) * zbyszek (34) * decathorpe (32) * nirik (25) * zodbot (25) * bcotton (13) * mhroncok (11) * cverna (10) * cmurf (5) * RaphGro (3) * pingou (1) * Conan_Kudo (0) * Eighth_Doctor (0) * dcantrell (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YWA0ACgkQEV1auJxc Hh4dRw//Saw76tSw4ERLwRoMCwfSioK+nkjLTrGO3+y6EZjez3LZWwbx8QDy3sAz ghunCu6KF8OXBPzxuZRY7euE7qkF9HYNjSQe9zNGSXJi9afyH0m4CrLIctTMFEDb m9cB7RyN1oez/Qeiw6U4jBRlWkLlyYghiml+Z91HbGZPTDWZwZFNmnAs+zB5Wqm4 v5HD6IcxvL7L6f7vX272frjrr2Scjq86Iao5yY6GsAsSA49iZIeVLGEu8KktYfLc lWrJjZMtNt19DZ7cXzqAwmdsUggx8WEp8Dabb1vQblb8Hw/DfU4atGopB+Ns1JEi NipA6gpmGGah7esnx4be45wFLpSE3NFQF7zqTBRcjE7Sl4dLYzE3zmSyKDDV6i/f Xv7X675INCmxWEYkyT1NcuqXKQg1ZcWM3tytOYx4KrVof7TQBT+ET00Db0T/HYfE uUrBu7VSmwPRb9zOaB70kXLGx+Bovuf34ATtn0CPJtFwxuNTjPJlsx/XJMtLVwSX 4oO1nQS/tR0Cd8ki31y+2f6MmoUWIHvI3aYBree2z3jB+5AiH6jAlDmRjIQT4Pow uvEwAhoFM02Yf9UIYv+pPRtAi6oLbQzCyVpfy61V1HQxs3pCPfnvGGaK8yVlBmF1 Ls/9+/h+xgDuzpIzho8m67s7mejHJsf36J6KJQnjOPkGrqn5iwk= =5+mx -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2020-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-07-22 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F33 System-Wide Change: Use %make_build and %make_install macros https://pagure.io/fesco/issue/2420 APPROVED (+5, 0, -0) F33 System-Wide Change: Golang 1.15 https://pagure.io/fesco/issue/2450 APPROVED (+7, 0, -0) = Followups = #topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs https://pagure.io/fesco/issue/2440 = New business = #topic #2448 F33 Self-Contained Change: PostgreSQL 13 https://pagure.io/fesco/issue/2448 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8YHekACgkQEV1auJxc Hh7/mg/+J0LzJuhQv/nE0tR6pgZ96rACCx75GMLR4+xB0HAexYbMjCtcjml50Fxc WAIRw2gO+DMd5piH26tuUf69lHl86mZ1oP15o6K/Eb6fxsZcFlWdvD/f9+TFTFIW gApaKCl6WP4zo40h23o6w47QqxGX1FoWGbvZWlduvegb51Dv2MvMYq2SP0NACWCG U3T90kOM7BLZGv1cdgw4Zon7kF0sjYOi5bWWZBHgD+eMzgPYJnNh1Ee4gQzXiS9a Y5JretH0uIFyv7JM9hD1qLr0ti1HTx8ZiqyXEsCdS1iDowm+XhUlEzOYyxdtqAsi jHn6r6Aqdng9pXpqT49jhJOqVmO95Nwy45nu01iGJx3etlfDQNqcKtQ/KtLKvZBr n2SKZ7F2YA9aIgvVzPo63uNkl9QpUs+0HhBzP8uASN1TQREucqRKYMfdFQ0RDl87 6D3jGUzZeot58aWVdJ6kJl9Y+b0OObOU8ceDoQSttiWVirHD7MTSuohtXs6KKrvf Di7C20YlyRP8mSDAgeV8cDJ/qY+SkgWqa2igmqUA/g/ZEu1+eCVOqPggdWT2StIz GDdjFAxIXSqic9vWrh53sWE7rJODmfw+i0C177btQTCvMQ1E5wRPZ949/gye+8UA H9Is+iuGutFNf0ROSx5Doy3VtZYgOaP3juNmOqoYVdhQV+5Ie8s= =0cum -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: make: *** No targets specified and no makefile found.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-22 at 07:24 +, Martin Gansser wrote: > Hi, > > cant't built guayadeque on rawhide [1] but on f32 [2] it works. > > [1] > https://kojipkgs.fedoraproject.org//work/tasks/4781/47574781/build.log > [2] > https://kojipkgs.fedoraproject.org//packages/guayadeque/0.4.7/0.16.20200717git3c54f64.fc32/data/logs/x86_64/build.log > > how can i solve this ? https://src.fedoraproject.org/rpms/guayadeque/c/00777277ceb0436439e0f670f3460e7bbe1c5984?branch=master > > Ragards > Martin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8X9RAACgkQEV1auJxc Hh4KOA/+N/90Bik7hgxylmEzSYNMQWiDqd+9/BXP4qv0g/o0lfU0ukF5tjGn7IV7 jtfsWXzeuPKkpU8uHXqp4al36nSCCLIZ7m/jI9XJnFyP7IN7HP6Bqz/M/BcTmoRq 8l/5ruSrEnhtzCl8OeXYwKjPad+2E6r7HLGU9iwB52B7bRi/ZNZl8b7S2lgiiej9 L576W0WGhFR2Ez9CTlcopKZy9mWAN2xQaidNQwqJS5E9GYJuOx/GaeedFYWldEUU 0CDtAP/ZdxibM0kvbVt2VIGZa+i0ibIxmTVxoMql3mkAnEF2NEu2lN3+CqAsf8TP TjW4S4jVTLP/ucwOrdUQlKmVjzaRqZfIKadWbDKmBj47cMV8dw6fESGVdZx97kdG gPnnXiVuTu9Y9mc2+9tgd154S0vO9njzltCYmVglwwn6Dx9gGHusUnu5hLeWmsN7 35yoZNSNZ5JpFYm+TQFiPGUABrbtM57ScJ5kon+j2Z15l3peKezkjekPFDZep/Ao Qe2j8vg+oH0YRm4SyTOSFf39S1YByaXpn1ZSQnqWWx1DnnM5/vjznKjVPhiF6GFc SbfgZdTemTwO6aFr5/pqxg7jm+QmmMePOO0UusDpINrZf0DIa+I+voxU//l6eO26 iECFgerNP/s5HweOKmI2ZEZF6M5JBzGabTwmJguS3snmPHZLeHo= =M/JT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: SwapOnZRAM and how it affects earlyoom thresholds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-07-14 at 01:28 +0900, Alexey A. wrote: > > The most > > common value I've found over a long period of time, for swap > > without > > hibernation is 50% of RAM. > > With low RAM (2G) it's easy to use swap on zram with disksize = 150% > MemTotal with opening browsers. > > 50% maybe OK with MemTotal=8G. > > > I'd like to hear from Alexey what he thinks about further reducing > > the > > values in earlyoom versus possibly raising the cap in > > zram-generator-defaults. > > It may be OK to reduce mem cap to 200 MiB. This threshold also can > work > well and may be sufficient to prevent freezing. > > I would suggest to increase zram disksize caps up to 75% and maybe to > 6GB. Please open ticket upstream with some more details, please. > пт, 10 июл. 2020 г. в 01:19, Chris Murphy : > > > On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter > > wrote: > > > > > > part of some irc discussions on > > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > > > > > raised my attention to related item, > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > > > As it stands currently with earlyoom, it's default thresholds are > > > 4% ram > > and > > > 10% swap before it acts. That's fine and dandy. > > > > > > Upon reading the SwapOnZRAM feature proposal, I see it is > > > advocating > > > allocating 50% of ram for swap. I'd like folks to consider and > > > evaluate > > how > > > this impacts earlyoom. It effectively makes the earlyoom memory > > threshold > > > double (right?). If so, at least think about lowering 4 to (2 or > > > 3), > > since > > > that will make earlyoom's behavior closer to before swaponzram > > > was > > > introduced. > > > > > > Thoughts? > > > > The net effect is that earlyoom is more likely to trigger than with > > a > > disk based swap because right now disk based swap is huge by > > default. > > It's huge by default to accommodate a hibernation image. The most > > common value I've found over a long period of time, for swap > > without > > hibernation is 50% of RAM. So this approximates those expectations. > > > > I'd like to hear from Alexey what he thinks about further reducing > > the > > values in earlyoom versus possibly raising the cap in > > zram-generator-defaults. I don't want to get too carried away > > there, > > because we are applying this to upgrades (wherever the to-be- > > obsoleted > > 'zram' package exists already even if not enabled). There is an > > opportunity, of course, right now and through beta testing, to keep > > on > > testing variations on both the size of the zram device used for > > swap > > and for earlyoom. But we also have another Fedora release, Fedora > > 34. > > So I'm more inclined to go conservative so long as that itself > > isn't > > causing problems. > > > > One thing I'm a bit skeptical of with reducing earlyoom's triggers > > is > > that free memory is needed for the recovery from an actual kill. > > Usually this is just sigterm. That's the first attempt. If that > > doesn't work then earlyoom issues sigkill, which is at a lower > > threshold already. > > > > > > -- > > 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 > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Mj3sACgkQEV1auJxc Hh4y9w/9GujtHWfY2C2QDcUfSaFwkGIgQgBP4oN4LC2QUlQyyQNAbMk7G
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-07-11 at 10:33 +0200, Benjamin Berg wrote: > On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > > > == Summary == > > > This proposal adds cgroup based resource protections for the > > > active > > > graphical session. This is done by passing a memory protection of > > > 250MiB to active users (capped at 10% of system memory) and by > > > enabling other cgroup controllers (CPU, IO) to ensure important > > > session processes get the resources they need. > > > > Just curious, why 250MiB and not some other number? > > Initially, it was an educated guess (i.e. it seemed low enough to be > reasonable and high enough to be useful). > > I then continued to do a bit of experimentation and found that my > gnome-shell would stop page-faulting quite a lot if I gave the > session > processes >=350MiB of memory (measured by manually setting memory.max > and using "perf trace -F -p X"). > > Tejun suggests it is sufficient to protect around 50-75% of the > required memory, so 250MiB still seemed like a reasonable value after > those tests. > > Note that it is easy to change, simpliy modify /etc/uresourced.conf > (and, ideally reboot to ensure it is properly applied to your user > session). Thanks for detailed answer! > > > See: https://pagure.io/fedora-workstation/issue/154 > > > > > > == Owner == > > > * Name: [[User:benzea|Benjamin Berg]] > > > * Email: bb...@redhat.com > > > * Product: Workstation > > > * Responsible WG: Workstation > > > > > > > > > == Detailed Description == > > > Graphical sessions should always be responsive, even when the > > > machine > > > is doing a lot work or in the extreme case has started to thrash. > > > We > > > have started to ship EarlyOOM with F32, however, while it is a > > > good > > > solution to this date, it is shipped with the understanding of > > > being > > > superseded by other approaches in the future. > > > > Does it mean we do not ship earlyoom anymore or what is this > > sentence > > supposed to indicate? > > EarlyOOM is still very useful today. However, from my point of view, > EarlyOOM is just an intermediate measure until a more advanced > solution > is implemented and can be rolled out to users. This solution will be > based on oomd (or rather systemd-oomd) and will make heavy use of > cgroups to work well. My question was more targeted whether we are not going to ship anymore earlyoom by default with this change or will they be both shipped at thie moment until something better is ready? > This is a longer path, shipping uresourced puts us a step further > down > that road. > > > [SNIP] > > Benjamin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8JsGwACgkQEV1auJxc Hh4eYQ/9Fmqs5eP9swk+JlsIwS/KiUzx2IkPDeIsdu0bGdLFpm6/ElRtEWLQMAnP vHEX35MUNWwbnphNTMsFUqWUDQ7UyfaBRak8CPpggkNCCiDERJniyx9TEWaV6X9O cNdCDo5opOgfmjOf5Sn71ucf3Hg0IePE3W9BiwHne7CAqkXrPmouYa95GD6T/gFE WCbQIqPTFFYgU9igaU5gUcOLJS/TwJe9ABB8tH+gfolPBG+c+UaR1BepGJH8+9e8 3ixjEedcA4Hh5iLPxpPX5nmw91L81kENhLGWhWWAa8TbkImLQ2SC+Phb57lll3PW 0IaJuRMvTV/rD4fMqWpKgdwNHwIe3dqzAvjF1gsYjmPHaY0dFRcxYBI/E0WLna2q /IYEzehUDbFZggPN8L+y4s5xywDq6xvbHLCemrSwzW7zB7Q6cfgQkUUUk/MntAwQ PvcV5Mb5eQqia4aMMUPbtgnuhU56AiQoA95MNpH+xVTyMqcOUUlci73x0rcbNc1P B2QPydWeUaK6chsO5LIDnPhcRkf874MRMZfRgYfuEUSNRl8fa0bOPGYajjOu28hV tJXiXviWQNa2rJLhey3CJCbTRWyestLZCmR6oXcU2vX1EniNh9f7lvpjt4KxZ9pe L33Bj0znhpBg5YDni4bFgG+1eKQqSXS1E45dlqzg6XdfE/3noeU= =yzFL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
; * Running mprime > (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); > choose local stress test, repeat by selecting 15 NOTE: mcatanzaro > has reported a huge impact, with both the session remaining mostly > responsive and EarlyOOM not kicking in (this makes sense, as overall > memory pressure is much lower, i.e. the session is waiting on memory > related IO less). The proposal owners have not been able to reproduce > this corner case so far. > * Log in two user A and B (same seat), run `stress-ng -c NCPUS` in > both. Switch between them and look at `top` to verify that the active > user gets a 5 times higher CPU share overall. > > == User Experience == > See other sections. > > == Dependencies == > There are no further dependencies. > > == Contingency Plan == > * Contingency mechanism: Remove uresourced from the default install > set and possibly also remove the preset again > * Contingency deadline: Final freeze > * Blocks release? No > > == Documentation == > Upstream is identical to the change owner. The upstream repository > has > a further README https://gitlab.freedesktop.org/benzea/uresourced > (which should not contain any more information than what is here). > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8JX4MACgkQEV1auJxc Hh69cw/9EUQU5YlPWl+yjOOLvMJ05Y27Eg2bg1INzde4iZIkuIydHS/ANXj9zIlF oMIbb7d1Gzh342Spdi7ANg7FdG23EnStJXWvDJb0XRVOcnbf6NIV0xttELMnSij+ NVMrdcmF5Vl2MI2HMBNfvLeyhCJAX6W/chf5lnyEwAWsEzRfagjs8I3WAMK6ZXr8 rMH+emU8xslhlTfON8tc30uvLWPAqkh85Md0X+Wl76lA+d09eCw0VsOQkI7hODKS l7L9s6mW1cpHv3wm9RmSJ3U3kq1IPCE4WvkjLcJIVtL1xX1qigrfBNnOXOjvdP+9 z9Ln4InzpmL/jsL6u715G9s0SE7MWelilN+K9juU8e2DZsqBBHY+S1j+YO1NZYXL K3jDH9Kr157jpyZnrBNcRzYJSt9wEL+jjNXtaErlfpwUsKCiIKeC7gaLFEbNS6Re iihGhJbHaRJB8O178s7WfUMD4Z/7EQoawBENKPLnxMsPdqkNcQC+1y9EGIs+PaQ5 I6L7FzhiSlqMrc8yQTXy8ebZKCMLZYy7bhLbrlhe3jYXHNHxCowyY2STBHiIYqkr LuqM5yo7+LUj7XIi4wTYFzXMhlkR8RZkDyzfe18tIq0Qvvrc2aOxPnjeUVZzPYkt NmKZIsQpw2ePGjNqWNSEk7tI5XeskrJEA4HRO26T2ydMBdgTMLE= =sFT5 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:35 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote: > > I don't know where / which the fix should be: DNF, comps or both. > > Simply putting the fedora-repos-modular in comps won't help since > > DNF > > is only using them when running `group install/update/remove`. > > What's to fix? Sounds like a feature, not a bug. It's well reasoned > above, > nothing depends on it. While it is behaving as it technically should, this is unexpected for the users. That's the only reason why I brought it here. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HMmoACgkQEV1auJxc Hh6K0g//b+BUTmjacqKE2nktWTdJGjmvqhVOuCvKp65i/EQV9CMtGidex3mEZnMN M/BT1eT8ZhLAh+4X1CVYxLzmknpOSKBbeK48kjBLzSXFvLRifgw7GXwnTkwp7TG7 jBlXI+k+qQZYx/Bsm09tgMNfiljHf0nsg7VpMkI4oVxmECx143LpNbZii8RI3dFc 0LX8vJ4KcEuE4Md3pORCOMGL6SDYrdBr/H0b9X2isY/JlsMWvIqMI1dZyodz5jMZ 2wCcscU7khpRNxmDI3xgnUgq9FwJnfKDciXG6EhUXTxA86kn1G7GvLaOw5zdZdDG 9mNjVaDLyL9Ik7fmbzY60/0mAYA4QK4L9s3yt/dVKDNP8LCCJR/ny+zMApimQ1jH Irgy4/XNJYWyhCARqGjoXGOLlguW3vjaTfA7+xZzvm1Hjk9D8fgAkvFQWwpzeFIm /Xj+nL4L35Zz5uOxYznUg/nmASV1jK+kvgGkf+RsGTx+MtYyURRekngNjVfT8BCb 3DRSmaE9EN9EH4A5ZBZNVATnhMGso6QB+B/HP5NUGBGKUlRtZ+uvGCV4c4omVZBE t5ep9yczF+uS5p+3YwzxT33AyVRnGYW2/uxuyXNEYz+yTCOAqCSk67/IpQe2wYfL 0oX7gu/1iNyZMYqdnnc+Crz7DbNKbmt/APbp2kP0Q5f4a7EYWCo= =j6pN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote: > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" > > action on > > a system upgrade, because we want that package to be prensented on > > the > > system. However I worry that DNF does not possess a capability for > > doing > > it. (Except of injecting that command into some externally executed > > script.) > > Unless I'm mistaken, it should only be present if the user manually > installed > it, and opted into modularity, right? No, it should be installed by default. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HLXMACgkQEV1auJxc Hh5HOA/7Bf+x4zEaow3IVuBEbDgg97oe76kivIOyHnCySWp8xPVCgHPAo4NnBem1 534aECZMKZO6zRfSVPjkvxiImUy51TKkMy//OOUl8YJrb/wD6fuUEr3BrMkvDbdC ztIswL7wnnPLAQIE36JbmzvOLcyfZUp867rgbB7nDCwZ+3GAX1u4q8UZXCn/4FZl z624gtab1VGqddvN38nih+nGPMTOXLGEafhGaz5Y9tuFcZKA1nfSPn8HDNNieNNK 3lii2e9WHFgWJc7pbahDGbJGRC1YK8wDLDtfcr7FG9VBtkyWsErjI1VEhd5YUCld ex8aFRvA5SnxuvZriyDWr+DTITQXmGEPYxbXSpCM7Tufl42ZYccWr1EV0w5bWjf3 jKkM/zzb2P8CGomA6XWNkO43fVwjG6LTHpsq1h4q8EomXUfRNh4UfMYtOC5U3Nj1 5sHaMJJzzPHtzpBLEeYX2ns323bEr59Nc3qsbmfI7hiyBZffXYC1/LkJIaMxW7Dy Fufswm13S06330VGt1QEaa379opyUkLcFMs8SdGjGY5RCTA2CEyEL0VbZuwSC+ql B7bK0MvzuPtZpZ6CRgJnd0gMlMo29NQ9GOetYzLgHk52TkvTpj35vPtcv4/klRVI lKxwyizOi2aAWB+tMq3LTfs3N48/XTygMIZcavOp2p6b/EJc//o= =oXCM -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PSA: dnf autoremove cleans fedora-repos-modular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora-
repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora-
repos (DEPENDENCY) and nothing depends on fedora-repos-modular so it is
not needed anymore (from the solver POV).
The fedora-repos is being pulled in by fedora-release-common (that is
brought by fedora-release-workstation or others). fedora-repos is not
part of the @core group in comps so its reason recorded in DNF DB is 1.
enum class TransactionItemReason : int {
UNKNOWN = 0,
DEPENDENCY = 1,
USER = 2,
CLEAN = 3, // hawkey compatibility
WEAK_DEPENDENCY = 4,
GROUP = 5
};
On my laptop:
❯ sqlite3 /var/lib/dnf/history.sqlite
sqlite> select trans_id,name,epoch,version,release,reason from
trans_item join rpm on rpm.item_id=trans_item.item_id where name like
'fedora-release%' or name like 'fedora-repos%';
1|fedora-release-common|0|33|0.8|1
1|fedora-release-identity-workstation|0|33|0.8|1
1|fedora-release-workstation|0|33|0.8|5
1|fedora-repos|0|33|0.6|1
1|fedora-repos-rawhide|0|33|0.6|1
21|fedora-release-common|0|33|0.9|1
21|fedora-release-common|0|33|0.8|1
21|fedora-release-identity-workstation|0|33|0.9|1
21|fedora-release-identity-workstation|0|33|0.8|1
21|fedora-release-workstation|0|33|0.9|5
21|fedora-release-workstation|0|33|0.8|5
143|fedora-repos-modular|0|33|0.8|1
143|fedora-repos-rawhide-modular|0|33|0.8|1
143|fedora-repos|0|33|0.8|1
143|fedora-repos|0|33|0.6|1
143|fedora-repos-rawhide|0|33|0.8|1
143|fedora-repos-rawhide|0|33|0.6|1
The packages that have been brought by the obsoletes inherit reason
(DEPENDENCY in this case) and since nothing depends on those they are
automatically cleaned up on the autoremove.
I don't know where / which the fix should be: DNF, comps or both.
Simply putting the fedora-repos-modular in comps won't help since DNF
is only using them when running `group install/update/remove`.
So sending this email just in case somebody will see this interesting
behavior.
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8G97AACgkQEV1auJxc
Hh6SkBAAo4iTvTmSImNbSRAZe6VzKfUJ1gBPjgMITEueM7pxa8zlZ7g2bOpl1UiI
TD+DKI953Qk2gZcN+WBvkQO13Cef/FD/lp6nGXvyo87mOs2ThSc+a6UgufEBceVY
Z5kGCoCQnfA6JkBtRtFdMbsCvVKtSRSOFJXlW7DCybLGKizUlFPqHdug0qxGpoO2
XWldoX0Bw0F11Pr2FqujZXlcfXe5G51lkfPFnChc0a4O0+d0/AsWZJ0dM0l1ff6l
GT43t+boiw9Dwp8KEBZTh7uTWQAeLAo9UxGIs2T2oZikHNwSSo13N6nwcS6x2XYd
AaHVET5dn4tITH9WjiknS9IHy06D5MZ8pWBRs46aav52Ro6GxNYeALYdhjaM2heG
mMGkjAWkXJ0qtaRR9qi68CfQiDfQjzYe0JXEHJTrLV+Pv42OrJJJoq7NWGOJbqV0
T9DYJoO63W74q/rttMNVMIBG8GtzbTBqoxuP9ooykpAzRv2LPn1Jc1L3eEBXSO0w
QW0SH5i6v6OgajCrc813TytboOua9zDZ55ENP0dJNXjqAiznZJjqrYG3RWUJH4cA
qx6xygK3OvZHm9vuL4VnXCp4wW/TDGf8MNGF0hoF75IbRN1+nrAAtGorx9BdV2g+
SvTV1Cs9CPyOKy0Q2brILtBZq6em6JNzkFAMg5h9xoce4brbyA8=
=UXSc
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote: > On 07.07.2020 19:57, Orion Poplawski wrote: > > What's the plan for EPEL8/7 compatibility? > > +1. The new Cmake macros behaviour must be backported to EPEL7/8. Feel free to submit patches to cmake3 and epel-rpm-macros. > Currently all fixed by proven packages SPEC files cannot be built on > EPEL branches. > > -- > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Fx9EACgkQEV1auJxc Hh7JzxAAtK8VXZz+jEdw1KICPRBOnsRvEcPBzpXbT7SLJd+84HRzxTFnWWJKqn3I 8hOKDl+lm00DKnplcIVPQXJ2g9CkV3a17bDWFGq9oW47eyH97lGRNUZifTKWcv7n OJNBB3OsU1jbhkKs0WtCX8NVmux2w9C/pCrSfcxCXxiWT7vz70NALqPX526sCDyb 6Unid5W/dZ35xl7tWmLm4WEwefpDOoCUF+khc9x8JPY6laczHmPk1RIdZ6g9a2FI Nwe6GNry1CWP22+wqxJlNQI0AEoev/olerIRD9hZ/TYiH+fRGqcOSefKDLE5TE3Y y9SF+5pEsELZgZm0hnI8b9QjIiNjf7m7RELn+Pdm/nS5eqJyIKuUUr/Zz+M4oDYW aZ2xToIyak769PmF6wr7x3oMAiT/OkvZRzwdpB6lC7cDslMAonsDisFIK8D7kE8x du/fHb/tIbbYuVVm4CnhxxY304U8NmBxCRsXZIYJNKdinG0nSAZUdy0Z5UqRk5VQ Tt2NMjSRBa2jV+AurM3thRCrJaVf6oPTKb6+pUsM6fBCF/HAoDN52AstxXNB97sS j/yOF4rPFg9N6i+ojDF7893n2ThkZXFERiqVTg2CWozLzK1g8AwfA66J38B5FQBJ QhL9vp8IO/aSrUa6pcfTbFTTozMncz7XZUDl4uStLFgUvkSzLxQ= =TyCb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote: > Richard Shaw 于 2020年7月8日周三 上午6:11写道： > > > Ok, so it appears this change was for F32+ only, so I can't merge > > master > > into f32 or earlier... > > > Maybe wait it to be backported into f31. The documents said this > will be > backported into older supported version. > > But now, merging master into older version is impossible, can cause > FTBTS. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6 Test them and leave karma please :) > > > > > This whole change is still broken AF. > > > > Thanks, > > Richard > > ___ > > 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 > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8FjcEACgkQEV1auJxc Hh6+yxAAoJAojZ3en5ip2Lov+rciwDYKQaNW7231oYN2FsuG5EakUtu9CPjCAjRW 9n7W7Z2QmkrV/aPg3V304n4UFfNiKp01HHVF9vco8ljryrJObWSgwhzsv/8VO1k7 O+3rSieII8TcUyupAP5VfEqgJb0GFqdPeJpDNh3kovMbDAH6kdEH4ZGmwg/+xoPn 7gNBNl5r7FBik9i8nLhxm3sgglw0zjzAT1ac9PFrx8fx7eXo8clbuAD0i6bi8qJM 7i0NSTppf0KaeDRv88VZUwQMeZmjL2FrUvFIiWDlPvynjqZ6aGa4rNnJrEOLYbRy mpZTYa4qIWQ4+rgwwQbFfHoc168ZDenoWLR5YE+Qr/SzlyFN09WPmwffnFELHCX+ DJgv2vUHbwpAW7WTDrwjPLb2vmfK3wtI5StPGTh4Ntp8uy7j/B2hZipvub1TLeDb i26ouzKmHDOohizWrA/CQwlpxx7qFRPl5NuQveCp4oV7A8Xram/2h/J9UEA3skxr +3m5RJBtjUVWfdMGUkxqL88H/WN4Z6EkCQXhnZA9IAU043kORu3uImMArmv3ZkPT rhiSq443HNIpvUOd0nwtxx3O47YSv9uvQWY35PL27VqSznzuPnK1MiOxShF3w/iR MpYadfe/lruo6xwppPUhLRqilumQZDUUZuZptWwVwV5ykBkRxfw= =IeUt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 11:57 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Ex
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 12:07 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing pa
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest` is executed.
If it is set to anything, it will use `.` as a directory so that build
is done in-place.
* %cmake now always passes -S/-B options.
* %cmake_build/%cmake_install/%ctest macros have been created.
* %cmake_kf5 changes are in progress by Neal at this moment.
So far these changes are not breaking (it becomes breaking if you unset
`%__cmake_in_source_build` macro), so we plan to backport them in
stable Fedora releases so that spec files can stay compatible across
Fedora branches.
I've ran scratch rebuilds of ~2k packages that are affected (not
including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
will be lower once we get %cmake_kf5 changes are in). The ones that
failed are:
* 141 use `cd builddir; cmake ..; make` pattern
* 823 use `cmake; make` pattern
* 96 failed for irrelevant or overlooked problem
Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
of-affected-packages.
NOW: I've booked 4 hours session this Sunday with Neal to go and fix
broken packages. If you are interested to help - let me know and I'll
send you an invitation.
Will keep you updated :)
On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> == Summary ==
> %cmake macro will be adjusted (-B
> parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the
> older
> supported Fedora releases) to perform various operations that are
> commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> etc.) way.
>
> Packages that will stop building are trivial to fix and will be
> adjusted either by maintainers or change owners.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> Esser]], [[User:ngompa|Neal Gompa]]
> * Email: ignatenkobr...@fedoraproject.org,
> besse...@fedoraproject.org,
> ngomp...@gmail.com
>
> == Detailed Description ==
> Historically, software builds had a singular build configuration and
> required running the build within the project root. Nowadays, there
> are many build modes and options that can be configured in projects,
> different build settings (e.g. compiler flags) / types (release,
> debug) that can be applied and different tools that can be used to
> actually execute builds (compilers like gcc/clang, build job
> schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> discourages users of doing in-source builds and recommends doing
> out-of-source builds.
>
> From cmake.1:
>
>
> To maintain a pristine source tree, perform an out-of-source build by
> using a separate dedicated build tree. An in-source build in which
> the
> build tree is placed in the same directory as the source tree is also
> supported, but discouraged.
>
>
> The other part of the change is introduction of additional macros is
> creation of set of macro that can build, install and run tests in a
> backend-agnostic, vpath-aware (out-of-source, in-source) way.
>
> === Migration ===
>
> %cmake + %(make|ninja)_(build|install)
>
>
> There are multiple paths to complete the migration:
>
> * Add -C "%{_vpath_builddir}" to the
> %(make|ninja)_*
> * Replace %(make|ninja)_build and
> %(make|ninja)_install with %cmake_build and
> %cmake_install respectively
> * Redefine vpath builddir %global _vpath_builddir . to
> continue performing in-source builds (and optionally converting to
> the
> %cmake_*)
>
> Depending on the package, one of these options may be used to adapt
> to
> this change.
>
> %cmake -B builddir +
> %(make|ninja)_(build|install) -C builddir
>
> No changes are needed.
>
> == Benefit to Fedora ==
> * Follow CMake upstream recommendations when building packages
> * Brings Fedora package builds more in-line with how upstream
> projects
> expect them to be built
> * Improve compatibility with other RPM distributions that already do
> this
> * Support backend-agnostic way of building CMake projects
>
> == Scope ==
> * Proposal owners: Implement necessary macros, try to build packages
> that BuildRequires: cmake in a side tag, analyze
> failures
> and fix the relevant ones (introduced by this change).
> * Other developers: While proposal owners will try to fix all
> affected
> packages, there might be som
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 18:00 -0700, PGNet Dev wrote: > (i'd been discussing this issue with praiskup @ copr-devel/buildsys; > he suggested that I bring it here ...) > > This spec > > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec > > which uses forgemeta to pull multiple SCM sources, and uses some > git/bash scripting in %defines, > > builds locally, on F32, via rpmbuild or mock build, from spec or > srpm, with NO error. resulting rpms are installable, usable & pass > testing. > > submitting the _same_ spec to COPR for online build FAILS @, > supposedly, similar Mock build By default COPR does not allow you to use internet though it can be enabled in the project settings. > Here's a diff > > https://www.diffchecker.com/izjQYkUF > > comparing the log output of > > SUCCESSFUL LOCAL BUILD > mock --buildsrpm --spec=~/rpmbuild/SPECS/nginx.spec -- > sources=~/rpmbuild/SOURCES > cat build.log > > and > > FAILED COPR BUILD > copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec > > https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz > > The goal is to have the same spec generate the same Mock build, > regardless of environment. > > Why does the COPR build's Mock build stage fail? > > IIUC, mock builds _should_ be portable between mock envs, at least > for the same chroot. > > Do I need additional prep of the spec prior to submit? Something in > my foregemeta/scm usage that's env-dependent? Something else I've > missed? > > Or is there an issue with the Mock build env @ COPR? > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7+vesACgkQEV1auJxc Hh6few//fpCK/6V7F+7FWmo5l6e+kXJgtl3KZZfsusAo07ETto5meeOjZibjM13N 4adwQMY83uUJkD13jQwfWBzrcuK8ER6rhAGZ8SnTLKo7wrCWuvO2b2OBZxyXgaVW 1TcJzZsLLxEvBX1OPzYYlymyZSFfvePul6K1ByFLkYVpAn1xtYOCiB1QUT0BmX4m AQihgGJ7w0P8BY8f4crERM4U/pmxzBH6TeSMiTyq4JQSqfeloVvdFjzAiZ6MBp1Z rb+XtMhu6vu6ZYYYFf4bqPzYann5Bu8KGylhanuS+Tvvo9TmfKEQYz1Ec5XFkWwL wyw3QrlqcfllcX3zd3bgQYpPLuJST1PJho6Pv2lYyFVjhj8GC9kjXskm42CXeauz oF4D3m/Iz6kN+YQw/w+tg2BAnD+BOJVZaaI/T3dQIo2WE7fZVQ7fPCCtOkwiZYbc +eoBybumEFspShLKykoi5ENWbi3qA95qE69h+286btdgakKX+zv4RfMa2/k4jmMj r/Qohlph20mHJYJXf3VBO3Sng+pB2+fp2nhf46JE7OjcXefMMBuyja7ko7wBAMC1 vdfQc1ppCAQMvxxc+O17TNdP3f5sitzlf7J1XeiaPWHsPVv1XbZjnQTER7lYMYTy PqvDnoIEYfY2pVXHmvczYxeCGtbjA04bRPpmx1PLC1wZl2jcL/s= =KWRR -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 12:20 +0200, Nicolas Mailhot via devel wrote: > Le 2020-07-02 11:59, Florian Weimer a écrit : > > * Nicolas Mailhot via devel: > > > > > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : > > > > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: > > > > > The detached changelog is just one more file in SRPM sources, > > > > > which > > > > > is > > > > > modified by rpmbuild at `%build` time with other files > > > > > rpmbuild > > > > > modifies. > > > > > > > > I don't like that. %changelog should be generated automatically > > > > on > > > > Koji > > > > side. > > > > > > Why? Koji schedules a build. > > > > No, Koji also builds the SRPM, via fedpkg-simple or a similar > > mechanism. > > Sure, by build I intended both the deployment packages and the SRPM. > > The main difference between the current workflow (the reason it fails > in > mock right now, but that should not be too hard to fix) is that the > SRPM > that includes the build info is itself a result of the rest of the > build. > > That seems the main point people misunderstand (thank you for making > me > clarify it), the proposal does not involve preparing a special SRPM > out > of band, that is then fed to koji, the SRPM containing the bumped > changelog and last build info is the result of the build process > alongside the binary packages. > > mock (and koji) just have to pick this SRPM at the end of the build > and > not use the SRPM as it existed before the build occurred. So who is going to implement necessary changes in mock and koji for this proposal to be complete? > And why is it that way? You do not consider a rpmbuild -bs a build > event > do you? We do it all the time to import packages from one system to > another. The only thing which is a real build that produces a bump > and > is stored in changelog history is a full rpmbuild -ba build. > > Regards, > > -- > Nicolas Mailhot > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79uiIACgkQEV1auJxc Hh6DWA//QXrE2wOef89QaKs/2KW9boWCZu3uapwHC+479iB2b1E3J7iw5c1JW03s 0BQ9sk+blA7WntICR2ebkq+wjv5A8upLDj7OGABxIag04MlMHXKD3HZtT67QoMUi vNEdxHr98oim7S/wI5ZizAAjxFApVoZmpsokaATc0r32wcyczVsWvBxEYmjw7Uo6 QqN38o/Z8Y9xaTDHf/S4d+FTUTbKmetpLmb5tLg25m62+0GaFMpfYo0lCuFID2on Ionk7+b0LH8DHaacxBwoV+6HiOno+qYLqDBLOKh5kJGFGr+o33uqqTfc3/7KouZh ui9F7TxeRpd+bbVhfQbAdQZEIWQCVaFSIza8YN8mXe6jcyyqqWjUOhWgGt6ihaSs h255wdI8VcZJXTSYt+qkXj5Z6fGvvDXjD+AoEtFyhP9sqm5qmFyEIm7xE/NGwFMj BO6xIumEFavP6lEylFtYH9j6q9LFvYBB5ITw33jI4Wq/lYbD4cB96ksuzz1FvDzp R76Y10H0naFmqN0IdLC7L8LV45uXFg/jZ0NCLQ/6d0kUm/FbggmhpePzJUZI/b3T phokAdf0RQ32NXXRj/unK8yMwaZfFd8ec+UK4VFb1+pECjgyvGxojp+vo7pVzEu8 QCTy+Cb5T96mwfO9ejFQMGV2VZBBoVPYsGc0hTmg4j7eA7fPiE8= =FeYg -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:27 +0200, Nicolas Mailhot via devel wrote: > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : > > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: > > > The detached changelog is just one more file in SRPM sources, > > > which is > > > modified by rpmbuild at `%build` time with other files rpmbuild > > > modifies. > > > > I don't like that. %changelog should be generated automatically on > > Koji > > side. > > Why? Koji schedules a build. The build registers its own build date > in > the produced packages. Koji decides to keep and commit the result, or > drop it (scratch build, failed side tag, whatever). Koji is still in > charge, the bumping is just integrated in the build process with the > rest of the package creation. I think Change Page does not mention that Koji will be committing anything to the dist-git. > And, unlike something done specifically by koji, the bumping will > import > and export across all build systems, ie all the bumps that occurred > in > rpmbuild, or mock, or copr, or obs, or whatever are imported in > fedpkg > with the rest of the srpm, and an srpm produced by koji can import in > rpmbuild, or mock, or copr, or obs, or whatever without loss of bump > information. > > And you no longer waste hours wondering why a package you just fixed > is > still failing on your test systems before realizing it is masked by > another build that did not share the same bump history. > > Regards, > > -- > Nicolas Mailhot > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79qyoACgkQEV1auJxc Hh7/uQ/+PU+KAwd+lCd4YMAEd41Caii7BBMSIOn7WQ5EJEJu9V4g7QvNFGi147Pw 95DH9jZNf6KIFbVNh32gi44fZ60Q2MCj4/H5Mq3PoGe+wa3ks4twbLox8rG2M1BG EWQVWXi8HWYZ5gR7QBUmVW0rpEYuyGNUMSFsavdAAv6hfq2LQMAA9lbSerWmOikK w+2SUuoo1D5l1ps8Bi7L91ZFH6Z7K9sdXxG8rhuK9EXuf63DwfXbraYCQdwOeCHP wXvyRkQ8D5w9MiFriN4e6zqp8SI8QvPnqhLWO9RoqYDr9FMc1tqKeaZN/yuIdu+Z zIQU1M1N4cfOm91TvNH/gAev9e9X9dvJMKPsVZF2K4yAE0MSy4EgjY0ixvv0KZWq RRTXqs/fYF/KLVfuwrI5ZVJTcthvuUi4YL+LDoC/TL7SfLJVTVv5t1ub8l0geTBc isFdIntggJEUxtovM/FG2/affYNJnxIW9diGJkQYYtqo7TpuHtW2yoYF2QJ3eKim yW0UQiyNZ81wpfHns0dzGm3EyUrqrWlazRCcgaxfH++MvVj2TSYnyiAmEF4YZg0r jFcjyMZ7ZXyekUvhjBBNMBow5dZ1F2178cEOeHhC8S4NFrX+UkuUkQE+UjMarr3p X6W2z2Gz/L/m3c1P+kLKYbMcpQCmzh2U6Or6F9zlUdwFLJTt4qw= =Y5uf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote: > Le 2020-07-02 09:52, Florian Weimer a écrit : > > * Nicolas Mailhot via devel: > > > > > > How do I let rpm generate the changelog automatically? > > > > > > This feature is not changelog generation, just changelog bumping > > > on > > > build events. You still need some other method to put non-build > > > events > > > in the changelog. > > > > What is “changelog bumping”? Why is it needed? What about release > > bumping? > > Changelog bumping is the act of putting the actual release bump and > build time in the changelog. > > With the change, the spec is able to self-compute its next release if > the spec file evr is older or equal to the last build event. How does it know that "last build event"? > On build, it will both bump the release, without touching the spec > file > (that is release bumping) and commit the new build event timestamp in > the detached changelog file at %build time (that is changelog > bumping). > > > > The detached changelog is just one more file in SRPM sources, > > > which is > > > modified by rpmbuild at `%build` time with other files rpmbuild > > > modifies. The tricky part is to modify the source file as a > > > source > > > file > > > so rpmbuild adds the result to the produced SRPM (and, that does > > > not > > > work in mock right now, because mock serves the SRPM that existed > > > at > > > the start, not at the end of the build. Though it’s probably just > > > a > > > matter of getting mock to call again its SRPM creation method at > > > the > > > end of the build). > > > > > > The packager does not have to request the modification in his > > > spec, > > > it’s done as part of the various %auto_foo calls the change > > > introduced > > > > Can you list the relevant %auto macros explicitly somewhere? Is > > %autosetup included in the set of macros that trigger this > > behavior? > > %autosetup is not part of the new framework, all the new %auto entry > points have %auto_something name/ > > Auto release bumping and auto changelog bumping involve registering > some > processing in the preamble (to compute the next evr), in %sourcelist > (to > deal with the source files involved in saving state) in %build (to > commit the new data to disk once the build is ongoing) and in > %changelog > (to get rpmbuild to record the new changelog state in package > metadata) > > ie it registers processing in %auto_pkg, %auto_sources, %auto_build > and > %auto_changelog > > The bumping is done by the buildsys subsystem ie practically by > %new_package (called by %auto_pkg, directly or via %buildsys_pkg), by > %buildsys_sources (called by %auto_sources), %buildsys_build (called > by > %auto_build) and %buildsys_changelog (called by %auto_changelog). > > It’s done by the buildsys subsystem because the %buildsys subsystem > is > tasked with writing the SRPM header in the new %auto_call framework, > so > only it knows which of the various (sub)package epochs and versions > are > the ones that apply to the SRPM. > > This may seem a bit complex and convoluted, but that’s because > autobumping > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > is a small addition over the big %auto_macros change. > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > And it is small because the big change provides all the low-level > infra > to code such high level features easily. > > The big change was not done for autobumping. It’s only once I coded > it > for other packaging needs that I realized it made implementing > autobumping trivial (trivial to me after all the other changes, maybe > not so trivial for the average macro reviewer). > > Regards, > > -- > Nicolas Mailhot > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-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/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxc
Re: IBus 1.5.23 - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:20 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/IBus_1.5.23 > > == Summary == > IBus 1.5.23 will replace the allowlist of XKB engines with the > blocklist of XKB ones. > > == Owner == > * Name: [[User:Fujiwara| Takao Fujiwara]] > * Email: fujiwara [at] redhat [dot] com > > == Detailed Description == > IBus currently provides the allowlist of XKB engines in > `/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can > show the XKB engines indicated in only that file in most desktops. > (gnome-control-center shows XKB list from gnome-desktop3 in GNOME > desktop instead.) The allowlist includes the limited XKB layouts and > variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the > allowlist has been supported to customize by sysadmin localy since > the > simple.xml is a simple text file and the default list has been > updated > upon the request. > > IBus 1.5.23 will replace the allowlist with the blocklist which > includes the disabled XKB engines and `ibus-setup` will shows all the > XKB engines which are '''not''' indicated in that file. The > blocklist > will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp' > layouts at the moment. > > I.e. the change won't effect GNOME desktop. So I do not fully understand this change. Is it actually breaking something or not? If so, I am surprised it happens when bumping micro version (.23). If not, does it have to be System-Wide change? > == Benefit to Fedora == > The users don't have to request the desired XKB layouts and variants > in IBus upstream and most XKB keymaps will be shown in ibus-setup. > > == Scope == > * Proposal owners: > * Other developers: N/A > * Release engineering: [https://pagure.io/releng/issue/9563 #9563] > * Policies and guidelines: N/A > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > If a keymap is shown in ibus-setup in the previous version, it will > be > shown in the new one. > > == How To Test == > # Log into XFCE desktop > # Run ibus-setup > > It will show 'English (UK)' keymap by default. > > == User Experience == > If a user customize `/usr/share/ibus/component/simple.xml` in the > previous version, the file will be replaced with new one. I think it is pretty much expected that if you modify something in /usr, it will be overriden by an update, no? > == Dependencies == > The change effects XKB engines only but does not input method engines > (E.g. libpinyin, hangul, and so on.) > > == Contingency Plan == > * Contingency mechanism: Drop the feature in Fedora 33 and postpone > it > to Fedora 34 > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lt4ACgkQEV1auJxc Hh7vKA//VigWO3Dx/Aj52Nb1zVUY6CluDKLwaYEJ1c3j6LYwNhH6LVYMLQUPRlw2 gNUHe5n7k2C1kiFP2s1+u/MEQXGxZwjzGgPxwVLNl9bOFfk8HnXrwHuTquucDC3T 0amg4G0x3LynbhCrzrzBxfOSy/GnlElUGKY66izaTMPnsHtGjrmHzb0eCOsaIYvl D4TxBJ7pTqJh6XG41UFHsyT82yuMAwjeS8mow7XsQY3a29wWN7A9cxyNBpv0Uhtb rXbN9ti5pk3qmc+XjSbbqNvS3ufVAOLGv9FOXmkOG3iY0uhSjLJXkSPesDkJdzYp EQR+W5nmFFsUEKKFUb4fwTJ5TEz1OjNtUYW09Ahuqq5S6xJv6IA7rMPkU05rxeMM Qac7q3LJ+cQM0vk9HKVIDfXmqX47tqCNpcrC5uDLb6MwBGvz7A9WJWdu71shuTAi Bmya4/yISh7C/5+pfpO4y2h+z7RYiA2visNdp3oYRWQ7o+8SMUjPHGzyIvX3TcF5 pZlmKrYsoyEiltyMoyhJTosOZ+wWpMhZQhjVNT3vq3nUYnSe3xAX7aGUoIF750O9 HOvjyDcpptCMjVr/b2pcQt7usLG+ISzta8LxZkm38RkFGSG3aewRTJGSTK+K7XQQ iUCRYGKePePPxtYZwNT212Hft1vBaN7hGzA7P3oXdYOblWuk9w4= =9bCf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
rpm
> lua API without blowing up on the landmines it is littered with.
> Therefore, I abstracted landmine avoidance in a single place.
>
> === Drawbacks ===
>
> Nothing is free, and a higher level of automation required using
> rigid
> naming for control variables. Because software is a lot less tolerant
> of fuzzy naming than human beings.
>
> So, all forge control variables are renamed, fonts control variables
> have been renamed too, and go control variables will need renaming
> (in
> that last case, that’s not a problem because moving to go modules
> requires reworking variables anyway, so it will be done as part of
> the
> module effort in F34).
>
> To ease the transition a compatibility layer was added to forge
> macros
> so old variables and new variables are aliased both ways (this will
> eventually go away because it’s quite a lot of compatibility code to
> maintain). Mixing syntaxes (old and new) is not supported, you need
> to
> convert your spec file to new forge variables or not at all (if not
> at
> all, do not try to use new features like patching).
>
> == Benefit to Fedora ==
>
> Spec files that do more with less manual expensive to maintain spec
> code.
>
> Without this productivity win, complex efforts like converting Fedora
> Go packages to Go modules, or draining the Font packages swamp given
> that legacy formats are no longer supported by apps, are not possible
> with the current level of Fedora manpower.
So this came out of sudden, without any discussion with RPM upstream.
What about integration with Rust, Python, Ruby and Java ecosystems? Is
it planned for the future? Having something very generic,
unmaintainable and overcomplicated just for Go and Fonts does not make
much sense to me.
> == Scope ==
> * Proposal owners:
> The core of the feature is done and tested (and retested). It may
> evolve during the redhat-rpm-config merge process.
>
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95
>
> * Other developers:
>
> The way current forge macros call forge macros will need a little
> patching once the change lands. For other packagers, there should be
> no change except a warning in rpm build logs to switch to the new
> syntax before the compatibility layer is removed.
>
> * Release engineering: https://pagure.io/releng/issue/9565
>
> * FPC: https://pagure.io/packaging-committee/issue/997
>
> * Policies and guidelines:
> Forge guidelines will need some rework (mostly simplification,
> because the new syntax is both more powerful and more regular).
> For the average packager, the new syntax is the same old syntax
> with
> little naming adjustments (for example, %{forgeurl} becomes
> %{forge_url}, %forgemeta is subsumed into %auto_init, etc)
>
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
>
> This is a pure build tooling update, it changes how things are built
> not what is built.
This is not fully true, this will make those packages non-buildable on
older, supported, Fedora releases.
> == How To Test ==
>
> A redhat-rpm-config packages with the changes and some example
> packages are available in
>
>
> https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/
I think it would be useful to put concrete examples on the wiki page.
> == User Experience ==
>
> N/A Packager experience change only
>
> == Dependencies ==
>
> The change depends on a redhat-rpm-config merge by redhat-rpm-config
> maintainers
>
> == Contingency Plan ==
>
> There is no contingency plan because the redhat-rpm-config merge will
> happen or not. If it does not happen, i18n, fonts and Go Changes that
> are/were envisioned for F33 or F34 will be postponed indefinitely.
Again, if this blows up, we need to know what needs to be reverted,
when and who will do that.
> == Documentation ==
>
> There is as much documentation as the average redhat-rpm-config
> change
> (ie comments in the macro files themselves)
>
> == Release Notes ==
>
> N/A Packager productivity change only
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to
> packaging-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.
Re: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
e devices > > * adding a centralized solution for delayed actions on storage > devices > and groups of devices (avoiding unnecessary work done within udev > context and hence avoiding frequent udev timeouts when processing > events for such devices) Is this purely about adding some package into the repositories and just to raise awarness that such tool exist? > == Scope == > * Proposal owners: > ** complete SID's infrastructure to fully support stabilized API for > other developers to start writing modules for SID; > ** document all of current SID's functionality, including the module > API and explain the difference (extension) to udev, write and > complete > man pages; > ** provide udev rules responsible for communication with SID and > possibly importing records which were marked for export to udev in > SID. > > * Other developers: > ** first version will make use of a module to handle > device-mapper-multipath devices (device-mapper-multipath package) > ** consult in more detail possibility of adding an LVM module even > for > this release (if not feasible at this moment, then postpone > development of this module to next release) > > * Release engineering: [https://pagure.io/releng/issue/9568 #9568] > * Policies and guidelines: no changes needed at this moment > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > We are introducing SID in this release and it will be disabled by > default so an upgrade has no impact here - all existing udev rules > for > various storage subsystems will still be installed as previously. > Subsystems for which a module will be already available in this > release will contain a switch in their udev rules to either use the > old udev rules (if SID is not active) or skip the rules appropriately > (if SID is active and related processing is handled within the SID > module instead). > > == How To Test == > * Basic testing involves (considering we have at least multipath > and/or LVM module present as well): > ** installing new 'sid' package > ** installing device-mapper-multipath and/or lvm module (presumably > named device-mapper-multipath-sid-module and lvm2-sid-module) > ** creating a device stack including device-mapper-multipath and/or > LVM volumes > ** booting with 'sid.enabled=1' kernel command line > ** checking device-mapper-multipath and/or LVM volumes are correctly > activated > > * More thorough testing: > ** (TBD) > > == User Experience == > Regular users shouldn't notice any change. SID is providing a > system-level infrastructure for convenient handling of > storage-device-related events through modules provided by other > developers. > > == Dependencies == > * a module to handle device-mapper-multipath is in cooperative > development with this change, the module will land in > device-mapper-multipath package (or its subpackage) > * the same applies for the LVM module (but that may be postponed as > described earlier) > > == Contingency Plan == > If SID is not complete in time, there's no need to execute any > special > backup plans. The distribution still contains all the original udev > rules to handle events for storage devices. If device-mapper- > multipath > and/or LVM provides the SID modules, these won't be built and > distributed. > > SID is not enabled by default so to start using it, one needs to > enable it explicitly. If enabling SID causes problems, it can be > disabled. For this purpose, there will be a kernel command line to > enable/disable SID so we avoid possible issues even at early boot > sequence if the device handled by SID is on critical path within boot > sequence. > > == Documentation == > * documentation (will be completed): https://sid-project.github.io/* > upstream repository: https://github.com/sid-project/sid-mvp > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lBMACgkQEV1auJxc Hh7VAQ/7B+6trAXJOJSusP7XzXfcjtyfk4rxriiyccfHsqEriHnVhbpipWJ2TrVe YnOdvDK0+iU+PNgyZueXV4OBZWaQLw76f+HC+0IbWlYuejIWKmEu/DRxnQS0Iz+6
Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > == Summary == > > redhat-rpm-config will be updated so users of the auto framework get > automated release and changelog bumping. > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > * Email: > > == Detailed Description == > > This is a system-wide change because all packages build with > redhat-rpm-config, but it only concerns packages that opted to use > this part of redhat-rpm-config (auto framework). > > The change will make those packages auto-bump and auto-changelog at > the rpm level, in an infrastructure-independent way. So how exactly is this supposed to work? From where will it get old changelog, how packagers will migrate to this, how does it affect reproducibility? > == Benefit to Fedora == > > Autobumping removes a huge packager shore and makes timestamping in > changelogs more reliable. > > == Scope == > * Proposal owners: The feature is coded and works at the rpm level. > Unfortunately, mock filters away the srpms containing the bump state, > so it does not work in upper layers. > > * Other developers: The feature requires buy-in by mock developers > (and probably koji developers) to lift the restrictions that block it > above the rpm level. Also, it requires a mechanism to pass the user > name and email that will be used in bumped changelogs (defining two > variables in ~/.rpmmacros is sufficient at rpm level) So are you asking mock and koji people to implement something? Did you talk to them before submitting this proposal? > * Mock issue: > https://github.com/rpm-software-management/mock/issues/599 > > * Release engineering: https://pagure.io/releng/issue/9567 > * Policies and guidelines: maybe eventually if things work out on the > technical level > * FPC issue: https://pagure.io/packaging-committee/issue/998 > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > This is a pure build tooling update, it changes how things are built > not what is built. > > == How To Test == > > A redhat-rpm-config packages with the changes and some example > packages are available in > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > Since the mock/copr layer is currently blocking the feature, you need > to install the redhat-rpm-config and forge macro packages available > in > this repo locally. Afterwards you can take any of the example > packages > in the repo and rebuild them with rpmbuild -ba to your heart content, > and see the releases bump and the changelogs being updated > accordingly. > > To get beautiful changelogs, you also need to add > > > %buildsys_name Your name > %buildsys_email Your email > > > in ~/.rpmmacros > > == User Experience == > > N/A Packager experience change only > > == Dependencies == > > The change is a spin-off of > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > Therefore, it depends on the success of that other change and will > probably need rebasing if the code in this other change evolves > during > the redhat-rpm-config merge. > > It also depends on mock / copr/ koji buy-in and changes, that may add > their own requirements. > > == Contingency Plan == > > There is no contingency plan because the change will happen or not at > all. This is not true. If it will happen but then something will be entirely broken we need to revert it.. And we need to know when, how and who will do that. > == Documentation == > > There is as much documentation as the average redhat-rpm-config > change > (ie comments in the macro files themselves) > > == Release Notes == > > N/A Packager productivity change only > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to > packaging-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/packag...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77k5MA
Re: The future of legacy BIOS support in Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > changes > it beg the question if now would not be the time to stop supporting > booting in legacy bios mode and move to uefi only supported boot > which > has been available on any common intel based x86 platform since > atleast > 2005. > > Now in 2017 Intel's technical marketing engineer Brian Richardson > revealed in a presentation that the company will require UEFI Class 3 > and above as in it would remove legacy BIOS support from its client > and > datacenter platforms by 2020 and one might expect AMD to follow Intel > in > this regard. > > So Intel platforms produced this year presumably will be unable > to run > 32-bit operating systems, unable to use related software (at least > natively), and unable to use older hardware, such as RAID HBAs (and > therefore older hard drives that are connected to those HBAs), > network > cards, and even graphics cards that lack UEFI-compatible vBIOS > (launched > before 2012 – 2013) etc. > > This post is just to gather feed back why Fedora should still > continue > to support legacy BIOS boot as opposed to stop supporting it and > potentially drop grub2 and use sd-boot instead. > > Share your thoughts and comments on how such move might affect you so > feedback can be collected for the future on why such a change might > be > bad, how it might affect the distribution and scope of such change > can > be determined for potential system wide proposal. I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this configuration, develop tooling for them if possible for migration and do not allow upgrades that will simply break their system. > > Regards > > Jóhann B. > > > 1. > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77RJkACgkQEV1auJxc Hh4+4A//QC8EWxecyBbSWu8uo2dSlFgqcCJ4zn6fkpgsU1PPhcezTPNKBFYdXUag QMN5d6fawQE7LWRMY6y1Gq4oyANPQyJVshUeOcOBkyDpnZN13uCJSLDXpmHifpOJ Up27VxVjYRb4kkPyHZqiwOkJP8U/4NfKeWkfew5CFGufKjX1dQVS8CeNWgpl1YsM aTTLd5CvzDiMN4GBoaSRZmI9YDbrQbElqrk6BZD1wAIVnBbpvCq8wUJFRKIcx6O1 gMxpGV9txZ2HLKqmUYRtQUl5+CKTS45vJszGdlWPPqjiGpgGEDtsAqCPfWiyHUAc 0FZYdYHt3a1/jmNH0WRS2UOmeu5FP8VUOUvywVn3e4A5Dbi3Bdv2xuOGPD+xyti6 TAE3bWnYE1i7T1N6xoD90z2w+iQLFi12ftA7wkajNjf4e0MaawRBKuiG9VhL2xUA vCDFaL/tqSQDPkWlrQblUjpJEOZOrtxQl48iMTNWmo92AtmuuARNwSsXNxEeP3GP 2DVM69j3CrGPpEBCIt4PdymHTQ2AHalUZwSAxEiT0NjwZ11uS0dAK7ipzwbUr+gt Kwt202qSB5CZWSYe+VMDDxVyHJAIjpllzejaNBnVFrtpNmAXEjTJY+0sU/JW8o37 2HXm675cbN+X8AvNXMypoVJFcGRvqvaneKn4ywqhVhrRRzc5B38= =xrlO -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 09:25 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including > thermald in the default install. I have strong feeling that this has been already submitted before. https://fedoraproject.org/w/index.php?title=Changes%2FThermalManagementWS&type=revision&diff=580846&oldid=557200 Sadly the diff is so small that I don't think change owners really read feedback from the mailing list. Neither it incorporated "Feedback" section in the proposal. > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors > to monitor the temperature and use the best available method to keep > the > CPU in the right temperature envelop. On certain systems this is > needed to > reach the maximal performance. thermald will for example use the PPCC > power > table to set power limits (when available, see for example > > https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.html > ). > This is for example the case on Ice Lake, where thermald can increase > the > performance of the out-of-the-box behaviour of Fedora. > > Not strictly necessary, but *further* improvements can be achieved by > using > per-model thermald configurations. The most straight forward way of > using > those is for the user to install dptfxtract (available from > rpmfusion). At > least parts of what dptfxtract can already do may be integrated into > thermald in the future thanks to the reverse engineering work done by > Matthew Garret (see > https://github.com/intel/thermal_daemon/tree/mg_patches_test, > https://github.com/intel/thermal_daemon/pull/224). Should the reverse > engineering effort be merged, or if the user installs dptfxtract, > then they > can expect a performance boost on some machines. > > Theoretically one could ship appropriate per-machine configurations > as a > separate package (or inside thermald). However, this is not part of > the > proposal for a number of reasons: > 1. It is not clear how the configuration data can be collected > 2. We do not currently have an implementation to load such > configuration > data > 3. This may become obsolete with if the reverse-engineering effort > continues and is merged (or picked up by Fedora) > > For a more details explanation please consult Intel's [ > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. This affects many modern laptops (e.g. > the > Ice Lake platform). On affected machines, Fedora would continue to > have > poorer performance compared to other distributions. I think the change page is missing information what exactly this daemon does if it is installed. > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install I believe this won't do anything because the daemon won't be enabled. > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > Install the packages and use e.g. turbostat to monitor the > performance. > Improvements may only be visible if the non-free dptfxtract package > is also > installed. So if improvements are only visible when non-free software is installed - - what is the reason to ship it by default? > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Don't ship package by default > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 11:04 +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > > On 29.06.2020 22:04, Ben Cotton wrote: > > > Fedora only support these RAID sets when they are already > > > configured in > > > the BIOS at installation time. So we can solve the problem of > > > dmraid.service still depending on the obsolete udev-settle > > > service by > > > making dmraid.service disable itself if no supported RAID sets > > > are found > > > on its first run. > > > > +1 for this change. > > > > Also the LVM monitor can be disabled too if LVM is not used in > > current > > Fedora installation. > > > > LVM monitor: -2.01 seconds. > > RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be > installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed > to > be there and enabled - it should not impact load time all that > much... ❯ systemd-analyze blame | grep lvm 4.103s lvm2-monitor.service Sadly you can't have lvm2 not installed: lvm2 is needed by (installed) libvirt-daemon-driver-storage- logical-6.4.0-1.fc33.x86_64 that is required by other libvirt stuff which ends up with gnome-boxes. > > Zdenek > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77BK0ACgkQEV1auJxc Hh4V8hAApS1m1x4gqE66qQZuf81bcHPU3wTYYgLvzqVr69eq25hzu1pIQDT1oXJH WgHuucYKCQjr2JO9dv2Amil0hNlnrRP6AONJ28f22xUnUHoM93vYi7Y6Ba5sbGh6 31DRf5FEgfcBODXmB4XVGm2vXxlWeMYVnR9ujKHvnl/8ODrI6jLrvIDl02rFq3eT Gym144modLy6cKVaUBRO8q6n26A8wHXKQ+9Gj7h95c5vHZzZd3QReITxsim+Lxee 3iVPI7sRPI6VYZFvtsG+sLJgQlUvrcD1pjkCUJDwIPQG8cnvmfUk8L1TtDOfeRZK Uzn/NQgx8WNAcpOJtE3PrqDLRQl7jVHwulwXP+181RYSAeuX5z69qXZZ+7kq2lVh OtTRKQbfed2VYdrd0emOizZH92zGNR8gtJ4PkCu3ThWEaYnH3eJ5r8FM/znoFOI1 P+rkllVce8AJ0+V+ZJOR3/hLQSN8bcOREm9shxWz7TixUPbkzsRUh4EAWamznyKL ZUHQbv9MZZ5HEvw2+7Ukb8tULsXNBWm1mSMVMhE92XueTaavAkY6E1iPmWaZ1R7y Tvmh1Gmq6Hk/DNb6qQtBPESKHGT9Y4T+8wbKDm8YilotwEZpQ0B1T7W/oTS+ZHKu 0woM7DnULdbtGaPcH1DM+3Q9XTkDWTbxVF3kG90f6oKezSpmntg= =hlFt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-29 at 12:26 -0400, Matthew Miller wrote: > On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote: > > > We cannot include ZFS in Fedora for legal reasons. Additionally, > > > ZFS is not > > > really intended for the laptop use case. > > Has that actually been explored? How does Canonical get around the > > legal > > issues with OpenZFS' licensing? > > I can't really speculate on Canonical's legal stance and I encourage > everyone else to also not. > > I can point to Red Hat's, though: the knowledge base article here > https://access.redhat.com/solutions/79633 says: > > * ZFS is not included in the upstream Linux kernel due to licensing > reasons. > > * Red Hat applies the upstream first policy for kernel modules > (including > filesystems). Without upstream presence, kernel modules like ZFS > cannot be > supported by Red Hat. This is not fully true to my knowledge. Red Hat ships VDO and that is not even sent to upstream (yet?). > and "due to licensing reasons" links to > https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ which is > quite > interesting and quite long. If you have just time to read one > section, the > two paragraphs at the end under "Do Not Rely On This Document As > Legal > Advice" seem like the _most_ interesting to me. > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl76ONYACgkQEV1auJxc Hh5R7w//TvrXFDfvGwaKV0jSjy6OPKea+Y2urF8pjrH1lEBb2PpvW+I2jxqKy6BM lXeR0nShtlJJ6IHjq7IK8xUZiNBzbCbJQGURdRkh63ZENQrbJ52BPYJv190/Fh4g R/rHBbvja/Q0y/LRZK5heXknIELPZdWfD1N3hHvhc+J9uHlmozZBhlO3zk3kcZaL OwsrV5UzgccFfmWyOFTcx1VFLqoILJW6vo10m+qM47jwpdNlJQTBw9i1s8PDMsAI d045ZmX+u2ZTS7YJ3AJ+YaXQXlhI2DUUYc5R2hf8whUp7Fi68RJMseK8ar8kxLby HRSzTP55VYnApUBJ78KoVq7wvWdFCGq15YR39hVC/B1GgzjxYhzv53FJ2/Sy5Q2d jbWGvtpd8E5+29jhvGC+fDJ91XsTLdmkNOS8w+McQUkFiJdzqVzUIjzHz4bzK4wS agqsylZP+E79nxjKaQdE5vGdACN9cZnh/Za2sWLTGiVE1Rw7eDVhaDtpGjBVrwUr Y0sNSzbqVM2NE1pE6g43AisA533iD8b2XxplWhhoeHp1RRiASkp9yh6WibTDyFXW 9wnXmzIa3Swte3n+LvV9lSlILYoGdQKMljYNU/yr1zMsR9yBRx6fpijinzGWJ6oM /Ug7h+W7HPgWQk+sGJJs7mHXfYdAODzupSXhQml0hURMRQ/qaOs= =6vGj -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote: > On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote: > > On 6/29/20 12:27 AM, John M. Harris Jr wrote: > > > > > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: > > > > > > > On 6/28/20 11:35 PM, John M. Harris Jr wrote: > > > > > > > > > > > > > > > > > For the best filesystem ever created, ZFS, I can't say that I > > > > > agree > > > > > with > > > > > your assessment of that value. Having ZFS in Fedora would > > > > > throw Fedora > > > > > over the top as being the best Linux distro, hands down. I > > > > > can count > > > > > the > > > > > number of times that having root on ZFS has led to me waiting > > > > > on kernel > > > > > updates over the past three years on one hand, and could > > > > > still do so if > > > > > I > > > > > had half as many fingers! > > > > > > > > > > > > > > > > How many times are you going to keep mentioning ZFS? It's > > > > completely > > > > off the table, not allowed, never happening. (I consider the > > > > chance of > > > > Oracle doing something reasonable to be immeasurably small.) > > > > > > > > > See the relevant section of Mark's email. I also don't see how > > > it'd > > > require Oracle to change anything in order to get OpenZFS into > > > Fedora. > > > > > > You were mentioning ZFS, not OpenZFS. However, it's still the same > > problem. OpenZFS is CDDL which won't be accepted. The only way > > that > > can be changed is if Oracle does something. And as long as OpenZFS > > is > > an out-of-tree module, it won't be in Fedora. > > ZFS, in terms of Linux support, is generally OpenZFS. You will note > that Mark > also simply said "ZFS". Yes, OpenZFS is under CDDL. That's not really > a > problem. See > https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html > . Ubuntu's solution is wouldn't work for us, and it is a GPL > violation > (https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/), but > it's also not necessary. The package for OpenZFS could be provided as > a kmod > package instead, which would *not* be a GPL violation. > > I don't understand the attitude against this particular out-of-tree > module, as > it's readily available for every kernel within days of release. The > longest > lulls have been around holidays, where it took up to 5 days to get > support for > the latest stable kernel. First of all, Fedora is packaging not only latest stable kernel. Fedora is building kernel from git in rawhide almost daily. Secondly, kmods in Fedora are not allowed. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl75nhoACgkQEV1auJxc Hh7u8g/+N/1Z9nEzFSzDLk6G5kOcfdeexDIv9EhtfLhmSuPDbwtt/t0JqHpWxxWx 8pf42bG85OkatyeMKE+Ycb9eW3ZSJ008i9Et2Nm9F9WS11KrfSWmVOjl1lJ7vQpD 9MJsvGgTQObcKriVxi6HEST/av9CStCzLyqjejMhyG/cXqTZ0sZuF9ZmdudiKGi+ gzDGxcJYeCnnagklomGB55mfz/+SrQphGNUc/yHbRJgrNpNmbUTIfl4mzSzu+12L 3kpPBLIaQYHp+Va8SV8C9jzWe3CXhN95pL5NqL6fcGouB9ciyds+1U0+xyPZF3kt Va+ziIKdbPJbBfgut4qa84QPCaUCb2gvCOUbL8IDV0ohlk05ss20NFDo26FxKEFQ QFqTGJGgrZZd3MK7HO0y/pZTtegv2dUxBy/xzqYo+5iLMczDTI3RJYWZoLDEP/wV 8fsF6jltCXXYvzWeQ9lk2aHODrP34PmqTTCvbwwzmQThB4ruG7h6Q4ec27MK+umz eW7di/U4cnB6JsJIII1ZJAy8E9vH98n1zUPFrpXsYhAq5AmepMMHtQB8A4CQoGkp 3F2csTTT1OR8f35RInt/IVZ0aLwB+vhdXmtWyZk35aRRTHZ1PIzcH4yd0mt1GObG LenIifmIdp/aQtgZAc3023517cg7zR+G4iABzu1yDf0tVsnA1g4= =ihOE -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
3-4 days based on my experiences) > even on a relatively small SSDs (not to mention HDDs) and it also > will shorten SSD lifespan. > > If laptop is put into sleep mode without users noticing that btrfs is > running maintenance ops on background (and it often is), the > likelihood that file system will get corrupt goes up the roof. > Something users can do is use TLP and as a first aid set > SATA_LINKPWR_ON_BAT=max_performance for TLP which then will shorten > the amount of time laptop can be used without recharging. And this > has been a standing issue at least since 2015 with no real fix on > sight other than "lol, stop using btrfs" like one commentator at > Reddit wrote. Do you have some link to the bugreport about this? > The btrfs-check is also a massive can of worms and it cannot be > safely run. At least not without reading pages upon pages of manual > and becoming an expert in understanding how btrfs works. Expecting > every Fedora end-user to do this is unrealistic in many different > ways. Well, I hope people don't run random commands from the internet? Myself I did not even need to run anything like that. > The btrfs has no native encryption to my knowledge. However > alternatives such as zfs already has a trusted and reliable > encryption used in numerous FreeNAS installations around the world. Upstream is working on that. > And much of these issues and many more are straight up mentioned in > btrfs' own wiki pages at kernel.org where one of the most shocking > admissions is: "So, in general, it is impossible to give an accurate > estimate of the amount of free space on any btrfs filesystem. Yes, > this sucks." > > Source: > > https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complicated.3F > > And these are the brains before btrfs admitting this that there is no > solution for this. No amount of userspace tools developmen and UX/DE > integration is going to solve this for the end-users. > > Please, don't switch to btrfs. It is not mature. It is not well- > understood. It is not properly "battle-tested". It can still die on > its own. It's just a ridiculous meme file system. At this point it > would take me some decade of smooth sailing at OpenSUSE side to start > believing that btrfs is ready for prime time in my own personal > Fedora systems. Even 5 years of smooth sailing would give more faith > in it. But as it stands I have to strongly oppose btrfs. It's too > much of a headache with no relief in-sight. > > > -- > Antti (Hopeakoski) > > P.S. Sorry for this emotional nature of this message. But I really, > really like my Fedora and I really, really dislike btrfs due past > highly negative experiences with it (some of them happening to me as > recently as last year). > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl74lVoACgkQEV1auJxc Hh6LNhAAu6OC9A3PngNst6Ym9Bfq2TlNwfTiwk0nJrOMleAQwhmAySmfVtv8YeQF ozDYuPOqcLKDsSxrNKDzA+aaOegZpNnvTNB2UOFZgGQPdrTqGXv+kt3FCk9Vu0kF 6SW6DB83sgfuP93RJ7LDqktOw/EtCX4PWtRj1mSixTlpBqSQ3YPYHittgWnD/pWK Ka4h4WrQVvpY6tS7rfCCk+Vc4QLMBy5cw7Og/TtrBBJ9jFU2pZbbJ6wDKFMOC6l6 wr65un/9FuwKY9o8DGaqePTezVijTVumXfrAjtkfsvpxze2CJKCOC3r9+GQjWXmK WszsZ4tBJuoHrndINHTOronOsBrj3UoRkMqnCThu5JqMMqo0+9EsqewjbtCJYD7U gAYAT2neHzWKaNM3rl9hxOj1vkiwaLFiwYkDAmfwwaPJ5DH5FsjACevXj03E6zNn WwHZTHR1pi3SogU08wY0WszBrkemEBkwD7tbA5VZPtXSyAe/ae0qJsWfB4f/ebqf JDoTlbctYMAQ5HCTIE+d0n4U7XiBUcXGvN4Eb+mej+fqQwVdUKz0XYUdLFfDthef YCH+8WEz9ej9W2TGnB/1gjPK+1U6GllF5O2jJQmS/qYQgVk1oZsxnQg2e27HUswj UdLOtVuRDZu46LndelTke/SxQXrW6+C+C6UVgy0t6sPenUIVvIU= =MUeD -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 12:37 -0700, Gerald B. Cox wrote: > I was an early adopter and used BTRFS for many years, singing its > praises. > I was particularly interested in the RAID capabilities. Then in 2016 > the > bomb was dropped that: > > "It turns out the RAID5 and RAID6 code for the Btrfs file-system's > built-in > RAID support is faulty and users should not be making use of it if > you care > about your data. Well, the RAID5 and RAID6 in Btrfs is still not really working fine and there are some threads in linux-btrfs@ at kernel ML. Workstation users are not using RAID (even if they do, I am not even sure how it is configured today with Anaconda). Even for those that do, RAID0/1/10 seems to be working just fine with Btrfs. RAID5/6 is definitely not something that people run on their laptops. > There has been this mailing list thread > < > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55161.html > > > since the end of July about Btrfs scrub recalculating the wrong > parity in > RAID5. The wrong parity and unrecoverable errors has been confirmed > by > multiple parties. The Btrfs RAID 5/6 code has been called as much as > fatally > flawed > < > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55179.html > > -- > "more or less fatally flawed, and a full scrap and rewrite to an > entirely > different raid56 mode on-disk format may be necessary to fix it. And > what's > even clearer is that people /really/ shouldn't be using raid56 mode > for > anything but testing with throw-away data, at this point. Anything > else is > simply irresponsible." > > The current situation as I understand it is the problem is "mostly > fixed" - > whatever that means. > > So, BTRFS is great, ready for prime time... many people are using it, > etc. > etc. etc. until something goes wrong and then you get... well, it's > experimental and not intended for production. Sucks to be you. > > At some point you have to fish or cut bait. I was under the > impression > that Redhat had done exactly that with the announcement and direction > of > Stratis. > > Why are we not concentrating on Stratis and XFS? Seems to me after > waiting > for almost a decade for the promise of BTRFS to be fulfilled and then > having so many > people be burned, we should be turning the page rather than > continuing to > rehash the same old arguments. Well, because those have different use-cases? One of the problems with XFS is that you can't shrink it. With systemd-homed on the horizon, it will become a problem. It also does not like much when power goes down (even with battery on laptops it is not uncommon), two my colleagues got XFS destroyed (for one of them, twice) when they had to turn off their laptops using power button in last ~2years. Then they have switched to ext4 and nothing like that has happened again. But that one does not have features that are very useful on laptops. Stratis uses XFS under the hood, so it has same problem, but also it still can't be used as a root filesystem. And generally it is designed for different use-case than a workstation. > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73qagACgkQEV1auJxc Hh7sthAAg+omUP71jyuAEXoy1/+B3m+OSikBEAxRS055en4JaKROLQ2UVJOSCzs+ KSJkg413ex8ORxH3l8vhnIlWCVXwV8de2duAt85DpknGe0XHpnLTtC45/xejUiln tjpz8RqyEYTXMEE7KhJpc3KCLgN1VHyVtr+6Y0P1WUOBQWj1iF5kfrB5J+VhYpVO qygMcjlSiFtJW4gfs8siukSebn1t3ILGX9eOvxjhNGgrsfZ4bboq5N4rhFb2+NWF sjBmjE9qIFJK21xgp1XPJHiF4SsfL8CQZqgvBGYcnfmcGb7wiXPZEvzVJ5VVSNh2 7l4VWrix+YDXKmhD7WccCLZOjEGJg7CSOHndm6FPQt6++OGMsWUdmZNAsB9Iw6Ia Y5oDYuVxRqH5VLPKwKfb4FIQJDr/RESJU7Xd9W0+RPwjLb73k6sPyn3eWBMbiWaa 5e8G/GlWJtT1GGQT3fBnUtKhRBrCJQ/tH/oDmWQ7BLgUWisiU2eOaMB3MCWDq13F uaKB63CU8EnvdDJGCbjy0U+D/e2ZRD8tKNcJAn1dl8+sBD28/vd5cO2aTv4AYSjG Jf9e7RHTy+giMx4jvKbPaQb6187Im92C/7J8rBuk7PhLhtZQU7RM5CPj9aiqYkWg 7OoNVWQSRbljS0V3J0qsUmvwXf5PngLjCKqBot2vbZIV7FM0sls= =Q/6i -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote: > On Thursday, June 25, 2020 2:38:13 PM MST Jan Kratochvil wrote: > > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote: > > > > > I'm not sure why you think end-users can't use a free OS. > > > > > > First steps of end-users is to install Chrome, Spotify and > > VirtualBox. > > So there is left no advantage of a Free OS. > > > > > > > > > I've run with SELinux enabled for years, rarely if ever causes > > > problems > > > for typical stuff. > > > > > > Sooner or later something does not work. I do not want to open this > > can of > > worms whether SELinux yes or not, it may be a good idea but IMNSHO > > it is > > not for a development machine. > > I definitely agree on taking out "rhgb quiet", that's annoying as all > hell, > not knowing what's going on during the boot process. Why does the user need to know what's happening when system boots? > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73pqkACgkQEV1auJxc Hh5AUw/+I3C4LBRAV/JYGGg5TOVn/s4fNgl0ynNRcDDwOGeXJJsuA05o/gU1CWd2 WpnRYMWhMuGjunKs5/ZDxbLENlHsDgnkWrb82Lq9/bZnZwclqCTpWhJFMqDP0zQT FGjhvEDE5XyWoGanYjgI84MNoiTaBRzwaZnncUkfREx3n8RsF8sZWc2hdNynmJVR iZ2O+rsXzL5RfFDQwimyEFRjwlJC0J1baqxm+8XBXRf3/Y4X/YahyO2x6oDY8irO fYbbC1LOlaB9FsrC94uJB9BU8kY/cpZHA8D+CyNYakrCpqiciFwu1gnaqgj5mmtU JOtPbYOxyMb91JTfiyQnTP3MPMoSOQraMO7/VVefGS8LeW3r2dteH163gOSiNhCM bO7R1fusa4FZOUcKp9lbnv61GzbNZ6X1P63lVPLgd61YqcUUDwDdx2rMim+46j11 UxKXGLqlrQbW62EhQhhn3DILfMm37oj66GghE2Drln8l1PZ0LHH8v8I8WCwdJGZ3 hePvbDV7DMmMEt5g/HD1r/qaQSr30f4ZeIWGHFoH3sMepHGWr8uOBRDmccHoqyiE /uo4yPXiNOilcrTnb7db5aY3c0Ghxyh1LyQbqGC8BCUD79NBUo0BlTWgk2W5l19j uxrYusQH8GGv4i7Q1WUvVnAEjdMsgKaa8UwTlXnGEkvIoHU7ZX4= =c/Lb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 10:35 +0200, Roberto Ragusa wrote: > On 2020-06-26 22:13, Justin Forbes wrote: > > > Saying production on millions of systems is a bit misleading here, > > when you are talking about millions of systems at a single company. > > ...in a redundant configuration where losing a disk is tolerated by > design > and managing data that have very low vale (mostly pictures of cats > and random chats). > > Filesystem quality must be measured in other conditions: have a > Postgres > on it, financial transactions, random blackouts, etc. Do you run postgres, financial transactions and random blackouts on your laptop / workstation? If so, isn't it just for testing purposes? I'm not saying that it is not important to have filesystem stable and such, but just saying that typical workstation workloads is not utilizing disks that much (if at all?). > -- > Roberto Ragusamail at robertoragusa.it > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl73B70ACgkQEV1auJxc Hh5sxxAAkRqwvcSoGHIK//W8rx3jlcpfWFQ6yVs16fDjWUB+Riv3YEcN8AuSkWAl OuW5ZcEu+kUJ2RZHpruqSFE69Z9IPIkjs9jbawkhFgU0f4F32I4NliLJj9+xHdpK p/KdzTf1tvKzy3hjxS7IDJEWJToPDAxjtdH8mD+XcXTFgTHiR1xS+sfPxPrMbIh3 jmySlx7ExSwixpJwqTljyK9xVK+1r8iA38vkr4DA2sKlm7cX3USQhQbFK3LsuOGz nWYy6oYkPWpcdGna8ETaZwfe3bwc/VMfJJtxFNZib3zsuRvsItuzhRle/OTB1r+K 6EXWbzpg8g7NzT3WwfpGlyC0G0K9VJkWFye7aBWSFNDi21Svr7565NyZFGXgJGnG 0mMZY68TAr8ybGxTf+1nPh8LK9alKJLmADgPhzenPUoRVlb6hMLGkwTNmgcEeD9g dhwao2eEx8TY4he+kVBXtTb+v2+AivTpV/iJT0gU9uRjtxuB4f+hqkuHnuS6fg7n YlOOqmexecc6kln008Xq5a8ayJoz/91XTR5fjslotesRT29FyLbkCJlvXRCvLxJW d0bVCtOdiKHZKamBzSlxWgr46R6J6eqyHlF2lelVJPmqKAY8QqxLOKF6hHM8KjGT 1RldNvsN7Muy5bd/s9uqqEeiMsdZ3EikVvMyOM0rurdIhIwxRMY= =TrQ7 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-26 at 21:22 +0200, Markus Larsson wrote: > > On 26 June 2020 21:04:00 CEST, Michael Catanzaro < > mcatanz...@gnome.org> wrote: > > On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson > > > > wrote: > > > I strongly agree. BTRFS has been 5 years from production ready > > > for > > > almost a decade now, please don't force this on users that > > > doesn't > > > know any better. > > > > This is hard to square with the fact that it's already being used > > in > > production on millions of systems. It's also hard to square with > > the > > data presented by Josef -- the only hard evidence I've seen on the > > topic of filesystem reliability -- which shows btrfs is an order of > > magnitude more reliable than xfs (although we don't know how it > > compares to ext4). Surely if xfs is good enough for RHEL, and btrfs > > is > > at least 10x more reliable than xfs, that suggests btrfs should > > probably be good enough for Fedora? > > > > Do you have any real evidence for your claim that would be more > > convincing than what Josef has presented? > > Josef's server parks is a bit of a different use case than laptops as > other people has already pointed out. > If you want data on how it works in a desktop/laptop scenario talk to > openSUSE users about how many times the "btrfs randomly ate my > volume"-bug was "fixed". > > When I ran an environment of about 4500 SLES and about 5000 RHEL > servers btrfs failed about 3 times as often as xfs (this from our own > in-house statistics). That was 3 years ago but filesystems takes long > to mature and I have been keeping ear near openSUSE to see where it > goes. > Is this as big as Josef's environment? No but it is first hand data > to me (to you it is of course just anecdotal evidence) Keep in mind that SLES does backport btrfs patches because they support it. RHEL does not. And we are talking about Fedora here anyway. > BTRFS has the potential to become great, I just think it isn't there > yet and it'll take 5 years of smooth sailing to convince me. Probably you should try it with Fedora's kernel? > > > > ___ > > 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 > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72TU8ACgkQEV1auJxc Hh759w//XHCXloEj6QAUNpVxCEljVwm1WQVl1jfH3p+mex1a5Dan242COXkVaEzy 6zR79EZf7ONg1dTU41fq1mg3gWkFAE/q+OD4cSJ/Jbwyt/L+L40MgD1h7UmNo0/P uytLZYC3BUIq9ARAH2DlYMHSQUcYZ8TOyrlxWUmkyqPnc99D9CkkqReRjWA/EtYi mVNOzCQwdMefSJu6+HZlFIhyYeyBbmfu/Q0v5uQE9CQbmN/AuyTHmWG3jRYTINxg 7w8vFPLwjUEmUno+i0Jvkdr4EqSZihV4ljoA0MO8OEADHamjnUOWX8HiFN6E6y+V cDXPvVTqdf7v+Hz6j6F2cUDbm6PQrbd5fODMeCVibuE5knDB587jRcrqXYfSp+wL 66VRnHXYrOAMHXKlcs+XpPxkqfy5AdgvkP63PUZTWb4yb4wElVVpFNsBf2wk7TXu kp9cKSf+1CSaIq0oD1uY9YB4Xm9elI3pRJJHuH8TrOKI4RsxnmjXdpXB+pzNf8BH 8PQex0mAwcvefiK0MfaJcl6cP9PgIvvAb75OoWulEsXGG9uPT1ZknYwgXPFN+eDs T5Wr/7957eiDDgYDtxPXQfliI58AtnCh1ysNcEf5vRLEARs3HLT8Mo+Z+o78ZvpG ZNYkixPYKGrGrUdLJzwXqlQAy6wlNXDzTIxPtrXy5DHMkuAAAqo= =2hBc -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-26 at 17:30 +0200, Lennart Poettering wrote: > On Fr, 26.06.20 10:42, Ben Cotton (bcot...@redhat.com) wrote: > > > https://fedoraproject.org/wiki/Changes/BtrfsByDefault > > If this is decided to be the way to go, please work with kernel > maintainers to make btrfs.ko a built-in kernel module, so that > initrd-less boots work... (it's kinda pointless anyway to have > something as module that is now gonna used by most people anyway, it > just slows things down for little benefit) Good point, we'll make sure to not forget about it. > Lennart > > -- > Lennart Poettering, Berlin > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72F54ACgkQEV1auJxc Hh4GlBAAmKs/XoAYcj4+H8L1CAppzO4sK+4ubP7jRJ+f+VkSZ8jiDDzx/AgbDty3 byLFznYREKvqXWwTSm3cjvHl/8ZOoLCV5WGe7BMz6o6xqXfphDt0lVj1ZAbgXBoR 4BYOlMSqFI836nLMew1rR7ipOwpCdCVX60RJMPXurTptYOqIqp0Zoq0TRqqMOFTU zD2CYcMHkxUlWbFJUfUae2VylW3L9IWsBlOq4HpZl7HF/zeDgLUFlt8jaOyZBUwK plE22PaeZr5h0qULgJutlmeg7H2k8eF+Oa5a5ZAQQJzywoKtICJzm9NB9Ls1lvCC GAUYpE96cnimUZWa2zI8IhZ98x44hb5Yk5undGiw+7uDhBUFfdxbE9xteq8PL3X/ fk13RyG0YOMqn2HhS/F4xOgtENo4qmxpDZQEmnOd0mQ0IrIaYn9EI2FzWGNkYGlN Vpv5OZrVEFeWaFpeCSs/M2jQXyTLmPrO2pM8lHEPiw6p6n2Jq7izNOeEvU802tnQ /EFANvLm0toU2+eAaMLUQKMkIkUGfyCAuHrv2c2vZHfpkq+/9Q58P0DnL1A6F1UJ /kSTUbQEQJMKJxERGROC3JzIMJFKiVbmuKy8rQ4+OB4Un9I67jxoGpJmxQF1/RgM QHdlsDZEGXqsZh5bZXyv8aLW/s+8bByhmp+si0rT+HIQGbJNpnQ= =Yl5y -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Avoiding the automatic /usr/bin/python3 dep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-06-25 at 14:50 +0100, Richard Hughes wrote:
> Hi all,
>
> In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and
> other people working with low level firmware blobs. In
> https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was
> suggested we split them off as a subpackage to avoid the
> /usr/bin/python3 dep which is unwanted on CoreOS. It does seem a bit
> crazy to split off a subpackage when the rpm header will be bigger
> than the contents. Given these are such small files and certainly not
> warranting dragging python3 onto the image, I did hope I could use
> %{?python_disable_dependency_generator} to tell rpmbuild to basically
> ignore the .py files and not add a /usr/bin/python3 dep on my package
> automatically. Unfortunately that seems not to work. Ideas welcome,
> thanks!
I think removing that dependency is simply wrong. It essentially means
that one would not be able to use those scripts without dependency
being installed.
You should split that package and can use Recommends to pull it in by
default if desired, but definitely not removing a Requires.
> Richard.
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl70r2YACgkQEV1auJxc
Hh4O8A/9Hvo8dEqo0/yV2rdUr/v/OYwggwbWTVXHm4L8OhgRBGhhVPjI3vKYiumu
NsfgMmCNa5FE7MsYkFEg89CiJrbWT1+9JWxSDbtj1rFsh4OoDRM06Nddd6w3Kvuh
LPh0u7Rm2Jb1JD+V4U8GCinR2guIPsBHEDfdM87twt6UnuRBnZneURIXALIi7SBM
zO7BxcuxGGN9xn7V5UZA5771yfdIAoJNi0sndWTK7NehjITPTIwyESs/ReDwBs1D
ix58Ch7587kH7qslK6hWWppkYvyfxG/bMHlWuu/Os2bLKZtWmdAa1UlhPbxZokPf
U+UKZYSi31waUgN7o9aynRGt3Hj5ukrJ4HnJw+0Z7X6BHY/l5xAGlDhr1fS7he0T
th2Ta3EmT16taSlMhtn1EujnlW0e3DBf48WJyfUWLwntXu4uPxsZOef83ET+TCuA
Ch3UwD1XG31TgHI+8w7mlonh5wLxea+pEtUu0hMHa9RSejA3wEER9iYeGxz1c9Lg
k4UNTeeffTF+ryP3/zq2lbVE06ifrCkO20QQ/KR3YtjtI0HeAvCR7+hWNlPA+hnw
zcpJnkbo2COiwM6PsU7TFg5Dal8J+atbmIIOc81FMoj3fhi+BaiZnUSHkAqiU0te
2NMmPl4O2QFVfMPmmp+nmieu0sUNQP5QXiCUtxN5akqFsl0zbF0=
=fnbm
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2020-06-24)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = #fedora-meeting-2: FESCO (2020-06-24) = Meeting started by ignatenkobrain at 14:04:37 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-06-24/fesco.2020-06-24-14.04.log.html . Meeting summary - --- * init process (ignatenkobrain, 14:04:50) * #2409 F33 System-Wide Change: CompilerPolicy Change (ignatenkobrain, 14:07:07) * LINK: https://fedoraproject.org/w/index.php?title=Changes/CompilerPolicy&action=history indicates the proposal was not updated (mhroncok, 14:08:44) * ACTION: law to propose PR for the Packaging Guidelines and we will vote again once that ready. (ignatenkobrain, 14:12:46) * #2390 Request to permit module default streams in ELN (ignatenkobrain, 14:12:56) * ACTION: everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo (ignatenkobrain, 14:18:02) * ACTION: sgallagh to submit Self-Contained Change Proposal once ready (ignatenkobrain, 14:20:36) * #2407 Find a new meeting time slot (ignatenkobrain, 14:20:45) * LINK: https://whenisgood.net/f2hzskx/results/gbhh7ba (zbyszek, 14:23:18) * LINK: https://framadate.org/ supports maybe (cverna, 14:39:25) * ACTION: bcotton to ask Council about moving their meeting to another time. (ignatenkobrain, 14:41:25) * Next week's chair (ignatenkobrain, 14:41:28) * ACTION: cverna will chair next meeting (ignatenkobrain, 14:42:12) * Open Floor (ignatenkobrain, 14:42:20) * LINK: https://fedoraproject.org/wiki/FESCo_meeting_process (ignatenkobrain, 14:43:07) Meeting ended at 14:52:17 UTC. Action Items - * law to propose PR for the Packaging Guidelines and we will vote again once that ready. * everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo * sgallagh to submit Self-Contained Change Proposal once ready * bcotton to ask Council about moving their meeting to another time. * cverna will chair next meeting Action Items, by person - --- * bcotton * bcotton to ask Council about moving their meeting to another time. * cverna * cverna will chair next meeting * sgallagh * everyone is welcome to comment on modularity PR#83, once the discussion will be over there - sgallagh will update requiest and notify FESCo * sgallagh to submit Self-Contained Change Proposal once ready * **UNASSIGNED** * law to propose PR for the Packaging Guidelines and we will vote again once that ready. People Present (lines said) - --- * Son_Goku (60) * ignatenkobrain (51) * mhroncok (34) * sgallagh (30) * zodbot (24) * nirik (22) * dcantrell (15) * cverna (13) * zbyszek (13) * bcotton (9) * decathorpe (4) * Conan_Kudo (2) * law_ (2) * Eleventh_Doctor (1) * Eighth_Doctor (0) * Sir_Gallantmon (0) * King_InuYasha (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7zgyMACgkQEV1auJxc Hh79QA/+IVaJbzACBXQlfVYcjsnpAR3xsXAh+dKFg69nUi8ecml+8IdHJ+odJ2pa IC8uouqROHwhguhq1TmwYoBp0tWzCKRBmzQoSjNWIPR/UZrMumrX2B1dGktjYWxj nTOPtj+ZG+GemTPw6LyDwqkT35p8GOuwkp3m7s4ggSNi+63INf/EiJCT2f+hptRa u1GNo3dhALKzmu5/Q0HmDoJLD/4URO86Z33V+V7J2CB6UaN6WCFH0Pep07dTpVRW /aAVjmFwTCPD4jKI9PZOP3M6jFGDZ/0NAyDwsz+71/fNPVHk1UC/cApGp2OWtXAi PlwSqmg6s/w28UTDNqUnk/Tgz8FckItF/SrLAe9XflwN8oykGkx7Y6l6yKfiKBsh utFcuqPa8MIMNHLIOAVu0HVYoMbAVWJE/6ksftdpF0h0B0+tAGLHq+azewc3fGpk jDbqtL4Ai8z2xBHsgQJ2dzqTlPWX6r2WQyVaDdgJFU3AW2e4u+3+7dBYJwcuF/Av MsANV2ih5CTkxMLdSEnpZlCteMrRaDTlsjyScTZngysEajWAxCOQvozwPznPzEBX voT3CCUam+84795JnMtwutroIOYUL+1H2bDP2yU5dQTwcX0u7thkX9f+PI4Ift+b PJQfIMf7MVVLj4bg8HrsHL73IU++rFj0KZ2300yrog5UYt14GvA= =yN02 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2020-06-24)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-06-24 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F33 System-Wide Change: Aarch64 Pointer Authentication & Branch Target Enablement https://pagure.io/fesco/issue/2403 APPROVED (+6, 0, -0) New FESCo rep to Fedora Council needed https://pagure.io/fesco/issue/2405 dcantrell willl be a new representative (+9, 0, -0) F33 System-Wide Change: swap on zram https://pagure.io/fesco/issue/2408 APPROVED (+7, 0, -0) = Followups = #topic #2390 Request to permit module default streams in ELN https://pagure.io/fesco/issue/2390 #topic #2407 Find a new meeting time slot https://pagure.io/fesco/issue/2407 = New business = #topic #2409 F33 System-Wide Change: CompilerPolicy Change https://pagure.io/fesco/issue/2409 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7yPJgACgkQEV1auJxc Hh4sPA//em6sOv4mugq2qEcya409mXHp6Q19yWMp44rYjyeAgVv/TZzQceol2IxG mEMfLpI8qsE1COyP7+IOBVqmfHhpBNVN0Fjy7hCnpcWfRiiRqgN4ZYva5eZIQdI3 YJKQe1Uh2/wrJZcplaP8aa7tDL4KlV7zDd3IvULRle1TBtYGU3byTCYxHeXmj3ou ldKL86tpcc6Vyk3eh1qb4iiwEvKDOvQT1WRLYq7wUxlj6DIofvrNxwsNcs8JEr9x kv2JhRxtwyI2qxgc+mHshYNg+DD/pZiotkNjJSUeRzfNUxo+jP8VV9V4TogfMMR/ d8XKx64QfpkGFggeHPU5vOJMc3VL1hVJUu7QPbqh+eDXt7/H9IpGxlAzipYHdf1X blwFYttl0ng8RqrVuzFONGcic0UF+SSW5cSC88mGd/VxIUZ7UwXmSSh8E0LV9fNF dvGo5cY4IFUsssxuI/gGvPE2y6XlNH/Fptb+TZKaC/xPNB8F6qUUBqAVFxDUCrC8 KTr301JqK5rgVzF+dlJalOI62uj1hLyIcfFjSQLUM63KbLvo/FXfBenu9efG5FIm Uh3g/9p9ungJvJX+BI/0LHVx0aBN/oRFfxcJ3NjfoeUESj9dOF5QujXXyNPFqKXV ssS6fnnuIGfO52ozB7396CxRfP7jUKEm7lsrHuraTiU2vFoBksU= =G87X -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-22 at 09:19 +0200, Petr Pisar wrote: > On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote: > > Around the idea and concept of modularity... what are the benefits > > to Fedora, > > Fedora developers, and Fedora contributors? Through the various > > discussions > > on modularity, nothing solid in this regard has been presented. If > > I am > > Fedora contributor now, what can modularity do for me? > > > It can define a build order among packages of a module. For that you don't actually have to design some special format. The buildsystem should figure this out on its own. And there are such buildsystems that do that - Open Build Service. > It can change RPM macros in a build root (including SRPM build root). I think this is not really good idea, but again - you don't have to invent new format for this. Open Build Service allows you to do that in a project configuration. > It can use transient build dependencies (a package is built, only > used as a build > dependency of a consquitive package, and then dropped and never > shipped). Same here. > It can build and deliver a package against multiple exclusive > dependencies > (e.g. for different Fedora releases). The same thing. > It can build a package from dist-git sources that do not depend on a > Fedora > release. Again, same. > (Teoretically you can build a module from non-RPM components; I've > never tried > it.) > > -- Petr > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7wdP4ACgkQEV1auJxc Hh5iiBAAsdv3yWu6y+Un2LIGFcAomRmwijA3C3aajdNXDHWO3mco/MYDukjPVMIl FHO7xDg13ZCvxQ+AsKyVjJwRXI8ugyLatLBTO9sXLUw8LBtl36RfH/P2wXYCA6kM kB1aWYxxBlBLuZ2cJmyYJHfXEtOFDQHz1gORIX5HyXnL/asXOPwgeh+VjYGnNMPn FHSGCelFrW+aRU8E6vxxuqNrqFwZwXbv3ccHEJIihRMeFKoGFqfDRy/KMQFQ7zZm NagszNoFpfAhRLEqRYaHg3GR0Kl8DYlcJCNJrXmoBdlu/nlDy2soOOzs7PiiFtuN izdZeASITvpcBvR5h/wt52IZCAGP/G/YmSZE73LWteBZhiUBimuAzl1cAEQWfPBc /y8/mdMXaGAKtQcWZ8ZZNMXYqpyR2Ahrl13fK2XwFBcyi6/mnCsX27KAlczhdnlS siBzxyQW8PBvcbZdWF2XlR4W39RHH+EHdIHeeHdGauc+Oent6xObXVW9HIp/Vvkh VH87cdSBPGiJDmZMXBWs1QqViTHzxSlyX8PI3bFxFoYA+7ZwrER75hQnKNN22Or+ Bfl5i6EHtReatUW1uxtmVODON5hZ8fcxi8v6prjDAGTUMWHHkb6f7tcR1dH42/Sf 1OLXojU8gYMuuY/ooace7zto5ByfIJT0ViUFi0eV0qvG5w053D8= =iMXG -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-18 at 09:24 -0400, Josh Boyer wrote: > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote: > > > Hello Fedora Community! > > > > Hi Josh, > > > > > I am a long-time Fedora Community member, and may be familiar to > > > many > > > through previous FESCo or devel list discussions and passionate > > > debates. However I write to you today with a different community > > > hat > > > on, as a lead Architect for Red Hat Enterprise Linux. The RHEL > > > organization has been following the modularity discussions within > > > Fedora, particularly around ELN, and often the question of what > > > plans > > > we have for modularity in RHEL 9 has come up. Our Fedora Project > > > Lead > > > and a number of FESCo members have reached out and asked if we > > > can > > > provide some perspective here, and I am both happy and excited to > > > have > > > that opportunity. > > > > > > As the Fedora Council has pointed out [1], we certainly > > > acknowledge > > > there are improvements to be made and have a team already working > > > on > > > them. They recently outlined their plans in conjunction with our > > > Product Management team in a Fedora Council call as well [2]. > > > We’re > > > continuing to invest time and effort in this packaging solution > > > and > > > are confident that the team can deliver against their plan. It > > > is > > > somewhat of a new experience for all of us when Red Hat is direct > > > with > > > our product intentions, but we discussed the larger gaps we see > > > with > > > usage in RHEL and are putting our efforts towards solving those > > > gaps > > > with this plan. > > > > > > Modularity is important to RHEL and those efforts are already > > > underway. We will be leveraging modularity in RHEL 9 where it > > > most > > > makes sense. This is primarily centered around our Application > > > Streams concept, which has been well received by our customer > > > base. > > > Providing a consistent but improved experience is the base > > > requirement, which allows us to have continuity from RHEL 8 to > > > RHEL 9 > > > and lowers the hurdle for our customers when upgrading from one > > > major > > > version to another. > > > > It is nice to hear that it is helping to solve problems in RHEL > > (even > > though I've heard many people saying that it is nightmare now). Is > > there a list of requirements that you have so that we could > > potentially > > develop something that would be useful to Fedora same as for RHEL > > 10+? > > The dnf team is working to gather those internally. RHEL 10+ is > still > ~5 years away, and while we're working hard to develop our product > roadmap, that's still far enough off that we haven't put much down in > terms of requirements :) > > > > It is always good to push the boundaries and search for better > > > ideas > > > and improvements, and that is part of what makes Fedora great. > > > We > > > are > > > doing this in the context of the RHEL 9 release as well, so our > > > near > > > term timeline and requirements mean we are working on evolving > > > modularity, not a revolution or a replacement. We are excited by > > > ELN, > > > as it presents a possible space to allow those that want to > > > continue > > > to iterate on modules a place to do so without necessarily > > > impacting > > > the broader Fedora distribution in its entirety. It is my > > > personal > > > hope that we can use that opportunity to improve modules and > > > modularity in the open source, Fedora-first way we’d prefer. Our > > > near > > > term effort to improve the existing modularity implementation > > > ahead > > > of > > > RHEL 9 needs to occur, and we’d like to do that work in Fedora, > > > rather > > > than in closed product development. Longer term, we are open to > > > contributing to a better replacement that meets many of the same > > > goals. This is what makes our distribution ecosystem work well, > > > and > > > not having that upstre
Re: RHEL 9 and modularity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote: > Hello Fedora Community! Hi Josh, > I am a long-time Fedora Community member, and may be familiar to many > through previous FESCo or devel list discussions and passionate > debates. However I write to you today with a different community hat > on, as a lead Architect for Red Hat Enterprise Linux. The RHEL > organization has been following the modularity discussions within > Fedora, particularly around ELN, and often the question of what plans > we have for modularity in RHEL 9 has come up. Our Fedora Project > Lead > and a number of FESCo members have reached out and asked if we can > provide some perspective here, and I am both happy and excited to > have > that opportunity. > > As the Fedora Council has pointed out [1], we certainly acknowledge > there are improvements to be made and have a team already working on > them. They recently outlined their plans in conjunction with our > Product Management team in a Fedora Council call as well [2]. We’re > continuing to invest time and effort in this packaging solution and > are confident that the team can deliver against their plan. It is > somewhat of a new experience for all of us when Red Hat is direct > with > our product intentions, but we discussed the larger gaps we see with > usage in RHEL and are putting our efforts towards solving those gaps > with this plan. > > Modularity is important to RHEL and those efforts are already > underway. We will be leveraging modularity in RHEL 9 where it most > makes sense. This is primarily centered around our Application > Streams concept, which has been well received by our customer base. > Providing a consistent but improved experience is the base > requirement, which allows us to have continuity from RHEL 8 to RHEL 9 > and lowers the hurdle for our customers when upgrading from one major > version to another. It is nice to hear that it is helping to solve problems in RHEL (even though I've heard many people saying that it is nightmare now). Is there a list of requirements that you have so that we could potentially develop something that would be useful to Fedora same as for RHEL 10+? > It is always good to push the boundaries and search for better ideas > and improvements, and that is part of what makes Fedora great. We > are > doing this in the context of the RHEL 9 release as well, so our near > term timeline and requirements mean we are working on evolving > modularity, not a revolution or a replacement. We are excited by > ELN, > as it presents a possible space to allow those that want to continue > to iterate on modules a place to do so without necessarily impacting > the broader Fedora distribution in its entirety. It is my personal > hope that we can use that opportunity to improve modules and > modularity in the open source, Fedora-first way we’d prefer. Our > near > term effort to improve the existing modularity implementation ahead > of > RHEL 9 needs to occur, and we’d like to do that work in Fedora, > rather > than in closed product development. Longer term, we are open to > contributing to a better replacement that meets many of the same > goals. This is what makes our distribution ecosystem work well, and > not having that upstream lessens the value we all get from such > experimentation in the open. While I support you that we should do it in Fedora, does this essentially mean that this technology is useful only for RHEL and you do not plan to develop it *for Fedora*, but rather *for RHEL in Fedora*? > Hopefully that provides some context and helps FESCo and the wider > community understand where Red Hat is headed with modularity on the > Enterprise side. Sadly no. It helps to understand your plans, however it does not help to understand the reasons behind, whether you can't change UX in the RHEL 9, or you think that technology is good enough for your use-cases or any other reasons. Basically this email just says "We decided for Modularity in RHEL 9 and we would like to do it in Fedora Infrastructure first". > josh > > [1] > https://communityblog.fedoraproject.org/fedora-council-and-the-future-of-modularity/ > [2] https://bluejeans.com/s/W_P0D > ___ > 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 - -- Igor Raits --
Re: Regression in build_make macro?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 20:38 +0200, Andy Mender wrote:
> Howdy everyone!
>
> Some time ago we discussed the misuse of the make %{?_smp_mflags}
> construct
> and that one should switch to %build_make. I tried that and all of my
> COPR
> builds failed completely. Here's a log from one of them:
> https://download.copr.fedorainfracloud.org/results/andymenderunix/7kaa/fedora-32-x86_64/01475167-7kaa/builder-live.log.gz
>
> Is there anything I'm missing?
Yes, the macro is named %make_build :)
> Cheers,
> Andy
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7qZRwACgkQEV1auJxc
Hh6/lw//Uv0vPPdZTVJHLoihzMytEGX1TLcot4kY5+Oa4Eq0VXrmFbXfVAWWCApG
iGCEnVYRiowTAFpwZBzQlyOk7HqAwcO15BrTawDz+acwmF3TvcqM6ugBTVLhad27
ys/Q7BmFic2IGBRB/jBiYHK/jLMqcGc75ekk0a0TSfduj3si5SxvU5o9HcdDUnHr
oH9vEYjapk3RoDPekxFu70B2nd19aOKEJyQoo885HkuxKC+KTHpWqz6ol4Y9cWED
qq8Vp44VbV422q6xpjP6aaDM2xKvyaoPMj5R99+Y5E4nTY9lwKMHy0Vr3kIEun7j
XhzDJjvdkOR9jX4njflZKVf8nPNbG8loBczoL2ZuSUXkfmKb+vS1mw3E3vMkyq5z
beYtF8bYk5/N+HJw79EWJXxE8OlqP/a8ToZXF5CvdFxvJEXrhRe63THvZSr0wYYd
64HeECzbkkkOxf1vrf4wm4SIgAjYZZ6fezbXnWDp+UqR1qgtkbt1ifwKJW7Kj4Hf
cZ7B+1dfjBdve4PU4CtUXU8/hPVw31Sr7ab4+peauVDkjuFjzPzDcuKkJdZFnwoe
2Mdzskz4fW9MefvHODKMq1iNZKbcVF95MerHFKqVWwaioZlgWh14R9ewLv/+naTU
NYgGnQFTfYtOmIoJhWqbshBcGD/MkeyUxeorb89lSmSyd81EuDI=
=nh0b
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 23:45 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > You can also do "%cmake -B %{_vpath_builddir}" and that will work
> > on
> > old and new distro releases alike.
>
> Not on really old distros, because it requires CMake 3.13 (2018-11-
> 20):
> https://cgold.readthedocs.io/en/latest/glossary/-B.html
It has been there since F29, and now oldest supported is F31.
> (The undocumented variant "%cmake -H. -B%{_vpath_builddir}" should
> work with
> some older versions of CMake, not sure how far back, but it is not
> documented and may break in newer CMake versions.)
>
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7psAsACgkQEV1auJxc
Hh7QLA/+IjUXol0e9378X5q+tAMoZZnvXJDEeEeCp5TtT4SUY2kKCs5gKneCK8Gc
bQTrw2opo+pTn4TxFz/oo1RzRcP5wZ3LdmKp8w2e924tmzQAsE3LXlaS5m61zC06
S9K7kg8ANMgwBe6um5ARhgMR4F19l+nb3jvfhbn/wWCxlAK8O7mWJa01f6HLFh1z
S49JZXCd+Ivn2CqE3gDViFDU4pPsrraWU3h36ttEvYj9T7cZZnLFWdLI2dAxh5xO
GVNBkGShodo0+qCaGBzl3Ky5IJPOBZvLyekfYN3jZz0hqav/0UYMtdFzBmAlHBCv
bfz9PzTBiA+LA8M3TF1VMPaGFZO/BuGgRhJ4/tIn9f2iea9RRjK0O5kLNMxCy9Y9
7++Hvh5s0fyccnxrYI67Hop8Jwt/O1dBIVfxpdiAR0NCuwWq27Kwn1oFMLV66V4x
ISrUeGyQXhcoDmbN19CywyhklTBilu+KNo0o4D7gUcsyczrfzeGa9fBulMWZfoUa
gx9uTtsybaYtGx3L/O2Fh9XC1zkvMTBNFsXPKjHo/9u4SAwGuE91JT4OEaUhdQVq
9pmNSIy3hUgJwUr1BpiqJ+hWVGNFsjiq8cWuhmdKezUQiu9jR7gMJ7uAhcYH8Pfu
jjFSI3Kjd4g/r9RUMxNws+jI39v8IgEQU3tLjlA9l0Jb+QJU34w=
=CMj5
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 23:52 +0200, Kevin Kofler wrote: > Dan Čermák wrote: > > Or you use the new %cmake macro only in the f32, epel8 and master > > branch and leave the other branches as they are? > > That requires maintaining the branches separately and not fast- > forwarding > them, but fast-forwarding is the most convenient way to maintain > several > leaf packages. > > We have had the discussion of whether to maintain separate specfiles > on > separate branches or use conditionals many times. Both are allowed, > and > different maintainers have different preferences. So trying to force > maintainers to do things one way rather than the other is not going > to fly. > > So I think pointing out that a specfile "simplification" can actually > be a > complication in the presence of conditionals is a valid point, and > "don't do > that then" is not a satisfactory answer. As it's written in change proposal, we are going to backport %cmake_build and %cmake_install into older Fedora so you can have same spec file across all Fedora releases. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7pr6AACgkQEV1auJxc Hh7REA/8D+CczSJ+Pv4f6ph8lqYIH7Fh2AH7//2JwFD3gA7/AEZrL5+Eig5ZBFQq MzEz1Q8UPn5qDGrH7/69WBrCiOigg5jjs6L2sAVmkRyXIvycueOVZtW6DQMWgmfw Gp86SO+EHFF6csAq7bTqHFfFypyShVz9DgBZw2KqbvAhUxHx/M5ubS/WqGKEmFIs Ro5y0gEzEp3P7fjevDG/H3J/5s11jo/zFCrO3snNtZqc3aLPR0BQqre2JOUWLjYl YcFqKaaQXVKhSEiX3GKe9MsPqARI4b2Y/RhyCJ7SxkfgywpNAWVY9Iy+eCV6jaPe ZGZvpa0vxaOduLkvOO7h3hYgTdtAd95uPrJHWFKJrpjCpYAC81nGnuLEXZRuKBvl 04wwPUFxlXUQALPEQvX+HQeY+XKkecjEuUpmyd5HtsYQ2oMWdB+hfa/Kc975F1Iz 2RC9uGNsnAuGQ7STMG7Gvcxx0Ik51/cdvH0DV+jjaUbBBb1WqxNaPJ79n0YTXnt0 2GYMHzC5UE9Mj05PJzfUZSwh2+hHyi4vQ7aW5z/m1fUwP+AfaenOf/8HkP2CKmUO 6wlgcQO4m2SB8mwjiVRwKmbORyBzu5G8aXs40sFXfEKOlEv6hZFsv8D6Mqry9qfy vvdRrOx2Qn60s1Kw9TKUdhAafdzfRhL3CXIWm6etqfSsAf2sqh8= =pqxm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 15:18 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > The correct way of doing out-of-source builds is to use `cmake -S . > > -B > > builddir` and not cd/pushd and other things. Sadly we can't > > implement > > this enforcement without breaking packages that do `cd/pushd` but > > we > > will fix them. > > The pushd approach has been working since forever, which is why it is > used > in all templates. -S and -B are more recent (and redundant) > introductions. Right, they have existed before -S/-B were introduced, but it does not mean we should use old method forever just because we've used it before. Also they are not redundant. cmake [options] cmake [options] cmake [options] -S -B The former options are trying to guess whether you specify source dir or build dir while with these options you get a consistent way of telling them to cmake. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prksACgkQEV1auJxc Hh7sKg/+O8f1OiUT14JlBcJQabX864VfxfnFfzv4jnS22WiXdxlZ9pv3GP6sQQed vU+Vo0Hmq3v0Qf45qaNLx5pN8foYFD3zgTeSfTaDyCeAWvmebsiXbGEqmSXaddP5 Jdl89aAWg2UzwetYv3FrNqZkl9iVhEWLmFRBdoJ5DeVrpr3iovXM3Falu7GCsFMa zQ8CJNB4E/r4cLQCXzUFkfQMH3hqcg/v5XmWJvLmNm3lFhw4smrbI2f7g5MydXFH 0d+3MNpE+QjqLKXpLGqtKMkq/uFhmREOakwBDwJoJ5mQz0lw5JltVOnF0T/nbJIv T2Aqg1FK0sQF7CtsJP+dKfVfTeIRJ0VPtloF6UUiQAGgUh4/m85zgscV6UKETSoH H7CsN26yU064wVsYG/t3N3DM40/o/H/fweA3Be8UEhb8OrrLcwt9jvbMSVOSvsjQ UKwaBiaV7hXdC3pYrTvG2XZ/X//+jTM70yY1dV/GkBgUEvmt3CHvRtqqNAJrQEdR //JdXbzTZkLMamRFE0CBQ5uTG5zCj2u7boG4ZFg18Y+uO/DKBjT7AVMnKE2YtfuX c//lRTlbTgaeEGPPlqVzZo2lNKYthvyIk3Yq28Oi3mOAtmk8i3+E5lwkFP8JwYHa X2V1qMh+yOvvZDXR0pHJY3mXKMLLzggUStNxIzUk1toxt8/2uT8= =dOuo -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 01:38 +0200, Kevin Kofler wrote:
> James Cassell wrote:
> > If you're doing this, might I suggest reversing the condition so
> > the new
> > way is in the "else" part, hence "default"?
>
> The problem is that this results in a counterintuitive &&, as in:
> %if 0%{?fedora} <= 32 && 0%{?rhel} <= 8
> (by de Morgan's law, or if you want to analyze it directly, because
> 0%{?rhel} <= 8 will always be true on Fedora).
%if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
> > I've run into issues rebuilding packages because there was such a
> > condition from a decade ago and I didn't have %fedora defined
> > because I
> > was trying to build it for another distro. (Common issue amongst
> > the ruby
> > packages.)
>
> Then you will always get the conditional for the oldest Fedora (no
> matter
> what is the %if and what the %else part) because 0%{?fedora} will be
> 0, by
> design.
>
> The specfiles in Fedora dist-git are either only for Fedora or for
> Fedora
> and RHEL/CentOS. They are not expected to work on any other distro.
While this is true, I know that some spec files are taken as-is to
openSUSE and Mageia. So it would be nice to have same and simple spec
files that work across multiple distributions.
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prRMACgkQEV1auJxc
Hh4Hqw/+P6sboNTE3HXfqaPGiG06rzG69crm4LcDaDP2iwOHbXE43wY2+/gTNIaW
pl4hjIcoVH9ANJMQK56bvqHZYgl2z2PZ1MrlYOlAWVOi9CgDRqAX5toS6ivXiBWA
FbcDVWrYtbM/AL+Md0FFnEjjEZvAbXMBfDwAYcQc1Z/tjFHVYW0sCLg1H3XkZe21
3x3av3RH6TTrd7BQWa7DalRv5DJVbrrIqwpRwZmeiK9L2w2vJXGfkLKBQ/Tm0v87
SUZQ2OE+MrgGkF9CxW9z4rmSPzeQyNSAycL11SoyIBxXMIqnUeL/GdezK7mJaofS
PSlSz4hljSZqI+4kRbH4FMB0CSJz4xIJzGL1DAw0X8W2SzWoM69n3r7z4TQtX9Tv
jAf7MxSmY7mhDBnP6ePS5ecTOdvIQ5T0fdqUy8ATqLjnb3gq+2TVQJeF1eezHuMx
/E7OfLXczqpeg/vs0So4T91b2/lW/7zJicG+81Vw7efDHBJPMpp0YxXpQr8MOwwz
ALVG8OZU2KuYQnZ6OyJi3xB/3P2MDkPjq0G5revzmzirq6IkrB4d8CuuK8jq4gI7
wS81Re+Z0jU9oUKnT+5nUsRu6dC8iTM+j6qrCMGvhif1wgKlOM6FtR7MysZCwH34
ll+OXRvryP7QnRwacpDneh1OGxBz6JzBLXVdtsz5jWdErOFb4TQ=
=QAkM
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 18:54 +0200, Dan Čermák wrote:
> Kevin Kofler writes:
>
> > Michael Catanzaro wrote:
> > > Kevin, the goal is to *simply* these packages:
> > >
> > > mkdir -p %{_target_platform}
> > > pushd %{_target_platform}
> > > %cmake
> > > popd
> > >
> > > It's four lines. We get to simplify it down to one line. Proposal
> > > owners are provenpackagers and say they will try to fix affected
> > > packages. Fine by me?
> >
> > In the real world, it will end up as:
> >
> > %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> > %cmake
> > %else
> > mkdir %{_target_platform}
> > pushd %{_target_platform}
> > %cmake ..
> > popd
> > %endif
>
> Or you use the new %cmake macro only in the f32, epel8 and master
> branch and leave the other branches as they are?
Also note that %cmake_build and %cmake_install will be backported to
f32 and f31 so you won't have to care much whether it is in-source or
out-of-source. You can use those with `-B %{_vpath_builddir}` to ensure
that it will do out-of-source even on older Fedora versions, otherwise
it will behave slightly differently but this should not be a big
problem.
> >
> > i.e. 8 lines instead of 4, and much less readable. Most specfiles
> > need to
> > work on older distributions too.
> >
> > 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
> ___
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7o/DQACgkQEV1auJxc
Hh65YhAAl2Ym9ht9817hcXRiN1cIMqRceUITnG0TYZNco0ipKbWGIEeF44g/kHw1
coQmthh4J24a5vj6/CgXGozm/InpSkwiitPfsdrZ5rjtdafk83DGeVbEpNvKPu4/
5DngvInCe3K1/W0JyyI9uA2PtXrbnW7QtZfqu7SrKarCReQSwiCFfpAwEpKgq7Ma
xK2/Sidwtz6/wohrEYMs+FEtmzq+8YbkunGza3IKmFOolGGsZNyTmHya5LFu+AuM
VOgmM6LbJdCtgHFYgV0Ag/fvK3ftkIuXPRCiGriO/VRXY1QGnrnLcJXAgdycF5Th
L9HMPKQsLXWD/CLo0dOAZSRw8ls9JQgwste3qMZuE1RimpIyO1UsbFpbEpOJsjb6
ZrYoKPfrVSYhIndfGhTthujkrwAY6lGd33D6YMN8vpZXMCqiYwRS9iJp3tREejFO
dmMsc24BiXCU3pusINakVDc8pAM1tUmP7OEIAFJkl7jLAv4sDXh1tJRyOr6RkS70
fQmvBE7UPs6zJ8wHwGmwbcOoPjemnbZUltmiXM5nIQ1o/Mqx6uP0QwCnOhOd+9tX
4w9fkxecunk0sAWFscaHWoE+wIiDMfM48FWJRKQXdRYdN5g/jeKrBqanK0N9RiI/
46xgJZyGTXmhKjAkINyEo1uw0wFHr7imKLZgmJKDTrhFQGwBReQ=
=9at0
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote: > Could please check what version of glibc has been installed during > mock build? I can;t find the logs or the build artifacts. > But by checking other build yesterday I can found that glibc in koji > build is newer than the one on my computer (fedora rawhide x86_64) > I think the problem is because koji is using > glibc-common-2.31.9000-14.fc33 for f33 and we can only get a > 2.31.9000-13.fc33 now. > Maybe wait for mirrors to update (and install new glibc) and retry? That's true, but I am surprised that this is not handled by symbol versioning. This function seems to exist for long long time, so why did it break just now? > > Igor Raits 于2020年6月16日周二 下午6:11写道： > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Hello, > > > > I built gitui in koji (f33) yesterday and tried to run it on my > > laptop > > with Fedora Rawhide today and it does not work: > > > > gitui: symbol lookup error: gitui: undefined symbol: > > pthread_getattr_np, version GLIBC_2.32 > > > > Did anybody see something similar in other applications? Any ideas > > what's broken? > > - -- > > Igor Raits > > -BEGIN PGP SIGNATURE- > > > > iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc > > Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY > > QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv > > MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p > > NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn > > faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In > > h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1 > > nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn > > +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU > > bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS > > a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII > > mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI= > > =tZrU > > -END PGP SIGNATURE- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxZIACgkQEV1auJxc Hh6raw/+JA4UnrNHd3x/adWXtrpJis3eQTy8pzFiyLIxzFZlUGS/RjVeuK77ESsO DiphTp+9KXZ9QsWJqGlQuO1Epa1WnAYQGXZ3QEBuHgGIdphjEUePAj1+BFoAVVmK VkRsLEvySJnyMrppWsODYMVfMt5+sHrBtCvT3HSqjoc0CfKK20WVZ8Sf3tNSm44W twTswCRCR0B0G9oF0m99ql9AktwIKs1SbilGclpx05jGGTm1pwSS7G4RbMzEcO9i oElH8vRrT9OifESPIIHYxnvP/2zXt3ltBNmR+1jMB8qeISeK1CKqF41q7VCHtcS8 DSPGG7kXJUQxHMlA01VAl3+kcKetPv+0y9R9g4Ymzb3vaTm3b1MlJwrfZtA3/8jv BzeQhjFR2ANWV4tEHUvA06FJQV4kPfy7Y1adxeXD0me5VxMOvEPNmB0oCNrNDn5V IJlHMpqWX0Bbpa34NUu744LQcM7GyaircD4whLbG4uWHqbHJ3i8rgx7XGsPeKrAj kjhsFErKUk+R7/7/7+BFnOU29w63ZjTWxf0hhxVJ3KVrSmUQ0Xh0Fsv1flR8KzFa lvkCMC9Wd3+uG+dFla9X2B6BDGAKkgQdmlXNeKoulz57TCP3Ai43buYzFEpFGJrD 2HUuJp+qUAlK0/0Fh/0PEzhBwtIYUZv7iwADo5EcV1UUkaWLWYg= =tvmS -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
> %cmake?
I've just updated the change page that clarifies this question. I'm
also surprised that %cmake_kf5 does not use %cmake, but we are not
going to change this as part of this proposal and leave it for anybody
else who might want to work on that.
> 2. If a construct like this is used, I guess we will end up with a
> VPATH
> inside %{_target_platform}? So the -debugsource package will have
> a
> nested structure like Russian matrioshka puppets or Chinese boxes?
>
> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are
> doing
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit
> from disallowing in-source builds, it is just a simple special case
> and
> normally requires no extra code to support.
>
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxS4ACgkQEV1auJxc
Hh6VGA/8DTF4GLhj8yAJVQNn3JA7UyrYKlx89aHpxCQVtJg3SqbnwvZVHwrl2LHx
cDhnbYt7KmzGkVkG3iapdROBXFED80zXaGm4BAOZF9YXUQyphpaker4NkIyjfksx
GE2bD77ZlzP+5bBnSWSkJ6zJtdxVf7KK81V7jOV0tD2DkDJp6VjBvJJZ009PKZha
Exe5cr1bbALT6+j4IQTjTZOAiqxpQPZasb9/5VXz7G+J79ATv3kBpueoJpShba/t
BcTzdUVihBll5jS6BJQkFUhdfjb1kjZ4YndZ7aPSPnpNJFumYEyfkKrm+yIjlkA2
aaSL5Yy0RjHB8k+Sixftvc2sCjbtU6QhRYOOyxYpXXiHnHrev09YD+H2CzR8/FMf
e829Epm2eUDmKA4JEuCWNTwpRS+KZ+ga35GhVWsBzFecSQT8pGaz2Bu9teKZevR0
pnAzlxKt6VnXBHRWj1DtcoNUQbkDNI3/Nu25XwY3GsR/jjYNUl7Z6/UgtJmuodLL
1AZ3P9okMFofcevkD5rI+QPAG2SfEOGZd4ONZBZ9PP3w1gDWM0T0BojFGXYhZ19d
GGxlYvYKf0pmcAiKuoERJ8JFKC8HFYR6Nj2MzLX4odGHAkwAdaeht1LvZVkgNeDb
Ptt0GmxIUt0i6swjXgVvvIQH1G4fTsupXd6ZTgPwQzWNvXosoc4=
=qwEu
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 08:37 -0400, Neal Gompa wrote: > On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar > wrote: > > > > On Tue, 16 Jun 2020 at 03:09, Neal Gompa > > wrote: > > > > > > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler < > > > kevin.kof...@chello.at> wrote: > > > > > > > > How does this affect the many packages that already build in a > > > > separate > > > > build folder manually? There are even several specfile > > > > templates that > > > > contain the boilerplate for that. > > > > > > > > > > If they build a separate folder manually and are already using > > > the > > > VPATH macros, then there's no change. If they're using a > > > different > > > structure, we can adapt them to the standard VPATH macros, and do > > > other adjustments as needed. > > > > What if you need several builds with several flags? E.g., something > > like > > > > %build > > %cmake -B flag1 -DFLAG=1 > > %make_build -C flag1 > > %cmake -B flag2 -DFLAG=2 > > %make_build -C flag2 > > > > %install > > %make_install -C flag1 > > %make_install -C flag2 > > > > That still works, CMake processes the _last_ -B set, just like Meson. > So if you redefine it later, then everything still works. Yeah, also you should consider switching from %make_build / %make_install to the %cmake_build / %cmake_install that have -B option, so it is consistent across all your cmake code in the spec. > > > -- > 真実はいつも一つ！/ 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxI0ACgkQEV1auJxc Hh7Y8A/+Pcf+MMN79+wDAx7UymW2f5/fxq1gW7f/2KdXSpDBMNcV5xgn8V6b1Z1A nodEQ9PoCOLv7V/q2LZlk2QGs62eQxFWIbTSpCkzCGK1EXLgh3WZ8L1fVH09KYHl NA+eg8FjeQp4eq2wXzY4v3NYhmnJJke4W/WiiaUDZkDQIBRpJ0Wz3ivSQ7R76sH6 lwcNoaN8bGKgetv1WhyWw3BreybCQxigfDzdDHAwt22HGBo5DEkoiw5cx41gLqUO wewpxclacLEMfy4VXkdDQqAuLdSOfwmFFBold3XSyMUm63bMSQx8lDn9bQW21y4a etD0PuW/QnMbWiWQNZIgtNWpj1yD+igSDabDxzRQxHNRJ2Klft32JREhf49vxbha IG0tkzfHpeVy3p7SF6VDvkeCXoqfQTKvBO0ciJA9EZF2LleufSoYOgh16Ip3ZSCU mU6uhyPTg07dXijo0cgdEVzteLHR1+oDbxdbVldL3AKqJI+Tq9O/PQU/WcJulEtw iBNoCQLJWaqeZyMheYtTEMq4No5zHBXnsV8Hs2l/gz5DNr7k+yugP07ne3XSPG4U vRBMGoWNa7DcD9PNcSasQuHvlWoWNfz8/nrO7L5ec0/ss0FmIg5oIWoep/oSKZ7J apnQ4Xqq5ktibkpyQvX811Fsy+z2ITLN144lsOqOjLF2v1ByLWQ= =mBUP -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-16 at 12:16 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > Example above will stop working, > > So your change breaks hundreds of packages, exactly those that > already do > what you think is the right thing. The correct way of doing out-of-source builds is to use `cmake -S . -B builddir` and not cd/pushd and other things. Sadly we can't implement this enforcement without breaking packages that do `cd/pushd` but we will fix them. > Hence, sorry, but I am opposed to this change. > > > but we definitely do not want to have build tree in > > x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/. > > That was my point, yes (and what will happen if it does not error). As I said it will error out. And we will fix it. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxDQACgkQEV1auJxc Hh6ueg//SDqWyj2LAhdrwLS9yp/0pJrrfZ0NqFuhfEBKdG4uhxR0dwULeHZ257iq uQAHo92e6SAgnDEhTl+EoAcWqoM74Bf9ladXOckY/3WaHPV4QHGKIeQhzCrlaBt0 79vNaQ02Bss7lkr6a33tqem45DNLl80vMLk66otToKSAKce5sUT/mOx6KmEkJDHu iZykEVERRqSnAJtzgYhhpcT9T1nUVQCO0/0uJUUt1sq0Pr5S5hZPI1I/FTCod7YT OeMOvryRaPgEMu7iuxQ9gLC1ZkwPnUQX3t8rVs4XxAzydFTIxh7iVQpN1JKvCcBp jzkY/zY3TPNkKRIIc2oHeoSUDUQ03IT/pAAlv5zDKBpmAoN/E1ZxlYCFD92y2GsD /VgFCYU8wJeIykWVeFuDpLKmjD1z5d9RFcd8a8tUfswglbMdSEQHNSaI8HIPcAU3 fCiXn9dAjTsujA5qcnZZXcrfGFzJTcxvhlqAjz1cJLyy8y4ogvQ8iQrW2KviF/Tc 06EJ9edPTIaLKk3JN2rq2phOzr99z//PZT/ez7Om6Jh0Ov9CR1x0y+d2DhvToOfZ St+IjKrghPFPNTojQdMkXT5hNYJ92hn0NAGj90WmvnNvIYowGXMAZR7oDhcWcoOw N7Ab715wgy426BtvjwzVKg/kBNmGGX4wMDbQ20M7LdJaBcCT7KM= =lS8S -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
undefined symbol: pthread_getattr_np, version GLIBC_2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I built gitui in koji (f33) yesterday and tried to run it on my laptop with Fedora Rawhide today and it does not work: gitui: symbol lookup error: gitui: undefined symbol: pthread_getattr_np, version GLIBC_2.32 Did anybody see something similar in other applications? Any ideas what's broken? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1 nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI= =tZrU -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
> %cmake?
I forgot that it does not use %cmake, so I think we should change it
too. In that case, we should also update change page.
> 2. If a construct like this is used, I guess we will end up with a
> VPATH
> inside %{_target_platform}? So the -debugsource package will have
> a
> nested structure like Russian matrioshka puppets or Chinese boxes?
Example above will stop working, but we definitely do not want to have
build tree in x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/.
> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are
> doing
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit
> from disallowing in-source builds, it is just a simple special case
> and
> normally requires no extra code to support.
With this change, everyone will be more happier. Essentially we will
always do out-of-source build that is recommended by upstreams and you
won't have to think whether you need to build in-source or out-of-
source because it will just work.
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oV0MACgkQEV1auJxc
Hh7dxg//bGpoju+h0HS+ZqVUQxnHreOZeGM+/OoGwaut3M/tbHYqoSCHHFVGuCPe
e3SwVpdeFxnAvGpa6w5KAuVYTz1bwje8wSDDAmdAF7mUQCgCofZOwVwaqTkCIAVj
UCsZP4K+khwLNSZtrlvqHzp1qvweOk33MykqepG3IrwzX+QtaMkyciAZmxqewE1P
yqpVYtHJeeu4JSg2rcBWswTC08NOPImc/uMfwqSfB9kXUuzoF55iEvWSaYYSHVRa
J2J1MIC+COaj2TODb6F5kbjjasM3sX2QC4e0P6S/R1r+1Kh5Nt8lCYhiCBR86t6S
rTbMMMch+mkOjRdphmbF6NtJBE4q0YlDQfZDB2jhXk/4/PD9wMqOJwk62oobLIv8
qFFNmI62ROzdr44fOG/MsobgKeDI9Xn/VgMsPdeXFMa3hDVvAOKSDrRuHXwUTCX9
/+G1kXhnhhO5uxHtWdHlCGJOFplixELz371lOC8sLVkxYGNpX0vtLtfdMwK6bqLB
RFyJzqBDn0UWMGw+2OIAUw7lAydMXWvLUu781PfW87MIZotM1cu/b23mC4kbMKdT
Cn1vgFLE9VlKh9olB8dCcVBB55Oxk2JbtYNlffT2lZ6U618icoG5XRgqv5WauM6Y
oMpOw0OISRjteYNPNjx2FiIW92Elt8UCs84za27KXyQSDZORvCY=
=ZOqQ
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
>
> How does this affect the many packages that already build in a
> separate
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.
If they assume that builddir will be in `.`, they will break. And we
will fix them.
To prevent breaking, it is enough to specify `-B .` or setting
`%{_vpath_builddir}` to `.`.
> And why is it worth making a potentially incompatible change to the
> %cmake
> macro when it can already be done with the existing one?
Not sure if I follow, what means "can already be done with the existing
one"? Does it mean that you can already specify a build dir via CLI and
some packages already do (e.g. libsolv)?
>
> 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
- --
Igor Raits
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oVDMACgkQEV1auJxc
Hh6eAA//Zcu6swqz5QBUW/Tof+UrTZrYYSVomGuqp7ramJFlDjEOT2Vi8turzz+a
WUkFp3ITGml9W324Y75+TMq9nAnoAwiuEjhnknEQ1aO+U5n9wiCRQx+t0Gtw8sHT
BsP+vu1FbXVN9NgQxmVXfKlD4yB6JAzU1XvVF8szXpHpiJEA3fstMf4wtCJkWRNa
3jHpByUsLijgYoddTO/DCdqIBOtXUhoEHfm98ZmLI4rBvF85vAA67ylcKuWjXHNw
OKtVnTOYBxP16XLEQuP4MyjeZDcBbWxJgAWfaEE4ozhV+D8zRKYAuiRVi29ANJN/
D3QxwZVjMIOyPciT7yrurApP+njMsf58MNs5jVdW2PZX2Kx2unU0ojv+01jBz5qs
hYDlKTmk+zvYrLtG30HXSSoe+WuO2pzeQPAKrCODm89fteyzOfj0ZHW7j02vB/7O
d3WIw9KpKbvBdxTVlfL4aEBxvm3WXfjW2zcXCSCmxUHCX9Hs5pDqOK5KOHpdxWj5
n3msgjAJrF8Vap2cqPwWcbX0plyrKiTHspQuD5mj9j1jG9VjPK6ynNvmrzXJMn0D
wxrkJBA3FpLtNhI7XOdlHPKWVuiwVV369NKkavgKY3ea2QzHGJsnPOaaVoXCtMNl
90pSjpLh1jTntN0VlMMXN3pJaoC+QZw7i76WQJ6wIYp0VKN9j5E=
=SoZw
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground > > == Summary == > Fedora Workstation 33 uses animate background as default. > > == Owner == > * Name: [[User:luya| Luya Tshimbalanga]] > * Email: luyaATfedoraproject.org > * Product: Workstation > > > == Detailed Description == > > Starting from Release 33, Fedora Workstation uses default animated > background as a visual showcase. Spins and lab maintainers running on > desktop environment unable to support animated wallpaper will be able > to select a different frame from the default (and variant) > background. I was actually surprised that we don't do that already! > == Benefit to Fedora == > > Fedora Workstation will showcase its animated background seamlessly > as default. I am not sure if the Change Proposal is actually needed for this, but thanks for working on it. > Does this improve specific Spins or Editions? > Design Suite Labs, which is based from Workstation, and > Fedora Silverblue will take advantage of its change. Other Spins and > Labs will remains unaffected unless their respective maintainers wish > to use the default animated background. > > > == Scope == > * Proposal owners: > Fedora Workstation may need a slight increase of its ISO file size in > order to implement the animated backgrounds which are in PNG format. > Each frame from animation will be selectable from the Background > Settings. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: Possibly a slight increase of ISO file. > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > Users will notice an animation of the default background related to > the time of the day. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Revert to the default static background > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) > > == Release Notes == > N/A > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n2A8ACgkQEV1auJxc Hh5RFg//Sl5dAmadTFxJipPKtYbNdXINFBwjdqO0Ww2GjrJo7STOLhbGkGTS+hVH 4phJxONNml8PW9RbNBEzMJwhR+U8Ma5ghD8bslMYanmpjCwoTAVkSlttu9AvdFNp VZcEE3p4TNIKiygELl22EsIj2APm//cDoq7bY/Ltx9tIdJDob4G9aur7g631rzQm p0f60HznSHQdLE/5MmBfgWPu9TAh9IzFvXxXarmmDzg3njYlurfFhNUaBh3ZrwwR upAgjSgyL5YDqCE6PTuj1pAR/ZLlajXgdSiVKQmO5UTI4svC06iuMlBUFOIl2f11 +dhLWv4o13GWACEWnM+TD88vVYEwRGWLgbOn+wpz2GHPYBDyavtIhOZXUPHY4+lV GivFrdzstW6U1nC4VOwin2FpX3uJGSFw9XUgiRhEWbVngco9mR9/zSSXqyS06DFH ojvHO81FZiObZsuTkhaPKB9aNaZ9AtXWsRZ8ykYoJZNo7pL1K1y81hy0lRmGr6nE T3jq/c8mn/w8zKYSOvO+0OcyA17fTlnxwHtQKycZH2xRcikPlkUtXuBME4W2TDFH yNDQJj/B9+cBO6LsY6XyPQf+8NZpadTHvqhOKM1QWWhLMtMf3bwEFA1Q16ozrKKr pfqz3WEncKAF4/9wqOAJz1YoKP4jXMag7yLM10D8He787YMF20Q= =9nHC -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NSSDBMRemoval > > == Summary == > Network Security Services (NSS) historically supports 2 different > database backends, based on SQLite and dbm. Since Fedora 28, the > SQLite backend has been used by default and the dbm backend has been > deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format > SQL]]). This Change is about removing the support for the dbm backend > entirely. > > == Owner == > * Name: [[User:ueno| Daiki Ueno]] > * Email: du...@redhat.com > > == Detailed Description == > Applications that use the NSS library often use a database for > storage > of keys, certificates and trust. NSS supports two different storage > formats, one is based on SQLite and another one is based on dbm > files. > > Today's default file format used by NSS, used when applications omit > the type parameter, is the SQLite file format, and the older dbm > format has been considered as deprecated since Fedora 28, because it > has several drawbacks such as lack of support for parallel access to > the storage. > > As the default change was made 2 years ago, and NSS provides a > transparent migration mechanism from the dbm format to the SQLite > format, the suggestion is to completely disable the dbm backend. > > == Benefit to Fedora == > There are a few benefits: > * By disabling the dbm database, the size of the library binary will > be slightly smaller > * The NSS developers will be able to focus on the new file format > > == Scope == > * Proposal owners: > A build time environment variable (NSS_DISABLE_DBM) needs to be set. > > * Other developers: N/A > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > The impact should be limited, as long as the users always update from > the previous version. That would ensure the existing databases on the > system are properly migrated. Therefore, we propose this as a Self > Contained Change, rather than a System Wide Change. Does it mean that people who upgrade from F31 to F33 will work just fine? > In the discussion on the fedora-devel list, it was pointed that > pesign > package embedded the dbm format database. It has now been resolved in > [https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902]. > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > No user visible changes. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Revert the shipped configuration > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? No > > > > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n12oACgkQEV1auJxc Hh69AhAAqMcmdCbus8WJVDLeNcLl2o9jIMWGgcIzPcz0wrC70yGG46mkrlD47h/s c3ZuzhiCWi3xZ9NHOwkWpF46DJE9ac5/4bJjxv6doJNfRCoUIgdTYQpmXoYzWXqq mfQK8f2qD2PHaBkK+0Cq2z9TJ/7xigsPKxHPDbzwfjOV4IodTk/0RO6SxsdF6Y2V rOeaPVp+Lf+QRMKVGwpkRidMxwKxEsYN09MJc8yj9M+LL+lqepSzqB4oG1IevOlt 3xb1FG53W5WGe7SOEz4Gej3MVRt/YnZwsiIQD8ztEH8udp9+VBEEtyfVeNkcel0A t5Uq5sJccmWGARmua++4HC9lSPI92MbEITzePfBi8yPquXfhz7pBypKQ4922HarL 0Y4hj1D2hPCySXeFQ9sD0iccgcyew9a2Z/S//aCUIaMY2TTaqgPN2lo9MdD1MbFY r1YD24RA/ogSc+dyK01u354hsPvg0u/hfaZwmyBlXNLWmLu2nPHywhwrKbkPDppC G0dVqgHYSVVnFHuXmviuhWMyrUjiJJY7LDccXGrQEUoIAvU1nYw6HgWB7e/O8dwV OS+XOJDxlzdHolNxOXI+FUaL1r7MlbsAOAkFdS5lFBHSK81yU6BGn1KNPZ9K9z/T uFBZLsIr/T+/iT3pn+1N3DlLLXdAdw67N7MNh2mzwHWWIMv/6m4= =nJVu -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
ny other package. > > == Contingency Plan == > * Contingency mechanism: Drop `fedora-retired-package`. Or remove > `Obsoletes` from this sub-package. > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > == Release Notes == > TBD > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n0oQACgkQEV1auJxc Hh5v4BAAmjdMeYnF5GMjdH30EweQAz1Wsjex/QN/yUP3GOt50EPfy4jbU2RIwije RvwKkJF6JAgEY+Q+mKvRWRlTIu3cBA/Kh4qQS/LDzRSuRba6ZUBeZ3aG4Pe1fn4L XubI8pBHWPfO7W4w3nsF8ivSQoLighQm3/Ee/FqdAUmeD+ZyCqWZLV+hWMX45fMY LSlBLp+Lx7m0INWNBB5lxiXtvx66pBicyAp3YbWmfWGls8TdSMqpIEhSAizPM+Mn Kg09SkQqNtEydSAOS+TZi1fe5mQJKWGdaxTXEfUUO5pRSmIt/JR6uDltgru4ltWe 1eeN3Agp8xltChY8oadlK1SdPL5msjxguKVe1vMjoSXsQKzT53gzVAmeN2lCCnyT 122O2qklsG0RV4lx19aIAKpvq43gUnUAKXT6dZVbLIzh5UBfK2qGRuT6KNNVrRb8 N+fnkYqJ4XDPLdvoaAWdAAFn/WohV3/IXdX5jbN1XahJo5kxO7ePc1TVh0u2A4UW 9qdpAU8P0M5zKoreRWwvTkLKSWdz9wRnPJA0iZgxIWFbOBytmYxlKJzNGlGPKt1N r1dYid3q2QGX5OXNJvwnARQThRTtC+Q295/AF4EPKb4LsV0w7qUYKSe8kjYBRHxv yezHkTo2EUt4JKB6R64m7e05tDRP7wLMTdzLaxxPem+32Ap3cFM= =fm7+ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New protobuf blocked by old protobuf from module [f32]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 13:52 +0200, Tomasz Torcz wrote: > On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote: > > > - package protobuf-3.11.2-2.fc32.i686 is filtered out by > > > modular > > > filtering > > > - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by > > > modular > > > filtering > > > > > > What is the right way to fix this ? dnf module list shows me > > > loads > > > of > > > modules, but I'm not seing how to determine which of them are > > > enabled > > > vs > > > disabled, and more importantly which is providing this bogus > > > outdated > > > protobuf ? > > > > dnf module reset eclipse > > Could you please explain the steps how to arrive to this "magic" > invocation? dnf list on Daniel's system shows only one protobuf build - protobuf- 3.6.1-6.module_f32+6163+c0e6dcb2. Doing koji list-tags --build protobuf-3.6.1-6.module_f32+6163+c0e6dcb2 shows: module-eclipse-2019-06-3220190902131726-a48fff9b module-eclipse-2019-06-3220190902131726-a48fff9b-build - From where it is easy to figure out which module it is coming from :) > -- > Tomasz Torcz “God, root, what's the difference?” > to...@pipebreaker.pl “God is more forgiving.” > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nc1MACgkQEV1auJxc Hh6v0w//ZbRTLiJQJl664pTAPB4WMHhVtYqfCtnOVuA98oxo6VZRgVxK8VK6Lnv7 RQtVcljb11ObQs1Fbr0JijdTERqcRww9W//kYYXOGgs+PI7sZB/y2SnQ3jVybnXm cXDOHUvROjHPW9vhCM3N0wbDFSq/VWPoXHlUuejEZzt9m7OXGfqP4f/APbt2xyGX cttvLve7yg5EdjNwMqEDiaipThpFrqd/RCy2qWb8qBauHVm0AHDruGEcjL3oknoF CtzexxXXgs6eaoNnBpSkAer+iCRdhFhEmkBVk9kPYhNmUelKc8eYKTFDE1gVmpsB 4gHoxZMkTsc6MaAtlhbzPIYwx7Yfwa/spuQZdkp6Shew1fxjlEj4vq9kHZyuSFmW ir8SneTaqW+Aohv8Xs6E/hBIwm/LfrW+5yWXCeNP9uOwZCi1S+v1IaoxMj0q1o9q MbLLtXGjdjv9iHiEm5enr0FM/4Z/ls/ob9IQ2boWbqWHuNSTngR26BRKAFbcNcGG htj5VR6JDu14gsxA1bgQxZQtm90f0UPD+T44VIFR4G1IqGIp82Q5DuZrqbBUCaNZ B4WuFrooORL/mwwDKIleuWailAyeLQo5bQ8PTSH0EBwUM+sYdHigNYcO6tBQP5Kx JoDlkYuoXH2/ShRc2zqUg95IHRCslQan4YpUo834p+sUA6XPYCY= =MuWT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New protobuf blocked by old protobuf from module [f32]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-06-15 at 11:31 +0100, Daniel P. Berrangé wrote: > I'm trying to install gmic on my Fedora 32 system, which requries > opencv, > which requires protobuf 3.11 > > DNF refuses to install any of them though, because protobuf 3.11 is > blocked > by modularity: > > - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular > filtering > - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular > filtering > > All I can see with "dnf list" is a seriously outdated version from > an unknown > module: > > protobuf.x86_64 > 3.6.1-6.module_f32+6163+c0e6dcb2 > fedora-modular > protobuf.x86_64 > 3.6.1-6.module_f32+6163+c0e6dcb2 > updates-modular > > What is the right way to fix this ? dnf module list shows me loads > of > modules, but I'm not seing how to determine which of them are enabled > vs > disabled, and more importantly which is providing this bogus outdated > protobuf ? dnf module reset eclipse > > Regards, > Daniel > -- > > : https://berrange.com -o- > > https://www.flickr.com/photos/dberrange :| > > : https://libvirt.org -o- > > https://fstop138.berrange.com :| > > : https://entangle-photo.org-o- > > https://www.instagram.com/dberrange :| > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nUNkACgkQEV1auJxc Hh4Ijw/+LN9prD1aH0AiNQGExJA1wtq2AMK1rCUGDgUwuC0AbGf0Iw6gf03DgvDL 636ncSbApXlmxR+LhAhyCriAaa7CpMciB3YJvlLrGR7NLGkNLj7zMvETpueXTq7d D/Qj6gnTL90asfHNip8EiXRj4zIRhexf6kVNXnmthfnlU8+44RQcOc5bGztJ633D u8cMo2ksKLWni2n+Or7Oh6LO0Pob0LxH/iaSOVg+TIoQ84/6nHWZFIarrmzC8D+H d0xuSBGcQFDw+5gXA4dVXz0FhYPIYDBtV7ZzCEgn9uNyY4BpMrfIlxF1DGiLMSIz NCiLtpiUEvukWzmKWkUDHk5//NawtNPRzOT7WaKdvbcHr43fouZrPKw1mNU3AmgJ zAgkvMSTpKzGOG328y9XEx/mYcHC/rw/+ct+1m2ctCp8NR3/oPRUUQ5CIt0Y0Vbk oOPnFghGF8wbSd+jdqgRyTsKBI0OSwQCaVBsNM9lx81J6zVfWTCaNiOgrRy/jWrd w2btjd/TagDMKgj2PBcPTPrLjU1BAXZWbT58XFMsM8AGfUrUryE894o2eW+qPeNv f2ruwOsG4uh1qnJh7KKUQCnmpqbWPK1ACwqHdcGdAnqXtqmlCF9PyyVynZ9R3KlH sF1B0oY1/FofziAClw88zyvqBEc6vsEfPGbJo6N5h/UoAtcSqNk= =d4WE -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Is there way to include some sensitive credentials in builds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I am packaging one nice GUI application (newsflash) that is working with API of some services like feedly. Those require some API key, but I think it is against their rules to have it included in the plain-text format in git. I am curious if there is a way how to get those passed during the build. The key can be passed as an environment variable on the user's system, but there is no way everybody will be getting their own keys and I think this is non-trivial process. I think shim does that by building unsigned copy, then signing it outside of Fedora infrastructure and making signed build with prebuilt, signed binaries. This would not help in my case. Any ideas? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7k5lUACgkQEV1auJxc Hh4DJhAAr8lkzSGSZipWQA70K57+bLCQDv7M7igmQYo9vUVz3QH004aShKOZ7tmy XWvkx/T/lNQ7V0ND1jvs74/NwskYYojPgTHNNTUtYOK1krmBtTGjcZcaR66CJXay YZpUiYGouvFmHn15X9VDGO0uoMM4kAPWhdkZ1/Ruw5cSfwSZMW7j48WPaeu6iYNj zujO3hyIfkv5TY323Wx1x8MfPyH5IgwOmZ/OiCyW6mmJaXBj+P+qgMuWZnmkrxea prfK6/Amb8HOm8AbbSN6Cg+jszcRGSAdkSNEPG7ryGbOtWI1SnuzbIqMv3ffE2Rm 5eO9Ycgo9HGDFNLuEMOCT8CkNdl4kf/wYvd3TjktfFQxyqJIJXFlnAWuZJa4i+6Z fq5XIAsmu9aPftKjmF7kYusN0UZQ3Z7Fq0wphdOgPd9wXnGjdeqy/7tkopHSgTJ6 9mxYkXUPmD8kI9LyCVCZOltGsArB1X0GmRaiGnTsfd2H33JQY38+kv2OO1kP6pkG F+osagb3E3rW8cAxWuKWLgx5ElCbLTbe1gdPwNi2gvYEtExxkMqdJAnujkkGXoQk zkKi/KsQrcEj69M83t19GxaaxMc4Ns8ccin9vYe09ffCJKsUUTgvxvCFBtmpSim6 NHx7y8h2VezuF2D4hmR6Q0Vw3Y/EXRPU/7euBl6/Gc6z3+5OzmM= =9tek -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Datacenter move days 3 and 4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-11 at 21:24 -0700, John M. Harris Jr wrote: > On Thursday, June 11, 2020 9:09:53 PM MST Kevin Fenzi wrote: > > We are working on getting this install moved over to recent > > fedora or rhel, but for now it's rhel7 and python34. > > RHEL7 is better than RHEL8 anyway. ;) > > I'm planning to skip RHEL8 entirely, it's totally b0rked. Good to know. Please avoid posting such messages to the mailing lists. Thanks. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7jSlMACgkQEV1auJxc Hh6tpBAAjNN6Hl71RlZ1sAugggpQBJt0/rZ7KpL86L5a/rT8qkSqDIyGCF8MpoFd xBkDQrz2oHd2sSbjTtORlHYuxtrmuju7FijudyphhJVTAWvfdrKfv80f/+zRYwcV gNpgvReqWR2woMSs0TnJnodjnc5adpO+UDR83U2DSI7enJlsUA/HQg4h9O3eDb7t Hupt37/SInUlKkrAe/Rq6967AEIsu+C4VNo3O0kb9wSqCMaWEyyKr0o6M+dqMzQL kZ4gmIwNz2EzDAJaSP1GDDMfrJosUZ3ApsnjcE02UuTcK0+kjT4dp+/bNioUVO4+ FVnka7MhIs4DTqT6lxqLnPCl5CTkXA0t0MqJOMcRtW/OFSYpB6l1d5SRcgu4vlMl G2LmnZ2pEhgTWvIJlv49dDeZOi3IlF2i1XAydKSMKOTHR4kekFy5Wz76UXh2EMRR 0FV6Z3BGNsXD2X9/T5wRKjfaC/+rs9zMZ3Zc3zrT/UgXYSLaYyOHun+geIiz5GJp 5qx/pVoIp0a4wl0u6WVRjqLrtpfQDOorw0Ng1foea3AqMJzHaB0Yep1Rwuq1eGdK Or/yybv1Ud52Jt8rid/zFluPPvJZz3oXeSzL+O5jzdvT5QZsz6z17y9yVVnqDLjm 2TtnU76QEy87Iv/fCWOF/cVEw0XJK3zs0zomXkWti2pKY9cXySY= =wm6E -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Inactive maintainer - dmsimard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Anybody knows new contact of David Moreau Simard ? Seems that email is not active anymore. https://bugzilla.redhat.com/show_bug.cgi?id=1841624 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7d4tQACgkQEV1auJxc Hh5gow//UM5WlL+yOcd5uANoVqbQpD6/FxzxFirFQ89J6LYhzDU88pj0YkD35dT1 3/+tHN7VrBfNPmYAAXyQitpCKvPmhnRE1sFIk+zxh+GkcN/e2AvXTAh1U5MW75+X zMP5hjHedmSvWGvT/IH+qvGdS8ZlMOA4Bgc65dAlHV0x8m3jhb6ue1xxDL94ZftN 18k6K+LMstNiW6ypXpis/Awx1P6On+dgrfHLxqgj+C+4ADqs14Gd9UztvE3ytf8E Emm78SDUKzRraNoA4tk0u26soqhFS+y4tjNQA1mfgo2Pkz8hNfKgd4ThrsDxthcy CBs8hFQ1RequjKHoTyWMAQJo6cWNvsFBr+qrSaMJWaPmS5AuiNUDVvNn6tMQUQT2 GNVMH+DHye8WzSugVQc8nlWCapXSV4Jx4GApauznjLWkzHKE7XQwkOWdLgN+MAix g/GGp3n9v2K1cjb1JSnLx0crVELie9XQyFx7tYY3VbO9sd0avge4dHmcvfWtrY7A QrdLqJQhmfBzO7JvG9uLhb4YE6wtYCRwN0fxIJJU9QjEm32vatHk8MrNZYII/R4G hKKylUoBoLaHHx8dulVXCxvUcXkX7TFJNVFm0bBYv8q/dPXe4748JPtIRd2siTTH chQKRohPbmkAaZFIwRpVMxo/4LOnBGdRwjahVdDzHPD69E5v6e0= =qtWT -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Some services are failing to start with mount namespace errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On fully updated rawhide, ● systemd-hostnamed.service - Hostname Service Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service; static; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/systemd-hostnamed.service.d └─disable-privatedevices.conf Active: failed (Result: exit-code) since Sun 2020-06-07 07:56:50 CEST; 2min 19s ago Docs: man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5) https://www.freedesktop.org/wiki/Software/systemd/hostnamed Process: 4654 ExecStart=/usr/lib/systemd/systemd-hostnamed (code=exited, status=226/NAMESPACE) Main PID: 4654 (code=exited, status=226/NAMESPACE) CPU: 7ms Jun 07 07:56:50 igors-t480s systemd[1]: Starting Hostname Service... Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Permission denied Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-hostnamed: Permission denied Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=226/NAMESPACE Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'. Jun 07 07:56:50 igors-t480s systemd[1]: Failed to start Hostname Service. Also seen this with fprintd and systemd-timedated. fprintd.service: Failed to set up mount namespacing: /run/systemd/unit- root/: Permission denied fprintd.service: Failed at step NAMESPACE spawning /usr/libexec/fprintd: Permission denied Restarting those services make them work fine sometimes, but not always. Any ideas where to report this bug? - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7cg3YACgkQEV1auJxc Hh6Cxg/5ATwHWnT63B1c2dgmOTWbBiB8oZyoQ7YeWsFwNFiUOsF8ap4Ndx3idpuU 1Xesq4MPLhfOlCdBwT8QPxP2vqMfmc3Fxe+jwxBjN/u9yBOqUbaDGWkq6c2d7+rB AZ0pfJLCEodn86UrXkZJ6RhAS/8pXSS60Y13+UgVZhzI/1y9HSfKhjhi6GFDTxDS WRHR7rqeij3XAjM8HQ+bYTjLmxkFIJx0EjfE3sO8va9HSxvnSbSIUuKQnzBtDb5D N92NUkKLfNx6gjL5mcKaKbdwIyazBzxSIgGN9Bz53H30xQCYV86RA9iyvvRQcqQY gLlD8gsnDJJHpcW9Jad5qX44Jqa1dyp4i/2WXozskv387GAAAJ9L00hZuJmHKVjJ 1MT321/A8iEI6DXukkGRdsXtQ5QJRYW2bg6N5PsW/BetHEwWd2+y55zlAbsuzSth Qfhasw/9u8NptuFINrSaZ0RB/OiRHld7OFh7G0tX3ShrjNjF8c9SLUI6eETtLOeP jv8ArHDg7mebjCsHGmCeEqCcNi0CRRl7fCbd0j9J0h9g2jtuE0bjqfrrNHRUhdAk AL9s1xK4Blk0XA+x4nOqnzRZpn5YnlCC4kpmiihKX3i5bH3O6q0qDueDG371qmj1 YaAD6KmRza/+nOPxYUoYtZ4orLFG1VnobJloBzpNmPMPb+Wqzrs= =vw+H -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > The change says it will use 50% of user’s RAM size, but not more > > than > > 4G. > > But if the machine has only, say, 4 GiB of RAM, then the amount of > extra RAM > you get that way might not be sufficient to avoid OOM. > > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > > > Also -1 to adding something to the core system that is written in > > > a > > > language > > > for which we do not even have dynamic linking support. Or even > > > real > > > static > > > linking support, as opposed to packaging libraries as source > > > code. > > > > This is not fair. It is a programming language that is safer than C > > and > > is already used by some projects that we ship. rpm-ostree, firefox, > > librsvg2 and others. > > 1. librsvg2 and firefox are not really core system components. They > are > UI-related packages (an image processing library and a web > browser), > which is at least one layer higher. > 2. rpm-ostree is only a core system component if you use an ostree- > based > installation. In the default Fedora system, it is not. > 3. I think that it is a bad enough precedent that even these packages > are > using Rust. We do not have a reasonable way to package software > written > in Rust. Packaging libraries as source code is not reasonable in a > binary > distribution. (And yes, I was opposed to the Go packaging > guidelines from > day 1, and the Rust packaging guidelines copy the same broken > concepts, > so I am opposed to those as well.) As a result, shipping Rust > software in > Fedora is very painful, because everything is essentially > statically > linked (actually compiled on demand at application compile time > and then > statically linked into the application). Why is it painful? You have all dependencies packaged that follow semver (not like Go) and it is quite easy to build those packages. Another example here could be nodejs, even though it does not link statically it is just PITA to package since ecosystem is just full of very small libraries that do not really like to cooperate so you need to have tens of different versions of a lib in a repo. I consider this much bigger problem than the Rust has in Fedora. > 4. The Rust toolchain is also inherently foreign on Fedora because it > is not > based on GCC (but on LLVM). That way you can say that mesa is foreign because it uses LLVM. If there is ever alternative compiler to Rust that is based on GCC and has feature parity, we can definitely consider trying it out. But the referene compiler works just well. > > Core system components should be written in C. The higher layers (UI, > extra > CLI tools, etc.) can use C++ as well. IMHO, any other programming > language > is just a pain. We also have Fedora CoreOS that uses https://github.com/coreos/afterburn and https://github.com/coreos/zincati that are written in Rust as well and those are core system utilities. I don't think saying "Ditch Python, Ruby, Perl, … from the system components" is useful for anyone since you know that it is not going to happen. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcdkACgkQEV1auJxc Hh6Aqg//bbeyDzTLPVhN41P7TU5LeA2d1c/Ya2tjbpvWf3VaWsJ26UDdLUyIXw2c r4/C3Kkda7qGHmOSjLRlBvzEMe3e7wO+Xi+16ZyTex6+2M1bxifAXZHTz1wtkhIW AmdMvyjJbCrzc3jUG3dj3FfE4PWjS58tZYIvG8XEcRxoyvWOsMRqdaxP0V9Frhr7 9hxULUenGpVzvXz+z8/s7rosN4yqTotv1HCFRCworHhXXErVzEy8ha7EjZpGwnyL zDssJ0jB+5eMYk94J2NG5ZwBkOSxBfYMEO4dDLQdMPk6jBEfpZg1jS5wIkbUx3UR fZpitoOs5snIyh46bjL5ldod9lgJ+j7txSle0tpTbeGsPRqVIq+k7NhRI7s24q+R uaJwHDsGRtBaWeTzzykCPlj7kRh/y/fV3TIBzpi5apK1aXxmAZw/RuMXzZK65yFb cGQ79jKanOzRMCD97T+ExiBNpk5Oj0dEF3dWlbHAxoHDc5UFRxyizUPPUNGHooTg qmnssso/a4MoS0/IdTsHpJP62Xm7tGBm9VfIDkK9GFxBZ+L5nj/43yuBxKUMA2s/ pWBZ2FiqzLQ0RyD1IqXsUVyoxm3X66FRywkTgUdg56MQAvZQkppdeoBwoP4kBOdS Yqnt/GC3iq0bt+7Rt7TQudB5fXOKnFL7oGyrx6zAoct3n+F+HNk= =H4dJ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:19 +0200, Kevin Kofler wrote: > Chris Murphy wrote: > > So yes it's well suited for these cases and the proposal does > > include > > them. If they wish to be left out, that's up to those working > > groups. > > It's possible to make sure /etc/systemd/zram-generator is not > > present. > > Also, why does this have to be a systemd generator? As a user > administrating > his own systems, I find those to be extremely annoying, because they > do > stuff behind my back that I never asked to happen and I have to mask > them > (and/or uninstall them completely) to get rid of the unwanted > behavior. > > E.g., the systemd generator that tries to automount partitions not > listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap > partition > I have on my SSD in case I ever need it, which is normally NOT > mounted to > avoid wearing out the SSD). So why does systemd want to second-guess > me and > mount that partition behind my back unless I go out of my way to mask > the > magic generator? > > So why can this zram feature not be a line in fstab, a parameter > passed > through the kernel CLI, or some other solution that is easily > tweakable and > that will definitely not affect upgrades of existing installations > (unlike > yet another systemd generator, if it happens to get installed for > whatever > reason)? > > IMHO, the only systemd generator that should ever mount partitions of > any > kind (including virtual ones such as zram) is the systemd-fstab- > generator. > If you want more stuff mounted, it should be added to /etc/fstab, > that's > what that file is for! Well, with systemd.mount it is already possible to mount things that are not in /etc/fstab. That file has same disadvantages as any other configuration files in «unstructured» format. You can't override some specific setting of it, disable some mount by simple command (that is not sed) and so on. Also if AIUI, it is not trivial to make it work with just fstab because something has to create a swap during the boot and fstab entry clearly can't do that. > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcA8ACgkQEV1auJxc Hh5VGA//SNQOQdLoTvqZKdfS9DpPSsvh/Lii/FMe38viOmy6hcAjQJ6Z3PlJX9cb e/4i8af/OTzYkoYLQLlRwOfXszcZvKCEtjAJz3yfOTOxwxuItucsC7HeuMXiDlpG 3RuV2yLoZFOo+BwlfjFLxvNZRag+w8GLuSLFO0Nes1xjZMNwoI31PVyIykZ60YsH LX7vPZ80QOKAQHpPuxChyOIH0uXelGN8Mnl7lVu9jPPaDQaCzbUpcSBTeiNK0MGK oUFMXB0zfTZqk0iLI3VVdf3MZl2hro9R4c3AkbDsitcFwlWoMuM07U8jdNvuf0pP Zlm5hnZ/Xks3RzC+6wsIqB//ubS5f6WYLt4B/tH4zhAyW2CIxcWx3n9eonLshFX+ QqS92HuS/KBfcVG5GCpAMVwBdZwikjxbnf0CQ0az34iae2FmKwyVc2jKOwwdwCke eGnMeo623p4uuLC+R9LwjQCAK8BHi6dQqRgY+Ybp6ymzPpffqaWzENxRmGeG/0M3 cNjrsHQlKvxnXhbbungeJIEPVFXn4Y/V1sXOrj5JMW/M9Dk44M3lrATiiiojZDxA tRsKgtGKzT4WTp67N4/dnK61ByCDAew39IG8JFUr/2dUDoDkEpXk4mSxcU3K7kln +yagnUD6UTTeWWtq76nKer9ydjrN/tdi9yVfHGFXqbKboFKQ/ok= =rfaN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
Firefox > or Chromium. > I'm less familiar with the LibreOffice situation, so I won't try to > give an > opinion there. > > Perhaps in this case we leave it up to the Fedora packager? > > > > > > In some ways this means there is no "default" compiler for > > > Fedora. The default > > > is whatever the upstream project supports/recommends. However, > > > there are > > > probably many packages with upstreams that are ambivalent about > > > their compiler > > > choice. For those packages I would recommend we keep the status > > > quo at the > > > current time. For a package with a dead upstream, the Fedora > > > packager should be > > > able to select the compiler they want to use for the package. > > > > I would prefer the policy to have a stronger preference for GCC > > when > > there is no good reason to change. Currently it's worded like > > keeping > > the status quo is Jeff's personal opinion. I would like it to be > > policy. > So that text was literally copy and pasted from internal discussions. > So, yea, > it's my opinion and I think it's one of the option questions this > body needs to > hammer out to more precisely define any updated policy. > > My preference would be to stick with GCC when upstream has no > recommendations/support policy around supported compilers to avoid > unnecessary > churn. > > I would also be willing to support the Fedora packager's discretion > if they can > make a case for it and upstream has no strong preference. For > example a packager > may simply be more familiar with Clang/LLVM and thus more adept at > understanding > what a particular diagnostic means and how to fix it properly. > > Changing, but then expecting you, Tom, Jason or someone else to fix > or interpret > diagnostics for them no longer working code isn't reasonable IMHO. > > > > > i.e. where the current policy is that you *must* use GCC, unless > > granted a specific exception, I would like it to be that you > > *should* > > use GCC unless there's a good reason not to. > I could live with this so long as we define "good reason" to include > upstream > preferring one toolchain over the other. > > > > > "Upstream only builds+tests with Clang and using GCC requires lots > > of > > work from the Fedora maintainer to fix problems that upstream don't > > care about" is a good reason to use Clang. > > > > "I've heard the cool kids use Clang, so I changed my package to use > > it, but I don't know what these compiler errors mean" is not a good > > reason to switch if it just makes work for other people. > > > > When there is a real advantage to using a particular compiler, I do > > think it's good that packagers should be able to make an informed > > choice. > I think we're actually largely in agreement. I don't want change for > change's > sake or because the cool developers use X Y or Z. I want the change > to have a > real technical reason behind it. > > > > > Ideally we'd have CI building (nearly) everything with *both* GCC > > and > > Clang, and finding and fixing problems in packages and in both > > compilers. But that's probably not realistic (yet?). > You may remember me advocating for this in our meeting in Montreal :- > ) So, yea, > I'd be totally on board with something like this. I think Tillman > was also > interested and even floated the idea of finding additional Fedora > builder > resources to facilitate this kind of scheme. > > The big problem then becomes getting packagers to address the > diagnostics. I've > been disappointed at how many packages are ignoring diagnostics > (particularly > those with security implications) and I'm actively looking at schemes > to improve > this situation :-) Just make them error by default and people will have to deal with it :) > Jeff > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bMH8ACgkQEV1auJxc Hh5bGw//RlZibAdAUs6xXOk0A/6Xudz/GdVdf23qeO+BWyPHjQWpFfRsFEuUu6y2 P+RQ/tqdBwccACX1+H39f1mBfvx3GQfRiWbtf2aZTZ305Pc/1psh9nSvMOisa6dP LV8PnS5/tptVmjqOdALupkwA2A6XHp8VDy/EbLJ8dcV7Aag5ygEMttOdzfqg9bPJ +nha9VanxPWOsirfxpv6gb824LFFqjqZnWoOJuDqNIYnAmb/b6IbJdkqGcDcIrni 1Rz5w5Pmc4/B7SIYvmXu9BAW4rLmFPEPRmc6S+kWERLNMm03dtsYfo8D3JQo6a7W cTqa2fwoG9fy4pH6MG4/CSAbaAjxYK41lMloUCOtBVIsRjkUFt6m/snyPZd1m2mC en2292Am0dkk3H9ZcCra7/sDyerb2WrwUwgLOpUqpklmXB+r+ILTyaxRH5p/oolS T5xd1aLMJ9utBLMIINDaHnNiI/jqoO/7OEesjb3Qxu65PiLWCzYTfpEX6zlxCG+m 9yQi18QrwA5Cd9uGug+cTZlH6CeVGPIqMR6F+pNvqdkxz+yXlTkCQsQFGkuCWcpC 0wewgBpf7OXf5XcEgXM5ZbewgNrdWq8PQ5RlAuovOkAGe214gQtSt8gwESfJ2D5c aefXybm8ef+NWpHufw2DAIzqc8zXAc7AqaDPSy11tOoDtfsRSJw= =DYhd -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote: > On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote: > > > > Just curious, how is it done in RHEL? Just some kind of CI that > > analyses all builds or? > So we have a step that sits between the build phase and when the > resultant > packages land in the distro which runs annocheck to validate options > used, CET > coverage across the binary, PIE, etc etc. If that annocheck run > fails, then the > packages are not allowed into the distribution, buildroots, etc. > > We flipped it on a couple years ago in the run up to RHEL 8 and it > proved to be > quite valuable. Seems like a thing we should do in Fedora CI for each update! Thanks again for all the work on making distribution better! > Jeff > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aqYQACgkQEV1auJxc Hh5xuBAAiW2mcJsidegXZcnsI5BQanOsVlawmBi6wvZUs5oMb6QpxSrDlMGPQhBr rW+fLdcC8sHyj4sKeC3Rvc//nURiPXLEtB9MDTZVYbdnglt2dNszDIxxxYtL4ktq fd1EvFNvVtB0mdymErgv0zDIDmkJFlsjkageQ/JZBTrFozHTERQadst8QvEoXZRR EmF1WWIy4ERMKSqX3gP1QE4M0pNjwZVNT72lXjf5oUhIcYvfCwsZCacml7GT8mnt Z+2T9GX/k3DRV568LIbuO3thW+hd4GHQa3eL0l3k/NKOy7US4eDET3At64MQgox3 S+pRSNqHlerRSrrlgDkWUY5gojumN2SwESsXdgw91K53Kvw1zOdppBfp93Q1jBJm sHJQR6yQZzh+9Ucn9ayFHE4pX9Zuvmi/93FiQ1sXSJXAvCEbKkCnMfeYVPCHkM6P d7jFvtbjq0Psl7qjV8ydYtUnNKrSzc/TnnrHbYwCxJ15rdVRKJ/TVV5P+M28+jh+ L+EW1niJpHN5ixgBy4N8OOUwzNi7Y9F9mhF7dLQHUN2rHharVikPfath/KoQ1L6D RYwPkpinn3ffw7FQX/9h3BdhxAF9M0W6/9NUoJwT5TB7v3yRtXbKNakT2BTJN/2z 9GK7szXrO35wHpebpQgjVTY96wZK6ieYiOVzIIyk1O6msBwKpB8= =miEX -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:58 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote: > > On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote: > > > > > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > > > joh...@splentity.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > In discussions with both cloud and server folks, their use > > > > > > cases often > > > > > > do not even create disk-based swap at all. A small swap-on- > > > > > > zram > > > > > > provides all the benefits of inactive anonymous page > > > > > > eviction, > > > > > > including reducing reclaim of file pages, without the black > > > > > > hole > > > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So yes it's well suited for these cases and the proposal > > > > > > does > > > > > > include > > > > > > them. If they wish to be left out, that's up to those > > > > > > working > > > > > > groups. > > > > > > It's possible to make sure /etc/systemd/zram-generator is > > > > > > not > > > > > > present. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the > > > > > Server > > > > > image > > > > > right now, and go with its automatic partitioning scheme > > > > > generation, > > > > > it'll give you a swap partition on LVM. This is correct for > > > > > most > > > > > servers, > > > > > not necessarily the LVM part, but having swap on disk. > > > > > > > > > > > > > > > > > > > > The proposal recommends changing this. Cloud and Server folks > > > > will > > > > decide what's best for their use cases, not me. > > > > > > > > > > > > In that case, would you be open to changing this proposal to only > > > affect > > > Workstation? > > > > > > I think it is fine to have the proposal as it is. Those groups will > > chime in if they do not like this approach. Having things > > consistent > > across editions (in this regard) makes more sense to me tbh. > > What makes sense for desktops doesn't necessarily make sense for > servers, or > other environments. Fedora isn't just a desktop distro. Additionally, > what > GNOME folks believe to be best is normally not the best for other > desktop > environments. Can you be more specific about potential problems you see in other use- cases like server? > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7appIACgkQEV1auJxc Hh5Dqw/+MbNqLrRDJb+cYb61f9+M/lvvDIV2OOoYDggchn+gQfUZbW5oEuMUzJY1 zBCqGUzm0nQovKXZtVigBTcLIW2rl7x9PNrDkF1yI6YpeZ52lQFeC+WlETaOs7f9 KaF6MRfjKY+w1qEX8zDnvA0lCjZJUkreoPI6YanQ6/GvX6bCABF3QjEEGjQNNcKL R6BKFdBKTvI1YHb2lPwNNlK8bDi+IBuEZ466WhaT/tDfGtnvHU6XVYzSwle8W5br W0W13xwH/K/40rgff32TFUoczDgB0XzwtEJ6UkJBUjQJV/mSHRuIa7Bwev8BbuNX Lik1lEQHAWvAyxCAuVrq45d0dzxHpYHwSp1tKaDZgbn8T0NDIZOJNn1q8T9OFhnM ZnnX3TOX2Ey9CaDFCnI6aca4LrRrkdSbcuwwtfefl+zlFqdfMHaBFS+6afMvYLDk JfYGVVwg2wKxX9a8YYFAMFshFjbDRT0lKDg+yhvxCdKjzvAxi0bR+7cEbw/NamR6 NTxsDwG8HNNYMHD8JOM3230uSK22bX1x9c4xzaAgOTtmG6StnekS8nLXs/kZBr1I hXyJ58+dCsh0podC7Sanz+XeFdMtxqQN+8Y0KDDY18sA+wYQwt/5GpkWEk4JPrF4 H2mT7hqm7gNAscXdxAl4b6/yjHR57B5sV2/AU+/XBLIH5JTDuMc= =bmkv -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 13:53 -0600, Jeff Law wrote: > > On 05/06/20 10:26 +0200, Igor Raits wrote: > > ... > > > Well, upstreams are not necessarily enabling many security > > > features > > > or > > > optimizations. So you are effectively saying "upstream knows > > > better" > > > where I would have to disagree with you. > > > > Yes, this is a very good point. > > > > Many of Fedora's packages have upstreams that are not using the > > latest > > compilers, libraries, security features etc. > > > > Just because upstream hasn't been updated to work with compiler > > hardening features doesn't mean we should disable those features. > > Just > > because upstream's code is not portable to more than one compiler > > doesn't mean we shouldn't send them bugs (or better still, > > patches).<> > Right. Though I think the security side of this largely belongs in > redhat-rpm- > config and moving annobin/annocheck into an enforcement role (like > we've done > with RHEL). > > We did this for RHEL and while painful, getting the vast majority of > packages to > honor the flags injection and verification via annobin/annocheck > before the > resultant packages can be included in the distro has been a big win > and enables > us to do a lot of useful things knowing that the flags injection > works well. > > Fedora is behind on this. While most packages honor flags injection, > we don't > actually know which do not (either by accident or design) and we > don't have a way > to easily find them. So things like CET in enforcing mode by > default are going > to be harder to achieve in Fedora than in RHEL. But like so many > things, I don't > have the time to push on something like this for Fedora. Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or? > Jeff > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7apgkACgkQEV1auJxc Hh5dhxAAk6g0ayGwzp9gg0P7LiNv1bfk9yFKMI/cI9ToFi2D3bzOCMomvorDui15 EbRZ+YeBB0aMt8OFMKDFwrLpL6dz9rfjxUi5XLuuUzvhpWpgfi4hDJSM8wY3vT5q vEKLCUi/pSGTIRkAYWnxmrJh7XaUIhuQS4FOWId0rzx++7ywPXKCcimMEmR5PnfU qVA1ulPsWrMZVQIiAM4EecJtHTlBKS8kVv5LecZmx0kqNeiiXFnBhThpTiM5LJJX xLhDGYWRKLPHCCKTBbi1nmN+AC71rEikQykry6XruiHFJUrimKdRytP3wdio89ox cbMbinZolYyHUo9aqN/Mqz1diIAoJsQhZ47RQY78lVnR5D78hUYzFCxg4dYQJp2r U0eOwe8Pd4lZxnpEt3Cegyn/2BlEViQPZvBLZa1yzJ5wpMapcqwNTYsv/H5h8Cj5 UpVzBT6/wbsJA528cpqpb3xZuR97M39dHJac1gs9UWXQlu4oM32A59nuHQKhVYxn ZCmiyLg7yl96tgvE/ilDZrsVA84CC2GY9yZY7FHEFEO+WAAIVUUwTCIsyJXAmMzR VWxuCv00ho78wT+UROaFBhYbjaSQJyrTgITpKBRD/Pcim7rO1PIisOg1bVZgTlZd xPcHCzjMGJ6idrROlGlgmj0Mqj7x9fUqEsxqlNSd3QO8NF/GPNY= =S+0b -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote: > > On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: > > ... > > > > Sadly some upstreams insist on clang just because they like it > > more, > > without any technical reason. The question that comes to my mind: > > Should we still try to convince upstreams to use GCC in such cases > > or > > not? > It happens (choosing Clang because they like it) and while we can > (and have) > engaged upstreams on this topic and I suspect we will continue to do > so in some > cases. > > But in the end I think we still have to respect the upstream > project's choices, > even if it's just because they like Clang/LLVM more than GCC. > > > > > > > Also does this mean that Clang is now fully supported compiler by > > full- > > time working people @ Red Hat in toolchains team that are also > > contributing to upstream? Just curious if we will be able to "fully > > support" people when we find bugs in the compiler. > Yes. Absolutely. Tom S & Serge G directly. Others in a more > indirect capacity. > > > > > And also, does it mean that we will be following same pattern as > > with > > GCC to test pre-release versions in rawhide, do the mass rebuild > > and so > > on? > Some of that is already happening internally. Tom's got a tester > which spins > Fedora packages with Clang/LLVM. I'm not sure if he's trying to > cover the whole > distro, but it is running regularly (it shares a jenkins instance > with my > tester). > > > > > ... > > > > I think this is not fully true because clang / gcc produce > > different > > binaries in terms of size / performance. So just switching compiler > > in > > some package may result in significat (hopefully not) performance > > gain > > / drop. > Certainly switching compilers can result in performance changes. > Having been > through this kind of disruptive change on the other side (GCC vs > various vendor > compilers through the 90s), what tends to happen is the compilers get > to a point > where they're typically +-5% of each other on the vast majority of > codes. That's > where Clang/LLVM and GCC are today based on the data I've seen. > > > > > Also we probably should mention that -fstack-clash-protection is > > not > > available in clang, so in theory binaries can be less secure due to > > that. > Clang/LLVM is closing that gap rapidly. I fully expect stack clash > protection to > be at parity on the relevant platforms except aarch64 by LLVM 11 and > a reasonable > chance to reach parity on aarch64 by LLVM 12. Sure thing! I just asked to have it documented that as of F33 it is not yet implemented, but is planned to be worked on. So that users do not expect it to have all security features built-in as on F33. > > > > > ... > > > > I think this should mention that annobin plugin should be prepared > > for > > clang. > Nick Clifton is already working on that :-) > > Jeff > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aol8ACgkQEV1auJxc Hh5p+w//XQ32GF4YUnJUXbzQzquqogtmnr+wPcfsY9ZsjTR2PRQUhq+C0JV2ipf3 esitrJQlLPsBfU1pyxRT3ISFQZp4/RR6OtUddMPGS0TDj1UMyyBfuuRC+LKpm4wV MoYsOByMlKEZxeqHe2fKvWvxtcXhe1ocFaqpA3lJAPIxAg3UhjiZzqW7UjqqWQVI wC/Ap5BPSyNUH1QAtkfC98q58YNkMtm3YzUGHfebpp608gNgUzk/R8iE/Is+pHC0 laqiGpnhj8y2jwjqkBSc2sZhgwqYOYYPYy61YhouyNLNin5PqDA1dSBcnrNFXmHv gai1a9uHvN/jYUfDmpgE8TaO4EvWIncnlQV7E7SuH8X48nXNzYjqZl1CRj3bkAm6 kE/ZASmTE9p9aNrq5c7YnQy16zgX/jFVZuge4yKvJFfCZSSwMOPizVAMS2eVjBUG ToJE7q2YmGIwwqjX4W59HElCQXTwK4Yrscr5j9F5mJH+IOzOXuu3tW+XyeX6cjs6 OnyeXGJ1lojO5jBIC6PPJ5KtSFUBjOFyQqJb8ydYGdtwFXgjGDYxiBwJEASo00yE Gx1wpkIhQYGdglbDhVk8qd01S4c2IVpsb0ezGL2Irr0TKAtkFw9N6KM04hNf6zyH RdfTNrdJvNwR2QfyOdhWIRsdjI8/EnacZzORKOQ1pouldEuHQv4= =shcY -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > > > > > In discussions with both cloud and server folks, their use > > > > cases often > > > > do not even create disk-based swap at all. A small swap-on-zram > > > > provides all the benefits of inactive anonymous page eviction, > > > > including reducing reclaim of file pages, without the black > > > > hole > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > So yes it's well suited for these cases and the proposal does > > > > include > > > > them. If they wish to be left out, that's up to those working > > > > groups. > > > > It's possible to make sure /etc/systemd/zram-generator is not > > > > present. > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the Server > > > image > > > right now, and go with its automatic partitioning scheme > > > generation, > > > it'll give you a swap partition on LVM. This is correct for most > > > servers, > > > not necessarily the LVM part, but having swap on disk. > > > > > > The proposal recommends changing this. Cloud and Server folks will > > decide what's best for their use cases, not me. > > In that case, would you be open to changing this proposal to only > affect > Workstation? I think it is fine to have the proposal as it is. Those groups will chime in if they do not like this approach. Having things consistent across editions (in this regard) makes more sense to me tbh. > -- > John M. Harris, Jr. > > _______ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7an1kACgkQEV1auJxc Hh5Ezg/+PrFUmkHOc46SKgDIMa5x3w/SCHOF3VKhpvN4bQ6WWY+HpJhmsh92dvle ogYnseXIl2wuOyCr75vIMXpuyvBGoZMBlFJmQZG5+2jABJ1/DZ+MyyYgpBWZtkPs QUoNs03pJ70DHuLjakv4mX9nbXqHPBwOzlQuk07ivdVoj6qTXDhkSpJCBULlBm/N QsHCIPOoP7Hmu5AZuNopjgzvlr9Ezt3ra/SM65hSxJDNl2Pn/Piex4A35i8+WHgs iWCvH04iF/+iLt6V09Rya2d+9xWary05DtZdmIRbsR2IjgoYIWtOwC1rp8DsRcL/ nsRODfQuMbP7HB2IihpWIF4A9PATcVP1r+DE7NtlLdSERqrSbTvKcycbsbGww/7b 9IZhhNSRJ0CH4xyRW7R9E6mRHR8K9uYykD8t0eWS7dIlw7mIbDZnwjHYRu1qlQzK OdgPZkpY9aZkAWWA5iFE3pWIYYmCkRwPPytxFVH4adEqSo0i5xJs0bmbHowthVZ0 zjLQRv/LNxZJTedKgCyLtEt9fb0Gza/8+zrlcmYC1Ahq9+NSWYalFMwRJunRL95b L9NlTQ8qYUZEAQM9zIL4ULjniUL9lNuq5GIH9OE3JdCvtNY78Ml4u9GjRRX+HwjX 22MQqgNdXQ5tWvcJo2gRDSaUzpIENVvPwY8mUwoEuN4ceYVgnvw= =RlRQ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote: > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro < > > > > mcatanz...@gnome.org> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > That is the plan, otherwise the swap-on-zram device > > > > > > probably never > > > > > > gets used. And then its overhead, which is small but not > > > > > > zero, is > > > > > > just > > > > > > a waste. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap > > > > > partition, > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > swap-on-drive. And the installer will still permit swap-on- > > > > drive being > > > > added in custom partitioning. Both of these paths results in > > > > two swap > > > > devices. > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap- > > > > on-disk, > > > > to remove /etc/systemd/zram-generator.conf. And in that case, > > > > users > > > > will not get swap-on-zram. And we could also forgo the change > > > > being > > > > applied on upgrades. > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram > > > device > > > on upgraded systems. This would lead to less unexpected behavior. > > > I'd > > > support that, for sure :) > > > > > > Contra argument: It also leads to fragmentation of the user base. > > Most > > users use a distribution because they trust the decisions. And > > while > > it is only a preference, not a policy the Workstation Product > > Requirements Document says "Upgrading the system multiple times > > through the upgrade process should give a result that is the same > > as > > an original install of Fedora Workstation." > > > > There is a balancing act here that should be considered because a > > large percent of Fedora users upgrade rather than reprovision. It > > might even be the majority case. > > Well, that's for the GNOME stuff. This is a system-wide change > proposal, is it > not? Additionally, you could still be meeting that requirement here, > as a new > install with the same options selected, that is, to have a swap > partition, > would disable the zram device. That'd be a nice middleground for > users like > myself that don't have enough RAM to waste on a zram device. I'm > writing this > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where > giving half of > my RAM to zram would kill my system's performance, if not quickly > cause OOM. Either you did not read the page or I misunderstand how zram works. It will take 3G of your memory and call it a SWAP. With a compression. So essentially, if the starts will be aligned you will end up with 9G of memory. Of course, if that is not enough, you can add on top of that swap on the disk. > -- > John M. Harris, Jr. > > ___ > 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 - -- Igor Ra
