Re: Lua 5.4.0

[Julian Sikorski]

W dniu 29.06.2020 o 20:30, Tom Callaway pisze:
> I just built lua 5.4.0 in Rawhide. As with previous major updates of
> lua, the package also includes a copy of the lua 5.3 libraries so that
> rawhide does not just become broken reps. If you depend on lua, please
> rebuild your packages in rawhide and let me know if you run into any issues.
> 
> Thanks,
> Tom
> 
Hi,

mame (genie bundled with it to be precise) no longer builds due to
luaL_register disappearing
https://bugzilla.redhat.com/show_bug.cgi?id=1864109
I reported this to upstream who advised to just use bundled lua-5.3. I
tried the approach found online [1] and, while it got me past the
compilation issue, it caused
PANIC: unprotected error in call to Lua API (attempt to index a nil value)
once the compiled binary was run. Would anybody be able to help? Thank
you in advance.

Best regards,
Julian

[1] https://github.com/microwish/Lua-MCCH/pull/1/files







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

Re: Test machines for s390x?

[Kevin Fenzi]

On Wed, Aug 05, 2020 at 11:26:34PM -0400, Elliott Sales de Andrade wrote:
> Hi,
> 
> Now that ppc64 is gone, s390x is the only big-endian architecture
> left. Bugs around endianness are not usually difficult to fix, _if_ I
> can debug it and see where exactly the problem is. However, this
> requires a tedious guess-a-patch, try a scratch build, check the
> result, rinse and repeat.
> 
> Mock (with --forcearch) is completely useless for this. The programs
> just crash during the build in such a way that I can't even use
> `catchsegv`, and gdb is unusable in the container. And besides, the
> programs don't actually crash on real s390x anyway..
> 
> Just like we have test machines for other less used architectures [1],
> I am wondering if there is some way we can spin up a test machine for
> s390x?

