Re: Review swaps

[Dave Dykstra]

I would really appreciate a review for 'apptainer', just a name change
from 'singularity':
https://bugzilla.redhat.com/show_bug.cgi?id=2034758

Dave


On Wed, Jan 05, 2022 at 11:47:10AM -0700, Jerry James wrote:
> On Wed, Jan 5, 2022 at 8:34 AM Artur Frenszek-Iwicki
>  wrote:
> > I've got this sad boy waiting for a review since September:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2006685 
> > pasdoc - Documentation generator for Pascal source code
> >
> > I can review some C, C++, Pascal or shell stuff in return.
> 
> Since Arthur Bols is giving me some freebies (thank you, Arthur!), I
> will do the same for you.
> -- 
> Jerry James
> http://www.jamezone.org/ 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

[Marek Polacek]

On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
> On 1/11/22 13:00, Steve Grubb wrote:
> > Hello,
> > 
> > On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/GNUToolchainF36
> >>
> >> == Summary ==
> >> Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
> >>
> >> The gcc 12 is currently under development and will be included in
> >> Fedora 36 upon release. The glibc 2.35 change will be tracked in this
> >> top-level GNU Toolchain system-wide update.
> > 
> > Reading through the GCC 12 changes, there is a significant new feature to 
> > GCC 
> > that would appear to be useful for security. There is a new:
> > 
> > -ftrivial-auto-var-init=zero
> > 
> > flag that initializes all stack variables to zero. Zero being a nice safe 
> > value that makes programs crash instead of being exploitable.
> > 
> > Are there plans to enable this flag so that all applications, but more 
> > importantly the kernel, are hardened against uninitialized stack variables? 
> > This is one of the major classes of security bugs that could potentially be 
> > eliminated during this mass rebuild.
> 
> There are currently no plans that I am aware of that involve turning on
> '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub
> and Marek to comment.

Also not aware of any plans to always enable it.
 
> It is something that should be discussed, turned on in Rawhide first,
> and likely via redhat-rpm-config default flags first, and then we should
> fix any fallout.
> 
> I'd only be comfortable if we did it early and worked through the 
> consequences.
> So it could be something to discuss for F37.

Right.  It reminds me of MALLOC_PERTURB_, but for automatic variables.

Obviously it's always important to measure its slowdown (maybe run a SPEC
benchmark) / compile time / stack usage.  Some of it has been done:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
but that was an early version of the patch.  Still, it seems like it'd be
acceptable.

It's a new feature, only present in GCC 12 (which hasn't been released as of
now), so I think it needs more testing before it could be (considered to be)
enabled by default.

A good thing is that it doesn't suppress the -Wuninitialized warning so
you still get a chance to fix your bugs.  It also comes with an attribute
to keep variables uninitialized even when the options is turned on.

From what I've seen its the kernel that would most benefit from the option,
and it looks like it already has support for it:

CONFIG_INIT_STACK_ALL_ZERO
CONFIG_INIT_STACK_ALL_PATTERN

so maybe it's enough to enable it for the kernel.  Or start there, see how
it does, then add it to our hardening flags.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Test-Announce] [Test Week] Fedora Linux Kernel 5.16 2022-01-23 through 2022-01-29

[Chris Murphy]

On Thu, Jan 20, 2022, 3:54 AM Artem Tim  wrote:

> Asking here due:
> Your message to the test mailing-list was rejected for the following
> reasons: The message is not from a list member.
>
> 5.16 will contain full preemption enabled?


It will still be voluntary by default, but 5.16 can have it changed with a
boot parameter, preempt=full

/proc or /sys should have a way to change it during run time, but might not
be available if UEFI Secure Boot is enabled.


Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Koji issue: tagBuild tasks failing - don't panic too much

[Adam Williamson]

Hi folks! So, you may have noticed that some package builds in Koji
recently are being reported as failed because the `tagBuild` task -
which happens at the end of a successful build - "failed". The error
reported is that the build was already tagged. This shouldn't be
happening - the builds definitely weren't tagged before the task ran.

We've been looking into it this morning and have filed an issue on Koji
for the devs to look into:
https://pagure.io/koji/issue/3220

So hopefully we'll be able to resolve it reasonably soon.

For package builds, this is ultimately only a cosmetic error. The tag
operation does actually work. The package build has effectively
completed successfully - the build was tagged and will be in future
composes. The task shows as failed in Koji, but you can ignore this.

For composes this is a bigger problem, as we're getting this error on
image builds (yes, these get tagged, no, I didn't know either!) and it
causes composes to fail if a blocking image hits this bug. We'll be re-
running composes that fail on this bug until it can be resolved.

Sorry for the trouble!
-- 
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

Re: kTLS related failures on rawhide in OpenSSL 3.0.1

[Richard W.M. Jones]

On Thu, Jan 20, 2022 at 07:33:49PM +0100, Dmitry Belyavskiy wrote:
> 
> 
> On Thu, Jan 20, 2022 at 6:49 PM Richard W.M. Jones  wrote:
> 
> On Wed, Jan 19, 2022 at 01:30:54PM +0100, Dmitry Belyavskiy wrote:
> > On Wed, Jan 19, 2022 at 1:24 PM Sahana Prasad  wrote:
> >
> >     Hello everyone,
> >
> >     Could anyone kindly help with investigating the kTLS related
> >     failures in [1] They could be infrastructure related issues, the
> >     right kernel versions that support kTLS.
> >
> >     [1] https://src.fedoraproject.org/rpms/openssl/pull-request/19
> >
> > The error is specific to armv7hl architecture. Could somebody please
> > assist us with investigation of this problem?
> 
> I could reproduce the patch locally by building openssl +
> the patch in the link on
> Linux armv7 5.11.12-300.fc34.armv7hl+lpae #1 SMP Wed Apr 7 16:13:08 UTC
> 2021 armv7l armv7l armv7l GNU/Linux
> 
> There's no extra output from dmesg (which I assume one would see if
> kTLS was failing?).  Is there anything in particular you want to know?
> 
> Could you please execute `sudo modprobe tls` and re-run the test?

