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
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.
>
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 t
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 impor
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 email to devel-le...@li
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 me.
> You can see th
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
> third-class. :(
Thi
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 installed.
I have n
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 type "service".
>
>
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 also
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 devel-le...@lists.fedoraproject.org
Richard Hughes writes:
> On 24 August 2017 at 08:45, Marius Vollmer 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
> group with the same origin.
Okay, that was my understanding o
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> I propose to keep AppStream metainfo data in packages, and map from
>> package names to module names during construction of the collection
>> data.
>
> Can you elaborate a bit? At th
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 would certainly simplif
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> - Metainfo is in packages, but we need to be installing modules.
>
> How are we going to be installing modules in a modular-system?
> PackageKit is only going to be able to install packages so
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.
16 matches
Mail list logo
