Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)

[Miroslav Suchý]

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?


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

[Panu Matilainen]

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 -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 6:14 PM Chris Adams  wrote:
>
> Once upon a time, Chris Murphy  said:
> > > For example, snmpd stores program-generated config in /var/lib/net-snmp,
> > > which gets merged with config from /etc/snmp.
> >
> > What's the exact consequence of deleting either /etc/snmp and
> > /var/lib/net-snmp - separately and together?
>
> Delete either one and permanent config is lost.  Admin config is in
> /etc/snmp and program-generated config (sometimes based on admin config)
> /var/lib/net-snmp.

So it renders the system like a cleanly installed Fedora system. It's
not like there's additional breakage beyond simply not having access
to particular SNMP services. I don't have an /etc/snmp dir, and the
/var/lib/net-snmp dir contains a couple empty directories.


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


> And that's just one thing I know of that uses /var in such a manner.
> How many other things expect /var to be an integrated part of the OS?

Well, affore mentioned selinux issue
https://bugzilla.redhat.com/show_bug.cgi?id=1290659

But deleting /var/lib/selinux doesn't cause obvious failure - though I
might be (silently) in a security reduced situation, I can't really
tell.


> Making /usr "special" and throwing all other directories away is a bad
> plan, only sustainable for a niche subset of packages.  If snapshots are
> so important, an actual integrated plan for the WHOLE OS needs to be
> created, not just by recreating all the parts of / that someone is
> interested in under /usr.

The snapshots, rollbacks, FHS, /usr /var question is bigger than, and
is also out of scope for, this change proposal. I think it's relevant
and important, but needs to go into its own thread.


--
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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Chris Adams]

Once upon a time, Chris Murphy  said:
> > For example, snmpd stores program-generated config in /var/lib/net-snmp,
> > which gets merged with config from /etc/snmp.
> 
> What's the exact consequence of deleting either /etc/snmp and
> /var/lib/net-snmp - separately and together?

Delete either one and permanent config is lost.  Admin config is in
/etc/snmp and program-generated config (sometimes based on admin config)
/var/lib/net-snmp.

> If there's program-generated config in /var/lib/net-snmp, why can't it
> regenerate it when its missing?

The documented way to create SNMPv3 users puts the config in
/var/lib/net-snmp.  The system serial number and engine ID are randomly
generated at the first startup and saved in /var/lib/net-snmp (but are
then supposed to stay constant for the life of the system).  Persistent
network interface IDs are stored in /var/lib/net-snmp.  Those are just a
few things I know of.

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.

And that's just one thing I know of that uses /var in such a manner.
How many other things expect /var to be an integrated part of the OS?
Making /usr "special" and throwing all other directories away is a bad
plan, only sustainable for a niche subset of packages.  If snapshots are
so important, an actual integrated plan for the WHOLE OS needs to be
created, not just by recreating all the parts of / that someone is
interested in under /usr.

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

[Kevin Fenzi]

Hi all,

Per the Fedora 36 schedule[1] we have started a mass rebuild for Fedora 36
on Jan 19th, 2021. We will run a mass rebuild for Fedora 36 for the
changes listed in:

https://pagure.io/releng/issues?status=Open&tags=mass+rebuild

The mass rebuild will be done in a side tag (f36-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-failures.html


Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-need-rebuild.html


FTBFS bugs will be filed shortly after the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,

Kevin

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
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: Packaging my own software?

[Michel Alexandre Salim]

On Tue, Jan 18, 2022 at 01:29:33PM -0600, Chris Adams wrote:
> I've got a script for quickly building KVM VMs with libvirt from a
> kickstart, and I think others would find this useful.  I've put it on
> Github, including an RPM spec, and would like to see it in Fedora and
> EPEL.
> 
> Is it okay for me to package my own software, or should I try to recruit
> someone else?  Packaging my own software makes it feel like I'm abusing
> Fedora's infrastructure and mirror servers around the world, just to
> make it easier for me to install my own script and dependencies. :)

