Review swap: carbon-c-relay

2024-08-08 Thread Igor Raits
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

2023-03-19 Thread Igor Raits
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

2022-04-23 Thread Igor Raits
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'?

2022-01-09 Thread Igor Raits
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)

2021-12-29 Thread Igor Raits
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?

2021-11-29 Thread Igor Raits
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

2021-11-28 Thread Igor Raits
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?

2021-11-27 Thread Igor Raits
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?

2021-11-27 Thread Igor Raits
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?

2021-11-27 Thread Igor Raits
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)

2021-07-19 Thread Igor Raits
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

2021-06-22 Thread Igor Raits
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

2021-06-22 Thread Igor Raits
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

2021-06-22 Thread Igor Raits
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

2021-06-22 Thread 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)
#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)

2021-01-15 Thread Igor Raits
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?

2021-01-15 Thread Igor Raits
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

2021-01-15 Thread Igor Raits
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)

2020-12-29 Thread Igor Raits
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

2020-12-25 Thread Igor Raits
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

2020-12-25 Thread Igor Raits
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

2020-08-30 Thread Igor Raits
-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

2020-08-30 Thread Igor Raits
-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

2020-08-29 Thread Igor Raits
-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?

2020-08-06 Thread Igor Raits
-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

2020-08-04 Thread Igor Raits
-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

2020-07-24 Thread Igor Raits
-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

2020-07-24 Thread Igor Raits
-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

2020-07-22 Thread Igor Raits
-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)

2020-07-22 Thread Igor Raits
-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)

2020-07-22 Thread Igor Raits
-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)

2020-07-22 Thread Igor Raits
-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.

2020-07-22 Thread Igor Raits
-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

2020-07-13 Thread Igor Raits
-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

2020-07-11 Thread Igor Raits
-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

2020-07-10 Thread Igor Raits
; * 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

2020-07-09 Thread Igor Raits
-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

2020-07-09 Thread Igor Raits
-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

2020-07-09 Thread Igor Raits
-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

2020-07-08 Thread Igor Raits
-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

2020-07-08 Thread Igor Raits
-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

2020-07-08 Thread Igor Raits
-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

2020-07-08 Thread Igor Raits
-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

2020-07-03 Thread Igor Raits
-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 ?

2020-07-02 Thread Igor Raits
-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

2020-07-02 Thread Igor Raits
-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

2020-07-02 Thread Igor Raits
-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

2020-07-02 Thread Igor Raits
-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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Igor Raits
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

2020-06-30 Thread Igor Raits
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

2020-06-30 Thread Igor Raits
-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.

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Igor Raits
-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

2020-06-30 Thread Igor Raits
-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

2020-06-29 Thread Igor Raits
-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

2020-06-29 Thread Igor Raits
-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

2020-06-28 Thread Igor Raits
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

2020-06-27 Thread Igor Raits
-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

2020-06-27 Thread Igor Raits
-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

2020-06-27 Thread Igor Raits
-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

2020-06-26 Thread Igor Raits
-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

2020-06-26 Thread Igor Raits
-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

2020-06-25 Thread Igor Raits
-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)

2020-06-24 Thread Igor Raits
-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)

2020-06-23 Thread Igor Raits
-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

2020-06-22 Thread Igor Raits
-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

2020-06-18 Thread Igor Raits
-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

2020-06-18 Thread Igor Raits
-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?

2020-06-17 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-16 Thread Igor Raits
-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

2020-06-15 Thread Igor Raits
-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

2020-06-15 Thread Igor Raits
-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

2020-06-15 Thread Igor Raits
-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

2020-06-15 Thread Igor Raits
-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

2020-06-15 Thread Igor Raits
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]

2020-06-15 Thread Igor Raits
-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]

2020-06-15 Thread Igor Raits
-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?

2020-06-13 Thread Igor Raits
-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

2020-06-12 Thread Igor Raits
-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

2020-06-08 Thread Igor Raits
-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

2020-06-06 Thread Igor Raits
-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

2020-06-06 Thread Igor Raits
-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

2020-06-06 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
 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

2020-06-05 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
-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

2020-06-05 Thread Igor Raits
-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

  1   2   >