I get similar errors, eg:

===(1946;465  3/5   9/12   2/11  0/2   47/434 )=
# INFO:  @ test/helpers/ssltestlib.c:1004
# No progress made
# ERROR: (bool) 'create_ssl_connection(serverssl, clientssl, 
SSL_ERROR_NONE) == true' failed @ test/sslapitest.c:1197
# false
# 20C0F4B6:error:0A000197:SSL routines:SSL_shutdown:shutdown while in 
init:ssl/ssl_lib.c:2244:
# OPENSSL_TEST_RAND_ORDER=1642715404
not ok 2 - iteration 2
===(1962;468  4/5  12/12   2/11  0/2   59/434 )=
80-test_cms.t .. ok 
===(2020;478  4/5   2/11  0/2  117/434 )
# INFO:  @ test/helpers/ssltestlib.c:1004
# No progress made
# ERROR: (bool) 'create_ssl_connection(serverssl, clientssl, 
SSL_ERROR_NONE) == true' failed @ test/sslapitest.c:1197
# false
# 20C0F4B6:error:0A000197:SSL routines:SSL_shutdown:shutdown while in 
init:ssl/ssl_lib.c:2244:
# 20C0F4B6:error:0A000197:SSL routines:SSL_shutdown:shutdown while in 
init:ssl/ssl_lib.c:2244:
# OPENSSL_TEST_RAND_ORDER=1642715404
not ok 3 - iteration 3
# --
# INFO:  @ test/helpers/ssltestlib.c:1004
# No progress made
# ERROR: (bool) 'create_ssl_connection(serverssl, clientssl, 
SSL_ERROR_NONE) == true' failed @ test/sslapitest.c:1197
# false
# 20C0F4B6:error:0A000197:SSL routines:SSL_shutdown:shutdown while in 
init:ssl/ssl_lib.c:2244:
# 20C0F4B6:error:0A000197:SSL routines:SSL_shutdown:shutdown while in 
init:ssl/ssl_lib.c:2244:
# OPENSSL_TEST_RAND_ORDER=1642715404
not ok 4 - iteration 4

(and much more)

There's still nothing in dmesg.  Is there a way to look at more detail?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Retired: system-config-repo

[Alec Leamas]

Dear list,

I have retired system-config-repo.

This is something I should have done long ago. I did the upstream as a 
basically failed experiment, and I doubt anyone will miss it. When it 
now failed to build I finally got my finger out.


--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

golang failures in the F36 mass rebuild

[Tom Stellard]

Hi,

If you maintain a golang package and you are seeing it fail with the error:

`flag provided but not defined: -Wl,-z,relro`

This failure was caused by 
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/166

It looks like it is affecting almost every golang package at the moment.  I'm 
talking with
the golang SIG about how to fix this.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Stewart Smith

[David Kirwan]

Welcome Stewart!

On Thu, 20 Jan 2022 at 18:50, Stewart Smith via devel <
devel@lists.fedoraproject.org> wrote:

> Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
> Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
> also Fedora.
>
> I have a (decently) long time Linux history, remembering Slackware 3.5
> on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
> (yay PowerPC). I’ve spent the vast bulk of my carreer around the free
> software ecosystem, having spent a long time in the MySQL community, and
> more recently OpenPOWER, and now working on Amazon Linux.
>
> I have a few areas of interest that I’d personally love to contribute
> around and see progress in the Fedora ecosystem. The idea of atomic
> updates and rollback with systems like rpm-ostree is quite fascinating
> from an operational point of view (my personal desktop is currently
> running Silverblue), and likely fits really well with the versioned (and
> version locked) repositories we’re doing with Amazon Linux 2022 and
> beyond. I also think there’s a lot of interesting supply chain assurance
> we can do to ensure continual and increased confidence in the open source
> ecosystem and way of development. Then there’s things like performance,
> boot times (including time-to-first-useful-work), image based
> deployments (who needs an installer when you can have cloud-init or
> similar to init things). So, that's a few areas of interest :)
>
> With my AWS hat on, I’m pretty excited to see what we do over the coming
> years with Fedora and Amazon Linux, and growing the number of people who
> have working on Fedora as part of their day job (and yes, we're hiring).
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
David Kirwan
Software Engineer

Community Platform Engineering @ Red Hat

T: +(353) 86-8624108 IM: @dkirwan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Ali Yousefi Sabzevar

[David Kirwan]

Welcome Ali!

On Wed, 19 Jan 2022 at 23:11, Ali Yousefi Sabzevar 
wrote:

> Dear fellows,
>
> This is Ali. Long time Open Source user since FC4 (Fedora Core 4), but
> also worked with main debian based distros too.
>
> I work specially with Fedora, CentOS/RHEL and Ansible.
>
> It's been a few days since I found v (vlang) very interesting.
>
> I found out that the rpm package is not available on fedora repo. I
> thought it's a good time to contribute by building the RPM package of a
> promising programming language.
>
> Any constructive suggestion is highly appreciated.
>
> Regards,
> Ali Yousefi Sabzevar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
David Kirwan
Software Engineer

Community Platform Engineering @ Red Hat

T: +(353) 86-8624108 IM: @dkirwan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Stewart Smith

[Peter Lemenkov]

Hello Stewart! Welcome. Hope you will like it.

чт, 20 янв. 2022 г. в 19:50, Stewart Smith via devel
:
>
> Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
> Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
> also Fedora.
>
> I have a (decently) long time Linux history, remembering Slackware 3.5
> on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
> (yay PowerPC). I’ve spent the vast bulk of my carreer around the free
> software ecosystem, having spent a long time in the MySQL community, and
> more recently OpenPOWER, and now working on Amazon Linux.
>
> I have a few areas of interest that I’d personally love to contribute
> around and see progress in the Fedora ecosystem. The idea of atomic
> updates and rollback with systems like rpm-ostree is quite fascinating
> from an operational point of view (my personal desktop is currently
> running Silverblue), and likely fits really well with the versioned (and
> version locked) repositories we’re doing with Amazon Linux 2022 and
> beyond. I also think there’s a lot of interesting supply chain assurance
> we can do to ensure continual and increased confidence in the open source
> ecosystem and way of development. Then there’s things like performance,
> boot times (including time-to-first-useful-work), image based
> deployments (who needs an installer when you can have cloud-init or
> similar to init things). So, that's a few areas of interest :)
>
> With my AWS hat on, I’m pretty excited to see what we do over the coming
> years with Fedora and Amazon Linux, and growing the number of people who
> have working on Fedora as part of their day job (and yes, we're hiring).
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Self Introduction: Stewart Smith

[Stewart Smith via devel]

Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
also Fedora.

I have a (decently) long time Linux history, remembering Slackware 3.5
on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
(yay PowerPC). I’ve spent the vast bulk of my carreer around the free
software ecosystem, having spent a long time in the MySQL community, and
more recently OpenPOWER, and now working on Amazon Linux.

I have a few areas of interest that I’d personally love to contribute
around and see progress in the Fedora ecosystem. The idea of atomic
updates and rollback with systems like rpm-ostree is quite fascinating
from an operational point of view (my personal desktop is currently
running Silverblue), and likely fits really well with the versioned (and
version locked) repositories we’re doing with Amazon Linux 2022 and
beyond. I also think there’s a lot of interesting supply chain assurance
we can do to ensure continual and increased confidence in the open source
ecosystem and way of development. Then there’s things like performance,
boot times (including time-to-first-useful-work), image based
deployments (who needs an installer when you can have cloud-init or
similar to init things). So, that's a few areas of interest :)

With my AWS hat on, I’m pretty excited to see what we do over the coming
years with Fedora and Amazon Linux, and growing the number of people who
have working on Fedora as part of their day job (and yes, we're hiring).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Neal Gompa]

On Thu, Jan 20, 2022 at 8:14 AM Demi Marie Obenour
 wrote:
>
> On 1/20/22 01:13, Panu Matilainen wrote:
> > On 1/20/22 06:16, Chris Murphy wrote:
> >>> Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a
> >>> new system, with new IDs, a renumbered interface table, and loss of
> >>> SNMPv3 users.
> >>
> >> You're not going to wipe /var to do a reset casually - the idea would
> >> be, this hardware isn't coming back to this environment. An easy
> >> option with snapshots is you can define your own rollback point, which
> >> includes environment specific configuration rather than the "wipe /var
> >> and /etc" method of factory reset.
> >
> > Who exactly is the alleged user of the "factory reset" feature?
> >
> > Nobody in their right mind should think, or be lead to think, that 'rm
> > -rf /some /dirs' is sufficient to wipe your possibly confidential data
> > to a degree that you can just ship the hardware away.
> >
> >   - Panu -
>
> Agreed.  “Factory reset” means either “I trust the secure erase function
> on all of my disks” or “all the data that has ever hit the disk was
> encrypted and I just securely deleted the encryption key”.

"Factory reset" means "reset to initial setup state". You're talking
about "secure erase", which is very different and leaves the system
unusable.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: kTLS related failures on rawhide in OpenSSL 3.0.1

[Dmitry Belyavskiy]

On Thu, Jan 20, 2022 at 6:49 PM Richard W.M. Jones 
wrote:

> On Wed, Jan 19, 2022 at 01:30:54PM +0100, Dmitry Belyavskiy wrote:
> > On Wed, Jan 19, 2022 at 1:24 PM Sahana Prasad  wrote:
> >
> > Hello everyone,
> >
> > Could anyone kindly help with investigating the kTLS related
> > failures in [1] They could be infrastructure related issues, the
> > right kernel versions that support kTLS.
> >
> > [1] https://src.fedoraproject.org/rpms/openssl/pull-request/19
> >
> > The error is specific to armv7hl architecture. Could somebody please
> > assist us with investigation of this problem?
>
> I could reproduce the patch locally by building openssl +
> the patch in the link on
> Linux armv7 5.11.12-300.fc34.armv7hl+lpae #1 SMP Wed Apr 7 16:13:08 UTC
> 2021 armv7l armv7l armv7l GNU/Linux
>
> There's no extra output from dmesg (which I assume one would see if
> kTLS was failing?).  Is there anything in particular you want to know?
>

Could you please execute `sudo modprobe tls` and re-run the test?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Chris Murphy]

On Wed, Jan 19, 2022 at 11:14 PM Panu Matilainen  wrote:
>
> On 1/20/22 06:16, Chris Murphy wrote:
> >> Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a
> >> new system, with new IDs, a renumbered interface table, and loss of
> >> SNMPv3 users.
> >
> > You're not going to wipe /var to do a reset casually - the idea would
> > be, this hardware isn't coming back to this environment. An easy
> > option with snapshots is you can define your own rollback point, which
> > includes environment specific configuration rather than the "wipe /var
> > and /etc" method of factory reset.
>
> Who exactly is the alleged user of the "factory reset" feature?
>
> Nobody in their right mind should think, or be lead to think, that 'rm
> -rf /some /dirs' is sufficient to wipe your possibly confidential data
> to a degree that you can just ship the hardware away.

The thread is about an Authselect change. I think interesting but
unrelated discussions should go in a dedicated thread.

Resetting a computer's OS to default settings is not the same thing as
media sanitization. One is strictly about reverting to default
configuration. The other is about removing latent data from the media.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: kTLS related failures on rawhide in OpenSSL 3.0.1

[Richard W.M. Jones]

On Wed, Jan 19, 2022 at 01:30:54PM +0100, Dmitry Belyavskiy wrote:
> On Wed, Jan 19, 2022 at 1:24 PM Sahana Prasad  wrote:
> 
> Hello everyone,
>
> Could anyone kindly help with investigating the kTLS related
> failures in [1] They could be infrastructure related issues, the
> right kernel versions that support kTLS.
>
> [1] https://src.fedoraproject.org/rpms/openssl/pull-request/19
>
> The error is specific to armv7hl architecture. Could somebody please
> assist us with investigation of this problem?

I could reproduce the patch locally by building openssl +
the patch in the link on
Linux armv7 5.11.12-300.fc34.armv7hl+lpae #1 SMP Wed Apr 7 16:13:08 UTC 2021 
armv7l armv7l armv7l GNU/Linux

There's no extra output from dmesg (which I assume one would see if
kTLS was failing?).  Is there anything in particular you want to know?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fwd: Self Introduction: Ali Yousefi Sabzevar