You still need a reviewer to approve it initially anyway, so I don't see
why not :)

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: gcc-12.0.0-0.4.fc36 in rawhide

[Michel Alexandre Salim]

On Wed, Jan 19, 2022 at 04:09:09PM -0700, Jerry James wrote:
> On Wed, Jan 19, 2022 at 3:56 PM Michel Alexandre Salim
>  wrote:
> > Rebuilding folly, and building the latest tagged release, both fail with
> > GCC 12:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2042690
> >
> > It happens that libfmt has also been upgraded, so it's hard to pinpoint.
> > I'm going to see if I can tag a scratch build of the newer fmt on a F35
> > sidetag so we can rule that out.
> 
> I don't know if GCC 12 has anything to do with poppler/texlive
> breakage in Rawhide, but mentioning it here just in case:
> https://bugzilla.redhat.com/show_bug.cgi?id=2042421.  The fact that
> GDB is broken in Rawhide
> (https://bugzilla.redhat.com/show_bug.cgi?id=2042664) is making
> investigation difficult.

This seems unrelated, alebastr pointed out that the folly issue (on
ppc64le only) is likely due to the floating point ABI change Jakub
announced in the initial message.

It's likely fmt will needs to be rebuilt, but I'm hesitant to just try
bumping and pray unless I can try that in a side tag. Going to try that
next.

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Self Introduction: Ali Yousefi Sabzevar

[Ali Yousefi Sabzevar]

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jerry James]

On Wed, Jan 19, 2022 at 3:56 PM Michel Alexandre Salim
 wrote:
> Rebuilding folly, and building the latest tagged release, both fail with
> GCC 12:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2042690
>
> It happens that libfmt has also been upgraded, so it's hard to pinpoint.
> I'm going to see if I can tag a scratch build of the newer fmt on a F35
> sidetag so we can rule that out.

I don't know if GCC 12 has anything to do with poppler/texlive
breakage in Rawhide, but mentioning it here just in case:
https://bugzilla.redhat.com/show_bug.cgi?id=2042421.  The fact that
GDB is broken in Rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=2042664) is making
investigation difficult.
-- 
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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Michel Alexandre Salim]

On Sat, Jan 15, 2022 at 09:30:25PM -0800, Michel Alexandre Salim wrote:
> Hi Jakub,
> 
> On Fri, Jan 14, 2022 at 03:31:43PM +0100, 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 be
> > just those bugfixes and not new features etc. anymore.
> > https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> > most important is probably that vectorization is enabled at -O2 now
> > which is the option with most of the distribution is built with.
> > 
> > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> > some cases where people need to adjust their code.  Other things
> > include the usual C++ header changes, where previously some standard
> > header included some other header as an implementation detail but it doesn't
> > any longer and so code that relied on such indirect include that isn't
> > required by the standard needs to include the header that provides whatever
> > it relies on.  Or e.g. packages using -Werror where new warnings are
> > reported with the newer compiler and -Werror results in build failures.
> 
> Can this be documented soon?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032
> 
> It hit nextcloud-client:
> https://bugzilla.redhat.com/show_bug.cgi?id=2041135 which compiles fine
> with GCC 11 for F34 and F35.
> 
> > 
> > If there are bugs on the compiler side, please let me know immediately,
> > so that those bugs can be fixed before the mass rebuild next week.
> > 
> I'm going to exercise this with the new Folly stack on Monday once the
> weekly tags are created. Will try and report ASAP.
>
Rebuilding folly, and building the latest tagged release, both fail with
GCC 12:

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

It happens that libfmt has also been upgraded, so it's hard to pinpoint.
I'm going to see if I can tag a scratch build of the newer fmt on a F35
sidetag so we can rule that out.

Regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Unresponsive maintainer for python-flask-whooshee

[Jakub Kadlčík]

