Re: Workaround for missing gpg keys in mock?
On Thu, 22 Aug 2019 at 22:43, Christopher wrote: > > On Thu, Aug 22, 2019 at 9:03 PM Nico Kadel-Garcia wrote: > > > > On Thu, Aug 22, 2019 at 7:57 PM Christopher > > wrote: > > > > > > I'm trying to do `fedpkg mock` to locally build some packages, and I > > > keep getting errors about GPG keys not found for f31/f32 packages. How > > > do I work around this? > > > > Disable gpg checks in /etc/mock/whatever.cfg ? > > Thanks. I went looking at /etc/mock/fedora-rawhide-x86_64.cfg to > figure out how to do that... and I found the problem. The file is > still configured as though f31 is rawhide. So, I simply replaced all > occurrences of "31" with "32", and "30" with "31". > This is fixed in the current version of mock-core-configs. It was just pushed to stable, so you should be able to update it soon. > And, then it worked fine. So, thanks for pointing me in the right > direction. The answer was really stupidly obvious once I knew where to > look. :) -- 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
[389-devel] 389 DS nightly 2019-08-23 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/23/report-389-ds-base-1.4.1.6-1.fc30.x86_64.html ___ 389-devel mailing list -- 389-de...@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-de...@lists.fedoraproject.org
Fedora-29-updates-20190823.0 compose check report
No missing expected images. Failed openQA tests: 1/2 (x86_64) ID: 434613 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/434613 Passed openQA tests: 1/2 (x86_64) -- 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
Re: Workaround for missing gpg keys in mock?
On Thu, Aug 22, 2019 at 9:03 PM Nico Kadel-Garcia wrote: > > On Thu, Aug 22, 2019 at 7:57 PM Christopher > wrote: > > > > I'm trying to do `fedpkg mock` to locally build some packages, and I > > keep getting errors about GPG keys not found for f31/f32 packages. How > > do I work around this? > > Disable gpg checks in /etc/mock/whatever.cfg ? Thanks. I went looking at /etc/mock/fedora-rawhide-x86_64.cfg to figure out how to do that... and I found the problem. The file is still configured as though f31 is rawhide. So, I simply replaced all occurrences of "31" with "32", and "30" with "31". And, then it worked fine. So, thanks for pointing me in the right direction. The answer was really stupidly obvious once I knew where to look. :) ___ 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: Workaround for missing gpg keys in mock?
On Thu, Aug 22, 2019 at 7:57 PM Christopher wrote: > > I'm trying to do `fedpkg mock` to locally build some packages, and I > keep getting errors about GPG keys not found for f31/f32 packages. How > do I work around this? Disable gpg checks in /etc/mock/whatever.cfg ? ___ 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
Workaround for missing gpg keys in mock?
I'm trying to do `fedpkg mock` to locally build some packages, and I keep getting errors about GPG keys not found for f31/f32 packages. How do I work around this? ___ 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: plan to orphan cassandra
On Thu, Aug 22, 2019, 15:19 Honza Horak wrote: > Cassandra has been originally packaged by folks in our team, in the time > we had some stakes there. Since then, priorities changed and also people > involved are not in our team any more. We tried to keep it packaged in > Fedora with reasonable effort, but turned to be too big burden recently > (depends on python2, missing java deps). > > From that reason, with sadness in my heart, I'd like to announce a plan > to orphan the cassandra package in Fedora. So, this is obviously a call > for everybody who would like to take it over -- let me know. There is > also an idea to build it as a module, which could help us with missing > deps, but that would be done later and does not change the plan for > orphaning. > Hi! I've been dealing with the broken Java stack in fedora a lot recently, and I'm curious why you think building Cassandra as a module would help in this case. Fabio > Cheers, > Honza > ___ > 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: systemd-243-rc2
Thanks, so it looks like virtio and xen pv block devices (vd* and xvd*) will stick with mq-deadline on Fedora. ___ 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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel
On Thu, Aug 22, 2019 at 6:59 PM Rex Dieter wrote: > > Rex Dieter wrote: > > > Rex Dieter wrote: > > > >> Miro Hrončok wrote: > >> > >>> I'm hit by the above error in rawhide. > >>> > >>> Is this expected or unexpected failure? > >> > >> Since all qtbase really needs is the egl headers (and not pkgconfig > >> specifically), I went ahead and changed the dependency from > >> pkgconfig(egl) > >> to > >> libEGL-devel > >> instead. > > > > And, now hitting *just* the libepoxy dep issue, filed related, > > https://bugzilla.redhat.com/show_bug.cgi?id=1744320 > > against libepoxy, where they could consider workaround by adjusting away > > from pkgconfig dep to explicit libEGL-devel > > I went ahead and made that change as threatened, > https://bugzilla.redhat.com/show_bug.cgi?id=1744320#c3 > > and libepoxy/qt5-qtbase related builds should be unblocked for the moment There's a mesa build almost done for rawhide now that re-adds egl.pc like what was done for the other one too. ___ 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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel
On 22. 08. 19 19:58, Rex Dieter wrote: Rex Dieter wrote: Rex Dieter wrote: Miro Hrončok wrote: I'm hit by the above error in rawhide. Is this expected or unexpected failure? Since all qtbase really needs is the egl headers (and not pkgconfig specifically), I went ahead and changed the dependency from pkgconfig(egl) to libEGL-devel instead. And, now hitting *just* the libepoxy dep issue, filed related, https://bugzilla.redhat.com/show_bug.cgi?id=1744320 against libepoxy, where they could consider workaround by adjusting away from pkgconfig dep to explicit libEGL-devel I went ahead and made that change as threatened, https://bugzilla.redhat.com/show_bug.cgi?id=1744320#c3 and libepoxy/qt5-qtbase related builds should be unblocked for the moment Thank You! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-243-rc2
On Thu, Aug 22, 2019 at 05:44:13PM -, zfnoc...@gmail.com wrote: > > - BFQ is used as the default scheduler for disks, mmc cards, etc. > Perhaps I am not seeing the right patch, but looking at what was posted on > github [1], doesn't this udev rule skip over eMMC and SD cards which appear > as "/dev/mmcblk#"? Yes, you're looking at the wrong patch. Setting BFQ is a downstream decision: https://src.fedoraproject.org/rpms/systemd/blob/d7b2d46533ca7c2a2b9092ff9ef0dae12cdb3ef2/f/464a73411c13596a130a7a8f0ac00ca728e5f69e.patch -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ 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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel
Rex Dieter wrote: > Rex Dieter wrote: > >> Miro Hrončok wrote: >> >>> I'm hit by the above error in rawhide. >>> >>> Is this expected or unexpected failure? >> >> Since all qtbase really needs is the egl headers (and not pkgconfig >> specifically), I went ahead and changed the dependency from >> pkgconfig(egl) >> to >> libEGL-devel >> instead. > > And, now hitting *just* the libepoxy dep issue, filed related, > https://bugzilla.redhat.com/show_bug.cgi?id=1744320 > against libepoxy, where they could consider workaround by adjusting away > from pkgconfig dep to explicit libEGL-devel I went ahead and made that change as threatened, https://bugzilla.redhat.com/show_bug.cgi?id=1744320#c3 and libepoxy/qt5-qtbase related builds should be unblocked for the moment -- Rex ___ 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: systemd-243-rc2
> - BFQ is used as the default scheduler for disks, mmc cards, etc. Perhaps I am not seeing the right patch, but looking at what was posted on github [1], doesn't this udev rule skip over eMMC and SD cards which appear as "/dev/mmcblk#"? Also from the github discussion, what was ultimately decided regarding the IO scheduler for virtual block devices? [1] https://github.com/systemd/systemd/pull/13321/commits/5ab4d083dbe0a1ae095875c4af6ac26749b67211 ___ 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-gpg-keys not updated yet again
On 8/21/19 9:27 AM, Dusty Mabe wrote: > > > On 8/19/19 6:59 AM, Pavel Raiskup wrote: >> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek >> wrote: >>> Can we *please* send out the FN+1 and FN+2 keys a month before branching, >>> to *all* releases of Fedora, so we can avoid this pointless scramble? >> >> What about to have F33 keys right now, when the fresh F31 branch is out? >> > > +1. Go ahead and make the f33 keys when we branch for f31. I don't see how this helps any. I agree we should push out the f33 keys before next branching, but why now? kevin 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: fedora-gpg-keys not updated yet again
On 8/21/19 3:24 AM, Vít Ondruch wrote:
> That is not completely true. The only possible way is to update the
> `fedora-gpg-keys` first without anything else and that was the reason
> for [1]. But since [1] did not landed in Fedora prior the branch, there
> is no way to update Rawhide and keep everything Rawhide and at the same
> time keep checking signatures all the time.
But you could upgrade to the f31 version and then to rawhide.
>
> IOW prior branch, I had installed fedora-repos-31-0.2 together with
> fedora-gpg-keys-31-0.2. As long as there was no F31 compose, there was
> available fedora-repos-32-0.2 together with fedora-gpg-keys-32-0.2 (or
> 0.1, it does not really matter), but those were not possible to install,
> because they are signed by F32 GPG key, which is not available on my
> system yet. The fedora-repos-31-0.5 is the first post branch package
> signed with the key on my system. This allows me to install
> fedora-gpg-keys-31-0.5 but at the same time it changes the configuration
> of /etc/yum.repos.d/fedora{,-rawhide}.repo making the system F31 instead
> of Rawhide. And this is wrong.
Wrong how? What do you want there? Most/many people want to folow the
branch, so thats what we have always done there.
In any event, hopefully soon we will have rawhide named rawhide and not
31 or 32 and with that you can indicate what you want to do much more
clearly.
>
> But it should be better next time, because [1] finally landed. It allows
> to update fedora-gpg-keys without updating fedora-repos. That means it
> should be possible to get the new Rawhide keys and then keep updating
> from Rawhide repository.
You can still update both and just change the repo configs the way you
want as well.
kevin
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: fedora-gpg-keys not updated yet again
On 8/21/19 2:50 AM, Petr Mensik wrote: > > I think f32 key should NOT be used until this is fully separated and > compose for older versions exist. Unless that key was leaked somehow, > there is no hurry, right? That hurry makes pain to many people without > justification for it, > I think. Well, sure, I suggested we might want to 'pause' rawhide composes until we have a branched next time, but that isn't great either because it means people wanting to work on rawhide also have to wait for it. > > There would always be mass rebuild in later stage of F32, no need to > switch key immediately. I think new key should not be enabled for > signing in new Rawhide until all supported versions have that key in > stable updates repo. That is not yet true now. Sure, and we could push the new fedora-repos update sooner. I don't disagree. > > I am thinking, is there written guidance how to switch signing key on a > branch? Are we prepared for emergency in case that key was leaked? We had to do this in fedora 9(?). Basically a new key was issued and everything was resigned with that key and the repo was fedora9-newkey. kevin 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: "ERROR: Could not find useradd in chroot" in COPR rawhide builds
On Thursday, 22 August 2019 17:37:06 CEST Marcin Zajaczkowski wrote:
> Hi. Probably I missed some announcement, but my doublecmd builds have
> started to fail a few days ago in rawhide with:
> > Complete!
> > Finish(bootstrap): dnf install
> > ERROR: Exception(/tmp/tmp5fbduv2b/doublecmd-gtk.spec)
> > Config(1015329-fedora-rawhide-x86_64) 0 minutes 57 seconds
INFO: Results
> > and/or logs in: /var/lib/copr-rpmbuild/results
> > INFO: Cleaning up build root ('cleanup_on_failure=True')
> > Start: clean chroot
> > INFO: unmounting tmpfs.
> > Finish: clean chroot
> > ERROR: Could not find useradd in chroot, maybe the install failed?
>
>
> https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-ra
> whide-x86_64/01015329-doublecmd-gtk/builder-live.log.gz
> https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/
>
> Do I need to add anything extra to my SPEC file, but there is some issue
> with the rawhide builds in COPR? My Fedora 29 and 30 builds work fine.
> Marcin
I filed a bug for this, it's fixed in GIT:
https://bugzilla.redhat.com/show_bug.cgi?id=1743843
You can disable use_bootstrap_container experimental feature for now until
this is released.
___
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: "ERROR: Could not find useradd in chroot" in COPR rawhide builds
On 22. 08. 19 17:37, Marcin Zajaczkowski wrote:
Hi. Probably I missed some announcement, but my doublecmd builds have started
to fail a few days ago in rawhide with:
Complete!
Finish(bootstrap): dnf install
ERROR: Exception(/tmp/tmp5fbduv2b/doublecmd-gtk.spec)
Config(1015329-fedora-rawhide-x86_64) 0 minutes 57 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
ERROR: Could not find useradd in chroot, maybe the install failed?
https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-rawhide-x86_64/01015329-doublecmd-gtk/builder-live.log.gz
https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/
This might be caused by https://bugzilla.redhat.com/show_bug.cgi?id=1740421
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
"ERROR: Could not find useradd in chroot" in COPR rawhide builds
Hi. Probably I missed some announcement, but my doublecmd builds have started
to fail a few days ago in rawhide with:
> Complete!
> Finish(bootstrap): dnf install
> ERROR: Exception(/tmp/tmp5fbduv2b/doublecmd-gtk.spec)
> Config(1015329-fedora-rawhide-x86_64) 0 minutes 57 seconds
> INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
> INFO: Cleaning up build root ('cleanup_on_failure=True')
> Start: clean chroot
> INFO: unmounting tmpfs.
> Finish: clean chroot
> ERROR: Could not find useradd in chroot, maybe the install failed?
https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-rawhide-x86_64/01015329-doublecmd-gtk/builder-live.log.gz
https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/
Do I need to add anything extra to my SPEC file, but there is some issue with
the rawhide builds in COPR? My Fedora 29 and 30 builds work fine.
Marcin
___
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: systemd-243-rc2
On Thu, Aug 22, 2019 at 02:09:03PM +0100, Tom Hughes wrote: > On 22/08/2019 13:10, Zbigniew Jędrzejewski-Szmek wrote: > > >- BFQ is used as the default scheduler for disks, mmc cards, etc. > > [https://bugzilla.redhat.com/show_bug.cgi?id=1738828] > > Looking at the patch you're applying it looks like NVME disks > are not currently included - was that deliberate? Yep. BFQ maintainer said: > The rule doesn't consider nvme devices either, but, in this respect, > I'd agree with testing this change with only single-queue devices > first. See https://github.com/systemd/systemd/pull/13321 for the full discussion. > I realise considerations may be different for SSDs but SATA SSDs > do seem to be included and the bug explicitly mentions it as being > suitable for SSDs. If this experiment gives positive results, we can easily extending the rule to cover more devices. Zbyszek ___ 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: Trying to reach FAS user brouhaha (Eric Smith)
I opened a ticket here: https://pagure.io/fesco/issue/2213 for my specific package. On 22 Aug 2019, at 8:29, Gabriel L. Somlo wrote: On Thu, Aug 22, 2019 at 07:44:29 -0500, tachokni...@gmail.com wrote: Hey all, subject line says it all. I’m trying to get in contact with Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the libbsd package. I’ve emailed him directly but haven’t heard back; does anyone know if he’s still active in the Fedora community? Same here, for icestorm: https://bugzilla.redhat.com/show_bug.cgi?id=1740871 and yosys: https://bugzilla.redhat.com/show_bug.cgi?id=1740872 Although, per the official unresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I'm still half a week too early to post to the fedora devel list... :) However, since it has come up, I figured I should join the thread. If anyone knows how I could get in touch with Eric regarding yosys and icestorm RPMs, I'd appreciate the pointer. Thanks much, --Gabriel ___ 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
Orphaning rubygem-{journey,rbovirt}
Hello, rubygem-journey - This package is dead upstream (actually it was subsumed into Ruby on Rails) and nothing depends on it in Fedora. rubygem-rbovirt - Nothing depends on this package in Fedora and I have no other use for it. 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
Fedora-31-20190822.n.0 compose check report
No missing expected images. Failed openQA tests: 13/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190820.n.4): ID: 434419 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/434419 Old failures (same test failed in Fedora-31-20190820.n.4): ID: 434391 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/434391 ID: 434395 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/434395 ID: 434397 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/434397 ID: 434411 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/434411 ID: 434422 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/434422 ID: 434426 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/434426 ID: 434428 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/434428 ID: 434430 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/434430 ID: 434455 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/434455 ID: 434461 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/434461 ID: 434480 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/434480 ID: 434485 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/434485 ID: 434509 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/434509 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190820.n.4): ID: 434492 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/434492 ID: 434493 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/434493 Passed openQA tests: 117/152 (x86_64) New passes (same test not passed in Fedora-31-20190820.n.4): ID: 434362 Test: x86_64 Server-dvd-iso release_identification URL: https://openqa.fedoraproject.org/tests/434362 Skipped non-gating openQA tests: 21 of 154 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 1 packages(s) removed since previous compose: fedora-repos-rawhide Previous test data: https://openqa.fedoraproject.org/tests/433928#downloads Current test data: https://openqa.fedoraproject.org/tests/434361#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 1 packages(s) removed since previous compose: fedora-repos-rawhide Previous test data: https://openqa.fedoraproject.org/tests/433930#downloads Current test data: https://openqa.fedoraproject.org/tests/434363#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used swap changed from 6 MiB to 0 MiB 1 packages(s) removed since previous compose: fedora-repos-rawhide 2 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service, pcscd.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 2.42 to 1.03 Average CPU usage changed from 48.88095238 to 22.4 Previous test data: https://openqa.fedoraproject.org/tests/433977#downloads Current test data: https://openqa.fedoraproject.org/tests/434410#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used swap changed from 5 MiB to 0 MiB 1 packages(s) removed since previous compose: fedora-repos-rawhide 1 services(s) removed since previous compose: pcscd.service System load changed from 1.20 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/433979#downloads Current test data: https://openqa.fedoraproject.org/tests/434412#downloads Installed system changes in test x86_64 universal install_package_set_minimal: 1 packages(s) removed since previous compose: fedora-repos-rawhide Previous test data: https://openqa.fedoraproject.org/tests/434005#downloads Current test data: https://openqa.fedoraproject.org/tests/434438#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used mem changed from 1047 MiB to 843 MiB Used swap changed from 7 MiB to 0 MiB 1 packages(s) removed since previous compose: fedora-repos-rawhide 1 services(s) added si
Re: Trying to reach FAS user brouhaha (Eric Smith)
On Thu, Aug 22, 2019 at 07:44:29 -0500, tachokni...@gmail.com wrote: > Hey all, subject line says it all. I’m trying to get in contact with > Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the > libbsd package. I’ve emailed him directly but haven’t heard back; > does anyone know if he’s still active in the Fedora community? Same here, for icestorm: https://bugzilla.redhat.com/show_bug.cgi?id=1740871 and yosys: https://bugzilla.redhat.com/show_bug.cgi?id=1740872 Although, per the official unresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I'm still half a week too early to post to the fedora devel list... :) However, since it has come up, I figured I should join the thread. If anyone knows how I could get in touch with Eric regarding yosys and icestorm RPMs, I'd appreciate the pointer. Thanks much, --Gabriel ___ 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
Orphaning rubygem-hike
Hello, This package is dead upstream and nothing depends on it in Fedora, therefore I am orphaning it. 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
Fedora 31 compose report: 20190822.n.0 changes
OLD: Fedora-31-20190820.n.4 NEW: Fedora-31-20190822.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 3 Dropped packages:11 Upgraded packages: 194 Downgraded packages: 0 Size of added packages: 132.21 KiB Size of dropped packages:1.67 MiB Size of upgraded packages: 2.68 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 380.73 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-31-20190822.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: python-lrparsing-1.0.16-2.fc31 Summary: Python library for constructing LR(1) parsers RPMs:python3-lrparsing Size:73.49 KiB Package: python-pystalk-0.5.1-2.fc31 Summary: Python client library for the beanstalkd work queue RPMs:python3-pystalk Size:23.22 KiB Package: taskopen-1.1.4-1.fc31 Summary: Script for taking notes and open urls with taskwarrior RPMs:taskopen Size:35.50 KiB = DROPPED PACKAGES = Package: atomic-devmode-0.3.7-8.fc31 Summary: Atomic Developer Mode RPMs:atomic-devmode Size:28.82 KiB Package: dvb-apps-1.1.2-19.1505.3d43b280298c.fc31 Summary: Utility, demo and test applications using the Linux DVB API RPMs:dvb-apps Size:1.16 MiB Package: python-cloudfiles-1.7.11-10.fc30 Summary: Python language bindings for Rackspace CloudFiles API RPMs:python2-cloudfiles Size:46.56 KiB Package: python-dictclient-1.0.1-23.fc31 Summary: Python client for DICT protocol RPMs:python2-dictclient Size:26.18 KiB Package: python-ipaddr-2.1.10-13.fc31 Summary: A python library for working with IP addresses, both IPv4 and IPv6 RPMs:python2-ipaddr Size:38.25 KiB Package: python-ntlm3-1.0.2-11.fc31 Summary: Python 3 compatible NTLM library RPMs:python3-ntlm3 Size:39.98 KiB Package: python-strainer-0.1.4-17.fc31 Summary: Tools to allow developers to cleanup web serialization objects RPMs:python2-strainer Size:53.92 KiB Package: python-velruse-1.1.1-13.fc31 Summary: Simplify third-party authentication for web applications RPMs:python2-velruse Size:72.70 KiB Package: python-weberror-0.13.1-10.fc30 Summary: Web Error handling and exception catching middleware RPMs:python2-weberror Size:115.77 KiB Package: python-wifi-0.5.0-21.fc31 Summary: Python binding for the wireless extensions RPMs:python2-wifi Size:61.93 KiB Package: pyttsx-1.0-16.fc31 Summary: Cross platform text-to-speech RPMs:pyttsx Size:37.70 KiB = UPGRADED PACKAGES = Package: GoldenCheetah-3.5-0.12.20190821git1d6d66f.fc31 Old package: GoldenCheetah-3.5-0.11.20190225gitd93404f.fc31 Summary: Cycling Performance Software RPMs: GoldenCheetah GoldenCheetah-data GoldenCheetah-doc Size: 44.43 MiB Size change: 381.05 KiB Changelog: * Wed Aug 21 2019 Martin Gansser - 3.5-0.12.20190821git1d6d66f - Update to 3.5-0.12.20190821git1d6d66f Package: accerciser-3.33.91-1.fc31 Old package: accerciser-3.33.4-1.fc31 Summary: Interactive Python accessibility explorer for the GNOME desktop RPMs: accerciser Size: 2.52 MiB Size change: 890 B Changelog: * Wed Aug 21 2019 Kalev Lember - 3.33.91-1 - Update to 3.33.91 Package: ack-3.0.3-1.fc31 Old package: ack-3.0.2-2.fc31 Summary: Grep-like text finder RPMs: ack Size: 76.19 KiB Size change: 116 B Changelog: * Wed Aug 21 2019 Robin Lee - 3.0.3-1 - Release 3.0.3 Package: apache-ivy-2.4.0-18.fc31 Old package: apache-ivy-2.4.0-17.fc31 Summary: Java-based dependency manager RPMs: apache-ivy apache-ivy-javadoc Size: 1.55 MiB Size change: -61.63 KiB Changelog: * Wed Aug 14 2019 Fabio Valentini - 2.4.0-18 - Disable ssh, bouncycastle, and vfs support. Package: arm-none-eabi-gcc-cs-1:9.2.0-1.fc31 Old package: arm-none-eabi-gcc-cs-1:7.4.0-2.fc31 Summary: GNU GCC for cross-compilation for arm-none-eabi target RPMs: arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++ Size: 981.10 MiB Size change: 319.18 MiB Changelog: * Wed Aug 21 2019 Michal Hlavinka - 1:9.2.0-1 - updated to 9.2.0 Package: avr-gcc-1:9.2.0-1.fc31 Old package: avr-gcc-1:7.4.0-6.fc31 Summary: Cross Compiling GNU GCC targeted at avr RPMs: avr-gcc avr-gcc-c++ Size: 134.59 MiB Size change: 13.99 MiB Changelog: * Wed Aug 21 2019 Michal Hlavinka - 1:9.2.0-1 - gcc updated to 9.2.0 Package: blis-0.6.0-3.fc31 Old package: blis-0.6.0-2.fc31 Summary: BLAS-like Library Instantiation Software Framework RPMs: blis blis-devel blis-openmp blis-openmp64 blis-serial64 blis-srpm-macros blis-threads blis-threads64 Size: 36.76 MiB Size change: 163.92 KiB Changelog: * Sat Aug 17 2019 Dave love - 0.6.0-3 - Patch out use of simd pragma - Use devtoolset-8, not -6 on el6/7 - Fix dblat3 test
plan to orphan cassandra
Cassandra has been originally packaged by folks in our team, in the time we had some stakes there. Since then, priorities changed and also people involved are not in our team any more. We tried to keep it packaged in Fedora with reasonable effort, but turned to be too big burden recently (depends on python2, missing java deps). From that reason, with sadness in my heart, I'd like to announce a plan to orphan the cassandra package in Fedora. So, this is obviously a call for everybody who would like to take it over -- let me know. There is also an idea to build it as a module, which could help us with missing deps, but that would be done later and does not change the plan for orphaning. Cheers, Honza ___ 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
Orphaning rubygem-audited.
Hi, Nothing in Fedora depends on rubygem-audited and I don't have any other use for this package, therefore I am orphaning it. 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
Drop "pki" Module?
Hi all, I filed a releng ticket about a week ago [0] but haven't heard back. Is there any action I can take myself to move this along? Thanks, Alex [0]: https://pagure.io/releng/issue/8637 ___ 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: systemd-243-rc2
On 22/08/2019 13:10, Zbigniew Jędrzejewski-Szmek wrote: - BFQ is used as the default scheduler for disks, mmc cards, etc. [https://bugzilla.redhat.com/show_bug.cgi?id=1738828] Looking at the patch you're applying it looks like NVME disks are not currently included - was that deliberate? I realise considerations may be different for SSDs but SATA SSDs do seem to be included and the bug explicitly mentions it as being suitable for SSDs. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
gstreamer-plugins-base revival
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs to get it building again is to disable the gtk-doc generation... I don't really want to own it, but I have dependent packages, so if no one else does, I will claim it. If you want it (or know of some reason it shouldn't be brought back), please speak up. Thanks, Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Trying to reach FAS user brouhaha (Eric Smith)
Hey all, subject line says it all. I’m trying to get in contact with Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the libbsd package. I’ve emailed him directly but haven’t heard back; does anyone know if he’s still active in the Fedora community? Thanks, Ron ___ 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
systemd-243-rc2
New release of systemd is now building in rawhide and branched. Two important changes: - The unified cgroup hierarchy (cgroupsv2) is now the default. Use systemd.unified-cgroup-hierarchy=0 on the kernel command line to undo this change. [https://fedoraproject.org/wiki/Changes/CGroupsV2] - BFQ is used as the default scheduler for disks, mmc cards, etc. [https://bugzilla.redhat.com/show_bug.cgi?id=1738828] There's a bunch of fixes too since -rc1, in particular in systemd-networkd. Enjoy! Zbyszek ___ 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: No longer supporting mailing lists:
On Thu, Aug 22, 2019 at 6:51 AM Florian Weimer wrote: > > Have you ever encountered the daily message limit? It seems to be quite > low, at 100. That alone seems to make mailing list mode useless. > > The daily message limit is a site controlled parameter. It can be changed by the administrator. https://meta.discourse.org/t/daily-limits-for-outgoing-mails-per-user/41458 ___ 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
ABRT configuration service removal
Hi all, ABRT currently provides a D-Bus daemon, abrt-configuration, for reading and changing the config files of ABRT and its plugins. It was introduced 6 years ago without much fanfare and its source code has not been touched since. The original use case seems to have been in machine provisioning, though a quick search through GitHub and reverse dependencies suggests that it's not used publicly in any piece of software. Hence, its removal from ABRT is currently being considered. Is anybody here using or aware of somebody else using the abrt-configuration daemon in their workflow? Kind regards, Matěj Grabovský ___ 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: No longer supporting mailing lists:
* John Harris: > RE: No longer supporting mailing lists: > This project literally cannot function without mailing lists. We do not > currently have a viable alternative. See all of the issues we've had trying > to > work with Mailing List mode on Discourse. It is not a complete feature, so we > (at least I) cannot recommend switching to it at this time. Have you ever encountered the daily message limit? It seems to be quite low, at 100. That alone seems to make mailing list mode useless. Anyway, I thought this is about switching to external hosting of mailing lists for those who need them, not banning them altogether. 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: Unable to install numpy with pip in python3.8
On Thu, Aug 22, 2019 07:53:19 +0200, Jos de Kloe wrote: > Hi, > > this seems to indicate that there is an incompatibility in how numpy > calls cython macros. > > On 8/22/19 12:38 AM, Ankur Sinha wrote: > > error: macro "__Pyx_PyCode_New" requires 16 arguments, but only 15 given > > Actually, there already is a bug report on cython here: > https://github.com/cython/cython/issues/2938 > discussing this incompatibility. > > It means that the c code needs to be regenerated from the numpy pyx > cython files before it will work, so you would need to use the latest > numpy version from git. > > This is also mentioned in this numpy issue 3 days ago: > https://github.com/numpy/numpy/issues/13927 > > Which states: > "Closing, in summary for python3.8 you must build from a git checkout > until we release official 3.8 wheels/tarballs." > > It won't work for pip builds yet. Ugh! Thanks for that Jos. I'll go build it from git. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]
On 22/08/2019 00:10, Chris Murphy wrote: > Anyway, the Fedora Workstation working group has this as an issue > being explored by a subgroup very soon, and make recommendations back > to the working group. So there will be a lot more discussion about > this in the near future. > https://pagure.io/fedora-workstation/issue/82 > https://meetbot.fedoraproject.org/fedora-meeting-2/2019-08-19/workstation.2019-08-19-13.01.html Hi, and while the subgroup of the group investigates ... Perhaps it would be a good idea to ask LUKS maintainers during the process, what do you think about the idea? :-) With the upstream maintainer hat on, there are several groups, that pushes very hard for TPM use, and others against it, for years already. (Just TPM1.2 is now obsolete, and most hw vendors pretend it never even existed.) This is Linux, there are so many possible use cases that the only strategy is to allow maintainers to configure it. If you see what is going upstream now, I am trying to prototype support for dynamic token handlers. (A LUKS2 token is an object that can be used to unlock LUKS keyslot using some external input - like TPM2). All this stuff can be completely disabled/compiled out, but also we can have TPM2 token handler installed by default - it depends on user/distro policy. You can use wrappers like Clevis/Tang, but there will also be a more straightforward solution to use TPM2 in LUKS2 in the near future. The initial idea behind LUKS is that it is a hw-independent solution, that's why we have very strong memory-hard password-based key derivation there for opening a keyslot. (If you have a decently strong passphrase, offline dictionary attack cost is very high, even if you have massive computation power.) If you enable an attacker to just unlock it using present hw, most of the parameters do not make sense anymore. It depends on the threat model, but let just expect stolen laptop that unlocks the disk automagically on that hw. And of course, we can use TPM with a PIN. Then our brave automation will try to use a cached passphrase (for example), and locks out TPM chip with exceeding number of PIN tries :) Also, the use of TPM2 can be very fragile. Seems that PCR registers changes are very different on different hw. Changing some BIOS option can cause that your system no longer boots, while on other hw it still works. So before you enable any such mechanisms, be very careful, you are opening a big can of worms. Milan p.s. Actually, there are also plans for much broader academic research for TPM2 behavior, and I would be more than happy if Fedora users could help us. Stay tuned ;-) ___ 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