[Ali Yousefi Sabzevar]

Hello, everyone,

Yesterday, I introduced myself and created a review request on Red Hat
bugzilla for a new rpm package (v programming language).

Can someone take a look and help me further?

https://bugzilla.redhat.com/show_bug.cgi?id=2042701

Regards,
Ali

-- Forwarded message -
From: Ali Yousefi Sabzevar 
Date: Thu, Jan 20, 2022 at 12:10 AM
Subject: Self Introduction: Ali Yousefi Sabzevar
To: 


Dear fellows,

This is Ali. Long time Open Source user since FC4 (Fedora Core 4), but also
worked with main debian based distros too.

I work specially with Fedora, CentOS/RHEL and Ansible.

It's been a few days since I found v (vlang) very interesting.

I found out that the rpm package is not available on fedora repo. I thought
it's a good time to contribute by building the RPM package of a promising
programming language.

Any constructive suggestion is highly appreciated.

Regards,
Ali Yousefi Sabzevar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

F36 Change: Cockpit File Sharing (Late Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/cockpit-file-sharing-2-4-1-5


== Summary ==
A cockpit module to make file sharing with Samba and NFS easier.


== Owner ==
* Name: [[User:PBoy| Peter Boy]], [[User:sgallagh| Stephen
Gallagher]], [[User:salimma| Michel Salim]] on behalf of Fedora Server
WG
* Email: 

== Detailed Description ==
Provides an improved graphical web-based interface for provisioning
and ongoing administration of NFS and Samba shares. It thus
complements the standard Fedora Server command line interface.


== Benefit to Fedora ==
Significantly improves usability for Fedora Server Edition
administrators when deploying and maintaining NFS and Samba shares.

It thus makes Fedora Server Edition more attractive for use as a file
server, especially for new users without extensive experience with
Fedora.

It thus helps to expand our user base.

== Scope ==
* Proposal owners: The package has already landed in the F36 repo now
(and is available in
updates-testing for stable Fedora, EPEL 8 and EPEL 9). No further
action required

* Other developers:
* Release engineering: none
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:


== Upgrade/compatibility impact ==
N/A

== How To Test ==
* Install Fedora Server Edition on supported hardware (no special
requirements but network connectivity)
* Prepare a Linux Client Workstation ready to mount NFS share
* Prepare a Windows or MacOS client ready to mount a Windows share
* On Workstation connect to server Cockpit and follow the Web
interface guidance to create a NFS share and a Samba share
* Use Linux and Windows desktop accordingly to connect to the server
using the  respective standard procedures

== User Experience ==
The interface serves as a guide for carrying out the required steps
and independently performs necessary follow-up actions based on the
user declarations. New users or users with little routine are provided
with simple and error-free server administration, while experienced
administrators are spared a lot of typing work.
The user interface provides guidance to

== Dependencies ==
none



== Contingency Plan ==

* Contingency mechanism:  N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)


== Documentation ==
N/A (online guidance)



-- 
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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Thu, Jan 20, 2022 at 02:31:52PM +, Richard W.M. Jones wrote:
> On Thu, Jan 20, 2022 at 02:30:24PM +, Richard W.M. Jones wrote:
> > 
> > The qemu bug led to this optimizer mis-compilation bug which seems
> > very serious:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
> > 
> > I'm not sure I would try GCC 12 generated code until this gets fixed.
> 
> s/try/trust/

It is a serious bug, but the likelyhood that it triggers on other packages
is low.  We don't mass rebuild again any time we fix some wrong-code issue
in gcc, that would be many times a year, only if we know it affects
significant amounts of packages.  And even in those cases it can be a
targetted test mass rebuild with instrumented compiler to warn us that it
triggers that bug and from that determine what needs to be rebuilt (we've
done it several times in the past).

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