Hello

This is more of an FYI, and me doing this for the first time, and trying
to follow the instructions closely, rather than looking for a way to
contact the unresponsive maintainer.

BZ ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=2042681

We already talked with rkuska privately before starting the unresponsive
maintainer process, and he is still here, active, but he isn't able to
log in into his FAS account and maintain the package. We figured, this
may be a good way to transfer the maintenance permissions to Copr team.

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: hiredis soname bump

[Kevin Fenzi]

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

kevin


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: Workflow and other problems with the Fedora container infrastructure

[Josh Boyer]

On Tue, Jan 18, 2022 at 8:40 AM Pierre-Yves Chibon  wrote:
>
> On Sun, Jan 16, 2022 at 08:42:30AM -0500, Josh Boyer wrote:
> >On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi <[1]ke...@scrye.com> wrote:
> >
> >  On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> >  >
> >  > One of the things that has recently happened in the Koji space is the
> >  > addition of a kiwi-build task to build images using the KIWI tool[1].
> >  >
> >  > KIWI supports building all kinds of operating system images, 
> > including
> >  > OCI containers. The Fedora Cloud WG is poking at the idea of using
> >  > KIWI for the cloud image to replace the unmaintained and brittle
> >  > ImageFactory, and we could also look at doing container builds with
> >  > KIWI to replace the OpenShift Atomic Reactor system. That would
> >  > drastically simplify the architecture and make container image builds
> >  > considerably more reasonable for the Container SIG and any other
> >  > stakeholders.
> >
> >  Yeah, thats quite interesting. I would be happy to move to a pipeline
> >  thats less fragile here. :)
> >
> >  There's also talk about moving things to use ImageBuilder, but I don't
> >  think it does containers.
> >
> >We can, and should, have RFEs for Image Builder to do containers.  I know
> >we need this internally as well.  It may farm that out to buildah in the
> >background or something, but that remains to be determined.
> >In the interest of commonality across the Fedora/CentOS/RHEL ecosystem, I
> >really think using Image Builder as the tool to build images is the best
> >approach.
>
> The underlying tool, osbuild, can already build container. They can be made
> available as tarball which one can just `podman import` afterward :)

Yes.  Why make people do that instead of just publishing an OCI
compliant image?  I know why, but that's the RFE :)

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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:48 AM Chris Adams  wrote:
>
> This push to destroy /var really needs to be stopped, or at least
> handled as a whole and not on a piecemeal basis.  There are many
> packages that store data and config in /var that is NOT to be deleted at
> will.  The big thing is databases, but there are lots of little things.

No one is envisioning non-obvious or automatic factory resets as a
matter of course.

Firefox keeps a bunch of databases ~/.mozilla/firefox. Were it true
that deleting any of these databases resulted in Firefox crashing, or
otherwise being non-functional, that would be a bug. It is also true
that deleting these databases, or the entire user profile, constitutes
data loss. That it is data loss doesn't absolve an application from
misbehaving, rather than reverting to a default but functional state.


> For example, snmpd stores program-generated config in /var/lib/net-snmp,
> which gets merged with config from /etc/snmp.

What's the exact consequence of deleting either /etc/snmp and
/var/lib/net-snmp - separately and together?

If there's program-generated config in /var/lib/net-snmp, why can't it
regenerate it when its missing?



-- 
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: Firefox Hardware acceleration & VA-API how-to

[Christian Stadelmann]

Thank you, Martin!

I've just updated the wiki page to remove the rdd stuff which should no longer 
be necessary with Firefox 96.

Thanks to the wiki page, one can check whether hardware acceleration is 
available.

Is there any indication (e.g. in about:support) to see whether video hardware 
acceleration is working? Or any tool to check?

Is hardware acceleration a prerequisite for using VA-API accelerated video 
decoding? (Background: my GPU is too old to get hardware acceleration support 
in firefox, but I do have VA-API with some video decoding support in hardware).

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

