Re: I say thanks for another release (F32)
On Tue, 2020-04-28 at 15:58 +, sixpack13 wrote: > Hallo > > official Release statement isn't out yet, but I say thanks for > another > nice Fedora release to *all* people made F32 happen. Seconded. Thanks all for making this. BK ___ 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
python2-dns without DNSSEC support in rawhide
Hello. I'd like to switch python-dns crypto backend from pycryptodomex and ecdsa to python-cryptography. Upstream already did the same in master branch: https://github.com/rthalley/dnspython/pull/449 But, because python2-cryptography is not available in Fedora anymore, this change will disable DNSSEC functionality in python2-dns. There are only two packages depending on python2-dns: mailman and trac-spamfilter-plugin. I did a check and rebuild of both of them and it seems that they both work with the new version and there is no usage of DNSSEC in their codebases. COPR: https://copr.fedorainfracloud.org/coprs/lbalhar/dns/ PR: https://src.fedoraproject.org/rpms/python-dns/pull-request/5 If you think we should not merge the PR, let us know rather sooner than later. Have a nice day. Lumír ___ 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: bodhi: stuck updates
And thank you for taking care of 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: Block discard on more things
On Tue, Apr 28, 2020, at 6:51 PM, Chris Adams wrote: > Now that Fedora 32 has fstrim.timer enabled by default... how about > discards for the things that fstrim doesn't get? Two main things I know > of: > > - swap: Do discard at swapon time by setting "discard=once" in > /etc/fstab would be somewhat similar to the periodic fstrim call. I > don't know how much impact the "discard=pages" option might have (the > man page says it is asynchronous, but it might make low-memory > situations worse). > Seems reasonable. > - logical volumes: Set "issue_discards = 1" in /etc/lvm/lvm.conf so that > removed LVs get discarded. > Could foreclose data recovery in case LV was removed entirely, so I'd leave it to fstrim.timer on the eventual filesystem. 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: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 1:52 PM Simo Sorce wrote: > > On Tue, 2020-04-28 at 13:18 -0600, Chris Murphy wrote: > > Long term, many solutions need to be considered. And not only > > technical, but their impact on release engineering. > > What is the goal ? > > If the goal is just making it easy later, you could encrypt with a null > default passphrase that the system uses automatically and do not ask > the user. Upstream dmcrypt folks don't seem to like this. https://www.saout.de/pipermail/dm-crypt/2019-December/006290.html https://www.saout.de/pipermail/dm-crypt/2019-December/006295.html In that thread, there is a rejection of the very idea that (disk) encryption by default is a good or necessary thing. It unquestionably does add complexity, and therefore risk to user data. I suspect Anaconda folks won't want to support something upstream argues against, and doesn't officially support. There could be good reasons to go in a different direction than upstream advise, but there's probably a reasonably higher burden on advocates proposing such a plan. > > > Today's full disk encryption (except /boot) paradigm is long term > > untenable. The negatives are the sole reason why they're not used by > > default, even in a short term context. > > The fact something is not the default does not mean it is untenable. The default status isn't part of the suitability assessment. I assert it must be suitable to be a default, which does show my bias: defaults are often perceived by most users as either recommended or safe, and I try to assess defaults from that perspective. > > The working group's evaluation so far, shows that alternatives are > > only available in the long term. Hence the (re) evaluation of whether > > encryption by default is such a good thing, that it should be enabled > > by default for Fedora 33, despite the limitations of the current > > design. > > I do not see how you can enable full disk encryption by default unless > you accept that you are forcing user to use 2 passwords. > > If that is unacceptable (and it probably is) then it can't be a > default. Probably true. > > It's not decided whether system data should be encrypted by default, > > or made only opt in, and if so how to encrypt them. The working group > > is (perhaps painfully) aware that there are many options. > > Again it really depends on the threat model, if the evil made is the > issue, then, unless you have a signed integrity model you have to > encrypt the system as well. > > If the threat model is just stolen/lost laptop/disk then encrypting the > user data only would be sufficient. Right. And even if the long term goal is to account for Evil Maid, doesn't disqualify an implementation that only protects the stolen/lost laptop case. Building on prior advancements is acceptable, no different than with UEFI Secure Boot. > > The bootloader, kernel, initramfs, /usr definitely need to be trusted > > (implies a need for integrity and authenticity). > > You cannot trust /usr w/o integrity checks. > > > It's likely that /etc > > /var and ~/ need to be trusted. > > I guess you need to define what you mean with trust on second thought, > as I do not think I share the same definition with you. Trust is a continuum and it can be misplaced. So whether I trust a thing or not reflects more on me than the actual trustworthiness of the thing under discussion. That's maybe the best concise definition I can muster without verbose examples... Insofar as /usr: If it is encrypted (cryptsetup LUKS default) I trust that the confidentiality provided essentially makes it impossible for an attacker to inject malware - this loss of precision needed for such an attack by encryption gives it an illusory sense of integrity that it really doesn't have. Therefore I do not trust that it's free from either incidental corruption or a malicious attack on the ciphertext that could e.g. cause something to crash or result in weird behavior. If in addition to LUKS encryption, I were to add minimal integrity checking via dm-integrity or Btrfs CRC-32C for everything, I trust there's no incidental corruption; I'm not totally certain whether I can really trust there's been no malicious attack. I can't assess it, but suspect it depends on the particular attack (skill of the attacker) and versions of many things. Whereas if it were not encrypted, but employed either dm-verity, dm-integrity or Btrfs using hmac:sha256, I would trust the contents against either incidental or malicious attack - so long as I trust the HMAC hasn't escaped my control. As for /var and /etc, were they to be encrypted using fscrypt+ext4, I can trust only that detailed user usage data (that which exists in file extents) isn't being leaked. But the metadata isn't encrypted, so could some skilled attacker look at the unencrypted /etc /var metadata and infer that I use a VPN even if they can't acquire keys? I don't know, I can't assess it. I also can't assess the demarcation line of accept
ckermit?
There was a failed build of ckermit for F32 back in early February by releng [1], and I don't see any later attempts for F32. There is a successful build for ckermit for F33 from yesterday [2]. I'd like to request a rebuild for F32. Is it sufficient to request that here, or is there some other procedure that I should use? Also, I use ckermit daily as a terminal emulator, so if a co-maintainer is wanted, I'd be happy to volunteer - FAS ID stevenfalco. Steve [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1434605 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1498879 ___ 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
Block discard on more things
Now that Fedora 32 has fstrim.timer enabled by default... how about discards for the things that fstrim doesn't get? Two main things I know of: - swap: Do discard at swapon time by setting "discard=once" in /etc/fstab would be somewhat similar to the periodic fstrim call. I don't know how much impact the "discard=pages" option might have (the man page says it is asynchronous, but it might make low-memory situations worse). - logical volumes: Set "issue_discards = 1" in /etc/lvm/lvm.conf so that removed LVs get discarded. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (anaconda also affected)
On Tue, Apr 28, 2020 at 11:30:46PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 28 April 2020 at 22:15, Kevin Fenzi wrote: > [...] > > I'm a bit more concerned with keybinder3. That's needed by blueberry > > which we use in the Xfce spin. > > I care about blueberry as well, even though I use MATE. > > > Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership > > too? > > > > I guess I can take it if no one else wants to... > > ... but I really wouldn't like to take on another package, I have too > much on my plate maintaining what I have already. ok. I went ahead and took it. Co-maintainers welcome 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: Feedback on default partitioning and encryption
On Tue, 2020-04-28 at 16:23 -0500, Michael Catanzaro wrote: > On Tue, Apr 28, 2020 at 1:18 pm, Chris Murphy > wrote: > > This is the dilemma. It necessarily needs a single schema, there is > > only one default. Customizations aren't going away. > > We're not trying to come up with something that works perfectly for > everyone. We're just trying to come up with a default that works > reasonably well for most users. That means: > > * Only one password prompt > * Password prompt must support ibus and normal expected range of > languages (i.e. not be done in plymouth), because not all the world > uses Latin alphabets > * Optimize for single-user systems, but don't break multi-user either > > Regarding the use cases: "shared workstation vs personal desktop vs > personal laptop vs corporate laptop," we support all of the above. We > want to optimize for personal desktop, personal laptop, and corporate > laptop, not for shared workstation. We still need shared workstation > and multiuser laptop to *work*, though, but it's OK if it's not quite > as secure. > > That said, the installer cannot know whether additional user accounts > will be created in the future, so the installer does not know which > use-case it's installing for. ;) And people can change use over time. I do not see an easy way out here anyway, good luck! Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 03:51:57PM -0400, Simo Sorce wrote:
> If the threat model is just stolen/lost laptop/disk then encrypting the
> user data only would be sufficient.
Strictly speaking I'd say /etc/shadow, /var/lib/{pgsql,mysql}/,
/etc/sysconfig/network-scripts/ and /etc/NetworkManager/ are
also quite likely to contain user data - the first as a
bruteforce-target, the second as these are quite often installed on dev
machines (in my experience), and the others as they often contain
passwords in plaintext, which may be even more critical as the actual
user data.
I'd say there is no way around full disk encryption, maybe lifting the
hard restriction on not having double encryption might be an option, but
I don't have any performance data on that.
All the best,
David
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: Orphaned packages looking for new maintainers (anaconda also affected)
On Tuesday, 28 April 2020 at 22:15, Kevin Fenzi wrote: [...] > I'm a bit more concerned with keybinder3. That's needed by blueberry > which we use in the Xfce spin. I care about blueberry as well, even though I use MATE. > Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership > too? > > I guess I can take it if no one else wants to... ... but I really wouldn't like to take on another package, I have too much on my plate maintaining what I have already. 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: Fedora 32 is available now!
On Tue, Apr 28, 2020 at 1:54 pm, Alan wrote: How do I switch desktops from gdm? switchdesk does not seem to work and the control on the login screen seems to have gone away. It's moved to the bottom-right corner of the login screen now. ___ 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: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 1:18 pm, Chris Murphy wrote: This is the dilemma. It necessarily needs a single schema, there is only one default. Customizations aren't going away. We're not trying to come up with something that works perfectly for everyone. We're just trying to come up with a default that works reasonably well for most users. That means: * Only one password prompt * Password prompt must support ibus and normal expected range of languages (i.e. not be done in plymouth), because not all the world uses Latin alphabets * Optimize for single-user systems, but don't break multi-user either Regarding the use cases: "shared workstation vs personal desktop vs personal laptop vs corporate laptop," we support all of the above. We want to optimize for personal desktop, personal laptop, and corporate laptop, not for shared workstation. We still need shared workstation and multiuser laptop to *work*, though, but it's OK if it's not quite as secure. That said, the installer cannot know whether additional user accounts will be created in the future, so the installer does not know which use-case it's installing for. ;) ___ 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: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 12:36:22PM -0400, Simo Sorce wrote: > So in the end I do not believe you can come up with a single schema for > "workstation" unless you narrow down the scope of workstation to a > smaller set of use cases to the exclusion of the others. I think it's okay to do just that. We have other offerings for other use-cases (like the media server you mentioned). -- Matthew Miller Fedora Project Leader ___ 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 is available now!
On Tue, 2020-04-28 at 09:55 -0400, Matthew Miller wrote: > It’s here! We’re proud to announce the release of Fedora 32. > Thanks to the hard work of thousands of Fedora community > members and contributors, we’re celebrating yet another > on-time release! > > Read the official announcement at: > > * https://fedoramagazine.org/announcing-fedora-32/ > > or just go ahead and grab it from: > > * https://getfedora.org/ > So far it looks very nice. Only one issue... How do I switch desktops from gdm? switchdesk does not seem to work and the control on the login screen seems to have gone away. ___ 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: Orphaned packages looking for new maintainers (anaconda also affected)
On Tue, Apr 28, 2020 at 08:01:31AM +0200, Dan Čermák wrote: > Sérgio Basto writes: > > > On Mon, 2020-04-27 at 12:39 +0200, Miro Hrončok wrote: > >> GConf2 > > > > GConf2 is orphan, why ? no maintainers or a task force to be removed ? > > GConf2 has been deprecated for well over a decade and afaik unmaintained > for nearly half a decade. Thus: please just remove it from your > dependencies and use gsettings instead (the upstream replacement). > > Many packages might actually not require it at all: emacs was pulling it > in, but it works just fine without it and with gsettings instead. Yeah, I am happy to let GConf2 go into the night... thunar-vfs depends on it, but thats just the old vfs layer Thunar used to use kept around for compatibility. It should go also. I'm a bit more concerned with keybinder3. That's needed by blueberry which we use in the Xfce spin. Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership too? I guess I can take it if no one else wants to... 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
Fedora 33 System-Wide Change proposal: Boost 1.73 upgrade
https://fedoraproject.org/wiki/Changes/F33Boost173 == Summary == This change brings Boost 1.73 to Fedora. This will mean Fedora ships with a recent upstream Boost release. == Owner == * Name: [[User:jwakely| Jonathan Wakely]] * Email: jwak...@redhat.com == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is one of explicit Boost non-goals, this entails rebuilding of all dependent packages. This has also always entailed yours truly assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. Such care is to be expected this time around as well. The equivalent changes for previous releases were [[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora 28 Change]], [[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora 25 Change]], [[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23 Change]] and [[Changes/F22Boost158|Fedora 22 Change]]. == Benefit to Fedora == Fedora 32 includes Boost 1.69 which is the same version as F31 and F30, and is several releases behind the latest upstream release (Boost 1.73 is due for release late April 2020). Fedora will stay relevant, as far as Boost clients are concerned. Boost 1.73 brings four new components: * [https://www.boost.org/libs/outcome/ Boost.Outcome], A set of tools for reporting and handling function failures in contexts where directly using C++ exception handling is unsuitable, from Niall Douglas. * [https://www.boost.org/libs/histogram/ Boost.Histogram], Fast and extensible multi-dimensional histograms with convenient interface for C++14, from Hans Dembinski. * [https://www.boost.org/libs/variant2/ Boost.Variant2], A never-valueless, strong guarantee implementation of std::variant, from Peter Dimov. * [https://www.boost.org/libs/nowide/ Boost.Nowide], Standard library functions with UTF-8 API on Windows, from Artyom Beilis. * [https://www.boost.org/libs/static_string/ Boost.StaticString], A dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage, from Vinnie Falco and Krystian Stasiowski. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f33-boost" [ https://docs.pagure.org/releng/sop_adding_side_build_targets.html build system tag] ([ http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html discussion]): TODO ** Build boost into that tag (take a look at the [ http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493] for inspiration) ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: ** Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. ** The existing `boost-nowide` package will need to be retired, as it is now included in the upstream Boost release. * Release engineering: [https://pagure.io/releng/issue/9421 #9421] (a check of an impact with Release Engineering is needed) * Policies and guidelines: ** Apart from scope, this is business as usual, so no new policies, no new guidelines. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * The `boost-jam` package has been replaced by `boost-b2`. The separate `boost-nowide` package will be replace by a subpackage of `boost`. * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. Historically this hasn't been too much of a problem and could always be resolved before deadline. == How To Test == * No special hardware is needed. * Integration testing simply consists of installing Boost packages (`dnf install boost`) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients). == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new Boost packages, and may need to adjust their code if the new Boost release is not source-compatible. * Developers using `bjam` to build their own software will need to switch to using the new name for the tool, `b2` == Dependencies == Packages that must be rebuilt: $ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u All clients: $ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source == Contingency Plan == * Contin
Re: Feedback on default partitioning and encryption
On Tue, 2020-04-28 at 13:18 -0600, Chris Murphy wrote: > On Tue, Apr 28, 2020 at 10:37 AM Simo Sorce wrote: > > I have a hard time commenting over the next 2 becuse it seem like the > > probelm is not just technical, but there is no clear vision of whether > > there is one and only one solution or if multiple solutions need to be > > considered. > > The short term is necessarily limited to the existing functionality of > the installer. Shall "encrypt my data" be enabled by default or not? > Seems like a good idea, but there are knock on effects that have > various deleterious effects. Is it worth enabling only in the short > term? Or should it be left as is, and focus on the long term design > and planning? > > There are few examples of encryption enabled by default in the desktop > world. Presently, that seems to be only Pop!_OS. > > On mobile devices this is more common. But even more common than > encryption is trustworthiness (integrity and authenticity of the > image; and statelessness, with the option to do a reset). > > Long term, many solutions need to be considered. And not only > technical, but their impact on release engineering. What is the goal ? If the goal is just making it easy later, you could encrypt with a null default passphrase that the system uses automatically and do not ask the user. > > I personally prefer to encrypt the whole disk, because the machine I > > care for encrypting is a laptop that can potentially be > > stolen/displaced easily. However I do not care at all that there are > > two different step (encryption password and separate account password), > > and in fact I prefer to keep them separate because I join the laptop to > > a separate IDM system so the account password is not managed by the > > laptop. > > Custom ways of account management aren't going away. The scope of this > topic is: Fedora Workstation defaults. It just informs that the default depends on the environment, there is a big difference on what the reasonable defaults are depending on use: shared workstation vs personal desktop vs personal laptop vs corporate laptop, etc... > Today's full disk encryption (except /boot) paradigm is long term > untenable. The negatives are the sole reason why they're not used by > default, even in a short term context. The fact something is not the default does not mean it is untenable. > The working group's evaluation so far, shows that alternatives are > only available in the long term. Hence the (re) evaluation of whether > encryption by default is such a good thing, that it should be enabled > by default for Fedora 33, despite the limitations of the current > design. I do not see how you can enable full disk encryption by default unless you accept that you are forcing user to use 2 passwords. If that is unacceptable (and it probably is) then it can't be a default. > > I would love to have TPM integration, but just using TPM is useless for > > my use case, because if they steal my laptop they also get my TPM > > chip. TPM is cool only as an additional component but alone it is > > somewhat useless. If clevis is used then you can compose the TPM *and* > > a passphrase (or other item like a tang server or a phone/bluetooth > > beacon). > > TPM is in the long term category. Support for it in dmcrypt/cryptsetup > doesn't have an ETA. There's other integration work needed too. And I > don't think it's seriously considered for protecting user data, for > the reason you mention. Rather, it's considered for encrypting system > data. > > It's not decided whether system data should be encrypted by default, > or made only opt in, and if so how to encrypt them. The working group > is (perhaps painfully) aware that there are many options. Again it really depends on the threat model, if the evil made is the issue, then, unless you have a signed integrity model you have to encrypt the system as well. If the threat model is just stolen/lost laptop/disk then encrypting the user data only would be sufficient. > The bootloader, kernel, initramfs, /usr definitely need to be trusted > (implies a need for integrity and authenticity). You cannot trust /usr w/o integrity checks. > It's likely that /etc > /var and ~/ need to be trusted. I guess you need to define what you mean with trust on second thought, as I do not think I share the same definition with you. > The bootloader, kernel, initramfs, and > /usr definitely do not need to be private, though it doesn't hurt to > do so, there's nothing secret about them. Whereas ~/ definitely needs > an option to be encrypted, possibly by default. Whether something is confidential or not is a matter of threat model again. But I do agree that in the common case you might consider "distribution provided"-binaries as non-confidential and be left only integrity but not confidentiality protected. > Depending on whether and how /home or each ~/ are encrypted, there are > considerations like user flatpaks and possible duplica
Re: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 10:37 AM Simo Sorce wrote: > > I have a hard time commenting over the next 2 becuse it seem like the > probelm is not just technical, but there is no clear vision of whether > there is one and only one solution or if multiple solutions need to be > considered. The short term is necessarily limited to the existing functionality of the installer. Shall "encrypt my data" be enabled by default or not? Seems like a good idea, but there are knock on effects that have various deleterious effects. Is it worth enabling only in the short term? Or should it be left as is, and focus on the long term design and planning? There are few examples of encryption enabled by default in the desktop world. Presently, that seems to be only Pop!_OS. On mobile devices this is more common. But even more common than encryption is trustworthiness (integrity and authenticity of the image; and statelessness, with the option to do a reset). Long term, many solutions need to be considered. And not only technical, but their impact on release engineering. > I personally prefer to encrypt the whole disk, because the machine I > care for encrypting is a laptop that can potentially be > stolen/displaced easily. However I do not care at all that there are > two different step (encryption password and separate account password), > and in fact I prefer to keep them separate because I join the laptop to > a separate IDM system so the account password is not managed by the > laptop. Custom ways of account management aren't going away. The scope of this topic is: Fedora Workstation defaults. Today's full disk encryption (except /boot) paradigm is long term untenable. The negatives are the sole reason why they're not used by default, even in a short term context. The working group's evaluation so far, shows that alternatives are only available in the long term. Hence the (re) evaluation of whether encryption by default is such a good thing, that it should be enabled by default for Fedora 33, despite the limitations of the current design. > I would love to have TPM integration, but just using TPM is useless for > my use case, because if they steal my laptop they also get my TPM > chip. TPM is cool only as an additional component but alone it is > somewhat useless. If clevis is used then you can compose the TPM *and* > a passphrase (or other item like a tang server or a phone/bluetooth > beacon). TPM is in the long term category. Support for it in dmcrypt/cryptsetup doesn't have an ETA. There's other integration work needed too. And I don't think it's seriously considered for protecting user data, for the reason you mention. Rather, it's considered for encrypting system data. It's not decided whether system data should be encrypted by default, or made only opt in, and if so how to encrypt them. The working group is (perhaps painfully) aware that there are many options. The bootloader, kernel, initramfs, /usr definitely need to be trusted (implies a need for integrity and authenticity). It's likely that /etc /var and ~/ need to be trusted. The bootloader, kernel, initramfs, and /usr definitely do not need to be private, though it doesn't hurt to do so, there's nothing secret about them. Whereas ~/ definitely needs an option to be encrypted, possibly by default. Depending on whether and how /home or each ~/ are encrypted, there are considerations like user flatpaks and possible duplication and excessive space consumption. If they are LUKS-on-loop files as systemd-homed proposes, there are file system resize considerations when additional users are added, or when users later added actually have more space requirements. This is substantially more secure than fscrypt+ext4, but is fscrypt adequate for Workstation users by default? The performance impact of LUKS-on-loop files is negligible. I'm not certain about fscrypt's impact. But these are also further considerations. > > So in the end I do not believe you can come up with a single schema for > "workstation" unless you narrow down the scope of workstation to a > smaller set of use cases to the exclusion of the others. This is the dilemma. It necessarily needs a single schema, there is only one default. Customizations aren't going away. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 is available now!
On Tue, 28 Apr 2020 at 16:08, Matthew Miller wrote: > > It’s here! We’re proud to announce the release of Fedora 32. > Thanks to the hard work of thousands of Fedora community > members and contributors, we’re celebrating yet another > on-time release! > > Read the official announcement at: > > * https://fedoramagazine.org/announcing-fedora-32/ Awesome! > > or just go ahead and grab it from: > > * https://getfedora.org/ > > -- > Matthew Miller > > Fedora Project Leader > ___ > announce mailing list -- annou...@lists.fedoraproject.org > To unsubscribe send an email to announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org > ___ > announce mailing list -- annou...@lists.fedoraproject.org > To unsubscribe send an email to announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ 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: bodhi: stuck updates
On Tue, 28 Apr 2020 at 18:41, Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > Hi, > > Almost a week ago, I built cmpfit and fityk in side tags on F31, F32 > and F33. While the builds for F33 moved directly to stable - as > expected - the other two got stuck for 4 days. I noticed that I could > push them manually to testing, which I did a little over two days ago, > but they seem to be stuck again, transitioning from pending to > testing. Updates for other packages I built around the same time and > later are already in testing. These are the updates in question: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ee22c621f > https://bodhi.fedoraproject.org/updates/FEDORA-2020-cc2ae07056 > Some help? > Hi, It looks like Bodhi thinks that the builds were not signed so the update is not going to be pushed. It looks that there is a bug there since the builds are correctly tagged in koji. I will manually fix these update and file a bug upstream so we can look a fixing this. Thanks for reporting the problem. > > Best regards > ___ > 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
Fedora rawhide compose report: 20200428.n.0 changes
OLD: Fedora-Rawhide-20200426.n.1 NEW: Fedora-Rawhide-20200428.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 6 Dropped packages:0 Upgraded packages: 93 Downgraded packages: 0 Size of added packages: 4.83 MiB Size of dropped packages:0 B Size of upgraded packages: 1.95 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 76.24 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200426.n.1.x86_64.vagrant-virtualbox.box Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200426.n.1.x86_64.vagrant-libvirt.box = ADDED PACKAGES = Package: create-fake-rpm-2-1.fc33 Summary: Generate fake (S)RPM RPMs:create-fake-rpm Size:17.55 KiB Package: mingw-biblesync-2.0.1-2.fc33 Summary: A Cross-platform library for sharing Bible navigation RPMs:mingw32-biblesync mingw64-biblesync Size:95.37 KiB Package: python-jsonfield-3.1.0-1.fc33 Summary: A reusable Django field that allows you to store validated JSON in your model RPMs:python3-jsonfield Size:20.36 KiB Package: python-jsonrpc-server-0.3.4-3.fc33 Summary: JSON RPC 2.0 server library RPMs:python3-jsonrpc-server Size:23.50 KiB Package: python-spyking-circus-0.9.7-1.fc33 Summary: Fast and scalable spike sorting of large-scale extracellular recordings RPMs:python-spyking-circus-doc python3-spyking-circus Size:4.00 MiB Package: zswap-cli-0.4.1-1.fc33 Summary: Command-line tool to control zswap options RPMs:zswap-cli Size:691.29 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Add64-3.9.0-1.fc33 Old package: Add64-1.2.2-19.fc32 Summary: An additive synthesizer using JACK RPMs: Add64 Size: 783.16 KiB Size change: 201.65 KiB Changelog: * Sun Apr 26 2020 Erich Eickmeyer - 3.9.0-1 - New version 3.9.0 Package: R-git2r-0.26.1-5.fc33 Old package: R-git2r-0.26.1-4.fc32 Summary: Provides Access to Git Repositories RPMs: R-git2r Size: 2.21 MiB Size change: -1.92 KiB Changelog: * Mon Apr 27 2020 Igor Raits - 0.26.1-5 - Rebuild against libgit2 1.x Package: RBTools-1.0.3-1.fc33 Old package: RBTools-1.0.2-6.fc32 Summary: Tools for use with ReviewBoard RPMs: RBTools Size: 354.02 KiB Size change: 10.66 KiB Changelog: * Mon Apr 27 2020 Stephen Gallagher - 1.0.3-1 - Update to RBTools 1.0.3 - https://www.reviewboard.org/docs/releasenotes/rbtools/1.0.3/ Package: ansible-freeipa-0.1.10-1.fc33 Old package: ansible-freeipa-0.1.9-1.fc33 Summary: Roles and playbooks to deploy FreeIPA servers, replicas and clients RPMs: ansible-freeipa Size: 188.92 KiB Size change: 9.58 KiB Changelog: * Mon Apr 27 2020 Thomas Woerner - 0.1.10-1 - Update to version 0.1.10 with fixes and additional modules https://github.com/freeipa/ansible-freeipa/releases/tag/v0.1.10 Package: ckermit-9.0.302-22.fc33 Old package: ckermit-9.0.302-20.fc31 Summary: The quintessential all-purpose communications program RPMs: ckermit Size: 5.75 MiB Size change: 154.42 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 9.0.302-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Mon Apr 27 2020 David Cantrell - 9.0.302-22 - Drop BR libtermcap-devel (#1799227) Package: cpuid-20200427-1.fc33 Old package: cpuid-20200211-1.fc33 Summary: Dumps information about the CPU(s) RPMs: cpuid Size: 128.02 KiB Size change: 830 B Changelog: * Mon Apr 27 2020 Fabian Affolter - 20200427-1 - Update to new upstream version 20200427 (rhbz#1828251) Package: cvc4-1.7-9.fc33 Old package: cvc4-1.7-8.fc32 Summary: Automatic theorem prover for SMT problems RPMs: cvc4 cvc4-devel cvc4-java cvc4-libs cvc4-python3 Size: 41.93 MiB Size change: -1.74 MiB Changelog: * Sat Apr 25 2020 Jerry James - 1.7-9 - Rebuild for cryptominisat 5.7.0 - Add -cryptominisat patch to adapt to changes in 5.7.0 Package: domoticz-2020.2-2.fc33 Old package: domoticz-2020.1-2.fc33 Summary: Open source Home Automation System RPMs: domoticz Size: 46.17 MiB Size change: 267.98 KiB Changelog: * Mon Apr 27 2020 Michael Cronenworth - 2020.2-1 - New stable release * Mon Apr 27 2020 Michael Cronenworth - 2020.2-2 - Link against older minizip Package: dummy-test-package-crested-0-324.fc33 Old package: dummy-test-package-crested-0-308.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 28.87 KiB Size change: 914 B Changelog: * Sun Apr 26 2020 packagerbot - 0-309 - rebuilt * Sun Apr 26 2020 packagerbot - 0-310
bodhi: stuck updates
Hi, Almost a week ago, I built cmpfit and fityk in side tags on F31, F32 and F33. While the builds for F33 moved directly to stable - as expected - the other two got stuck for 4 days. I noticed that I could push them manually to testing, which I did a little over two days ago, but they seem to be stuck again, transitioning from pending to testing. Updates for other packages I built around the same time and later are already in testing. These are the updates in question: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ee22c621f https://bodhi.fedoraproject.org/updates/FEDORA-2020-cc2ae07056 Some help? Best regards ___ 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: Feedback on default partitioning and encryption
On Tue, 2020-04-28 at 10:18 -0500, Michael Catanzaro wrote: > Hi, > > The Workstation Working Group would like to solicit feedback on three > outstanding Workstation issues: > > * fedora-workstation#54, "Default disk partitioning layout for > Workstation" [1][2] > * fedora-workstation#82, "encryption of user data (excludes system)" > [3][4] > * fedora-workstation#136, "encryption of system data (excludes user)" > [5][6] > > We've been brainstorming on these issues for quite a while, and are > wondering if a wider audience might be able to help us decide what to > do. These are long threads, so I've posted summary comments [2][4][6] > in an attempt to summarize what I see as the most important points of > the previous discussion, but there's a lot of previous discussion and > it would be ideal to read or at least skim as much as possible to get a > feeling for what's already been considered before responding. I > encourage replies in the issues themselves, rather than on-list, to > keep discussion in one place. (An impossible expectation, I know) > > Michael > > [1] https://pagure.io/fedora-workstation/issue/54 > [2] https://pagure.io/fedora-workstation/issue/54#comment-644749 > [2] https://pagure.io/fedora-workstation/issue/82 > [4] https://pagure.io/fedora-workstation/issue/82#comment-644750 > [5] https://pagure.io/fedora-workstation/issue/136 > [6] https://pagure.io/fedora-workstation/issue/136#comment-644752 I commented on the first because I have direct experience over time. I have a hard time commenting over the next 2 becuse it seem like the probelm is not just technical, but there is no clear vision of whether there is one and only one solution or if multiple solutions need to be considered. I personally prefer to encrypt the whole disk, because the machine I care for encrypting is a laptop that can potentially be stolen/displaced easily. However I do not care at all that there are two different step (encryption password and separate account password), and in fact I prefer to keep them separate because I join the laptop to a separate IDM system so the account password is not managed by the laptop. I would love to have TPM integration, but just using TPM is useless for my use case, because if they steal my laptop they also get my TPM chip. TPM is cool only as an additional component but alone it is somewhat useless. If clevis is used then you can compose the TPM *and* a passphrase (or other item like a tang server or a phone/bluetooth beacon). That said, I am pretty sure there are cases of shared environment (say media station at home) where users may like encryption but definitely do not want to use 2 passwords. In that case using integrity to protect read-only partitions and encryption only on personal homes makes a lot more sense. So in the end I do not believe you can come up with a single schema for "workstation" unless you narrow down the scope of workstation to a smaller set of use cases to the exclusion of the others. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
I say thanks for another release (F32)
Hallo official Release statement isn't out yet, but I say thanks for another nice Fedora release to *all* people made F32 happen. Running F32 since beta was released without bugs on an pure Intel box. - some very minor though, but ... - nice ! stay healthy -- sixpack13 ___ 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-IoT-32-20200428.2 compose check report
No missing expected images. Failed openQA tests: 2/8 (x86_64) Old failures (same test failed in Fedora-IoT-32-20200428.0): ID: 588540 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/588540 ID: 588541 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/588541 Skipped non-gating openQA tests: 6 of 8 -- 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
Feedback on default partitioning and encryption
Hi, The Workstation Working Group would like to solicit feedback on three outstanding Workstation issues: * fedora-workstation#54, "Default disk partitioning layout for Workstation" [1][2] * fedora-workstation#82, "encryption of user data (excludes system)" [3][4] * fedora-workstation#136, "encryption of system data (excludes user)" [5][6] We've been brainstorming on these issues for quite a while, and are wondering if a wider audience might be able to help us decide what to do. These are long threads, so I've posted summary comments [2][4][6] in an attempt to summarize what I see as the most important points of the previous discussion, but there's a lot of previous discussion and it would be ideal to read or at least skim as much as possible to get a feeling for what's already been considered before responding. I encourage replies in the issues themselves, rather than on-list, to keep discussion in one place. (An impossible expectation, I know) Michael [1] https://pagure.io/fedora-workstation/issue/54 [2] https://pagure.io/fedora-workstation/issue/54#comment-644749 [2] https://pagure.io/fedora-workstation/issue/82 [4] https://pagure.io/fedora-workstation/issue/82#comment-644750 [5] https://pagure.io/fedora-workstation/issue/136 [6] https://pagure.io/fedora-workstation/issue/136#comment-644752 ___ 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 is available now!
On Tue, Apr 28, 2020 at 11:10 AM wrote: > > I noticed Jam is missing from the labs even though the ISO built and > everything was fine for the beta. Is this an oversight? > > I already replied privately, but for public reference, this is an oversight. I'll get it fixed shortly: https://pagure.io/fedora-websites/issue/1031 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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 is available now!
Hi Matthew, > From: Matthew Miller > > It’s here! We’re proud to announce the release of Fedora 32. > Thanks to the hard work of thousands of Fedora community members and > contributors, we’re celebrating yet another on-time release! > > Read the official announcement at: > > * https://fedoramagazine.org/announcing-fedora-32/ > I noticed Jam is missing from the labs even though the ISO built and everything was fine for the beta. Is this an oversight? Thanks, Erich ___ 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 CPU extensions can we assume are available by arch?
>Kevin Kofler wrote: >>Dave Love wrote: >> As far as I can tell, it doesn't do dynamic dispatch. Experimentally, >> if you build with -mavx2 and run on ivybridge (or for skx and run on >> haswell), the test code generates illegal instruction errors. It's some >> time ago since I looked at it, and I don't remember, but that's probably >> why I thought it wasn't very useful, apart from only having x86 and arm >> support. > >That's because it is a header-only library. It is either hard (and non- >portable) or impossible to do dynamic dispatch in a header-only library, >depending on the compiler and compiler version. (At least in past GCC >versions, it was impossible. This may or may not have improved since.) >Hence, dynamic dispatch, if desired, is left to the client application. And >I agree that this makes the library mostly useless. Less useful then we would like. But could be part of the larger solution. Properly structured they could help (not impede) building shared objects with multiple implementations and dynamic selection for vector codes. >You need an actual shared object with actual functions to do dynamic >dispatch nicely and transparently. I think the problem is lack of good documentation and examples. And perhaps motivation. GLIBC has been doing this some time, but at the time is was hard and difficult. But the compiler and runtime infrastructure has improved since. Perhaps we can make this simple enough for wide application to higher level libraries. I am finding for the implementation of pveclib, that vector multiple quadword (128-bit) precision multiplies are large enough, that you don't want to expanded them in-line. But the vector multiply quadword itself and the operations that implement it can and should be inline (for ppc64le). So I was forced to cross that boundary. Give me some time and I will have a documentation/examples that might general useful. ___ 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 32 is available now!
It’s here! We’re proud to announce the release of Fedora 32. Thanks to the hard work of thousands of Fedora community members and contributors, we’re celebrating yet another on-time release! Read the official announcement at: * https://fedoramagazine.org/announcing-fedora-32/ or just go ahead and grab it from: * https://getfedora.org/ -- Matthew Miller Fedora Project Leader ___ announce mailing list -- annou...@lists.fedoraproject.org To unsubscribe send an email to announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org ___ announce mailing list -- annou...@lists.fedoraproject.org To unsubscribe send an email to announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ 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
VMware NSX Engineer
VMware NSX Engineer The VMware NSX Engineer is an IT professional trained to effectively integrate and implement the VMware NSX security platform within a hybrid cloud infrastructure. The NSX Engineer must provide expertise in all aspects of network technology security for a VMware virtualized environment. Virtual Cloud Network, built on VMware NSX technology, is a ubiquitous software layer from the data center to cloud to edge infrastructure. It provides a secure, consistent foundation that drives the business forward throughout the World. https://www.fieldengineer.com/skills/vmware-nsx-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
Teletypewriter Installer
Teletypewriter Installer A Teletypewriter (TTY) Installer is a professional who installs and repairs telegraphic transmitting and receiving equipment. A teletypewriter is known as an electromechanical typewriter meant for point-to-point communication. According to the U.S. Bureau of Labor and Statistics (BLS), a Teletypewriter Installer falls into the category of telecommunication equipment installer (telex). https://www.fieldengineer.com/skills/teletypewriter-installer ___ 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-IoT-32-20200428.0 compose check report
No missing expected images. Failed openQA tests: 2/8 (x86_64) New failures (same test not failed in Fedora-IoT-32-20200423.1): ID: 588192 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/588192 ID: 588193 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/588193 Skipped non-gating openQA tests: 6 of 8 -- 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
Fedora-Cloud-31-20200428.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (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
Fedora-Cloud-32-20200428.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 588191 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/588191 -- 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: What CPU extensions can we assume are available by arch?
Dave Love wrote: > As far as I can tell, it doesn't do dynamic dispatch. Experimentally, > if you build with -mavx2 and run on ivybridge (or for skx and run on > haswell), the test code generates illegal instruction errors. It's some > time ago since I looked at it, and I don't remember, but that's probably > why I thought it wasn't very useful, apart from only having x86 and arm > support. That's because it is a header-only library. It is either hard (and non- portable) or impossible to do dynamic dispatch in a header-only library, depending on the compiler and compiler version. (At least in past GCC versions, it was impossible. This may or may not have improved since.) Hence, dynamic dispatch, if desired, is left to the client application. And I agree that this makes the library mostly useless. You need an actual shared object with actual functions to do dynamic dispatch nicely and transparently. Kevin Kofler ___ 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: Please keep an eye on AskFedora as we approach F32 release
Hi folks, We've already started to see Fedora 32 related questions on Ask Fedora. May I please request you to look at AskFedora and answer questions when possible, perhaps when you take short breaks from work? https://ask.fedoraproject.org/ -- 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
Fedora-Cloud-30-20200428.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (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: RFC: Feature macros (aka USE flags)
On 4/28/20 10:53 AM, Nicolas Mailhot via devel wrote:
Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
%_use_ncurses %{lua:
if rpm.expand("%{name}") == "yourpackage1"
or rpm.expand("%{name}") == "yourpackage2" then
print(rpm.expand("%{bcond_with foo}%{with foo}"))
else
print(rpm.expand("%{bcond_without foo}%{with foo}"))
end
}
%{name} use in macro logic is unsafe because %{name} does not exist in
the preamble before the Name: line, and the Name: line does not exist
before you start declaring package headers.
Just to clarify, this is true of all versions of rpm.
Once you’re in package
header declaration mode rpm parser behaviour will prevent you from
doing logic between headers blocks, so it all needs interleaving, which
ends un not possible sanely in any semi-complex spec file.
The rpm parser will now insult you with messages like
warning: undefined macro(s) in %{_sourcedir}:
/var/lib/builder/rpmbuild/SOURCES/%{name}
if you try to use %{name} at the srpm level.
This is an rpm 4.15 change
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
And that's a redhat-rpm-config pull-request, which doesn't really
explain a thing.
The actual background is in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1820349
- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Feature macros (aka USE flags)
On 4/27/20 5:33 PM, Petr Šabata wrote:
On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar wrote:
On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
Details in the gist:
https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
I'm very interested in overriding the global settings:
(1) Is it possible to override them from a modulemd when building a module?
I guess the asnswer is define %_with_ and %_without_ macros in
a buildopts/rpms/macros section of the module. Could elaborate more
the "Compatibility with RPM's --with & --without options" section?
Yes, you can, and that's exactly how you would do that.
Currently the macros as defined with bconds, in the basic form for
enabled by default:
%_with_foo %{bcond_without foo}%{with foo}
Please note hat the RPM options and the macros have three states (true, false,
undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
I don't ask about preserving a compatibility with this silly semantics, but
some clarification will be needed if this proposal becomes approved.
It might not work if with/without is set with these macros directly as
it is written right now. I'll have to test that.
(2) Is it possible to override them on a per-package basis?
E.g. I have ncurses in global.yaml:
- name: ncurses
description: Add support for ncurses.
enabled: true
and I have plenty of packages that use the ncurses feature in my module. What
should I write to my modulemd so that "ncurses" feature for "pcre" package is
disabled, but all the other packages have it enabled? Or is it a completelly
illed request to have the same feature enabled at one package and disabled on
another one?
It is and that's actually how the local is implemented.
Not entirely sure if we're talking about the same "local" here but I
spotted this in the use-macros.spec:
# %%global local
for source in string.gmatch(rpm.expand("%{?local}"), "[%w_-]+")
Please avoid taking over such broadly generic names as "local" in the
global macro namespace, rpm might well want to use %local as a macro
primitive (opposite of %global) one day.
It extends the
basic definitions with %{name} checks like this:
%_use_ncurses %{lua:
if rpm.expand("%{name}") == "yourpackage1"
or rpm.expand("%{name}") == "yourpackage2" then
print(rpm.expand("%{bcond_with foo}%{with foo}"))
else
print(rpm.expand("%{bcond_without foo}%{with foo}"))
end
}
Danger Will Robinson.
Such checks will on %{name} will only work after the Name: tag in the
spec, which is not obvious from the outset, and there's a large set of
packages in Fedora that only declare the name towards the end of the
spec preamble.
- Panu -
I know it's not very user friendly. Maybe there's a better way that
doesn't blow up on recursive macro definition.
P
___
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: RFC: Feature macros (aka USE flags)
Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
> On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> >
> > %_use_ncurses %{lua:
> > if rpm.expand("%{name}") == "yourpackage1"
> > or rpm.expand("%{name}") == "yourpackage2" then
> > print(rpm.expand("%{bcond_with foo}%{with foo}"))
> > else
> > print(rpm.expand("%{bcond_without foo}%{with foo}"))
> > end
> > }
%{name} use in macro logic is unsafe because %{name} does not exist in
the preamble before the Name: line, and the Name: line does not exist
before you start declaring package headers.
Once you’re in package
header declaration mode rpm parser behaviour will prevent you from
doing logic between headers blocks, so it all needs interleaving, which
ends un not possible sanely in any semi-complex spec file.
The rpm parser will now insult you with messages like
warning: undefined macro(s) in %{_sourcedir}:
/var/lib/builder/rpmbuild/SOURCES/%{name}
if you try to use %{name} at the srpm level.
This is an rpm 4.15 change
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
Regards,
--
Nicolas Mailhot
___
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