Sorry, not with the current setup. ;( 

I'll keep an eye out for any possiblity tho... I'd love to be able to
provide one. 

I think there may be a way to get access to a guest from ibm though. 
(I'll let folks who know about that chime in here though)

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

Re: Proposal to Add: Log In/Out Blocker Criteria

[Stephen J. Turnbull]

I'm really uncomfortable about the amount of crossp-posting, so I'm
limiting this to devel@ (I receive it) and test@ (obvious to me why
relevant).

Kamil Paral writes:
 > Adam writes:

 > > Arguably the environment from which they logged in is not
 > > "working as expected" if you can't then log in as someone else.
 > 
 > However, the existing basic criterion [1] only requires the *initially*
 > created user to be able to log in. So if you create a second user, and
 > can't log in with it after a system boot,

Adam's argument is that this is covered by "working as expected".

FWIW, I think that the criterion should be something like

users created by *scripts* as part of a *supported* installation
or upgrade process and which are documented as able to log in,
must be able to log in from any condition where login is
documented to be possible.  Logging out must return the login
facilities to the state in which log in occurred unless some
*condition* (such as shutdown in progress) *explicitly* changes
it.

By "scripts" and "supported" I mean to rule out situations where a
admin abused the facilities (such as after generating the standard
users root and alice by answering the "username" and "password"
questions, they go on to create bob and cindy and misspecify the
user's shell).  Of course if user error occurs, we should see if we
can do better, but my understanding is that this is a criterion for
"blockers", and that's why I want to rule out user error.

By "explicit condition" I mean that if a bug is reported "I can't log
in after X" and it is determined that some condition holds that
prevents the login, it's OK to either fix the condition, or document
that that condition prevents login.  Similarly, documenting is OK if
something happens after logging out that the user didn't expect, but
on reflection seems reasonable from the point of view of the
development community.

Another plausible admin error case is where some user has decided to
make obsoletewhenfirstreleasedsh their shell and the "supported
process" *deletes* that shell.  (We might want to fix that one rather
than documenting it, since it's easy enough to check.  For all I know,
we already do!  I've never deleted a shell package. ;-)

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Test machines for s390x?

[Elliott Sales de Andrade]

Hi,

Now that ppc64 is gone, s390x is the only big-endian architecture
left. Bugs around endianness are not usually difficult to fix, _if_ I
can debug it and see where exactly the problem is. However, this
requires a tedious guess-a-patch, try a scratch build, check the
result, rinse and repeat.

Mock (with --forcearch) is completely useless for this. The programs
just crash during the build in such a way that I can't even use
`catchsegv`, and gdb is unusable in the container. And besides, the
programs don't actually crash on real s390x anyway..

Just like we have test machines for other less used architectures [1],
I am wondering if there is some way we can spin up a test machine for
s390x?

[1] 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

[Orion Poplawski]

So, I'm getting one of these messages every couple of hours and I'd 
really rather not.  Who do I need to talk to about it?


FWIW - It seems to fail because of missing deps:

DEBUG util.py:621:  No matching package to install: 'cmake(Qt5)'
DEBUG util.py:621:  No matching package to install: 'cmake(Qt5X11Extras)'

Thanks,

  Orion

 Forwarded Message 
Subject: bpeck/jenkins-continuous-infra.apps.ci.centos.org's 
vtk-8.2.0-18.eln103 failed to build

Date: Wed,  5 Aug 2020 19:17:12 + (GMT)
From: notificati...@fedoraproject.org
To: or...@fedoraproject.org

Notification time stamped 2020-08-05 19:14:23 UTC

bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 
failed to build

http://koji.fedoraproject.org/koji/buildinfo?buildID=1546696

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposed Modular Policy for Fedora ELN

[Stephen Gallagher]

On Wed, Aug 5, 2020 at 6:17 PM James Cassell
 wrote:
>
> As general feedback, the footnotes make it hard to read the rendered version 
> of the document, forcing  me to scroll up and down.
>

Well, the idea is that the footnotes are additional information
providing justification for the policy. You should only need to look
there if you care *why* you're required to do something. I didn't want
that extra info cluttering the policy itself, so I footnoted them.

> More comments below.
>
> On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> > * If a stream of a module has build-time-only components, all such
> > components *MUST* be marked as `buildonly: True` in the module
> > metadata to avoid shipping them to users and polluting their
> > repository.
> >
>
> Can these be directed to a disabled-by-default build-dep repo of some kind 
> for those trying to do local builds?
>

That's not really a policy question, but it's *possible* that we could
do that as part of the compose. I don't see a lot of reason to do so,
since a local MBS build will handle it for you and as we establish
later on, the use of these should be a last resort, not a common
practice.

> Do these "non-shipped" packages shadow non-modular versions of the same 
> packages?
>

They would shadow non-modular versions if we allowed them into the
repository, hence why they are not composed there.

> > == Requirements for Default Streams
>
> I'd propose an alternative to Default Streams. Any package part of a default 
> stream should instead be auto-built in a given release where the stream is 
> marked as default. Pushes to the dist-git branch for that release would be 
> blocked by all but the auto build bot, and all changes should be made to the 
> stream branch.

We looked into that a while ago. The short answer is "it's a lot
harder to accomplish than it sounds" (particularly if you have
buildonly content required, such as relying on a too-new-for-Fedora
version of a build-system or something). If you want to propose a
possible way of doing this, please start a different email thread, as
it is off-topic for the policy discussion.

>
> The stream marked "default" for the particular module would be enabled as a 
> buildroot override, including build only packages, for such automated 
> non-modular rebuilds of streams marked "default".  This would obviate the 
> need of stream transition, except in cases if inter-module deps.
>
> Even given the status quo, I'd argue that streams enabled by nature of being 
> Default rather than being explicitly enabled, should not shadow non-modular 
> packages. As-is today, third party repos are marking themselves as 
> module_hotfixes to skip the shadowing issues.
>

Please do not derail this thread with a re-architecture of Modularity.
The shadowing is a core part of the functionality. What would even be
the point of being a default stream if your packages weren't visible
to the depsolver? (Don't answer that in this thread, please.)

> > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> > permits defaults streams that adhere to the policy below.
>
> Say EPEL, don't mention version.

EPEL 7 doesn't support modules and EPEL 9 hasn't been announced yet
and has no policy established. EPEL 8 is the only one that has made a
decision either way.

>
> > * Default streams *MUST NOT* provide a binary RPM with the same
> > package name as an RPM in a default stream in the same release except
>
> "default stream of another module"

Good catch. I will fix that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposed Modular Policy for Fedora ELN

[Stephen Gallagher]

On Wed, Aug 5, 2020 at 5:38 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> Hi, Stephen.
>
> On Wednesday, 05 August 2020 at 21:36, Stephen Gallagher wrote:
> > FESCo has requested that I submit the module policy once more to the
> > Fedora development list for discussion. Feedback is welcome.
>
> [...]
> > * The default stream of a module *MUST NOT* change to a different
> > stream within a released Fedora version.footnote:[This is an extension
> > of the 
> > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases[stable
> > updates policy].] The default stream *MAY* be changed in Rawhide or
> > during Fedora upgrades. Changes to default streams *MUST* be approved
> > via a 
> > https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process[Fedora
> > Change proposal].
> > * Packages *MAY* convert from a non-modular package to a modular
> > default stream (or the reverse) only in Rawhide or during Fedora
> > upgrades.
>
> > * Default streams *MUST NOT* provide a binary RPM with the same
> > package name as a non-modular RPM in the same release except in the
> > case of a transition from one to the other.footnote:[Modular packages
> > shadow non-modular ones. This rule ensures that we don't have any
> > shadowed packages in the default package set.]
>
> [1] Transitions to/from modular are already forbidden in Fedora
> releases, so saying "in the same release" makes no sense. I'd say "in
> rawhide or during Fedora upgrades".
>

It's redundant, but it doesn't need to be changed if we ever end up
allowing default streams in Fedora releases.

> > * Default streams *MUST NOT* provide a binary RPM with the same
> > package name as an RPM in a default stream in the same release except
> > in the case of a transition from one to the other.footnote:[In this
> > situation, whichever has the highest NEVRA would win the depsolving
> > and could break the other module.]
>
> I guess "transition to another default module" is what is meant above.

This was a bad copy-paste. Everything after "in the same release"
should be dropped. I'll fix that.

>
> > * Multiple default streams *MUST NOT* provide the same binary package
> > names at runtime.footnote:[They *MAY* provide other well-known names
> > in the same manner as permitted for non-modular content. For example,
> > two different default streams *MAY* provide content to be used with
> > the `alternatives` system or virtual `Provides` for capabilities.]
>
> > * Default streams *MUST NOT* provide a package that overrides a
> > package of the same name in the non-modular content except in approved
> > cases of migration between modular and non-modular delivery.
>
> This is redundant, already mentioned above[1].
>

It's not redundant for ELN, which is a rolling stream like Rawhide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mpich always injects lto flags

[Christoph Junghans]

On Wed, Aug 5, 2020 at 2:21 PM Jeff Law  wrote:
>
> On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > Hi,
> > >
> > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > when doing this I hit
> > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > which works for the build with openmpi, but gets ignored for the mpich
> > > build.
> > >
> > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > and then puts them in
> > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > >
> > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > reasonable?
> > >
> > > The flags also contain
> > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > >
> > > Christoph
> > >
> > Another related bug is:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> Note that the BZ complains about -fstack-clash-protection in LLVM which has 
> had
> various bits landing over the last few months.  So that specific issue I'd 
> expect
> to resolve itself over time.  The more general issue remains though.
https://src.fedoraproject.org/rpms/mpich/pull-request/4

Christoph
>
> jeff
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposed Modular Policy for Fedora ELN

[James Cassell]

As general feedback, the footnotes make it hard to read the rendered version of 
the document, forcing  me to scroll up and down.

More comments below.

On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> * If a stream of a module has build-time-only components, all such
> components *MUST* be marked as `buildonly: True` in the module
> metadata to avoid shipping them to users and polluting their
> repository.
> 

Can these be directed to a disabled-by-default build-dep repo of some kind for 
those trying to do local builds?

Do these "non-shipped" packages shadow non-modular versions of the same 
packages?

> == Requirements for Default Streams

I'd propose an alternative to Default Streams. Any package part of a default 
stream should instead be auto-built in a given release where the stream is 
marked as default. Pushes to the dist-git branch for that release would be 
blocked by all but the auto build bot, and all changes should be made to the 
stream branch.

The stream marked "default" for the particular module would be enabled as a 
buildroot override, including build only packages, for such automated 
non-modular rebuilds of streams marked "default".  This would obviate the need 
of stream transition, except in cases if inter-module deps.

Even given the status quo, I'd argue that streams enabled by nature of being 
Default rather than being explicitly enabled, should not shadow non-modular 
packages. As-is today, third party repos are marking themselves as 
module_hotfixes to skip the shadowing issues.

> * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> permits defaults streams that adhere to the policy below.

Say EPEL, don't mention version.

> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as an RPM in a default stream in the same release except

"default stream of another module"

> in the case of a transition from one to the other.footnote:[In this
> situation, whichever has the highest NEVRA would win the depsolving
> and could break the other module.]

V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 Change: Promote IoT to an Edition (Incredibly late System-Wide Change)

[Peter Robinson]

On Wed, Aug 5, 2020 at 7:12 PM Kamil Paral  wrote:
>
> On Tue, Aug 4, 2020 at 8:57 PM Ben Cotton  wrote:
>>
>> After discussing this with FESCo last week, this is submitted at a F33
>> change since it's largely a paperwork exercise at this point.
>>
>> https://fedoraproject.org/wiki/Changes/IoTEditionPromotion
>>
>> = Promote IoT to an Edition =
>>
>> == Summary ==
>> Promote Fedora IoT to an official Fedora Edition.
>
>
> If this is approved, will IoT images be composed as part of the main Fedora 
> compose, or will they continue to be a separate compose?

They will remain separate
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposed Modular Policy for Fedora ELN

[Dominik 'Rathann' Mierzejewski]

Hi, Stephen.

On Wednesday, 05 August 2020 at 21:36, Stephen Gallagher wrote:
> FESCo has requested that I submit the module policy once more to the
> Fedora development list for discussion. Feedback is welcome.

[...]
> * The default stream of a module *MUST NOT* change to a different
> stream within a released Fedora version.footnote:[This is an extension
> of the 
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases[stable
> updates policy].] The default stream *MAY* be changed in Rawhide or
> during Fedora upgrades. Changes to default streams *MUST* be approved
> via a 
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process[Fedora
> Change proposal].
> * Packages *MAY* convert from a non-modular package to a modular
> default stream (or the reverse) only in Rawhide or during Fedora
> upgrades.

> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as a non-modular RPM in the same release except in the
> case of a transition from one to the other.footnote:[Modular packages
> shadow non-modular ones. This rule ensures that we don't have any
> shadowed packages in the default package set.]

[1] Transitions to/from modular are already forbidden in Fedora
releases, so saying "in the same release" makes no sense. I'd say "in
rawhide or during Fedora upgrades".

> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as an RPM in a default stream in the same release except
> in the case of a transition from one to the other.footnote:[In this
> situation, whichever has the highest NEVRA would win the depsolving
> and could break the other module.]

I guess "transition to another default module" is what is meant above.

> * Multiple default streams *MUST NOT* provide the same binary package
> names at runtime.footnote:[They *MAY* provide other well-known names
> in the same manner as permitted for non-modular content. For example,
> two different default streams *MAY* provide content to be used with
> the `alternatives` system or virtual `Provides` for capabilities.]

> * Default streams *MUST NOT* provide a package that overrides a
> package of the same name in the non-modular content except in approved
> cases of migration between modular and non-modular delivery.

This is redundant, already mentioned above[1].

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mpich always injects lto flags

[Jeff Law]

On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > Hi,
> > 
> > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > when doing this I hit
> > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > which works for the build with openmpi, but gets ignored for the mpich
> > build.
> > 
> > I think the problem is that CMake picks up the lto flags from mpicxx
> > and then puts them in
> > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > 
> > So I think the fix would be to strip these flags from mpicc. Sounds 
> > reasonable?
> > 
> > The flags also contain
> > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > 
> > Christoph
> > 
> Another related bug is:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1821728
Note that the BZ complains about -fstack-clash-protection in LLVM which has had
various bits landing over the last few months.  So that specific issue I'd 
expect
to resolve itself over time.  The more general issue remains though.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Driverless scanning for WSD and ESCL supported scanners is coming

[Robert Marcano via devel]

On 8/5/20 8:30 AM, Jiří Eischmann wrote:

Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200:

Hi all,

I would like to announce sane-airscan project [1] will be shipped in
the
official Fedora repositories from Fedora 32 [2].

sane-airscan implements a backend for Microsoft WSD and ESCL (usually
called AirScan, originating from Apple) protocols, which are common
in
newer (2012+) scanners and multi-function devices for scanning.

Using sane-airscan, newer devices don't need vendor proprietary
software
for scanning any longer (e.g. hplip with its hp-plugin).

The project is divided into main package - sane-airscan - which
contains
helper tool - airscan-discover - for discovering devices in setups,
where automatic DNS-SD discovery doesn't do the trick, and subpackage
-
libsane-airscan - which the main package requires and the common
known
project for scanning - sane-backends - will require to get the
backend
into common scanning stack installation.

Please feel free to test it.


  Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.


If your clients are SANE supported OSs, you can already do that with 
saned. For example this documentation


https://wiki.debian.org/SaneOverNetwork




Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reminder: upcoming Fedora 33 deadlines & milestones

[Jonathan Wakely]

On 05/08/20 04:35 +0200, J. Scheurich wrote:



Am 05.08.20 um 01:52 schrieb Ben Cotton:

Here are some upcoming deadlines and milestones for the Fedora 33
development cycle:

Are you sure, that boost1.73 should be part of fedora 33 ?
It lloks like boost.173 would require a future verson of gcc/g++


This is nonsense. Boost 1.73.0 was already released months ago, how
could it require a version of GCC from the future?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mpich always injects lto flags

[David Schwörer]

On 8/5/20 8:45 PM, Christoph Junghans wrote:
> Hi,
> 
> I am trying to rebuild espresso to adapt to the recent cmake changes,
> when doing this I hit
> https://github.com/espressomd/espresso/issues/3396, which prevents us
> from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> which works for the build with openmpi, but gets ignored for the mpich
> build.
> 
> I think the problem is that CMake picks up the lto flags from mpicxx
> and then puts them in
> MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> 
> So I think the fix would be to strip these flags from mpicc. Sounds 
> reasonable?
> 
> The flags also contain
> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> 
> Christoph
> 
Another related bug is:

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

mpich should really clean up the flags that it injects - just using the
same set as is used to compile mpich is causing several issues.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mpich always injects lto flags

[Fabio Valentini]

On Wed, Aug 5, 2020 at 9:41 PM Christoph Junghans  wrote:
>
> On Wed, Aug 5, 2020 at 12:54 PM Jeff Law  wrote:
> >
> > On Wed, 2020-08-05 at 12:45 -0600, Christoph Junghans wrote:
> > > Hi,
> > >
> > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > when doing this I hit
> > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > which works for the build with openmpi, but gets ignored for the mpich
> > > build.
> > >
> > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > and then puts them in
> > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > >
> > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > reasonable?
> > >
> > > The flags also contain
> > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > You might try %global (which has global scope) rather than %define (which 
> > has a
> > local scope).   Or just strip it away like you've proposed.
> %global doesn't help either.

I think there have been similar problems with, for example, python and
ruby extensions.
python / ruby will store the CFLAGS they were built with and use them
to build binary extensions, which breaks when they contain e.g. the
flags for specs from redhat-rpm-config.
The mpich case sounds really similar. You'll probably need to adapt
that build environment to drop some flags which don't make sense in
the MPI context.

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

Re: mpich always injects lto flags

[Christoph Junghans]

On Wed, Aug 5, 2020 at 12:54 PM Jeff Law  wrote:
>
> On Wed, 2020-08-05 at 12:45 -0600, Christoph Junghans wrote:
> > Hi,
> >
> > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > when doing this I hit
> > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > which works for the build with openmpi, but gets ignored for the mpich
> > build.
> >
> > I think the problem is that CMake picks up the lto flags from mpicxx
> > and then puts them in
> > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> >
> > So I think the fix would be to strip these flags from mpicc. Sounds 
> > reasonable?
> >
> > The flags also contain
> > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> You might try %global (which has global scope) rather than %define (which has 
> a
> local scope).   Or just strip it away like you've proposed.
%global doesn't help either.

Christoph
>
> jeff
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Proposed Modular Policy for Fedora ELN

[Stephen Gallagher]

FESCo has requested that I submit the module policy once more to the
Fedora development list for discussion. Feedback is welcome.


Plainext (asciidoc) below, much more readable HTML at
https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/


= Policies Regarding Modules in Fedora, Fedora ELN and EPEL

== Requirements for All Module Streams
* The module maintainer *MUST* have explicit commit privileges to all
packages included in the module stream. The provenpackager privilege
in Fedora is not sufficient.footnote:[This ensures that the package in
the module is being maintained by someone responsible for it.]
* Components built into a module *MUST* be associated with a reachable
commit in Fedora dist-git.footnote:[There are legal and licensing
requirements for reproducibility of builds.]
* If a stream of a module has build-time-only components, all such
components *MUST* be marked as `buildonly: True` in the module
metadata to avoid shipping them to users and polluting their
repository.

== Requirements for Default Streams
* Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
permits defaults streams that adhere to the policy below.
* All RPMs in default module streams are required to conform to the
same 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/[requirements
around Conflicts] as non-modular RPMs.
* Packages provided at runtime by the default stream of a module
*MUST* depend only on packages provided by packages from default
module streams or the non-modular package set. By extension, default
streams of a module *MUST NOT* have a dependency on any non-default
stream.footnote:[It is highly recommended that default streams have no
module dependencies besides the platform to avoid potential future
conflicts during upgrades.]
* Packages provided from default streams *MAY* depend on content from
other default streams. If they do so, this dependency *MUST* be
encoded in the module metadata.footnote:[This is so that if the
maintainers of either module wishes to change its default stream, it
is easy to see what other modules would be impacted and coordinate
it.]
* All packages provided at runtime by the default stream of a module
*MUST* provide all the same functionality that a downstream consumer
would expect from a package in the non-modular package
set.footnote:[If a package is not filtered out from the default module
stream, it is going to be part of the default-available content and
therefore must be treated (and supported) just like a non-modular
package.]
* The default stream of a module *MUST NOT* change to a different
stream within a released Fedora version.footnote:[This is an extension
of the 
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases[stable
updates policy].] The default stream *MAY* be changed in Rawhide or
during Fedora upgrades. Changes to default streams *MUST* be approved
via a 
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process[Fedora
Change proposal].
* Packages *MAY* convert from a non-modular package to a modular
default stream (or the reverse) only in Rawhide or during Fedora
upgrades.
* Default streams *MUST NOT* provide a binary RPM with the same
package name as a non-modular RPM in the same release except in the
case of a transition from one to the other.footnote:[Modular packages
shadow non-modular ones. This rule ensures that we don't have any
shadowed packages in the default package set.]
* Default streams *MUST NOT* provide a binary RPM with the same
package name as an RPM in a default stream in the same release except
in the case of a transition from one to the other.footnote:[In this
situation, whichever has the highest NEVRA would win the depsolving
and could break the other module.]
* Multiple default streams *MUST NOT* provide the same binary package
names at runtime.footnote:[They *MAY* provide other well-known names
in the same manner as permitted for non-modular content. For example,
two different default streams *MAY* provide content to be used with
the `alternatives` system or virtual `Provides` for capabilities.]
* Default streams *MUST NOT* provide a package that overrides a
package of the same name in the non-modular content except in approved
cases of migration between modular and non-modular delivery.
* Default streams *MUST NOT* use the `data.buildopts.rpm.macros`
metadata section without approval by FESCo.footnote:[This feature
allows for overriding the standard macros for building packages in
Fedora and should be avoided entirely for default streams so they are
built just like non-modular packages.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://l

Re: mpich always injects lto flags

[Jeff Law]

On Wed, 2020-08-05 at 12:45 -0600, Christoph Junghans wrote:
> Hi,
> 
> I am trying to rebuild espresso to adapt to the recent cmake changes,
> when doing this I hit
> https://github.com/espressomd/espresso/issues/3396, which prevents us
> from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> which works for the build with openmpi, but gets ignored for the mpich
> build.
> 
> I think the problem is that CMake picks up the lto flags from mpicxx
> and then puts them in
> MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> 
> So I think the fix would be to strip these flags from mpicc. Sounds 
> reasonable?
> 
> The flags also contain
> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
You might try %global (which has global scope) rather than %define (which has a
local scope).   Or just strip it away like you've proposed.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

mpich always injects lto flags

[Christoph Junghans]

Hi,

I am trying to rebuild espresso to adapt to the recent cmake changes,
when doing this I hit
https://github.com/espressomd/espresso/issues/3396, which prevents us
from compiling espresso with -lto, so I set _lto_cflags to %{nil},
which works for the build with openmpi, but gets ignored for the mpich
build.

I think the problem is that CMake picks up the lto flags from mpicxx
and then puts them in
MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).

So I think the fix would be to strip these flags from mpicc. Sounds reasonable?

The flags also contain
'-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625

Christoph
-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 Change: Promote IoT to an Edition (Incredibly late System-Wide Change)

[Kamil Paral]

On Tue, Aug 4, 2020 at 8:57 PM Ben Cotton  wrote:

> After discussing this with FESCo last week, this is submitted at a F33
> change since it's largely a paperwork exercise at this point.
>
> https://fedoraproject.org/wiki/Changes/IoTEditionPromotion
>
> = Promote IoT to an Edition =
>
> == Summary ==
> Promote Fedora IoT to an official Fedora Edition.
>

If this is approved, will IoT images be composed as part of the main Fedora
compose, or will they continue to be a separate 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

Re: Respinning rawhide images every filesystem update?

[Kevin Fenzi]

On Mon, Aug 03, 2020 at 02:36:40PM -0400, Alex Scheel wrote:
> Hey list,
> 
> 
> How do Fedora rawhide images get respun? Every time filesystem updates,

They are rebuild in every rawhide nightly compose. 
Here's the one from last night/this morning: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=48713559

They are then pushed into our registry.

> it causes `dnf update` to fail in a podman container because filesystem
> can't be updated in a container. We either need to make sure filesystem
> updates  cause rawhide containers to be rebuilt, or figure out how to
> ship a container-friendly filesystem package.

Where are you pulling from? Our registry? docker.io? quay?

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

Review swap

[Jake Hunsaker]

Hello,

I need a package review for rig, looking for a review swap.

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


- jake / turboturtle

--
Jake Hunsaker
RHCA Cloud Specialist
Senior Software Engineer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Wednesday's FESCo Meeting (2020-08-05)

[Neal Gompa]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-08-05 14:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

F33 Self-Contained Change: .NET Core on Aarch64
https://pagure.io/fesco/issue/2453
APPROVED (+7, 0, -0)

F33 Self-Contained Change: Stratis 2.1.0
https://pagure.io/fesco/issue/2455
APPROVED (+9, 0, -0)

= Followups =

#topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto
macros - Detached rpm changelogs
https://pagure.io/fesco/issue/2440

= New business =

No tickets older than 7 days are waiting for input or are tagged with
"meeting".

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.



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

Re: Proposal to Add: Log In/Out Blocker Criteria

[Kamil Paral]

On Tue, Aug 4, 2020 at 5:07 PM Adam Williamson 
wrote:

> There's a sort of technical argument to be made that this is covered by
>
> https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#desktop-shutdown-reboot-logout
> .
> That says "Shutting down, logging out and rebooting must work using
> standard console commands and the mechanisms offered (if any) by all
> release-blocking desktops", with a footnote "Logging out must return
> the user to the environment from which they logged in, working as
> expected." Arguably the environment from which they logged in is not
> "working as expected" if you can't then log in as someone else.
>

However, the existing basic criterion [1] only requires the *initially*
created user to be able to log in. So if you create a second user, and
can't log in with it after a system boot, that would not be covered by
neither the basic one nor the one you just quoted. It would be covered by
the proposed change I made, though. I think it's a good idea to have a
clear "logging is must work" criterion somewhere.

[1]
https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior


> Adding a more explicit requirement wouldn't hurt, though, I guess. I
> sort of feel like it would be nice to somehow combine and rationalize
> all these related requirements somehow...
>

I'm not sure what exactly you have on mind. How would you like to improve
it? By having log in/out + shutdown + reboot in the same criterion, it
seems quite "combined".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Driverless scanning for WSD and ESCL supported scanners is coming

[Jiří Eischmann]

Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200:
> Hi all,
> 
> I would like to announce sane-airscan project [1] will be shipped in
> the
> official Fedora repositories from Fedora 32 [2].
> 
> sane-airscan implements a backend for Microsoft WSD and ESCL (usually
> called AirScan, originating from Apple) protocols, which are common
> in
> newer (2012+) scanners and multi-function devices for scanning.
> 
> Using sane-airscan, newer devices don't need vendor proprietary
> software
> for scanning any longer (e.g. hplip with its hp-plugin).
> 
> The project is divided into main package - sane-airscan - which
> contains
> helper tool - airscan-discover - for discovering devices in setups,
> where automatic DNS-SD discovery doesn't do the trick, and subpackage
> -
> libsane-airscan - which the main package requires and the common
> known
> project for scanning - sane-backends - will require to get the
> backend
> into common scanning stack installation.
> 
> Please feel free to test it.

 Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Neal Gompa]

On Wed, Aug 5, 2020 at 7:53 AM Lukáš Hrázký  wrote:
>
> Hi Neal, all,
>
> On Tue, 2020-08-04 at 07:42 -0400, Neal Gompa wrote:
> > On Tue, Aug 4, 2020 at 7:32 AM Till Hofmann  
> > wrote:
> > > Hi all,
> > >
> > > I have a number of packages that are FTBFS due to
> > > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.
> > >
> > > None of my packages has seen any commits for that change. I've read on
> > > the list that packages that are considered "a complete mess" are not
> > > touched. Are all my packages "a complete mess"?
> > >
> > > More seriously, are we expected to fix this ourselves? What happened to
> > > "proposal owners will fix as many Fedora packages as possible"? Should I
> > > just re-assign the bug to cmake?
> > >
> > > I don't generally mind fixing my packages, but I'm confused by the lack
> > > of communication here.
> >
> > There are only a few packages that were considered a complete mess,
> > mostly packages that did crazy build process scripting in the %build
> > and %install sections. Most packages don't fall in that category.
> > Basically if I can't understand how it works, I don't want to touch
> > it.
> >
> > The reason yours hadn't been touched yet is because neither Igor nor
> > myself managed to get to yours before the mass rebuild.
> >
> > It would be ideal if you can fix your own packages if we hadn't gotten
> > to them, as you know your packages. :)
> >
> > The general advice I would give is that if you did the following:
> >
> > %cmake .
> > %make_build
> > %make_install
> >
> > Then you should change it to the following:
> >
> > %cmake
> > %cmake_build
> > %cmake_install
> >
> > (Note the lack of "." as an argument to %cmake)
> >
> > If you are doing something like the following:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake ..
> > popd
> >
> > %make_build -C %{_target_platform}
> > %make_install -C %{_target_platform}
> >
> > Or like the following
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake ..
> > popd
> >
> > pushd %{_target_platform}
> > %make_build
> > popd
> > pushd %{_target_platform}
> > %make_install
> > popd
> >
> > Then you should do the following:
> >
> > %undefine __cmake_in_source_build
> >
> > %cmake
> > %cmake_build
> > %cmake_install
>
> What if I build for multiple platforms at the same time? E.g. in dnf we
> have:
>
> %build
> %if %{with python2}
> pushd build-py2
> %cmake -DPYTHON_DESIRED:FILEPATH=%{__python2} -DDNF_VERSION=%{version}
> %cmake_build
> make doc-man
> popd
> %endif
>
> %if %{with python3}
> pushd build-py3
> %cmake -DPYTHON_DESIRED:FILEPATH=%{__python3} -DDNF_VERSION=%{version}
> %cmake_build
> make doc-man
> popd
> %endif
>
>
> Do the new macros handle this case as well or do I need to stick to the
> old way (with defining the variable)?
>

It appears Igor already did the conversion for you[1][2], but you
could also elect to go the other way as you considered.

However, you may want to go ahead and start simplifying that spec
because we're not building Python 2 support anywhere. Even RHEL 7
isn't getting updated versions of DNF anytime soon.

[1]: 
https://src.fedoraproject.org/rpms/dnf/c/a8a0affb4c4fd1022f18b203d578e2230cce30df?branch=master
[2]: 
https://src.fedoraproject.org/rpms/dnf/c/61ec663be5c477cea68afb60279773661e186c52?branch=master




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

Re: What to do about FTBFS because auf cmake change?

[Lukáš Hrázký]

Hi Neal, all,

On Tue, 2020-08-04 at 07:42 -0400, Neal Gompa wrote:
> On Tue, Aug 4, 2020 at 7:32 AM Till Hofmann  
> wrote:
> > Hi all,
> > 
> > I have a number of packages that are FTBFS due to
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.
> > 
> > None of my packages has seen any commits for that change. I've read on
> > the list that packages that are considered "a complete mess" are not
> > touched. Are all my packages "a complete mess"?
> > 
> > More seriously, are we expected to fix this ourselves? What happened to
> > "proposal owners will fix as many Fedora packages as possible"? Should I
> > just re-assign the bug to cmake?
> > 
> > I don't generally mind fixing my packages, but I'm confused by the lack
> > of communication here.
> 
> There are only a few packages that were considered a complete mess,
> mostly packages that did crazy build process scripting in the %build
> and %install sections. Most packages don't fall in that category.
> Basically if I can't understand how it works, I don't want to touch
> it.
> 
> The reason yours hadn't been touched yet is because neither Igor nor
> myself managed to get to yours before the mass rebuild.
> 
> It would be ideal if you can fix your own packages if we hadn't gotten
> to them, as you know your packages. :)
> 
> The general advice I would give is that if you did the following:
> 
> %cmake .
> %make_build
> %make_install
> 
> Then you should change it to the following:
> 
> %cmake
> %cmake_build
> %cmake_install
> 
> (Note the lack of "." as an argument to %cmake)
> 
> If you are doing something like the following:
> 
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> 
> %make_build -C %{_target_platform}
> %make_install -C %{_target_platform}
> 
> Or like the following
> 
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> 
> pushd %{_target_platform}
> %make_build
> popd
> pushd %{_target_platform}
> %make_install
> popd
> 
> Then you should do the following:
> 
> %undefine __cmake_in_source_build
> 
> %cmake
> %cmake_build
> %cmake_install