On Thu, Jan 20, 2022 at 02:30:24PM +, Richard W.M. Jones wrote:
> 
> The qemu bug led to this optimizer mis-compilation bug which seems
> very serious:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
> 
> I'm not sure I would try GCC 12 generated code until this gets fixed.

s/try/trust/

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: gcc-12.0.0-0.4.fc36 in rawhide

[Richard W.M. Jones]

The qemu bug led to this optimizer mis-compilation bug which seems
very serious:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721

I'm not sure I would try GCC 12 generated code until this gets fixed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Wayland by Default for SDDM (Self-Contained Change proposal)

[Neal Gompa]

On Thu, Jan 20, 2022 at 2:11 AM Miroslav Suchý  wrote:
>
> Dne 18. 01. 22 v 15:28 Ben Cotton napsal(a):
> > ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> > mutually exclusive sddm-wayland-generic and
> > sddm-x11 greeter configuration packages.
> > ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> > *** Enable installation of the SDDM Wayland configuration snippet and
> > ship as sddm-wayland-plasma that is mutually exclusive
> > with the other sddm greeter configuration packages. This package will
> > supplement {{package|sddm}} and plasma-workspace-wayland
> > to be automatically installed together.
>
> When we switch SDDM to Wayland, will it be still possible from the SDDM to 
> choose whether I want to log in to X11 or
> Wayland? Or Wayland in SDDM enforce Wayland in the Plasma session?
>

You will still be able to choose to start X11 desktop sessions from
SDDM. This just changes SDDM *itself* to use Wayland.

Note that KDE Plasma already defaults to Wayland, so you will need to
explicitly choose the X11 session.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Vít Ondruch]

Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not 
static, generated at build time, not having anything in /etc unless 
somebody really wants to change something.


The files are not static at all, they are change with different kinds 
of authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature



As I said, the above is not my case and I'd say not case for most of 
Fedora users.




- apply changes when package is updated: authselect apply-changes



Why is this needed? In which packages? Why simply not apply the changes 
regardless of the previous state?



- apply changes when you modify your custom profile: authselect 
apply-changes



This is again belongs to the initial group.




They remembers how the current configuration looks like so we can 
check if user modified nsswitch and PAM configuration on their own or 
not.



"user modified nsswitch and PAM configuration" is not thing I do. The 
only time I needed to touch nsswitch configuration was always because 
the configuration was screwed up by some updates, not by me.



IOW, from users perspective, the configuration is static. If 
installation/updates changes the configuration, then it is again static 
from user perspective. So I still don't see the need to have the 
configuration files around by default.


Also, I think this proposal is focusing on wrong aspect, i.e. moving 
files around from one location to another. It would be much better to 
remove their need.



Vít




OpenPGP_signature
Description: OpenPGP digital 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2022-01-20 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2022-01-20 17:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2022-01-20 09:00 PST  US/Pacific
2022-01-20 12:00 EST  --> US/Eastern <--
2022-01-20 17:00 GMT  Europe/London 
2022-01-20 17:00 UTC  UTC   
2022-01-20 18:00 CET  Europe/Berlin 
2022-01-20 18:00 CET  Europe/Paris  
2022-01-20 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2022-01-21 01:00 HKT  Asia/Hong_Kong
2022-01-21 01:00 +08  Asia/Singapore
2022-01-21 02:00 JST  Asia/Tokyo
2022-01-21 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

#topic #1132 Mark comments as scriplets for Sources (automation) 
.fpc 1132
https://pagure.io/packaging-committee/issue/1132

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-1046 Improve separate test suite sourcing instructions 
https://pagure.io/packaging-committee/pull-request/1046

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not static, 
generated at build time, not having anything in /etc unless somebody 
really wants to change something.


The files are not static at all, they are change with different kinds of 
authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
- apply changes when package is updated: authselect apply-changes
- apply changes when you modify your custom profile: authselect 
apply-changes


They remembers how the current configuration looks like so we can check 
if user modified nsswitch and PAM configuration on their own or not.





Vít


Dne 18. 01. 22 v 18:32 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc


== Summary ==

Authselect will move several files that are currently stored at
/var/lib/authselect to /etc/authselect/.state. This does not affect
configuration backup, that will be kept at
/var/lib/authselect/backups.

The files that will be moved are:
* /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
* /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
* /var/lib/authselect/fingerprint-auth 
/etc/authselect/.state/fingerprint-auth

* /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
* /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
* /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
* /var/lib/authselect/smartcard-auth 
/etc/authselect/.state/smartcard-auth

* /var/lib/authselect/system-auth /etc/authselect/.state/system-auth

== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrez...@redhat.com


== Detailed Description ==

These files are used by authselect to detect changes to the system
nsswitch and PAM configurations when the configuration is updated with
an updated profile using 'authselect apply-changes'. There are two
reasons for the move:

1. The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of
ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360
BZ#2034360]

2. Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since
/var should contain only files that can be safely removed, /etc is a
better place for them.

== Feedback ==

This change is accepted by ostree system maintainers, see
[https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].


== Benefit to Fedora ==
This makes authselect more compatible with ostree model.

== Scope ==
* Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from
/var/lib/authselect to the new location. Spec file changes only.

* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10544 #10544]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A


== Upgrade/compatibility impact ==

No impact. Files will be moved automatically during update and
everything will keep working as prior.

== How To Test ==

1. Authselect keeps working as expected after the upgrade

== User Experience ==

This change is only under the hood, it does not affect user experience.

