Re: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote: > UEFI Secure Boot doesn't prevent you from gaining access to firmware > setup. It can cause some options in firmware setup to become > unavailable, e.g. compatibility support modules for presenting a > legacy BIOS. I'm skeptical that pin shorts permit you to gain access > to such things - but if so, it's clearly a vulnerability that should > be reported. This is by design. Generally, there's a marking on the silkscreen with something like "PWD" or "PASSWD" to mark it. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Supporting hibernation in Workstation ed., draft 1
On Wed, Jun 3, 2020 at 9:37 PM John M. Harris Jr wrote: > > On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote: > > And if it's enabled, the more likely attack vector is sabotage to > > induce a crash or corrupt user data, rather than malware injection. > > Since you don't know the nature of the attack, and neither do I, > > neither one of us knows when the corruption manifests or how. > > That would require physical access to begin with, and there are much more > interesting things you can do once you have physical access. Physical access is the topic. That is indicated in a UEFI Secure Boot context as it's intended to protect against evil maid attack. While bootloader malware (or bootkits) aren't only deployed by physical access, it's perhaps Exhibit 1 example wise anyway. > On all desktop > systems I've used both personally and in enterprise rollouts, there are pins > you can short to give yourself access to the firmware configuration. UEFI Secure Boot doesn't prevent you from gaining access to firmware setup. It can cause some options in firmware setup to become unavailable, e.g. compatibility support modules for presenting a legacy BIOS. I'm skeptical that pin shorts permit you to gain access to such things - but if so, it's clearly a vulnerability that should be reported. > I don't understand why, or where, there's a preference for AES-GCM. If you're > talking about using that for the boot image, you're just putting another key > the user is going to have to enter in front of them, which you've previously > complained about. Simply placing the key in the TPM is a bad idea, because > that leads to the exact same issue described above with physical access. While > it's true some implementations wipe the TPM when you reset the boot firmware's > settings, most do not. At that point, you've got the key from the TPM, you've > got the key needed to decrypt the image and you're now able to get to the data > on that system. The authenticated encryption of the hibernation image is concerned about specific attacks. As I said already, I don't know all of the attacks the designers are trying to mitigate. But I expect they aren't concerned with all possible attacks, rather the specific ones in the domain they can mitigate: pilfering the hibernation image and extracting secrets; modification of the image to corrupt it or cause corruption while in use in unsuspecting ways. But probably they are not concerned about the image being restored in a particular sequence of events to that same machine whereby the information decrypted by the resume process should be protect by other systems - not the AE hibernation image scheme. No one has the key from the TPM, that is not correct - it's unsealed in certain cases and provided to the kernel - if the attacker has that key for some reason then some other aspect of security has failed. It is not the responsibility of one protection scheme to protect against all attacks simultaneously. Just like it is not the responsibility of the AE hibernation image scheme to ensure login authentication to a desktop shell. -- 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: %configure broken in Rawhide
On 6/3/20 8:23 PM, Igor Raits wrote: At least it did not break anything than %configure, so the world did not explode:) It hit at a very unfortunate time. With the reduced data center power it is taking a long time to hit the build root. Two hours and counting... :( ___ 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: Supporting hibernation in Workstation ed., draft 1
On Wed, Jun 3, 2020 at 9:30 PM John M. Harris Jr wrote: > > The larger UX issue is that hibernation is disabled for ALL users just because > it doesn't work for users with Secure Boot, This is not correct. Hibernation is enabled in the kernel, it's only inhibited by lockdown, and Secure Boot being enabled is the trigger for enabling lockdown. [0.00] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7 [0.857522] Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7 -- 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: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote: > On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr > wrote: > > > > > > On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote: > > > > > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr > > > > > > > > > > If kernel lockdown is what disables this, we should look at fixing > > > > kernel > > > > lockdown so that it doesn't break hibernation. This is definitely a > > > > security decision that we shouldn't be imposing on the masses > > > > needlessly, in my opinion. > > > > > > > > > > > > > > > Instead you propose imposing a loophole for attackers to easily deploy > > > malware needlessly. Do you really not see how this is an untenable > > > position for Fedora? > > > > > > > > In my opinion, the threat model you're proposing here is absurd. If people > > can create a valid kernel image that will be loaded from a LUKS > > container, we have bigger problems. > > > Disk encryption isn't enabled by default. The no encryption case > obviously has to be considered. In my opinion, it's already considered. With no disk encryption, it could work just as it does on every system without Secure Boot. > And if it's enabled, the more likely attack vector is sabotage to > induce a crash or corrupt user data, rather than malware injection. > Since you don't know the nature of the attack, and neither do I, > neither one of us knows when the corruption manifests or how. That would require physical access to begin with, and there are much more interesting things you can do once you have physical access. On all desktop systems I've used both personally and in enterprise rollouts, there are pins you can short to give yourself access to the firmware configuration. Even where there's "intrusion detection" and similar here, you can just delete those records after getting in. At that point, you could replace any point of the boot process, even potentially putting something like your own ME/AMT in. Laptops often have pads that function in the same way. The physical access requirement to abuse this means that it'd only affect specific enterprise clients, and generally would not be in the threat model of end users of Fedora. Once you have physical access, you can do a lot with any system. > I also don't know all of the threat models the upstream developers are > accounting for. Did you read all of the referenced lkml emails? Do you > understand why there's a preference for AES-GCM, why they want to > secure the encryption key in the TPM, and why they want to use TPM > localities? And why they wanted it all simplified as well? Which, I > think is sortof funny actually because none of it is very simple. If > you understand those concerns and still have questions, you might > consider directing your concerns upstream. I don't understand why, or where, there's a preference for AES-GCM. If you're talking about using that for the boot image, you're just putting another key the user is going to have to enter in front of them, which you've previously complained about. Simply placing the key in the TPM is a bad idea, because that leads to the exact same issue described above with physical access. While it's true some implementations wipe the TPM when you reset the boot firmware's settings, most do not. At that point, you've got the key from the TPM, you've got the key needed to decrypt the image and you're now able to get to the data on that system. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 12:06:19 PM MST Simo Sorce wrote: > On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > > > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > > > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > > > > > > > > I would expect that using an encrypted partition for swap should be > > > > sufficient to allow it though. > > > > > > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > > The original set of patches for signed and authenticated hibernation > > > images called for the use of an HMAC for signing, and upstream > > > considered this insufficient and asked why not use AES-GCM to provide > > > a real AE (authenticated encryption) model. > > > > > > In what way do you believe it's not sufficient? > > > AES GCM Is generally *not* a good algorithm for disk encryption so I am > not sure why this is being brought up, HMAC is sufficient to verify > integrity. I was asking why encryption itself would not be sufficient, nothing to do with AES-GCM, just to clarify. > In any case the problem is that adding integrity protection cannot be > done w/o losing some space on the disk, as you need to save the > integrity tag/hmac. > > As to why just encryption is not sufficient that is because you can > easily play a number of replay attacks, corruption attacks, and > potentially even sectors-wap attacks with naive encryption schemes. > > This can be sufficient to generate an attack vector in certain > circumstance once the machine boots up again. > > (As an hypotetical if the attacker is able to observe which sector > contains the passwd file and can corrupt it or replace it with other > content that effectively gives it access with a known secret or a blank > password or whatnot, or maybe it can create corruption in the kernel in > such a way that it causes the machine to display a OOM that reveals > encryption keys, or... the possibilities are endless). All of these are possible through many other methods, but all of these require physical access. Once you're talking about physical access, the threat model changes entirely. > > > Not only is encryption alone inadequate, the signature verification > > > model should ensure that the hibernation image being restored was > > > created by the computer it is being restored to. > > > > > > Why? > > > Evil maid attacks. > > Because without a signature you could replace the whole image with a > completely functional one that you fully control. This sounds like legitimate functionality that may be desired. Am I wrong? > Boot the system with a hybernation image generated on identical > hardware but with your own data, give your own decryption key, presto, > as soon as the hybernation image is restored the system is running your > image. From there you could be able to use, for example, keys stored in > the TPM or simply you capture the real password for the real image as > soon as the user returns to the machine to unlock it and transmit it, > and now you have access to the original disk image and all its > contents... > Again, possibilities abound. > > > > > > I am not a cryptographer. And I can't do a better job of explaining > > > it. But it's a problem. And my disappointment isn't relevant to the > > > security issue. It's relevant from a UX perspective I suppose. > > > > > > It's a severe UX issue that you cannot use a standard feature of normal > > systems, hibernation. > > > A way to deal with hybernation o secure boot would be to *measure* the > hybernated image as the last action of hybernation and store the > measure in TPM. Fail to restore on boot if the TPM fails to check the > measured image. (Measure here effectively ends up being running an HMAC > on the whole disk image you want to restore and storing the results in > TPM). The larger UX issue is that hibernation is disabled for ALL users just because it doesn't work for users with Secure Boot, which are probably a minority when it comes to those running Fedora, CentOS or RHEL, and I'm saying this as a CentOS/RHEL sysadmin and Fedora user. I'd like to see some data on that before saying for sure, of course. > > > But, I've also just spent two days trying to track down a new > > > hibernation bug, resulting in fatal hibernation entry. Even without > > > the Secure Boot issue, hibernation can be a problem that requires > > > resources that are not finite. I had this working reliably several > > > months ago, and I've exhausted my time and interest for now doing > > > kernel regression testing and have literally no idea why it's > > > consistently failing now. On three machines (one is a VM). I did > > > report it upstream, I haven't gotten a reply yet (normal). > > > > > > There are two emails, bottom one is the first. > > > https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz > > > 3gB4 hf1nk...@mail.gmail.com/ -- John M. Harris, Jr. _
Is there a way to allow changing permissions of an rpm tmpfile dir?
The clamd package ships a default service (clamd@scan) with the following configuration: /usr/lib/tmpfiles.d/clamd.scan.conf: d /run/clamd.scan 0710 clamscan virusgroup %files -n clamd %ghost %dir %attr(0710,clamscan,virusgroup) /run/clamd.scan %ghost /run/clamd.scan/clamd.sock Now, a user might want to change the mode and group of the /run/clamd.scan directory to suit their purposes. They can do this by creating an /etc/tmpfiles.d/clamd.scan.conf file. But the next time a clamd update comes along rpm will reset the permissions of /run/clamd.scan until the next reboot. Any suggestions for how to avoid this? Can the /run/clamd.scan directory be marked %config(noreplace) or some such so that rpm will not modify the existing permissions? Could systemd-tmpfiles be run in such a way as to honor any user overrides in place? Thanks, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: %configure broken in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-06-04 at 02:58 +0200, Igor Raits wrote: > Uh, this is my fault. Ive tested it, but seems I have tested > something else. > > Not near the computer now, so if somebody can untag it - would be > much > appreciated. I got to my laptop faster than I thought. This should be fixed with redhat-rpm-config-160-1.fc33. There were actually 2 issues with the same thing, too many semicolons, one is from my commit and one from the PR that I have merged. Seems like a common problem when writing macros :/ At least it did not break anything than %configure, so the world did not explode :) > Sorry again. > > On Thu, Jun 4, 2020, 02:07 Orion Poplawski wrote: > > > On 6/3/20 5:36 PM, Jerry James wrote: > > > If koschei is telling you that your packages are failing to build > > > in > > > Rawhide, it may be because the %configure macro is currently > > > broken: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1843714 > > > > > > Just a heads up. > > > > > > > Thanks. Hopefully this gets cleaned up quickly. Seems like this > > would > > have shown up pretty quickly with local testing before building for > > rawhide. > > > > > > -- > > Orion Poplawski > > Manager of NWRA Technical Systems 720-772-5637 > > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > > 3380 Mitchell Lane or...@nwra.com > > Boulder, CO 80301 https://www.nwra.com/ > > > > ___ > > 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 > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7YTRAACgkQEV1auJxc Hh6gtg//dzoZX2h6BRoP/whPJBEKl8QtojmyrjqYUpCNBQAdeDHuZyPKjclJhGmZ nE/CqffmFbUNeebF2D+aICUvrf6xHSRWzAs9I75wsA2bPN+Xg9fmfSs+ZxzwH6Vt Z6/zqg0zu/xZpSUUEtNWh9DwnG+dIBN4hAua+0qThlRU8uUXJPVXtbXRJtqKvmVL AwaC39E5LRCew+FxiderFpRN1+L40UjdfJkHYoezkwszjOX0AZV+SZXQaoYEb9zB m5Fan5uz5uzqHd1JzPXi62yuFu1dHOziHZnc/0YvkS3F9/qeNLE2Z++KE7SwR6d0 dPB8wHseVGy0M5XkgDQ1N83lVDOnRJ30F/DyonDYX6NbKcmoYiM1OGRn/i8g9MuA np/0ixs/Vwj1vgKnST9yMlu7mHNQGOvuTudMr39JjPc1DYZEQ2JrbgEY1C0Ypc43 TlHEsLpDfFvyZ5icBCXKoCDN1z7xJOnhVVX6ow3LgpAe56svs52UQ3hMAC8TM9UQ dQNuIxS3+0KAmX/wH0SnbnMONAUk9JwRcBvh28jPv6mu46bZ0tjXUxLLFOsdZnqm WIKN7N842BHusCK2VxF7TrA4oD+Q3DWWRESEBi7o1emycUTqTlb7PBNeYR3UL219 3uyri+f91DWgRjYlyF8Th7bzfXC/hf+YIEuWfDpfy7XyuxJ2xnE= =Ps+B -END 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: Upcoming fedoraproject Datacenter move reminder and plans
On Wed, Jun 03, 2020 at 10:46:06AM +0200, Vít Ondruch wrote: > Just wonder, will there be any convenient way to remind me that the > service is down for a reason? E.g. redirect to status page. It would be > probably harder for all the CLI utilities we are using, but maybe > something which should be addressed as well. Many of our services have outage pages that will tell you to look for a outage and check status. There's nothing that covers all applications, but any that use our proxy system would be. 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: %configure broken in Rawhide
Uh, this is my fault. Ive tested it, but seems I have tested something else. Not near the computer now, so if somebody can untag it - would be much appreciated. Sorry again. On Thu, Jun 4, 2020, 02:07 Orion Poplawski wrote: > On 6/3/20 5:36 PM, Jerry James wrote: > > If koschei is telling you that your packages are failing to build in > > Rawhide, it may be because the %configure macro is currently broken: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1843714 > > > > Just a heads up. > > > > Thanks. Hopefully this gets cleaned up quickly. Seems like this would > have shown up pretty quickly with local testing before building for > rawhide. > > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ > 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03/06/20 15:21 -0500, Richard Shaw wrote: On Wed, Jun 3, 2020 at 3:16 PM Jonathan Wakely wrote: On 03/06/20 20:25 +0100, Ian McInerney wrote: >On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw wrote: > >> Ok, one problem after another with FreeCAD, maybe I'll get them fixed >> before f33 is released :) >> >> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In >> constructor 'Gui::DAG::View::View(QWidget*)': >> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100: >> error: '_1' was not declared in this scope >>55 | >> Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument, >> this, _1)); >> | >> ^~ >> >> Full log: >> https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log >> >> Scratch build: >> https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091 >> >> Any ideas? >> >> Thanks, >> Richard >> > >Looks like the boost::placeholders problem discussed earlier in this >thread: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/ >. Yes, exactly. You can fix it by adding: using namespace boost::placeholders; Is this fairly backwards compatible? I would like to send the fix upstream. It'll work with anything since Boost 1.60.0 released December 2015 (which is more recent than I realised). ___ 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: %configure broken in Rawhide
On 6/3/20 5:36 PM, Jerry James wrote: If koschei is telling you that your packages are failing to build in Rawhide, it may be because the %configure macro is currently broken: https://bugzilla.redhat.com/show_bug.cgi?id=1843714 Just a heads up. Thanks. Hopefully this gets cleaned up quickly. Seems like this would have shown up pretty quickly with local testing before building for rawhide. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
%configure broken in Rawhide
If koschei is telling you that your packages are failing to build in Rawhide, it may be because the %configure macro is currently broken: https://bugzilla.redhat.com/show_bug.cgi?id=1843714 Just a heads up. -- Jerry James http://www.jamezone.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: Supporting hibernation in Workstation ed., draft 1
On 6/3/20 12:06 PM, Simo Sorce wrote: On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: Why? Evil maid attacks. Because without a signature you could replace the whole image with a completely functional one that you fully control. Boot the system with a hybernation image generated on identical hardware but with your own data, give your own decryption key, presto, as soon as the hybernation image is restored the system is running your image. From there you could be able to use, for example, keys stored in the TPM or simply you capture the real password for the real image as soon as the user returns to the machine to unlock it and transmit it, and now you have access to the original disk image and all its contents... Again, possibilities abound. Thank you, that is a very clear explanation. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Wed, 2020-06-03 at 15:31 -0600, Chris Murphy wrote: > On Wed, Jun 3, 2020 at 1:07 PM Simo Sorce wrote: > > On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > > > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > > > I would expect that using an encrypted partition for swap should be > > > > > sufficient to allow it though. > > > > > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > > > The original set of patches for signed and authenticated hibernation > > > > images called for the use of an HMAC for signing, and upstream > > > > considered this insufficient and asked why not use AES-GCM to provide > > > > a real AE (authenticated encryption) model. > > > > > > In what way do you believe it's not sufficient? > > > > AES GCM Is generally *not* a good algorithm for disk encryption so I am > > not sure why this is being brought up, HMAC is sufficient to verify > > integrity. > > I don't know either. This is the discussion I'm referring to, for full > context: > https://lkml.org/lkml/2019/1/9/828 Alright it was just a question and not a strong suggestion, nothing to see (I do not want to go down a rabbit hole here anyway it is not relevant to this discussion). -- 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: Supporting hibernation in Workstation ed., draft 1
On Wed, Jun 3, 2020 at 1:07 PM Simo Sorce wrote: > > On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > > > > > I would expect that using an encrypted partition for swap should be > > > > sufficient to allow it though. > > > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > > The original set of patches for signed and authenticated hibernation > > > images called for the use of an HMAC for signing, and upstream > > > considered this insufficient and asked why not use AES-GCM to provide > > > a real AE (authenticated encryption) model. > > > > In what way do you believe it's not sufficient? > > AES GCM Is generally *not* a good algorithm for disk encryption so I am > not sure why this is being brought up, HMAC is sufficient to verify > integrity. I don't know either. This is the discussion I'm referring to, for full context: https://lkml.org/lkml/2019/1/9/828 -- 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
Fedora CoreOS rebasing to Fedora 32: known issues; upcoming test day
Today we’ve released the first Fedora CoreOS testing release based on Fedora 32. We expect that this release will promote to the stable channel in two weeks, on the usual schedule. New features include: Support for the Ignition 3.1.0 config specification. Use this with the FCC 1.1.0 config specification. For more on the new features, see here. It’s now easier to enable SSH password authentication. There are a few quirks that may affect you: New releases are signed with the Fedora 32 key. Accordingly, bare metal installations require coreos-installer 0.2.1 or greater. If you’re installing from media that matches the release you’re installing, you’ll already have the correct installer version. Ignition currently fails to set SELinux labels on absolute symlinks. For more info and a workaround, see #512. AWS instances may produce a kernel warning on shutdown. For more info, see #507. On Monday, June 8, we’ll be joining the Fedora QA team for a Fedora CoreOS test day. Join us in #fedora-coreos on Freenode to test Fedora CoreOS based on Fedora 32! For more information, see the mailing list post. Thanks for helping us make Fedora CoreOS awesome! Dusty Mabe, for the Fedora CoreOS team ___ 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: 20200603.n.0 changes
OLD: Fedora-Rawhide-20200601.n.1 NEW: Fedora-Rawhide-20200603.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 7 Dropped packages:4 Upgraded packages: 281 Downgraded packages: 2 Size of added packages: 240.97 MiB Size of dropped packages:1001.21 KiB Size of upgraded packages: 12.60 GiB Size of downgraded packages: 31.59 MiB Size change of upgraded packages: 285.46 MiB Size change of downgraded packages: -132.90 KiB = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ilua-0.2.1-1.fc33 Summary: Portable Lua kernel for Jupyter RPMs:ilua Size:81.70 KiB Package: llvm7.0-7.0.1-6.fc33 Summary: The Low Level Virtual Machine RPMs:llvm7.0 llvm7.0-devel llvm7.0-doc llvm7.0-libs llvm7.0-static Size:237.96 MiB Package: mpsolve-3.1.8-1.fc33 Summary: Multiprecision polynomial solver RPMs:mpsolve mpsolve-devel mpsolve-doc mpsolve-libs octave-mpsolve python3-mpsolve xmpsolve Size:2.83 MiB Package: php-composer-semver2-2.0.0-1.fc33 Summary: Semver library version 2 RPMs:php-composer-semver2 Size:20.71 KiB Package: php-doctrine-common3-1:3.0.1-1.fc33 Summary: Common library for Doctrine projects version 3 RPMs:php-doctrine-common3 Size:27.04 KiB Package: php-doctrine-inflector2-2.0.3-1.fc33 Summary: Common string manipulations with regard to casing and singular/plural rules RPMs:php-doctrine-inflector2 Size:25.36 KiB Package: php-doctrine-persistence2-2.0.0-1.fc33 Summary: Doctrine Persistence abstractions RPMs:php-doctrine-persistence2 Size:31.10 KiB = DROPPED PACKAGES = Package: istatd-0.5.8-21.fc32 Summary: Daemon serving statistics to your iStat iPhone application RPMs:istatd Size:404.84 KiB Package: python-django-simple-captcha-0.5.12-2.fc33 Summary: Django application to add captcha images to any Django form RPMs:python3-django-simple-captcha Size:104.54 KiB Package: rubygem-diff_dirs-0.1.2-6.fc32 Summary: Ruby helper to diff two directories RPMs:rubygem-diff_dirs rubygem-diff_dirs-doc Size:220.35 KiB Package: rubygem-slop-4.8.1-2.fc33 Summary: Simple Lightweight Option Parsing RPMs:rubygem-slop rubygem-slop-doc Size:271.48 KiB = UPGRADED PACKAGES = Package: Field3D-1.7.3-2.fc33 Old package: Field3D-1.7.3-1.fc33 Summary: Library for storing voxel data RPMs: Field3D Field3D-devel Size: 9.72 MiB Size change: -48.71 KiB Changelog: * Thu May 28 2020 Jonathan Wakely - 1.7.3-2 - Rebuilt for Boost 1.73 Package: FlightCrew-0.9.1-19.fc33 Old package: FlightCrew-0.9.1-18.fc32 Summary: EPUB validator RPMs: FlightCrew-cli FlightCrew-sigil-plugin Size: 3.99 MiB Size change: -196.13 KiB Changelog: * Thu May 28 2020 Jonathan Wakely - 0.9.1-19 - Rebuilt for Boost 1.73 Package: OpenImageIO-2.1.16.0-1.fc33 Old package: OpenImageIO-2.1.15.0-3.fc33 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 19.89 MiB Size change: 5.57 KiB Changelog: * Fri May 29 2020 Jonathan Wakely - 2.1.15.0-4 - Rebuilt for Boost 1.73 * Tue Jun 02 2020 Richard Shaw - 2.1.16.0-1 - Update to 2.1.16. Package: OpenSceneGraph-3.4.1-18.fc33 Old package: OpenSceneGraph-3.4.1-17.fc33 Summary: High performance real-time graphics toolkit RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk OpenSceneGraph-examples-qt OpenSceneGraph-gdal OpenSceneGraph-gstreamer OpenSceneGraph-libs OpenSceneGraph-qt OpenSceneGraph-qt-devel OpenThreads OpenThreads-devel Size: 63.45 MiB Size change: -2.83 KiB Changelog: * Sat May 30 2020 Jonathan Wakely - 3.4.1-18 - Rebuilt for Boost 1.73 Package: QuantLib-1.16-3.fc33 Old package: QuantLib-1.16-2.fc32 Summary: A software framework for quantitative finance RPMs: QuantLib QuantLib-devel QuantLib-doc QuantLib-test Size: 77.24 MiB Size change: -171.28 KiB Changelog: * Thu May 28 2020 Jonathan Wakely - 1.16-3 - Rebuilt for Boost 1.73 Package: YafaRay-3.4.4-1.fc33.2 Old package: YafaRay-3.4.4-1.fc33.1 Summary: A free open-source ray-tracing render engine RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib Size: 5.20 MiB Size change: 7.42 KiB Changelog: * Sat May 30 2020 Jonathan Wakely - 3.4.4-1.2 - Rebuilt for Boost 1.73 Package: anyterm-1.2.3-3.fc33 Old package: anyterm-1.2.3-2.fc32 Summary: A web-based terminal emulator RPMs: anyterm anyterm-httpd Size: 898.19 KiB Size change: -13.27 KiB Changelog: * Thu May 28 2020 Jonathan Wakely - 1.2.3-3 - Rebuilt for Boost 1.73 Package: asc-2.8.0.2-9.fc33 Old package: asc-2.8.0.2-8.fc32 Summary
Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On Wed, Jun 3, 2020 at 3:16 PM Jonathan Wakely wrote: > On 03/06/20 20:25 +0100, Ian McInerney wrote: > >On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw wrote: > > > >> Ok, one problem after another with FreeCAD, maybe I'll get them fixed > >> before f33 is released :) > >> > >> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In > >> constructor 'Gui::DAG::View::View(QWidget*)': > >> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100: > >> error: '_1' was not declared in this scope > >>55 | > >> > Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument, > >> this, _1)); > >> | > >> ^~ > >> > >> Full log: > >> https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log > >> > >> Scratch build: > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091 > >> > >> Any ideas? > >> > >> Thanks, > >> Richard > >> > > > >Looks like the boost::placeholders problem discussed earlier in this > >thread: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/ > >. > > Yes, exactly. > > You can fix it by adding: > > using namespace boost::placeholders; > Is this fairly backwards compatible? I would like to send the fix upstream. Thanks, Richard ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03/06/20 20:25 +0100, Ian McInerney wrote: On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw wrote: Ok, one problem after another with FreeCAD, maybe I'll get them fixed before f33 is released :) /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In constructor 'Gui::DAG::View::View(QWidget*)': /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100: error: '_1' was not declared in this scope 55 | Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument, this, _1)); | ^~ Full log: https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091 Any ideas? Thanks, Richard Looks like the boost::placeholders problem discussed earlier in this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/ . Yes, exactly. You can fix it by adding: using namespace boost::placeholders; ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw wrote: > Ok, one problem after another with FreeCAD, maybe I'll get them fixed > before f33 is released :) > > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In > constructor 'Gui::DAG::View::View(QWidget*)': > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100: > error: '_1' was not declared in this scope >55 | > Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument, > this, _1)); > | > ^~ > > Full log: > https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log > > Scratch build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091 > > Any ideas? > > Thanks, > Richard > Looks like the boost::placeholders problem discussed earlier in this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSKNR5UC5QW7LMBQWTEMSBD6RB25PHLO/ . -Ian ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
Ok, one problem after another with FreeCAD, maybe I'll get them fixed before f33 is released :) /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In constructor 'Gui::DAG::View::View(QWidget*)': /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100: error: '_1' was not declared in this scope 55 | Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument, this, _1)); | ^~ Full log: https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091 Any ideas? Thanks, Richard ___ 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: Supporting hibernation in Workstation ed., draft 1
On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > > I would expect that using an encrypted partition for swap should be > > > sufficient to allow it though. > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > The original set of patches for signed and authenticated hibernation > > images called for the use of an HMAC for signing, and upstream > > considered this insufficient and asked why not use AES-GCM to provide > > a real AE (authenticated encryption) model. > > In what way do you believe it's not sufficient? AES GCM Is generally *not* a good algorithm for disk encryption so I am not sure why this is being brought up, HMAC is sufficient to verify integrity. In any case the problem is that adding integrity protection cannot be done w/o losing some space on the disk, as you need to save the integrity tag/hmac. As to why just encryption is not sufficient that is because you can easily play a number of replay attacks, corruption attacks, and potentially even sectors-wap attacks with naive encryption schemes. This can be sufficient to generate an attack vector in certain circumstance once the machine boots up again. (As an hypotetical if the attacker is able to observe which sector contains the passwd file and can corrupt it or replace it with other content that effectively gives it access with a known secret or a blank password or whatnot, or maybe it can create corruption in the kernel in such a way that it causes the machine to display a OOM that reveals encryption keys, or... the possibilities are endless). > > Not only is encryption alone inadequate, the signature verification > > model should ensure that the hibernation image being restored was > > created by the computer it is being restored to. > > Why? Evil maid attacks. Because without a signature you could replace the whole image with a completely functional one that you fully control. Boot the system with a hybernation image generated on identical hardware but with your own data, give your own decryption key, presto, as soon as the hybernation image is restored the system is running your image. From there you could be able to use, for example, keys stored in the TPM or simply you capture the real password for the real image as soon as the user returns to the machine to unlock it and transmit it, and now you have access to the original disk image and all its contents... Again, possibilities abound. > > I am not a cryptographer. And I can't do a better job of explaining > > it. But it's a problem. And my disappointment isn't relevant to the > > security issue. It's relevant from a UX perspective I suppose. > > It's a severe UX issue that you cannot use a standard feature of normal > systems, hibernation. A way to deal with hybernation o secure boot would be to *measure* the hybernated image as the last action of hybernation and store the measure in TPM. Fail to restore on boot if the TPM fails to check the measured image. (Measure here effectively ends up being running an HMAC on the whole disk image you want to restore and storing the results in TPM). > > But, I've also just spent two days trying to track down a new > > hibernation bug, resulting in fatal hibernation entry. Even without > > the Secure Boot issue, hibernation can be a problem that requires > > resources that are not finite. I had this working reliably several > > months ago, and I've exhausted my time and interest for now doing > > kernel regression testing and have literally no idea why it's > > consistently failing now. On three machines (one is a VM). I did > > report it upstream, I haven't gotten a reply yet (normal). > > > > There are two emails, bottom one is the first. > > https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4 > > hf1nk...@mail.gmail.com/ > > > -- > > Chris Murphy > > -- > John M. Harris, Jr. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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: Adding Obsoletes to generated -debuginfo packages ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote: > Other possibility is to modify DNF to not touch such packages. Not > sure > if that would be better. Or is there already some functionality which > would exclude the package from dnf transaction, something like: > > ~~~ > # This package won't be installed, but will obsolete other packages > Provides: libsolv-self-destruct-pkg() > > ~~~ > > we use in fedora-obsolete-packages? Since they do not block the upgrades, does it really matter? However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically. > > Vít > > > > Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a): > > Because was bitten by this and there is not clear guideline, I have > > tried to draft something here: > > > > https://pagure.io/packaging-committee/pull-request/988 > > > > > > Vít > > > > > > Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a): > > > In libvirt we recently deleted a driver for the legacy Xen > > > toolstack. > > > > > > This was shipped in a libvirt-daemon-driver-xen RPM. > > > > > > I am able to add an "Obsoletes: libvirt-daemon-driver-xen < > > > 4.3.0" > > > line to the libvirt-daemon-driver-libxl RPM, which gives clean > > > upgrade path for users. > > > > > > If they have the libvirt-daemon-driver-xen-debuginfo RPM > > > installed > > > though that still breaks the upgrade. > > > > > > How can I get the auto-generated libvirt-daemon-driver-libxl- > > > debuginfo > > > RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < > > > 4.3.0" > > > statement ? It seems impossible, meaning users with debuginfo > > > have a > > > broken upgrade path. An unfortunate consequence of switching to > > > seprate > > > -debuginfo per sub-RPM. > > > > > > Regards, > > > Daniel > > ___ > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7X3hIACgkQEV1auJxc Hh4/SBAAta3Au3oyBA72koUfKaMhvw8/XcT4FHMcJNiInpyobYFNSMmAvjJPj2/L tIefm2tPmtqSv03OjnIaeENVNT+eNiCcHljDvnT4x8fFySRn+r9Qvs+A7PU7zAIc 11q2WD+wzinFeSuf62Y+tvIVb1TPPdBrJqSsh+f/v97YK94ZhTpzfBa1C7ysZOds JXSZo5Sh0OqLDmi876YdpCZnYn3DAbqmkCfMJJ5RNWDGu5KbN35s4utBZSTfqt73 bEh/TPZ22RkNYpPQU/70CJkBcJXVJMS6JzZIOUhvSE5ITvYTg/E26vL4AmZS0rY+ eWbaR2N7V7GDhVe5MM8wpHStF8KxGajROeqllR3OF0w8lKlxIPItj9DI7DHuBEtI IFJUq8L1OLnFP3PR3pkn6a8wNwLTVWmAy44lR4NCMn7J9SbvRcjmAuFx9O2IprIH wG9vmVo4Q2Olvh8HJYr09xAFGKzmqlZnBTgiPGwcHl5O4EkygPAEdHD1EcEtkeRv Ony/fi4HX2f3B1YKdlEoqs7sDsMvLPEJzw32MftMIdBBo8q/0Xba/EQMya76ihrh ai5AFAOiqpoNzN6FjceIEGm3G0n2YquLMW++uVPIB0VJLYmoXBuGZD02LLxUfTzm VFnSjqnyVMkNaavxJf2SyCPkRY8xqN3exymh0vQUOVPmWPAbywI= =hJ35 -END 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: Has something changed with RPMS?
On Wed, 3 Jun 2020 at 11:38, Richard W.M. Jones wrote: > I should say that there's also the possibility of writing a block > device plugin which is highly tuned in some way to the Koji use case. > We've already done discarding flushes and showed that you get all the > benefit of a RAM disk just by doing that (even when backed by a disk). > > Is there anything else specific to Koji builds: > > - Prepopulating the filesystem in the block device? > > - Making a block device which is highly tuned to the filesystem it > will contain (eg. keeping metadata in faster storage)? > > Our koji builders are everything from virtual machines using spinning disks, virtual machines using ssd (very few), virtual machines on iscsi to actual hardware. We do not have a budget to standardize on anything so expect that it will always be hardware spanning a 7 year lifetime with some new stuff to cycle out items. Other architectures are just as diverse and usually whatever has been 'gifted'. Any tuning is going to have to take into fact that reality. > - Sharing / deduplicating? > > I collected traces of the access pattern of existing Koji builds, but > they are huge and I'm not sure how best to analyze them. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > 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 > -- Stephen J Smoogen. ___ 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: Adding Obsoletes to generated -debuginfo packages ?
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like: ~~~ # This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg() ~~~ we use in fedora-obsolete-packages? Vít Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a): > Because was bitten by this and there is not clear guideline, I have > tried to draft something here: > > https://pagure.io/packaging-committee/pull-request/988 > > > Vít > > > Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a): >> In libvirt we recently deleted a driver for the legacy Xen toolstack. >> >> This was shipped in a libvirt-daemon-driver-xen RPM. >> >> I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" >> line to the libvirt-daemon-driver-libxl RPM, which gives clean >> upgrade path for users. >> >> If they have the libvirt-daemon-driver-xen-debuginfo RPM installed >> though that still breaks the upgrade. >> >> How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo >> RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" >> statement ? It seems impossible, meaning users with debuginfo have a >> broken upgrade path. An unfortunate consequence of switching to seprate >> -debuginfo per sub-RPM. >> >> Regards, >> Daniel > ___ > 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: Adding Obsoletes to generated -debuginfo packages ?
Because was bitten by this and there is not clear guideline, I have tried to draft something here: https://pagure.io/packaging-committee/pull-request/988 Vít Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a): > In libvirt we recently deleted a driver for the legacy Xen toolstack. > > This was shipped in a libvirt-daemon-driver-xen RPM. > > I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" > line to the libvirt-daemon-driver-libxl RPM, which gives clean > upgrade path for users. > > If they have the libvirt-daemon-driver-xen-debuginfo RPM installed > though that still breaks the upgrade. > > How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo > RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" > statement ? It seems impossible, meaning users with debuginfo have a > broken upgrade path. An unfortunate consequence of switching to seprate > -debuginfo per sub-RPM. > > Regards, > Daniel ___ 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-33-20200603.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Passed openQA tests: 11/11 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 172 MiB to 150 MiB Peak task count changed from 119 to 105 Previous test data: https://openqa.fedoraproject.org/tests/609356#downloads Current test data: https://openqa.fedoraproject.org/tests/610565#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 172 MiB to 151 MiB Peak task count changed from 120 to 104 Previous test data: https://openqa.fedoraproject.org/tests/609359#downloads Current test data: https://openqa.fedoraproject.org/tests/610568#downloads -- 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: Has something changed with RPMS?
I should say that there's also the possibility of writing a block device plugin which is highly tuned in some way to the Koji use case. We've already done discarding flushes and showed that you get all the benefit of a RAM disk just by doing that (even when backed by a disk). Is there anything else specific to Koji builds: - Prepopulating the filesystem in the block device? - Making a block device which is highly tuned to the filesystem it will contain (eg. keeping metadata in faster storage)? - Sharing / deduplicating? I collected traces of the access pattern of existing Koji builds, but they are huge and I'm not sure how best to analyze them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Has something changed with RPMS?
On Wed, Jun 03, 2020 at 11:13:26AM +0200, VÃt Ondruch wrote: > > Dne 02. 06. 20 v 19:26 Richard W.M. Jones napsal(a): > > On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote: > >> * Panu Matilainen: > >> > >>> Lets start with the basics: > >>> - is sqlite even involved - it will only be used on rawhide builds if > >>> mock bootstrap is used > >>> - does it make a difference if you override _db_backend to bdb/sqlite > >>> from mock config / cli define > >>> - a reproducer please (eg, what package is considerably slower to > >>> build than before, and by how much) > >> And: Does the difference reproduce when building on tmpfs? > > Good time to say that you can use an NBD loopback to mock-build either > > on a userspace ramdisk or backed by a disk but discarding flush > > requests. The performance is indistinguishable from tmpfs (and much > > more flexible in other ways). I did some benchmarking a couple of > > weeks ago: > > > > https://www.redhat.com/archives/libguestfs/2020-May/msg00053.html > > https://www.redhat.com/archives/libguestfs/2020-May/msg00074.html > > > > Easy set up is: > > > > # rm -f /tmp/sock > > # nbdkit -U /tmp/sock memory 100G > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > > # mkfs.xfs /dev/nbd0 > > # mount /dev/nbd0 /var/lib/mock > > > > or using http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html: > > > > # rm -f /tmp/sock > > # nbdkit -U /tmp/sock tmpdisk size=100G > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 1 > > # mount /dev/nbd0 /var/lib/mock > > > > or (requires bleeding edge nbdkit): > > > > # rm -f /tmp/sock > > # lvcreate -L 100G -n tmp /dev/fedora > > # nbdkit -U /tmp/socket --filter=fua fuamode=discard file /dev/fedora/tmp > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > > # mkfs.xfs /dev/nbd0 > > # mount /dev/nbd0 /var/lib/mock > > > > Rich. > > > > NBD kit is definitely interesting piece of technology, but I think there > is missing quite a bit to be as easy as you say and there is definitely > a lot of missing information, e.g. does the setup persist reboots? It > would be probably more interesting, if it was mock plugin the same way > tmpfs or lvm plugins are. A very fair point - it won't be easy to use until it's a plugin. Currently I'm looking at integrating nbdkit into kubenetes, so I don't really have time to look at mock. In answer to your specific question, does it survive over reboots? Answer in two parts: (1) Not if you just type those commands, but you can set up a systemd unit: http://libguestfs.org/nbdkit-service.1.html I haven't worked out the systemd voodoo to make an NBD filesystem mount itself automatically at boot, although that is undoubtedly possible using a mount unit. Difficult bit will be setting up the dependencies. For the RISC-V Koji builders I'm using nbdkit, but it's "hacked" using /etc/rc.local. (2) Additionally the memory plugin (http://libguestfs.org/nbdkit-memory-plugin.1.html) is a RAM disk, and the tmpdisk plugin (http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html) is intentionally designed to be like a "remote tmpfs". So obviously neither will survive a reboot. That's fine for mock builds. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Has something changed with RPMS?
On Wed, 2020-06-03 at 10:46 +0300, Panu Matilainen wrote: > > > > So this still seems kinda mysterious. Either somehow > > > it wasn't fsync'ing before but it is now, or somehow disk writing > > > performance on my system fell off a cliff? > > > > > > I'll try and poke it some more tomorrow if I can, try some old kernels > > > and/or old mock builds or something. > > > > > > > Found it. > > > > Nothing to do with databases, it's the new automatic SSD detection which > > also enables _flush_io to fsync files as we go during transactions. It > > does this on the grounds that it's good for the system otherwise (avoids > > trashing the caches and io peaks) and that it's not prohibitively > > expensive on SSD, but I guess this here quite clearly shows that it > > actually is. > > > > Will fix shortly. > > Okay, fixed in rpm-4.16.0-0.beta1.2 in rawhide. > > For it to take effect though, the bootstrap-root needs to be updated (or > recreated). I don't know whether mock updates that automatically and if > it does, under what circumstances. > > That's also how this all relates to the bootstrap stuff: > When using mock without bootstrap, host rpm config is used. On Fedora < > 33 hosts, rpm doesn't automatically enable the io-flushing so things are > fast if not using bootstrap, or building for F < 33. And OTOH if running > from a rawhide host things would be slow unless you were building for F > < 33 with a bootstrap. > > And that's also why you didn't need nosync before but suddenly it makes > a huge difference. Wow, thanks a ton for looking into that and fixing it so quickly! Really appreciate it. It sure would've taken me a lot longer to get there :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 6/3/20 4:50 PM, Jonathan Wakely wrote: > On 03/06/20 13:36 +0200, Miro Hrončok wrote: >> On 03. 06. 20 13:32, Till Hofmann wrote: >>> Yes, that's what I meant. I'm not going to test patches by submitting >>> builds over and over again, that's not really time efficient. I'll just >>> wait until it shows up in mock. >> >> $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel >> ... >> Installed: >> boost-devel-1.73.0-3.fc33.x86_64 >> ... > > Right. Using --enablerepo=local means your mock build will use the > buildroot, so you don't have to wait for it to be in the next compose. > > You do not need to wait, it's there now. I've ben building against it > locally for the past two days. > Thanks, I forgot about the local repo. Kind regards, Till ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03/06/20 13:36 +0200, Miro Hrončok wrote: On 03. 06. 20 13:32, Till Hofmann wrote: Yes, that's what I meant. I'm not going to test patches by submitting builds over and over again, that's not really time efficient. I'll just wait until it shows up in mock. $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel ... Installed: boost-devel-1.73.0-3.fc33.x86_64 ... Right. Using --enablerepo=local means your mock build will use the buildroot, so you don't have to wait for it to be in the next compose. You do not need to wait, it's there now. I've ben building against it locally for the past two days. ___ 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: Many packages unnecessarily link to libpython
On 2020-05-31 10:24, Honggang LI wrote: On Fri, May 29, 2020 at 06:47:35PM +0200, Petr Viktorin wrote: On 2020-05-18 03:53, Honggang LI wrote: On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote: rdma-coredledford honli jwilson rdma-core pyverbs must be linked with libpython38. For example, build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep -w U | grep PyInterpreterState_GetID U PyInterpreterState_GetID Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep PyInterpreterState_GetID 000c6a82 T PyInterpreterState_GetID This is exactly the case where the module should *not* be linked to /usr/lib64/libpython3.8.so. mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is loaded from Python when imported. The import will link link it to the particular Python interpreter it's imported into, which could be using a different libpython3.8.so (such as the debug version). OK, I see the problem now. But I don't know how to handle this. Let's take ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so as example. 1) Link with debug version. [honli@localhost pyverbs (master)]$ gcc -fPIC -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations -Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time -Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition -Wredundant-decls -O2 -g -DNDEBUG -Wl,--as-needed -Wl,--no-undefined -shared -Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o -Wl,-rpath,/home/honli/upstream/rdma-core/build/lib: ../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9d [honli@localhost pyverbs (master)]$ ldd ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so linux-vdso.so.1 (0x7fff2fbe4000) libibverbs.so.1 => /home/honli/upstream/rdma-core/build/lib/libibverbs.so.1 (0x7feed22c3000) libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7feed1e6e000) libc.so.6 => /lib64/libc.so.6 (0x7feed1ca3000) libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x7feed1c1b000) libnl-3.so.200 => /lib64/libnl-3.so.200 (0x7feed1bf7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7feed1bd5000) libdl.so.2 => /lib64/libdl.so.2 (0x7feed1bcc000) libutil.so.1 => /lib64/libutil.so.1 (0x7feed1bc7000) libm.so.6 => /lib64/libm.so.6 (0x7feed1a81000) /lib64/ld-linux-x86-64.so.2 (0x7feed22f7000) [honli@localhost pyverbs (master)]$ ldd ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9d.so.1.0 libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7f32570ac000) [honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9d.so.1.0 python3-debug-3.9.0~b1-3.fc33.x86_64 2) link with normal version [honli@localhost pyverbs (master)]$ gcc -fPIC -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations -Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time -Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition -Wredundant-decls -O2 -g -DNDEBUG -Wl,--as-needed -Wl,--no-undefined -shared -Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o -Wl,-rpath,/home/honli/upstream/rdma-core/build/lib: ../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9 [honli@localhost pyverbs (master)]$ ldd ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9 libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x7f7f8a7c7000) [honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9.so.1.0 python3-libs-3.9.0~b1-3.fc33.x86_64 As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to the linker. Otherwise, a lot of "undefined reference to xxx" error messages show up. /home/honli/upstream/rdma-core/build/pyverbs/srq.c:10425: undefined reference to `PyErr_GivenExceptionMatches' /home/honli/upstream/rdma-core/build/pyverbs/srq.c:8987: undefined reference to `_PyObject_GenericGetAttrWithDict' /home/honli/upstream/rdma-core/build/pyverbs/srq.c:7786: undefined reference to `PyModuleDef_Init' [honli@localhost pyverbs (master)]$ grep undefined error.txt |wc -l 876 Any hits how to handle this? Judging from the file name, mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module. If that's so, you shouldn't link it using gcc, but use a Python import statement to load it. Is there some reason to link it using gcc? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://
Fedora-IoT-32-20200603.0 compose check report
No missing expected images. Passed openQA tests: 11/11 (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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03. 06. 20 13:32, Till Hofmann wrote: Yes, that's what I meant. I'm not going to test patches by submitting builds over and over again, that's not really time efficient. I'll just wait until it shows up in mock. $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel ... Installed: boost-devel-1.73.0-3.fc33.x86_64 ... -- 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 6/3/20 1:01 PM, Frantisek Zatloukal wrote: > > > On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely > mailto:jwak...@fedoraproject.org>> wrote: > > On 03/06/20 12:35 +0200, Till Hofmann wrote: > > > > > >On 6/2/20 5:24 PM, Jonathan Wakely wrote: > >> ### C++ includes > >> > >> Several packages failed to build because they couldn't find C++ > >> Standard Library algorithms: > > > >> freeopcua: error: 'for_each' is not a member of 'std' > > > >I don't see a changelog entry (or a commit), did you only update the > >changelog if the build was successful? > > Yes. > > >I'll fix this as soon as boost 1.73 shows up in rawhide. > > It's already there. > > > Just note that it is in Rawhide, but you might not get it in mock and/or > system update before next Rawhide compose. It is in buildroot however as > can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33" > Yes, that's what I meant. I'm not going to test patches by submitting builds over and over again, that's not really time efficient. I'll just wait until it shows up in mock. Kind regards, Till ___ 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: Has something changed with RPMS?
On Wed, Jun 3, 2020 at 2:47 AM Panu Matilainen wrote: > > Okay, fixed in rpm-4.16.0-0.beta1.2 in rawhide. > > For it to take effect though, the bootstrap-root needs to be updated (or > recreated). I don't know whether mock updates that automatically and if > it does, under what circumstances. > I know it used to, every once in a while I would see something to the effect of "Root has aged out and will be rebuilt." But I assume a --scrub=root-cache would suffice? Thanks, Richard ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely wrote: > On 03/06/20 12:35 +0200, Till Hofmann wrote: > > > > > >On 6/2/20 5:24 PM, Jonathan Wakely wrote: > >> ### C++ includes > >> > >> Several packages failed to build because they couldn't find C++ > >> Standard Library algorithms: > > > >> freeopcua: error: 'for_each' is not a member of 'std' > > > >I don't see a changelog entry (or a commit), did you only update the > >changelog if the build was successful? > > Yes. > > >I'll fix this as soon as boost 1.73 shows up in rawhide. > > It's already there. Just note that it is in Rawhide, but you might not get it in mock and/or system update before next Rawhide compose. It is in buildroot however as can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33" ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03/06/20 12:35 +0200, Till Hofmann wrote: On 6/2/20 5:24 PM, Jonathan Wakely wrote: ### C++ includes Several packages failed to build because they couldn't find C++ Standard Library algorithms: freeopcua: error: 'for_each' is not a member of 'std' I don't see a changelog entry (or a commit), did you only update the changelog if the build was successful? Yes. I'll fix this as soon as boost 1.73 shows up in rawhide. It's already there. ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 6/2/20 5:24 PM, Jonathan Wakely wrote: > ### C++ includes > > Several packages failed to build because they couldn't find C++ > Standard Library algorithms: > freeopcua: error: 'for_each' is not a member of 'std' I don't see a changelog entry (or a commit), did you only update the changelog if the build was successful? I'll fix this as soon as boost 1.73 shows up in rawhide. Kind regards, Till ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On 03/06/20 09:53 -, Markus Neteler wrote: Hi Here another package: PDAL https://src.fedoraproject.org/rpms/PDAL/tree/master It depends on boost and I don't see changes in changelog. It wasn't found by the repoquery last week, because the package didn't exist when I started rebuilding things for Boost. I can't rebuild packages that don't exist yet. (at time it fails to compile due to this change, see https://bugzilla.redhat.com/show_bug.cgi?id=1843094) That says it fails to install, not fails to compile. Did you simply try rebuilding it? I've started a new build now: Building PDAL-2.1.0-7.fc33 for rawhide Created task: 45355046 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=45355046 ___ 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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
Hi Here another package: PDAL https://src.fedoraproject.org/rpms/PDAL/tree/master It depends on boost and I don't see changes in changelog. (at time it fails to compile due to this change, see https://bugzilla.redhat.com/show_bug.cgi?id=1843094) Best, Markus ___ 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: "how to install" is supposed to work?
Dne 03. 06. 20 v 11:03 Alessio napsal(a): > On Wed, 2020-06-03 at 10:54 +0200, Vít Ondruch wrote: >> Dne 02. 06. 20 v 9:32 Alessio napsal(a): >>> In Bodhi there is a dnf command in the "How to install" section, in >>> order to install the package to test. Something like: >>> >>> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA- >>> 2020- >>> 81a3b3df7d >>> >>> Is it supposed to work? Because every time I tried it, it didn't >>> work. >> Could you please provide more details about "it didn't work". Reading > It doesn't install anything: "Nothing to do." If this is the actual message, this should really be updated. If it said at least something as "advisory FEDORA- 2020-81a3b3df7d was not found in metadata", it would be more helpful. I think it would be good to open BZ ticket against DNF suggesting this to improve. Bodhi is trying to be helpful but DNF not at all. Vít > > But as clarified in this thread, it is a mirror propagation issue. Need > to wait, then it works. > > > A. > ___ > 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: Has something changed with RPMS?
Dne 02. 06. 20 v 19:26 Richard W.M. Jones napsal(a): > On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote: >> * Panu Matilainen: >> >>> Lets start with the basics: >>> - is sqlite even involved - it will only be used on rawhide builds if >>> mock bootstrap is used >>> - does it make a difference if you override _db_backend to bdb/sqlite >>> from mock config / cli define >>> - a reproducer please (eg, what package is considerably slower to >>> build than before, and by how much) >> And: Does the difference reproduce when building on tmpfs? > Good time to say that you can use an NBD loopback to mock-build either > on a userspace ramdisk or backed by a disk but discarding flush > requests. The performance is indistinguishable from tmpfs (and much > more flexible in other ways). I did some benchmarking a couple of > weeks ago: > > https://www.redhat.com/archives/libguestfs/2020-May/msg00053.html > https://www.redhat.com/archives/libguestfs/2020-May/msg00074.html > > Easy set up is: > > # rm -f /tmp/sock > # nbdkit -U /tmp/sock memory 100G > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > # mkfs.xfs /dev/nbd0 > # mount /dev/nbd0 /var/lib/mock > > or using http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html: > > # rm -f /tmp/sock > # nbdkit -U /tmp/sock tmpdisk size=100G > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 1 > # mount /dev/nbd0 /var/lib/mock > > or (requires bleeding edge nbdkit): > > # rm -f /tmp/sock > # lvcreate -L 100G -n tmp /dev/fedora > # nbdkit -U /tmp/socket --filter=fua fuamode=discard file /dev/fedora/tmp > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > # mkfs.xfs /dev/nbd0 > # mount /dev/nbd0 /var/lib/mock > > Rich. > NBD kit is definitely interesting piece of technology, but I think there is missing quite a bit to be as easy as you say and there is definitely a lot of missing information, e.g. does the setup persist reboots? It would be probably more interesting, if it was mock plugin the same way tmpfs or lvm plugins are. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bodhi: "how to install" is supposed to work?
On Wed, 2020-06-03 at 10:54 +0200, Vít Ondruch wrote: > Dne 02. 06. 20 v 9:32 Alessio napsal(a): > > In Bodhi there is a dnf command in the "How to install" section, in > > order to install the package to test. Something like: > > > > sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA- > > 2020- > > 81a3b3df7d > > > > Is it supposed to work? Because every time I tried it, it didn't > > work. > > Could you please provide more details about "it didn't work". Reading It doesn't install anything: "Nothing to do." But as clarified in this thread, it is a mirror propagation issue. Need to wait, then it works. A. ___ 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: Many packages unnecessarily link to libpython
On Mon, Jun 01, 2020 at 02:59:32PM +0800, Honggang LI wrote:
>
> I think I know how to avoid link pyverbs without libpython3.9. I will
> fix this for rdma-core (fc33).
I confirmed this patch fix this issue. However, upstream wants all shared
ELFs have fully described linking. That means all python modules had
been linked to specific libpython intentionally.
Upstream maintainer's reply:
It is a bit dangerous as any shared library that uses symbol versions
like glibc, rdma-core bits, etc MUST be provided at link time, so you
loose the safety of no-undefined.
Frankly I think python it is solving their problem the wrong way, you
should never encourage linking like this.
As upstream unlikely apply this patch, I don't want to apply dangling patch
in Fedora. So, is it possible to ignore this for rdma-core? If no, what
is the next step?
Thanks
=
diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index ca41fbb4..9743e5cd 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -21,12 +21,12 @@ function(rdma_cython_module PY_MODULE LINKER_FLAGS)
)
string(REGEX REPLACE "\\.so$" "" SONAME
"${FILENAME}${CMAKE_PYTHON_SO_SUFFIX}")
-add_library(${SONAME} SHARED ${CFILE})
+add_library(${SONAME} MODULE ${CFILE})
set_target_properties(${SONAME} PROPERTIES
COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-functi
on-type -Wno-implicit-fallthrough -Wno-unknown-warning
-Wno-unknown-warning-option ${NO_VAR_TRACKING_FLAGS}"
LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
PREFIX "")
-target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
+target_link_libraries(${SONAME} LINK_PRIVATE ibverbs rdmacm
${LINKER_FLAGS})
install(TARGETS ${SONAME}
DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
endforeach()
=
>
> Thanks
___
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: "how to install" is supposed to work?
Dne 02. 06. 20 v 9:32 Alessio napsal(a): > In Bodhi there is a dnf command in the "How to install" section, in > order to install the package to test. Something like: > > sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020- > 81a3b3df7d > > Is it supposed to work? Because every time I tried it, it didn't work. Could you please provide more details about "it didn't work". Reading the rest of the thread, there were some valuable suggestions how to improve Bodhi, but shouldn't we improve DNF instead? E.g. if there is `--advisory` option specified on command line, it would provide the message: ~~~ "It takes some time to distribute updates. If the above command does not install anything, please try again later. It should normally not take longer than _." ~~~ already suggested in other parts of this thread. Also DNF could be smart enough to compare the state of Bodhi and mirrors (but I am not sure if the `FEDORA-2020-81a3b3df7d` metadata are part of the repo or if the Bodhi is already queried for them or not). Vít > In addition a package received a negative karma due to that ^_^; > > Ciao, > A. > ___ > 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: Upcoming fedoraproject Datacenter move reminder and plans
Just wonder, will there be any convenient way to remind me that the service is down for a reason? E.g. redirect to status page. It would be probably harder for all the CLI utilities we are using, but maybe something which should be addressed as well. Vít Dne 02. 06. 20 v 18:40 Kevin Fenzi napsal(a): > Greetings. > > As previously announced, fedoraproject is moving many of it's servers > from one datacenter (phx2 near phoenix, arizona, usa) to another (iad2: > near arlington, virginia, usa). > > As we move from the old datacenter to the new, we will have a temporary > reduction in capacity. The new datacenter has a smaller, less-redundant, > lower-capacity version of our infrastructure. Over the next two weeks, > we will migrate services to it so that we can finish moving out of the > old datacenter. > > After everything is moved from the old datacenter, many of the servers > there will be shipped to the new datacenter and then re-added to bring > us back to full redundency and capacity. > > Out detailed checklist for these migrations is available at > https://hackmd.io/@fedorainfra2020/rJpsA4FLL > > To summarize what we are moving when: > > 2020-06-03 wed: The fedoraproject master mirrors will move to IAD2. A > very small outage may be noticed as dns changes. There may be some > mirroring slowdowns as we work out bugs. > > 2020-06-04 thu: Our internal ansible control host and the fedoraproject > wiki will move. The wiki will be down for a few hours. > > 2020-06-05 fri: Our meeting minutes archive > (https://meetbot.fedoraproject.org) and our freenode irc bot (zodbot). > These two services will see a hour outage or less. > > 2020-06-07 sun: We will pause for the next week adding new packages and > unretiring packages to avoid problems. > > 2020-06-08 mon: Our fedora-messaging bus and gateways to it > (github2fedmsg, bugzilla2fedmsg), mirrormanager, product definition > center (pdc), and our identity and authentication systems. Messages over our > message bus may be slow or missing and users may be unable to login at > various times as we migrate services over. > > Additionally, we will be stopping services that will not be back until > later in the month. > These include: > * Fedocal > * Badges > * Nuancier > * koschei > * simple-koji-ci > * All staging services (*.stg.fedoraproject.org) > > 2020-06-09 tue: The build and packaging ecosystem. This includes koji, > src.fedoraproject.org, osbs, odcs, container registries, bodhi (updates > system). During this day maintainers should avoid builds/updates if at > all possible as they may or may not work at various times. > > 2020-06-10 wed: Various small apps (mdapi, anitya, waiverdb, greenwave, > etc), mailman/lists.fedoraproject.org, and our datagrepper/datanommer > services. Mailing lists will be down for several hours as data is > migrated. Datagrepper will be down for most of the day as it's database > is moved. Other services will be down for short amounts of time while > they are moved. > > 2020-06-11 thu: Various small site building apps (docs building, fedora > websites building, reviewstats, blockerbugs) and elections will be > moved. elections will be up until the currently running elections > complete. (GO VOTE! https://elections.fedoraproject.org) > > 2020-06-12 fri: Catch up and fix issues day, along with re-enabling > package unretirements/new packages, and other 'paused' items. > > The week after this servers will be shipped and the week after that we > expect to start setting them up and getting them re-added. During this > time, we may have to make further changes to what services are available > in order to deal with load changes. > > If you have any questions or concerns, please file an infrastructure > ticket ( https://pagure.io/fedora-infrastructure) or come talk to us in > #fedora-admin on irc.freenode.net. > > Finally, I'd like to ask everyone to be patient as we do this move. I > know that it's painful when you are unable to contibute something when > you have time to do so, but rest assured that we are trying to migrate > things as quickly and smoothly as we can. > > Thanks. > > kevin > > ___ > 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.fe
[Test-Announce] [F32] Fedora CoreOS Test Day 2020-06-08
Hey All, The CoreOS team is working towards the final F32 Fedora CoreOS. As a result, the Fedora CoreOS and QA teams have organized a Test Day[0] for Monday, June 08, 2020. Since this is the very first FCOS Test Day, we are looking for people to try out the ''next'' stream which contains all the new things which move into ''testing'' and then ''stable''. Participants will not only run the regular test cases[1] but also can validate the FCOS Documentation on docs.fp.o[2] , file bugs and share feedback/results[3]. The developers team members and QA team as usual will hang around #fedora-coreos[4] and will help folks! [0]https://fedoraproject.org/wiki/Test_Day:Fedora_32_CoreOS_2020-06-08 [1]https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases [2]https://docs.fedoraproject.org/en-US/fedora-coreos/ [3]http://testdays.fedorainfracloud.org/events/84 [4]https://webchat.freenode.net/#fedora-coreos Happy Testing! Thanks -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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/test-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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag
On Wed, 3 Jun 2020 at 01:07, Jonathan Wakely wrote: > > On 02/06/20 16:24 +0100, Jonathan Wakely wrote: > >### Boost.Bind > > > >Several packages failed to build because the Boost.Bind placeholders > >_1, _2, _3 etc. are no longer in the global namespace. See the message > >in : > > > >BOOST_PRAGMA_MESSAGE( > > "The practice of declaring the Bind placeholders (_1, _2, ...) " > > "in the global namespace is deprecated. Please use " > > " + using namespace boost::placeholders, " > > "or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior." > >) > > > >This Boost.Bind issue affects: > > > >bear-factory > >domoticz > >gazebo > >hpx > >liblas > >luxcorerender > >pdns > >pdns-recursor > >uhd > >widelands > > I believe in most cases this can be fixed by changing > to and adding "using boost::placeholders::_1;" > somewhere. If the codebase is large enough, that can be complicated. In my case, I just defined BOOST_BIND_GLOBAL_PLACEHOLDERS and added a couple of missing includes to (which weren't required in previous versions because other boost headers were probably including that). Here [1]. Of course, then I informed upstream. [1] https://src.fedoraproject.org/rpms/rstudio/blob/fb93b3619bcfef3dcfe815e43c93659546e69376/f/0006-boost-173-global-placeholders.patch -- Iñaki Úcar ___ 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-20200603.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: 609877 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/609877 -- 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: Has something changed with RPMS?
On 6/3/20 10:18 AM, Panu Matilainen wrote: On 6/3/20 9:27 AM, Adam Williamson wrote: On Wed, 2020-06-03 at 09:06 +0300, Panu Matilainen wrote: On 6/2/20 7:25 PM, Adam Williamson wrote: On Tue, 2020-06-02 at 11:05 -0500, Richard Shaw wrote: On Tue, Jun 2, 2020 at 10:25 AM Adam Williamson wrote: On Tue, 2020-06-02 at 06:34 -0500, Richard Shaw wrote: boost-devel, nosync=False, bootstrap=True real 1m13.294s user 0m6.723s sys 0m2.761s --- So it looks like boostrap=True and nosync=False is the culprit, which I inadvertantly got myself into. I did have either set and of course nosync would be False by default and it looks like bootstrap=True by default for rawhide. When you say 'bootstrap', which setting do you mean exactly? I don't see one that's just called 'bootstrap', I see --(no-)bootstrap-chroot and --(no-|use-)bootstrap-image . $ cat .config/mock.cfg config_opts['cleanup_on_failure'] = False config_opts['nosync'] = True config_opts['use_bootstrap'] = False I got this from the documentation, maybe should have searched a bit more, didn't think there was more than one bootstrap option. That seems to be the same as --bootstrap-chroot , i.e. --no-bootstrap- chroot should set it False. So, if I explicitly set nosync = True in mock.cfg it goes back to being as fast as I remember. But that's somewhat odd, because: a) I definitely didn't have explicit config to turn nosync on before b) I didn't actually have the nosync packages installed at all until after I hit this problem so it seems like somehow before I was getting fast performance without using nosync, but now I need it? Weird... Okay, that's useful. I'm not at all familiar with how this all actually works in mock but I see that nosync.so is being copied around etc, and with bootstrap introducing an extra layer in between, it's not hard to imagine a subtle bug or two in there. Just a guess though. The thing is, I'm really pretty sure I *wasn't using* mock's nosync support before. I don't see how I could have been, since I didn't have nosync installed. Ah, sorry I misunderstood that a bit originally. So this still seems kinda mysterious. Either somehow it wasn't fsync'ing before but it is now, or somehow disk writing performance on my system fell off a cliff? I'll try and poke it some more tomorrow if I can, try some old kernels and/or old mock builds or something. Found it. Nothing to do with databases, it's the new automatic SSD detection which also enables _flush_io to fsync files as we go during transactions. It does this on the grounds that it's good for the system otherwise (avoids trashing the caches and io peaks) and that it's not prohibitively expensive on SSD, but I guess this here quite clearly shows that it actually is. Will fix shortly. Okay, fixed in rpm-4.16.0-0.beta1.2 in rawhide. For it to take effect though, the bootstrap-root needs to be updated (or recreated). I don't know whether mock updates that automatically and if it does, under what circumstances. That's also how this all relates to the bootstrap stuff: When using mock without bootstrap, host rpm config is used. On Fedora < 33 hosts, rpm doesn't automatically enable the io-flushing so things are fast if not using bootstrap, or building for F < 33. And OTOH if running from a rawhide host things would be slow unless you were building for F < 33 with a bootstrap. And that's also why you didn't need nosync before but suddenly it makes a huge difference. - 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: Has something changed with RPMS?
On 6/3/20 9:27 AM, Adam Williamson wrote: On Wed, 2020-06-03 at 09:06 +0300, Panu Matilainen wrote: On 6/2/20 7:25 PM, Adam Williamson wrote: On Tue, 2020-06-02 at 11:05 -0500, Richard Shaw wrote: On Tue, Jun 2, 2020 at 10:25 AM Adam Williamson wrote: On Tue, 2020-06-02 at 06:34 -0500, Richard Shaw wrote: boost-devel, nosync=False, bootstrap=True real 1m13.294s user 0m6.723s sys 0m2.761s --- So it looks like boostrap=True and nosync=False is the culprit, which I inadvertantly got myself into. I did have either set and of course nosync would be False by default and it looks like bootstrap=True by default for rawhide. When you say 'bootstrap', which setting do you mean exactly? I don't see one that's just called 'bootstrap', I see --(no-)bootstrap-chroot and --(no-|use-)bootstrap-image . $ cat .config/mock.cfg config_opts['cleanup_on_failure'] = False config_opts['nosync'] = True config_opts['use_bootstrap'] = False I got this from the documentation, maybe should have searched a bit more, didn't think there was more than one bootstrap option. That seems to be the same as --bootstrap-chroot , i.e. --no-bootstrap- chroot should set it False. So, if I explicitly set nosync = True in mock.cfg it goes back to being as fast as I remember. But that's somewhat odd, because: a) I definitely didn't have explicit config to turn nosync on before b) I didn't actually have the nosync packages installed at all until after I hit this problem so it seems like somehow before I was getting fast performance without using nosync, but now I need it? Weird... Okay, that's useful. I'm not at all familiar with how this all actually works in mock but I see that nosync.so is being copied around etc, and with bootstrap introducing an extra layer in between, it's not hard to imagine a subtle bug or two in there. Just a guess though. The thing is, I'm really pretty sure I *wasn't using* mock's nosync support before. I don't see how I could have been, since I didn't have nosync installed. Ah, sorry I misunderstood that a bit originally. So this still seems kinda mysterious. Either somehow it wasn't fsync'ing before but it is now, or somehow disk writing performance on my system fell off a cliff? I'll try and poke it some more tomorrow if I can, try some old kernels and/or old mock builds or something. Found it. Nothing to do with databases, it's the new automatic SSD detection which also enables _flush_io to fsync files as we go during transactions. It does this on the grounds that it's good for the system otherwise (avoids trashing the caches and io peaks) and that it's not prohibitively expensive on SSD, but I guess this here quite clearly shows that it actually is. Will fix shortly. - 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: Supporting hibernation in Workstation ed., draft 1
On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr wrote: > > On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote: > > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr > > > > If kernel lockdown is what disables this, we should look at fixing kernel > > > lockdown so that it doesn't break hibernation. This is definitely a > > > security decision that we shouldn't be imposing on the masses > > > needlessly, in my opinion. > > > > > > Instead you propose imposing a loophole for attackers to easily deploy > > malware needlessly. Do you really not see how this is an untenable > > position for Fedora? > > In my opinion, the threat model you're proposing here is absurd. If people can > create a valid kernel image that will be loaded from a LUKS container, we have > bigger problems. Disk encryption isn't enabled by default. The no encryption case obviously has to be considered. And if it's enabled, the more likely attack vector is sabotage to induce a crash or corrupt user data, rather than malware injection. Since you don't know the nature of the attack, and neither do I, neither one of us knows when the corruption manifests or how. I also don't know all of the threat models the upstream developers are accounting for. Did you read all of the referenced lkml emails? Do you understand why there's a preference for AES-GCM, why they want to secure the encryption key in the TPM, and why they want to use TPM localities? And why they wanted it all simplified as well? Which, I think is sortof funny actually because none of it is very simple. If you understand those concerns and still have questions, you might consider directing your concerns upstream. -- 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