What if I build for multiple platforms at the same time? E.g. in dnf we
have:

%build
%if %{with python2}
pushd build-py2
%cmake -DPYTHON_DESIRED:FILEPATH=%{__python2} -DDNF_VERSION=%{version}
%cmake_build
make doc-man
popd
%endif

%if %{with python3}
pushd build-py3
%cmake -DPYTHON_DESIRED:FILEPATH=%{__python3} -DDNF_VERSION=%{version}
%cmake_build
make doc-man
popd
%endif


Do the new macros handle this case as well or do I need to stick to the
old way (with defining the variable)?

Cheers,
Lukas


> The %undefine is only needed if you reuse your spec on F32 and older
> (including EPEL). Note that EPEL7 with cmake3 requires also undefining
> %__cmake3_in_source_build, since all macros use "cmake3" instead of
> "cmake" in that instance.
> 
> -- 
> 真実はいつも一つ！/ 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

devel@lists.fedoraproject.org

[Leigh Griffin]

Hey everyone,

At Nest with Fedora the CPE team will be presenting a Year in Review. As
part of that we want to hold a Community Q&A and this is a general call for
any questions that you might like to have answered by the CPE Leadership
team in that call? We can curate the top questions (with thanks to Ben
Cotton who is volunteering his help here) and will follow up on any
questions we can't fit in timewise in the call with a Community Blog.