== Dependencies ==

No dependencies.

== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* 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 ==

Authselect state files moved from /var/lib/authselect to 
/etc/authselect/.state.





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Thu, Jan 20, 2022 at 01:32:26PM +, Jonathan Wakely wrote:
> On Thu, 20 Jan 2022 at 13:05, Jonathan Wakely  wrote:
> >
> > On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
> > >
> > >
> > > I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> > > --arch-override=x86_64 builds, so I tried a full build and ran into this 
> > > on aarch64. :-(
> > >
> > > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include 
> > > -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> > > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include 
> > > -isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > > In file included from /usr/include/boost/integer.hpp:20,
> > >  from /usr/include/boost/integer/integer_mask.hpp:16,
> > >  from /usr/include/boost/random/mersenne_twister.hpp:26,
> > >  from /usr/include/boost/uuid/random_generator.hpp:17,
> > >  from /usr/include/boost/uuid/uuid_generators.hpp:17,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
> > >  from 
> > > /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
> > >  from 
> > > /builddir/build

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 13:05, Jonathan Wakely  wrote:
>
> On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
> >
> >
> > I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> > --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> > aarch64. :-(
> >
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > In file included from /usr/include/boost/integer.hpp:20,
> >  from /usr/include/boost/integer/integer_mask.hpp:16,
> >  from /usr/include/boost/random/mersenne_twister.hpp:26,
> >  from /usr/include/boost/uuid/random_generator.hpp:17,
> >  from /usr/include/boost/uuid/uuid_generators.hpp:17,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> > /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> > '

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Demi Marie Obenour]

On 1/20/22 01:13, Panu Matilainen wrote:
> On 1/20/22 06:16, Chris Murphy wrote:
>>> Deleting /var/lib/net-snmp/snmpd.conf means making the agent look like a
>>> new system, with new IDs, a renumbered interface table, and loss of
>>> SNMPv3 users.
>>
>> You're not going to wipe /var to do a reset casually - the idea would
>> be, this hardware isn't coming back to this environment. An easy
>> option with snapshots is you can define your own rollback point, which
>> includes environment specific configuration rather than the "wipe /var
>> and /etc" method of factory reset.
> 
> Who exactly is the alleged user of the "factory reset" feature?
> 
> Nobody in their right mind should think, or be lead to think, that 'rm 
> -rf /some /dirs' is sufficient to wipe your possibly confidential data 
> to a degree that you can just ship the hardware away.
> 
>   - Panu -

Agreed.  “Factory reset” means either “I trust the secure erase function
on all of my disks” or “all the data that has ever hit the disk was
encrypted and I just securely deleted the encryption key”.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
>
>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> aarch64. :-(
>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update to boost by any chance?

No, not

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Thu, Jan 20, 2022 at 7:50 AM Kaleb Keithley  wrote:

>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch
> --arch-override=x86_64 builds, so I tried a full build and ran into this on
> aarch64. :-(
>

ppc64le and s390x as well.


>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update t

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

I thought I'd solved all my gcc-12-isms in ceph by running --scratch
--arch-override=x86_64 builds, so I tried a full build and ran into this on
aarch64. :-(

/usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION
-DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT
-D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__
-I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include
-I/builddir/build/BUILD/ceph-16.2.7/src -isystem
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include
-isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem
/builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem
/usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE
-Wall -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security
-Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor
-Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move
-Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual
-fno-new-ttp-matching -fstack-protector-strong
-fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc
-fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
/usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION
-DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT
-D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__
-I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include
-I/builddir/build/BUILD/ceph-16.2.7/src -isystem
/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include
-isystem /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem
/builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem
/usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE
-Wall -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security
-Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor
-Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move
-Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual
-fno-new-ttp-matching -fstack-protector-strong
-fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc
-fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o
src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
In file included from /usr/include/boost/integer.hpp:20,
 from /usr/include/boost/integer/integer_mask.hpp:16,
 from /usr/include/boost/random/mersenne_twister.hpp:26,
 from /usr/include/boost/uuid/random_generator.hpp:17,
 from /usr/include/boost/uuid/uuid_generators.hpp:17,
 from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
 from /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
 from /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
 from
/builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
 from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
 from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
 from
/builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
/usr/include/boost/integer_traits.hpp:83:64: error: narrowing
conversion of '255' from 'int' to 'char' [-Wnarrowing]
   83 | public detail::integer_traits_base
  |

https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773

Are we expecting an update to boost by any chance?


On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek  wrote:

> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should b

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Vít Ondruch]

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not static, 
generated at build time, not having anything in /etc unless somebody 
really wants to change something.



Vít


Dne 18. 01. 22 v 18:32 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc


== Summary ==

Authselect will move several files that are currently stored at
/var/lib/authselect to /etc/authselect/.state. This does not affect
configuration backup, that will be kept at
/var/lib/authselect/backups.

The files that will be moved are:
* /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
* /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
* /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
* /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
* /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
* /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
* /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
* /var/lib/authselect/system-auth /etc/authselect/.state/system-auth

== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrez...@redhat.com


== Detailed Description ==

These files are used by authselect to detect changes to the system
nsswitch and PAM configurations when the configuration is updated with
an updated profile using 'authselect apply-changes'. There are two
reasons for the move:

1. The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of
ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360
BZ#2034360]

2. Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since
/var should contain only files that can be safely removed, /etc is a
better place for them.

== Feedback ==

This change is accepted by ostree system maintainers, see
[https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].


== Benefit to Fedora ==
This makes authselect more compatible with ostree model.

== Scope ==
* Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from
/var/lib/authselect to the new location. Spec file changes only.

* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10544 #10544]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A


== Upgrade/compatibility impact ==

No impact. Files will be moved automatically during update and
everything will keep working as prior.

== How To Test ==

1. Authselect keeps working as expected after the upgrade

== User Experience ==

This change is only under the hood, it does not affect user experience.

== Dependencies ==

No dependencies.

== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* 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 ==

Authselect state files moved from /var/lib/authselect to /etc/authselect/.state.




OpenPGP_signature
Description: OpenPGP digital 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: hiredis soname bump

[Miro Hrončok]

On 19. 01. 22 23:02, Kevin Fenzi wrote:

Thanks for the fixes.

I went ahead and merged the side tag because the broken by gcc packages
will be broken by the mass rebuild anyhow. :(

I'll try and poke at them some more next weekend...


https://bugzilla.redhat.com/show_bug.cgi?id=2042939
https://bugzilla.redhat.com/show_bug.cgi?id=2042940
https://bugzilla.redhat.com/show_bug.cgi?id=2042941
https://bugzilla.redhat.com/show_bug.cgi?id=2042942
https://bugzilla.redhat.com/show_bug.cgi?id=2042943

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Test-Announce] [Test Week] Fedora Linux Kernel 5.16 2022-01-23 through 2022-01-29

[Artem Tim]

Asking here due:
Your message to the test mailing-list was rejected for the following reasons: 
The message is not from a list member.

5.16 will contain full preemption enabled?
https://pagure.io/fedora-workstation/issue/228#comment-767601
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Petr Pisar]

V Thu, Jan 20, 2022 at 11:26:49AM +0100, Pavel Březina napsal(a):
> On 1/19/22 12:40, Petr Pisar wrote:
> > V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):
> > > On 1/19/22 11:35, Petr Pisar wrote:
> > > > V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):
> > > > > On 1/19/22 11:04, Petr Pisar wrote:
> > > > > > V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):
> > > > > > > Since /var should contain only files that can be safely removed,
> > > > > > 
> > > > > > While I agree with your change, this statement is false. /var is 
> > > > > > for any files
> > > > > > which are variable. Files which can be safely removed belong to 
> > > > > > /var/tmp and
> > > > > > /var/cache.
> > > > > 
> > > > > Though when removed, the application should remain functional and just
> > > > > recreate it automatically, right?
> > > > > 
> > > > Yes.
> > > > 
> > > > > Authselect would require user intervention.
> > > > > 
> > > > Yes.
> > > 
> > > Ok, how about phrasing it:
> > > 
> > > Removing these files would reduce authselect functionality, user would 
> > > need
> > > to run 'authselect select --force' to restore it. This however conflicts
> > > with purpose of /var which should contain only data that do not affect
> > > functionality when removed.
> > > 
> > That's better, but still not right. /var is not about "functionality when
> > removed". /var is simply about files which can change (as an opposite to
> > a change when installing a software). (Compare to
> > . E.g. 
> > if
> > you delete /var/spool/mail, then a lot of people will say that a 
> > functionallity
> > of their mailboxes is seriously affected.)
> > 
> > I would simply remove the sentence "This however...". Because the truth is
> > that the conflict is not with the purpose of /var.
> > 
> > If you want reason why /var is not suitable, then simpy admit that /var is
> > not managed by os-tree and that thus you need a better location which /etc
> > seems to be because you are moving authconfig's configuration files.
> 
> Thank you. This statement about /var was indeed an attempt to justify the
> change outside ostree-enabled systems. But as it seems to be false and it
> created unexpected discussion I rephrased the section to:
> 
> """
> These files are used by authselect to detect changes to the system nsswitch
> and PAM configurations when the configuration is updated with an updated
> profile using 'authselect apply-changes'.
> 
> Unfortunately, the current location conflicts with ostree model where /var
> is not writable during rpm transaction and this currently blocks compose of
> ostree systems (see BZ#2034360). At the same time /usr is read-only on
> client side of ostree-enabled installations therefore the files can not be
> moved there since it would break authselect on the client side.
> 
> Storing these files under /etc/authselect will make authselect work on both
> server and client side of ostree systems.
> """
> 
Thanks.