This push to destroy /var really needs to be stopped, or at least
handled as a whole and not on a piecemeal basis.  There are many
packages that store data and config in /var that is NOT to be deleted at
will.  The big thing is databases, but there are lots of little things.
For example, snmpd stores program-generated config in /var/lib/net-snmp,
which gets merged with config from /etc/snmp.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)

[Chris Murphy]

On Wed, Jan 19, 2022 at 6:08 AM Colin Walters  wrote:
>
>
>
> On Wed, Jan 19, 2022, at 6:38 AM, Neal Gompa wrote:
> > On Wed, Jan 19, 2022 at 6:05 AM Casey Jao via devel
> >  wrote:
> >>
> >> Doesn't rpm-ostree already provide transactional, image-based updates 
> >> without the use of filesystem snapshots? In addition, roofs snapshots are 
> >> only really useful if they are coordinated with bootloader management, 
> >> which is already built into rpm-ostree but not yet written for a 
> >> hypothetical btrfs-based atomic os updater.
> >
> > I think the bigger value would be around being able to use filesystem
> > snapshots with /var.
>
> Right.  In the ostree model the idea is all user data (except config files in 
> /etc) are in /var.  So if you want to back up all machine-local state 
> (including your home directories, container storage, libvirt VMs, etc.), you 
> just need one filesystem to save.
>
> It could make sense to save a snapshot of /var before performing major OS 
> upgrades.  But they're not strictly related.  (As an aside: personally, I 
> think snapshots have mostly just obscure use cases versus backup systems)
>
> I would agree with Casey though in that the opposite case of trying to 
> snapshot /usr (and then boot it) outside of ostree's control is likely to 
> confuse ostree at best at least today.


Yep. I've made an adjustment to emphasize the benefit of backing up
"var" rather than rolling back "root" - because while that can work,
it requires specialized knowledge to get the bootloader to do the
right thing. And as it's possible /boot contains only new
vmlinuz+initramfs compared to a potentially much older "root"
snapshot.

The rpm-ostree model could dispense with the "home" subvolume. But we
could cross this bridge later with systemd-homed, whether to store
that material in a "home" subvolume or "var" might become more clear.
The sd-homed btrfs and fscrypt backends will create per user
subvolumes when on btrfs. That moots the "var" and "home subvolume
distinction entirely. But the distinction remains for the luks backend
which is "filesystem on luks on loop" backing files, which subvolume
those user backing files are ideally located on.

My instinct is this matters less for installation and daily usage, and
more as a logical puzzle for disaster recovery. What items need to be
restored and how, in order to make a bad day less bad.



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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Chris Murphy]

On Wed, Jan 19, 2022 at 4:56 AM Vitaly Zaitsev via devel
 wrote:
>
> On 19/01/2022 09:54, Pavel Březina wrote:
> > This is the intention, it should not be touched by users therefore it
> > should not be visible to users, in my opinion.
>
> Packaging of hidden files/directories is not a good idea.
>
> /etc is meant to be editable by user.

Whereas /var/lib is not:

FHS 5.8.1
Users must never need to modify files in /var/lib to configure a
package's operation, and the specific file hierarchy used to store the
data must not be exposed to regular users.


-- 
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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Chris Murphy]

On Wed, Jan 19, 2022 at 3:04 AM 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.

Either /etc or /var should contain files that can be safely removed,
i.e. the system or application shouldn't break. Anything needing some
sort of base state information to function at all, needs to put that
in /usr, and customization/modification results in it being written to
/etc (configuration) or /var (runtime variable state information).

So if the files in question being moved were to be deleted, authselect
needs to handle that potential regardless of whether the state
information is in /etc or /var.

From FHS 5.8.1 about /var/lib
"State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between
invocations and between different instances of the same application."