Looking forward to seeing you all virtually at Nest!
Leigh

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Driverless scanning for WSD and ESCL supported scanners is coming

[Zdenek Dohnal]

On 8/5/20 10:07 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 05 August 2020 at 07:44, Zdenek Dohnal wrote:
>> Hi all,
>>
>> I would like to announce sane-airscan project [1] will be shipped in the
>> official Fedora repositories from Fedora 32 [2].
>>
>> sane-airscan implements a backend for Microsoft WSD and ESCL (usually
>> called AirScan, originating from Apple) protocols, which are common in
>> newer (2012+) scanners and multi-function devices for scanning.
>>
>> Using sane-airscan, newer devices don't need vendor proprietary software
>> for scanning any longer (e.g. hplip with its hp-plugin).
> This is great news, thanks to you and Alexander Pevzner for making it
> happen. It makes me smile even if my current printer is not supported
> and still requires hp-plugin.

Hi Dominik,

if your device is capable of AirPrint (is network printer+has enabled
IPP+capable to be installed as '-m everywhere' model via lpadmin), there
is a good chance (unless you are unlucky like me with Laserjet m1536dnf
- supports AirPrint, but not AirScan) that it supports AirScan too.

>
> Regards,
> Dominik

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

Re: Reminder: upcoming Fedora 33 deadlines & milestones