-- Petr


signature.asc
Description: 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 17:06, Colin Walters wrote:



On Wed, Jan 19, 2022, at 10:25 AM, Neal Gompa wrote:


I agree, I think it should move to /usr/lib/sysimage/authselect instead.


That would break the use case of running it on an image based (i.e. readonly 
/usr) system *client side*.

We settled on having it in /etc in 
https://bugzilla.redhat.com/show_bug.cgi?id=2034360 because that works 
symmetrically across both.  It's also keeps the backups closer to the original 
files (e.g. they're more likely to be on the same file so reflinks could be 
used).  I think these authselect backups are really similar to e.g. 
`.rpmnew/.rpmorig` and similar.


The purpose of these files is to detect user's non-authselect 
modifications of the configuration and prevent overwriting user's 
configuration. In other words, if you choose to modify PAM or nsswitch 
on your own without authselect, then authselect will stop managing the 
files for you unless you tell it to do so again.


The problem with ostree is that /var is read-only on server side and 
/usr is read-only on client side so neither can store these data. /etc 
is writable on both sides.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 12:40, Petr Pisar wrote:

V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):

On 1/19/22 11:35, Petr Pisar wrote:

V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):

On 1/19/22 11:04, Petr Pisar wrote:

V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):

Since /var should contain only files that can be safely removed,