If anything is more likely to get wiped in a factory/system reset, I
think it's /etc. I expect upon configuration information being reset,
that by extension the variable state information is rendered
unreliable or useless. Conversely, upon wiping a program's /var/lib
information, the configuration information in /etc is not inherently
invalid. I don't see much information in the FHS about the expected
behavior or consequences of wiping either location. But I think as a
distribution we can have the opinion the programs that face plant upon
finding empty /etc or /var/lib still should have the ability to
self-configure from /usr - be it a built-in process or some upstream
default /usr/etc configuration or base state information in /usr/var -
customization of either means populating the proper /etc or /var/lib

FHS 3.7 is pretty clear that /etc is for configuration information, no
binaries. I'm not completely sure I agree that state information is
disallowed in /etc, although I think the intent of the FHS here is so
that users can ostensibly reset a program's persistent state by wiping
the program's /var/lib information, which wouldn't alter its
configuration. If it's possible such a scenario confuses the program,
it really needs to be better prepared for this potential.

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

Fedora-Rawhide-20220119.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 20/225 (x86_64), 24/157 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220118.n.0):

ID: 1108641 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1108641
ID: 1108645 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1108645
ID: 1108646 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1108646
ID: 1108648 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1108648
ID: 1108649 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1108649
ID: 1108727 Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1108727
ID: 1108737 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1108737
ID: 1108749 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1108749
ID: 1108770 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1108770
ID: 1108821 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1108821
ID: 1108838 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1108838
ID: 1108839 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1108839
ID: 1108855 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1108855
ID: 1108859 Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/1108859
ID: 1108869 Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1108869
ID: 1108886 Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/1108886
ID: 110 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/110
ID: 1108892 Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/1108892
ID: 1108907 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1108907
ID: 1108924 Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/1108924
ID: 1108928 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1108928
ID: 1108939 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1108939
ID: 1108943 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1108943
ID: 1108945 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1108945
ID: 1108947 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1108947
ID: 1108948 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1108948
ID: 1108949 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1108949
ID: 1109031 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1109031

Old failures (same test failed in Fedora-Rawhide-20220118.n.0):

ID: 1108678 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1108678
ID: 1108697 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1108697
ID: 1108718 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1108718
ID: 1108739 Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1108739
ID: 1108758 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1108758
ID: 1108763 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1108763
ID: 1108768 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1108768
ID: 1108796 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1108796
ID: 1108808 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1108808
ID: 1108810 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.

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

[Colin Walters]

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.  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Wed, Jan 19, 2022 at 10:19 AM Fabio Valentini  wrote:
>
> On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton  wrote:
> >
> > 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.
>
> I wonder why you seem to be reinventing the wheel here?
>
> We are already moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm
> for a very similar reason, so wouldn't it make sense to do a similar
> thing here, and use /usr/lib/sysimage/authselect?
> Putting those files inside /etc (especially inside a hidden directoy)
> seems very wrong.

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



-- 
真実はいつも一つ！/ 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)

[Fabio Valentini]

On Tue, Jan 18, 2022 at 6:34 PM Ben Cotton  wrote:
>
> 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.

I wonder why you seem to be reinventing the wheel here?

We are already moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm
for a very similar reason, so wouldn't it make sense to do a similar
thing here, and use /usr/lib/sysimage/authselect?
Putting those files inside /etc (especially inside a hidden directoy)
seems very wrong.

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

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

[Michael Catanzaro]

On Wed, Jan 19 2022 at 12:56:26 PM +0100, Vitaly Zaitsev via devel 
 wrote:

Packaging of hidden files/directories is not a good idea.


Yeah that seems too creative. I don't think we need to hide files in 
system directories.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Fedocal] Reminder meeting : Fedora Source-git SIG

[Tomas Tomecek]

Today's meeting was really brief:

* Next sprint plans:
  * We're finally planning to set up the namespace where the initial repos
will live.
  * We will also start the engineering work on connecting the source-git
repos with Fedora dist-git counterparts (we should already have most of the
code, so this will really be just an integration exercise).