[Vitaly Zaitsev via devel]

On 05.08.2020 04:35, J. Scheurich wrote:
> Are you sure, that boost1.73 should be part of fedora 33 ?

It is already part of Fedora 33.

> It lloks like boost.173 would require a future verson of gcc/g++ 

No. Everything works as required.

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

Re: OCaml + binutils 2.35 on i386

[Richard W.M. Jones]

On Wed, Aug 05, 2020 at 09:54:14AM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote:
> >> When ocamlopt is used with binutils 2.35 to link an executable, we now
> >> get warnings that look like this:
> >> 
> >> /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only
> >> section `.text'
> >> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
> >
> > 32 bit is an architectural problem for OCaml.  Specifically because of
> > how the GC block headers are implemented it limits arrays / strings to
> > a maximum of 4M entries / 4M bytes, which was probably fine back in
> > the day but is unreasonably small today. [1]
> 
> I don't see how this is related to text relocations.
> 
> The problem seems to be lack of PIE support in ocamlopt on i386, as
> correctly identified by the warning.

I mean any time spent fixing OCaml on 32 bit is time wasted.
If it happens on x86-64 then that's a problem we need to look at.

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

Re: Switching package to fragmented default configuration

[Miroslav Lichvar]

On Tue, Aug 04, 2020 at 06:26:37PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
> > That's possible (the paths could be hardcoded in the systemd unit
> > file), but is it a good idea to force the users to use the new system?
> > If someone has a modified config, or is using one of the many ansible
> > roles for configuring NTP for example, why should it stop working? We
> > don't have to break configuration tools that just generate a config
> > from scratch.
> 
> Backwards compatiblity should be kept obviously. In systemd we look at
> {/usr,/usr/local,/etc,/run}/foo.conf and
> {/usr,/usr/local,/etc,/run}/foo.conf.d/*.conf, so foo.conf is the main
> config file, while the "drop-ins" in /etc/ have higher priority and
> server as overrides. This is backwards compatible with having just
> /etc/foo.conf.

I don't see how that works. If I hardcoded the paths and split
/etc/foo.conf into several /usr/lib/foo.conf.d/*.conf fragments, or
any other package dropped a file in that directory, there would be
additional settings applied from those fragments even if the user
had an old /etc/foo.conf file, right? The user would need to figure
out what are those additional settings and revert them in /etc. That
would not be a great experience.

If the fragments were explicitly loaded from the new default
/etc/foo.conf, it would be obvious to a user merging the
configuration, and it wouldn't change anything for users keeping their
old config not loading the fragments.

Also, dropping /etc/foo.conf from the package would cause rpm to
rename it to .rpmsave, which would need to be worked around in a
scriptlet I guess.

> > The trouble is that a fragment having a different name cannot disable
> > servers specified in a different fragment. If anaconda wanted to
> > override the default servers, it would need to know the name of the
> > fragment. In some cases users/vendors/products may want to specify
> > additional servers, sometimes replace them.
> 
> This can be handled by having a directive that means "wipe previous
> config for this setting". In systemd we handle this by treating an
> empty assignment as special:
> SystemCallFilter=open
> SystemCallFilter=
> SystemCallFilter=write
> SystemCallFilter=read close
> is equivalent to SystemCallFilter=write read close.

That looks hackish to me. We would need new directives to remove
previous settings in chrony. I thought the point of splitting the
default configuration was to get logical groups of settings that can
be overriden by adding a file to /etc/chrony.d, replacing a group of
related settings at once, which will work even when a newer package
adds more settings there. If I need to override individually each
directive from the default configuration, which I cannot predict for
future packages, then I don't see much of a point in this.

systemd doesn't seem to have fragmented configs. Maybe dovecot is a
better example. It has configuration split like this:

/etc/dovecot/conf.d/10-auth.conf
/etc/dovecot/conf.d/10-director.conf
/etc/dovecot/conf.d/10-logging.conf
/etc/dovecot/conf.d/10-mail.conf
/etc/dovecot/conf.d/10-master.conf
/etc/dovecot/conf.d/10-ssl.conf
/etc/dovecot/conf.d/15-lda.conf
/etc/dovecot/conf.d/15-mailboxes.conf
/etc/dovecot/conf.d/20-imap.conf
/etc/dovecot/conf.d/20-lmtp.conf
/etc/dovecot/conf.d/20-pop3.conf
/etc/dovecot/conf.d/20-submission.conf
/etc/dovecot/conf.d/90-acl.conf
/etc/dovecot/conf.d/90-plugin.conf
/etc/dovecot/conf.d/90-quota.conf

I was thinking about doing something similar for chrony, but move that
to /usr/lib. Maybe I'm mixing different incompatible ideas.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vít Ondruch]

Dne 04. 08. 20 v 21:38 Michael Catanzaro napsal(a):
> On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy
>  wrote:
>> Should we go back to the old workaround for F33? Madness for one more
>> release? And then drop the madness once there's a dnf solution?
>
> We could, but we have installed so many other things that it's
> becoming quite hard to keep track of them all, and if we're going to
> have a workaround for any one package I would recommend we use the
> same workaround for them all. And that's the merge request I have
> above. And for that to work, we would need to require that anyone
> touching comps also add a corresponding Recommends: in fedora-release.
> That would be unfortunate.


Wouldn't it be better to replace this part of comps by soft
dependencies? I quite don't understand why we have not dropped comps (at
leas for the use case of installation basic OS) when we got soft
dependencies in RPM.

Admittedly, the soft dependencies would be repeatedly installed compared
to comps, but now you are asking DNF to actually install the content of
comps repetitively. So there won't be difference at the end.


Vít


>
> I'd rather have a proper dnf fix in place for F33.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vít Ondruch]

Dne 04. 08. 20 v 20:58 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 16:45, Vít Ondruch wrote:
>> I think the "don't use autoremove" is better suggestion ATM, because I
>> don't really want to keep earlyoom on the system in case there is
>> systemd-oomd or whatever should be the successor.
> You can always easily swap one package to another:
>
> sudo dnf swap earlyoom systemd-oomd --allowerasing
>

I know I can swap packages and what not, but primarily I want to keep my
system in "default" state, mostly following the changes Fedora
contributors are proposing. So if the proposal is to have earlyoom
installed by default, then it is surprising it might not be installed.
This situation should be fixed generally without me changing anything.
And that is the reason I bumped this thread.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Driverless scanning for WSD and ESCL supported scanners is coming

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 05 August 2020 at 07:44, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to announce sane-airscan project [1] will be shipped in the
> official Fedora repositories from Fedora 32 [2].
> 
> sane-airscan implements a backend for Microsoft WSD and ESCL (usually
> called AirScan, originating from Apple) protocols, which are common in
> newer (2012+) scanners and multi-function devices for scanning.
> 
> Using sane-airscan, newer devices don't need vendor proprietary software
> for scanning any longer (e.g. hplip with its hp-plugin).

This is great news, thanks to you and Alexander Pevzner for making it
happen. It makes me smile even if my current printer is not supported
and still requires hp-plugin.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reminder: upcoming Fedora 33 deadlines & milestones

[Florian Weimer]

* J. Scheurich:

> It lloks like boost.173 would require a future verson of gcc/g++

Why do you think that?

According to Boost upstream, anything later than GCC 8 is untested, but
I don't think this is actually true.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OCaml + binutils 2.35 on i386

[Florian Weimer]

* Richard W. M. Jones:

> On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote:
>> When ocamlopt is used with binutils 2.35 to link an executable, we now
>> get warnings that look like this:
>> 
>> /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only
>> section `.text'
>> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
>
> 32 bit is an architectural problem for OCaml.  Specifically because of
> how the GC block headers are implemented it limits arrays / strings to
> a maximum of 4M entries / 4M bytes, which was probably fine back in
> the day but is unreasonably small today. [1]

