Re: TPM2 for disk encryption, clevis

Kevin Fenzi writes: > What does 'support for clevis' there look like? you mean just binding a > encrypted drive to look for clevis servers on boot? Yes, currently we only support the "tang" pin. > I think tpm2 might be good, but lots of machines don't have tpm2. > So I would think it would

Re: TPM2 for disk encryption, clevis

Richard Hughes writes: > On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote: >> As I understand it, there is a lot of evolving OS specific subtlety >> involved, so I am asking specifically how this would look on current >> Fedora and what to expect in the near future

TPM2 for disk encryption, clevis

Hi, we have some rudimentary support for Clevis in the Cockpit Web Console, and now the question is, should we add support for "tpm2" to that? As I understand it, there is a lot of evolving OS specific subtlety involved, so I am asking specifically how this would look on current Fedora and what

Re: Fedora should replace mailing lists with Discourse

Randy Barlow writes: > On Wed, 2018-10-17 at 13:14 -0400, Matthew Miller wrote: >> Discourse is *definitely* not a smooth, drop-in mailing list >> replacement >> like Hyperkitty is. > > I'm curious what is insufficient about Hyperkitty that Discourse does > well at. Badges, those are super

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

Neal Gompa writes: > And there's still the fun restriction of XFS not being able to shrink. But note that even ext4 can't shrink while being mounted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: AppStream and COPR (was: Splitting AppStream data into Workstation/Server)

Neal Gompa writes: > All PackageKit based software managers automatically download the > data, as the Dnf PK backend does this: > https://github.com/hughsie/PackageKit/blob/master/backends/dnf/pk-backend-dnf.c#L553 Ahh, thanks! "pkcon refresh force" indeed downloads it for

AppStream and COPR (was: Splitting AppStream data into Workstation/Server)

Neal Gompa writes: > [...] It's already kind of second-class in Fedora because it's not > properly integrated into our repodata (like it's supposed to be, and > how it is in openSUSE, Mageia, and even in COPR). > > We should be making AppStream data support first-class, not >

Re: Splitting AppStream data into Workstation/Server

Neal Gompa writes: > Implement your AppStream filter at the application level, rather than > messing with appstream-data package. Yes, of course. Cockpit will do the right thing even with the full appstream-data package. This is only about not having 15 MiB of useless data

Re: Splitting AppStream data into Workstation/Server

Neal Gompa writes: >> So, what about creating a dedicated appstream-data-server package that >> carries only those components that we want to see on a Server? >> >> Initially, it would contain only components of type "addon" that extend >> "cockpit.desktop", and components of

Splitting AppStream data into Workstation/Server

Hi, I hope that soon the first Cockpit add-on appears in the Fedora repositories. Cockpit can find such add-ons via their AppStream metainfo data, similar to how GNOME Software finds applications to install for a desktop environment. Thus, we would need to install the appstream-data package

Re: [modularity] Modules and AppStream

Stephen Gallagher writes: > That being said, the implementation is still under debate. Thanks for the clarification! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: [modularity] Modules and AppStream

Richard Hughes <hughsi...@gmail.com> writes: > On 24 August 2017 at 08:45, Marius Vollmer <marius.voll...@redhat.com> wrote: > >> One approach is just to put them all into the collection data: > > You can't have two components with the same ID inside a >

Re: [modularity] Modules and AppStream

Richard Hughes <hughsi...@gmail.com> writes: > On 23 August 2017 at 13:57, Marius Vollmer <marius.voll...@redhat.com> wrote: > >> I propose to keep AppStream metainfo data in packages, and map from >> package names to module names during construction of the c

Re: [modularity] Modules and AppStream

Owen Taylor writes: > The current expectation is that the only way that modules are going to > show up in GNOME Software is when they are safely wrapped up as a > Flatpak. Ah, that's nice. If we follow the same line for Cockpit, we would only show container images. This

Re: [modularity] Modules and AppStream

Richard Hughes <hughsi...@gmail.com> writes: > On 23 August 2017 at 13:57, Marius Vollmer <marius.voll...@redhat.com> wrote: > >> - Metainfo is in packages, but we need to be installing modules. > > How are we going to be installing modules in a modular-syst

[modularity] Modules and AppStream

Hi, what happens when the packages in a module contain AppStream metainfo files? In a non-modular repository, all these metainfo files get collected into a big AppStream collection file which is then used by GNOME Software (for example) to present interesting packages to the user in a nice way.