* The sprint after we'll work on a deployment.

* I hope that in 4 weeks we'll be able to do a demo and start hosting repos
for early adopters. See you there!


Tomas


On Tue, Jan 18, 2022 at 3:31 PM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>Fedora Source-git SIG on 2022-01-19 from 14:30:00 to 15:30:00 GMT
>At meet.google.com/mic-otnv-kse
>
> The meeting will be about:
> Meeting of the Fedora source-git SIG
>
> Agenda:
> https://pagure.io/fedora-source-git/sig/issues?tags=meeting&status=Open
>
> SIG Info:
> https://fedoraproject.org/wiki/SIGs/Source-git
>
>
> Source: https://calendar.fedoraproject.org//meeting/10101/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)

[Colin Walters]

On Wed, Jan 19, 2022, at 6:38 AM, Neal Gompa wrote:
> On Wed, Jan 19, 2022 at 6:05 AM Casey Jao via devel
>  wrote:
>>
>> Doesn't rpm-ostree already provide transactional, image-based updates 
>> without the use of filesystem snapshots? In addition, roofs snapshots are 
>> only really useful if they are coordinated with bootloader management, which 
>> is already built into rpm-ostree but not yet written for a hypothetical 
>> btrfs-based atomic os updater.
>
> I think the bigger value would be around being able to use filesystem
> snapshots with /var.

Right.  In the ostree model the idea is all user data (except config files in 
/etc) are in /var.  So if you want to back up all machine-local state 
(including your home directories, container storage, libvirt VMs, etc.), you 
just need one filesystem to save.

It could make sense to save a snapshot of /var before performing major OS 
upgrades.  But they're not strictly related.  (As an aside: personally, I think 
snapshots have mostly just obscure use cases versus backup systems)

I would agree with Casey though in that the opposite case of trying to snapshot 
/usr (and then boot it) outside of ostree's control is likely to confuse ostree 
at best at least today.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 rawhide compose report: 20220119.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220118.n.0
NEW: Fedora-Rawhide-20220119.n.0

= SUMMARY =
Added images:6
Dropped images:  1
Added packages:  8
Dropped packages:3
Upgraded packages:   162
Downgraded packages: 0

Size of added packages:  14.63 MiB
Size of dropped packages:10.30 MiB
Size of upgraded packages:   14.39 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -3.26 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20220119.n.0.aarch64.tar.xz
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220119.n.0.s390x.tar.xz
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20220119.n.0.armhfp.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20220119.n.0.ppc64le.tar.xz
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20220119.n.0.x86_64.tar.xz
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20220119.n.0.iso

= DROPPED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20220118.n.0.armhfp.raw.xz

= ADDED PACKAGES =
Package: cpputest-4.0-1.fc36
Summary: Unit testing and mocking framework for C/C++
RPMs:cpputest-devel
Size:1.28 MiB

Package: indi-3rdparty-drivers-1.9.3-4.fc36
Summary: INDI 3rdparty drivers
RPMs:indi-3rdparty-aagcloudwatcher-ng indi-3rdparty-aagcloudwatcher-ng-doc 
indi-3rdparty-apogee indi-3rdparty-drivers indi-3rdparty-eqmod 
indi-3rdparty-gphoto indi-3rdparty-sx
Size:2.22 MiB

Package: mingw-qt6-qttools-6.2.2-2.fc36
Summary: Qt6 for Windows - QtTools component
RPMs:mingw32-qt6-qttools mingw64-qt6-qttools
Size:8.85 MiB

Package: python-flask-security-too-4.1.2-3.fc36
Summary: Simple security for Flask apps
RPMs:python3-flask-security-too python3-flask-security-too+babel 
python3-flask-security-too+common python3-flask-security-too+fsqla
Size:241.08 KiB