I don't see how this is related to text relocations.

The problem seems to be lack of PIE support in ocamlopt on i386, as
correctly identified by the warning.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Remote wipe options for Fedora?

[John M. Harris Jr]

On Tuesday, August 4, 2020 10:38:29 AM MST Chris Murphy wrote:
> On Tue, Aug 4, 2020 at 7:40 AM Martin Langhoff
>  wrote:
> 
> >
> >
> > Are there options for remote-wipe features for Fedora (or RHEL for that
> > matter)?
>
> >
> >
> > Ideally something integrated into the early boot process, as well as a
> > persistent service that is non-trivial to tamper with. It would naturally
> > need a network/internet based service as control point.
>
> >
> >
> > Googling and searching the mailing list has not turned any leads.
> >
> >
> >
> > It is a can of worms, naturally, and I am well aware of limitations, and
> > tricky tradeoffs in remote-wipe schemes. For some use cases, including
> > one affecting me, it can reduce attack surface. I am hoping that some
> > solutions exist, I would be happy to improve, package, integrate...
>
> >
> 
> 
> Such a thing doesn't currently exist. There are pieces here and there,
> that could be tied together, or used as references:
> 
> - livecd-tools and dracut have a reset boot parameter for the live
> read-write persistent overlay. We don't use such a thing in
> conventionally installed systems though.