While I agree with your change, this statement is false. /var is for any files
which are variable. Files which can be safely removed belong to /var/tmp and
/var/cache.


Though when removed, the application should remain functional and just
recreate it automatically, right?


Yes.


Authselect would require user intervention.


Yes.


Ok, how about phrasing it:

Removing these files would reduce authselect functionality, user would need
to run 'authselect select --force' to restore it. This however conflicts
with purpose of /var which should contain only data that do not affect
functionality when removed.


That's better, but still not right. /var is not about "functionality when
removed". /var is simply about files which can change (as an opposite to
a change when installing a software). (Compare to
. E.g. if
you delete /var/spool/mail, then a lot of people will say that a functionallity
of their mailboxes is seriously affected.)

I would simply remove the sentence "This however...". Because the truth is
that the conflict is not with the purpose of /var.

If you want reason why /var is not suitable, then simpy admit that /var is
not managed by os-tree and that thus you need a better location which /etc
seems to be because you are moving authconfig's configuration files.


Thank you. This statement about /var was indeed an attempt to justify 
the change outside ostree-enabled systems. But as it seems to be false 
and it created unexpected discussion I rephrased the section to:


"""
These files are used by authselect to detect changes to the system 
nsswitch and PAM configurations when the configuration is updated with 
an updated profile using 'authselect apply-changes'.


Unfortunately, the current location conflicts with ostree model where 
/var is not writable during rpm transaction and this currently blocks 
compose of ostree systems (see BZ#2034360). At the same time /usr is 
read-only on client side of ostree-enabled installations therefore the 
files can not be moved there since it would break authselect on the 
client side.


Storing these files under /etc/authselect will make authselect work on 
both server and client side of ostree systems.

"""



-- 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
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: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Ankur Sinha]

Hello,

> - vanessa_kris contacted since December 10th
> 
> vanessa_kris is main admin of rpms/python-git-changelog
> vanessa_kris has a bugzilla override on rpms/python-git-changelog
> vanessa_kris is main admin of rpms/python-glymur
> vanessa_kris has a bugzilla override on rpms/python-glymur

Vanessa had to create a new user because the `_` doesn't work for
fedorapeople.org:

https://pagure.io/fedora-infrastructure/issue/10377#comment-767776

So, they've now created vanessakris (without the `_`) and we've given
the new account admin access on all these packages, and disabled the
older account.

I guess we should've used the older account to orphan these first? I can
ask Vanessa to do that now.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220120.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220119.0):

ID: 1109331 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1109331
ID: 1109340 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1109340

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Dan Horák]

On Thu, 20 Jan 2022 09:57:06 +0100
Pierre-Yves Chibon  wrote:

> Good Morning Everyone,
> 
> The packagers listed here have been receiving a daily email asking them to
> either adjust their bugzilla or their FAS account so the email address in FAS
> matches an existing bugzilla account.
> 
> Having a bugzilla account is mandatory per:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> 
> - gtiwari contacted since January 14th
> 
> gtiwari is main admin of rpms/bluez
> gtiwari has a bugzilla override on rpms/bluez

I will reach out to Gopal.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220120.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220119.0):

ID: 1109257 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1109257
ID: 1109266 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1109266

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- anoopcs contacted since November 27th

anoopcs is maintainer of rpms/glusterfs
anoopcs is main admin of rpms/glusterfs-coreutils
anoopcs has a bugzilla override on rpms/glusterfs-coreutils
anoopcs is maintainer of rpms/richacl
anoopcs is maintainer of rpms/samba
anoopcs is watching rpms/socket_wrapper

- gtiwari contacted since January 14th

gtiwari is main admin of rpms/bluez
gtiwari has a bugzilla override on rpms/bluez

- msehnout contacted since December 15th

msehnout is watching rpms/bind
msehnout is watching rpms/bind99
msehnout is maintainer of rpms/ipcalc
msehnout is watching rpms/libpcap
msehnout is maintainer of rpms/osbuild
msehnout is maintainer of rpms/osbuild-composer
msehnout is watching rpms/pure-ftpd
msehnout is watching rpms/tcpdump
msehnout is watching rpms/vsftpd
msehnout is watching rpms/wireshark

- sebix contacted since December 4th

sebix is maintainer of rpms/lockfile-progs
sebix has a bugzilla override on rpms/lockfile-progs
sebix is maintainer of rpms/logcheck
sebix has a bugzilla override on rpms/logcheck

- vanessa_kris contacted since December 10th

vanessa_kris is main admin of rpms/python-git-changelog
vanessa_kris has a bugzilla override on rpms/python-git-changelog
vanessa_kris is main admin of rpms/python-glymur
vanessa_kris has a bugzilla override on rpms/python-glymur


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Test-Announce] [Test Week] Fedora Linux Kernel 5.16 2022-01-23 through 2022-01-29

[Sumantro Mukherjee]

Hey All,

I would like to invite all of you to participate in the Kernel 5.16
Test week is happening from 2022-01-23 to 2022-01-29. It's
fairly simple, head over to the wiki [0] and read in detail about the
test week and simply run the test case mentioned in[1] and enter your
results.

As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat
for question and discussion.

If you are someone who is just starting out, remember that we give out
badges[2] for testing new Kernel Builds!

Collect 'em now :)


P.S : Please respond/replyback to @t...@lists.fedoraproject.org in
case you have any questions!!

[0] https://fedoraproject.org/wiki/Test_Day:2022-01-23_Kernel_5.16_Test_Week
[1] https://testdays.fedoraproject.org/events/126
[2] https://badges.fedoraproject.org/badge/science-kernel-tester-i
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@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