Package: python-google-cloud-dns-0.34.0-1.fc36
Summary: Python Client for Google Cloud DNS
RPMs:python3-google-cloud-dns
Size:31.37 KiB

Package: python-kanboard-1.1.3-1.fc36
Summary: Client library for Kanboard API
RPMs:python3-kanboard
Size:13.86 KiB

Package: rust-heck0.3-0.3.3-1.fc36
Summary: Case conversion library
RPMs:rust-heck0.3+default-devel rust-heck0.3-devel
Size:25.96 KiB

Package: uvw-2.11.0-1.fc36
Summary: Header-only easy to use libuv C++ wrapper
RPMs:uvw-devel uvw-doc
Size:1.97 MiB


= DROPPED PACKAGES =
Package: icedtea-web-2.0.0-pre.0.3.alpha16.patched1.1.fc36.2
Summary: Additional Java components for OpenJDK - Java Web Start implementation
RPMs:icedtea-web
Size:9.20 MiB

Package: uddi4j-2.0.5-25.fc35
Summary: Universal Description, Discovery and Integration registry API for Java
RPMs:uddi4j uddi4j-javadoc
Size:607.88 KiB

Package: wsil4j-1.0-25.fc35
Summary: Web Services Inspection Language for Java API
RPMs:wsil4j wsil4j-javadoc
Size:519.04 KiB


= UPGRADED PACKAGES =
Package:  R-highlight-0.5.0-7.fc36
Old package:  R-highlight-0.5.0-6.fc35
Summary:  R Syntax Highlighter
RPMs: R-highlight
Size: 2.69 MiB
Size change:  128.65 KiB
Changelog:
  * Tue Jan 18 2022 Mattias Ellert  - 0.5.0-7
  - Don't create std::string from NULL (gcc 12 error)


Package:  ansible-inventory-grapher-2.5.0-8.fc36
Old package:  ansible-inventory-grapher-2.5.0-7.fc35
Summary:  Creates graphs representing ansible inventory
RPMs: python3-ansible-inventory-grapher
Size: 33.07 KiB
Size change:  -212 B
Changelog:
  * Tue Jan 18 2022 Parag Nemade  - 2.5.0-8
  - Resolves:rhbz#2040942 - Change package requirement from ansible-python3 to 
ansible


Package:  awscli-1.22.38-1.fc36
Old package:  awscli-1.22.36-1.fc36
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.15 MiB
Size change:  127 B
Changelog:
  * Tue Jan 18 2022 Gwyn Ciesla  - 1.22.37-1
  - 1.22.37

  * Tue Jan 18 2022 Gwyn Ciesla  - 1.22.38-1
  - 1.22.38


Package:  bluedevil-5.23.90-1.fc36
Old package:  bluedevil-5.23.5-1.fc36
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 2.07 MiB
Size change:  -8.72 KiB
Changelog:
  * Thu Jan 13 2022 Marc Deop  - 5.23.90-1
  - 5.23.90


Package:  breeze-gtk-5.23.90-1.fc36
Old package:  breeze-gtk-5.23.5-1.fc36
Summary:  Breeze widget theme for GTK
RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 
breeze-gtk-gtk4
Size: 318.90 KiB
Size change:  -7.62 KiB
Changelog:
  * Thu Jan 13 2022 Marc Deop  - 5.23.90-1
  - 5.23.90


Package:  calligra-3.2.1-15.fc36
Old package:  calligra-3.2.1-14.fc36
Summary:  An integrated office suite

Re: kTLS related failures on rawhide in OpenSSL 3.0.1

[Dmitry Belyavskiy]

Dear colleagues,

The error is specific to armv7hl architecture. Could somebody please assist
us with investigation of this problem?

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


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

kTLS related failures on rawhide in OpenSSL 3.0.1

[Sahana Prasad]

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

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

[Vitaly Zaitsev via devel]

On 19/01/2022 09:54, Pavel Březina wrote:
This is the intention, it should not be touched by users therefore it 
should not be visible to users, in my opinion.