Nothing in Fedora, except live systems, makes use of overlay filesystems.

> - Silverblue/rpm-ostree and Fedora Core OS based systems have
> 'rpm-ostree reset' to blow away overlays. I'm not sure if it currently
> has an option to blow away user home as well as /etc and /var. If not,
> it could be extended.
> 
> - Perhaps this is something either ignition (CoreOS installer) or
> systemd-repart could do? Possibly more the former than the latter,
> because systemd-repart use case is more about adding, not removing,
> and growing, not shrinking.
> 
> - If you were to use 'blkdiscard' on an entire partition or drive,
> doesn't mean the data is truly gone, i.e. data remanence. It might be
> easier and safer to secure such data with LUKS encryption, and have a
> way to wipe the key or keys.
> 
> - There's also the concept on Android, Windows, and macOS for
> "recovery" partitions and booting. These recovery partitions tend to
> be read-only boots, with limited tools and interface. This could be
> leveraged for multiple needs: recovery boot for doing volume rescue
> and repair; it could contain the installer, capable of doing a network
> (re)install; or it could even be a "seed" from which a new system is
> provisioned, and made whole by e.g. 'dnf group install'.
> 
> - Fedora has a "rescue" GRUB boot menu option. This is a "no
> host-only" initramfs. Currently it's never updated, i.e. it gets
> stale. For a while I've wanted us to remove this initramfs during
> release upgrades, so they get regenerated. At the least it'd be nice
> to make this more useful than it currently is.

There's really no reason to update that initramfs frequently, it's only used 
for recovery, and it has everything in needed to initialize devices for boot.


-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org