Packaging of hidden files/directories is not a good idea.

/etc is meant to be editable by user.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam 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 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.

-- 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: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)

[Neal Gompa]

On Wed, Jan 19, 2022 at 6:05 AM Casey Jao via devel
 wrote:
>
> Doesn't rpm-ostree already provide transactional, image-based updates without 
> the use of filesystem snapshots? In addition, roofs snapshots are only really 
> useful if they are coordinated with bootloader management, which is already 
> built into rpm-ostree but not yet written for a hypothetical btrfs-based 
> atomic os updater.

I think the bigger value would be around being able to use filesystem
snapshots with /var.



-- 
真実はいつも一つ！/ 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: DIGLIM (System-Wide Change proposal)

[Roberto Sassu via devel]

> From: Roberto Sassu
> Sent: Tuesday, January 18, 2022 3:36 PM
> Hi everyone
> 
> I recently sent to the kernel mailing lists a patch set to support
> PGP keys and signatures.
> 
> Other than allowing the appraisal of RPM headers without
> changes to the building infrastructure, it would also simplify
> key management for the use cases requiring file or fsverity
> signatures (no need for a secondary key).
> 
> This is the link of the patch set:
> 
> https://lore.kernel.org/linux-integrity/2022080318.591029-1-
> roberto.sa...@huawei.com/
> 
> One point of the discussion was if there is the need to support
> PGP in the kernel, or if a distribution should adapt its key
> management to be compatible with key types currently available
> in the kernel.

I have a question related to this. Is the private key used to sign
kernel modules available also when other packages are built?

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

> It would be great if you could comment on this patch set, from
> the perspective of people managing a Linux distribution. Also,
> any thought related to the patch set would be appreciated.
> 
> Thanks
> 
> Roberto
> 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Zhong Ronghua
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)

[Casey Jao via devel]

Doesn't rpm-ostree already provide transactional, image-based updates without 
the use of filesystem snapshots? In addition, roofs snapshots are only really 
useful if they are coordinated with bootloader management, which is already 
built into rpm-ostree but not yet written for a hypothetical btrfs-based atomic 
os updater.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 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.



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

[Jakub Jelinek]

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:
> Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> 
> PHP is now FTBFS on s390x only
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437
> 
> 
> Any help welcome,
> Remi
> 
> 
> P.S. from build.log
> 
> 
> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
> 'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining
> failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
> option mismatch
>32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
>   |^~
> In file included from
> /builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
> /builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
> from here
>  8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
>   | ^~~

That error means that there is difference in the target attribute or #pragma
GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.

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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Petr Pisar]

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.

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


Authselect would require user intervention.



-- 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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Petr Pisar]

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.

-- 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: Self Introduction: Dorinda Bassey

[Dorinda Bassey]

Thank you guys for the warm welcome. I'm looking forward to contributing to the 
Fedora community. We meet again TimO :-D
I made a bug request - https://bugzilla.redhat.com/show_bug.cgi?id=2041917 so 
far I don't have any sponsor yet. I'd Appreciate help from anyone willing to 
sponsor me. Thanks :D
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20220119.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-20220118.0):

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

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

Fedora-Cloud-35-20220119.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-20220117.0):

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

Passed openQA tests: 7/8 (aarch64), 7/8 (x86_64)

New passes (same test not passed in Fedora-Cloud-35-20220117.0):

ID: 1108538 Test: aarch64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1108538
-- 
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: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/18/22 19:03, Vitaly Zaitsev via devel wrote:

On 18/01/2022 18:32, Ben Cotton wrote:
Authselect state files moved from/var/lib/authselect to 
/etc/authselect/.state.


Why /etc/authselect/.state and not /etc/authselect/state? Dot in front 
of the name means hidden file/directory.


This is the intention, it should not be touched by users therefore it 
should not be visible to users, in my opinion.

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