Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
Probably better than switching the system-wide policy to LEGACY is to create a policy modifier which alters only the minimum size of DH keys. $ sudo echo "min_dh_size = 1023" > /etc/crypto-policies/policies/modules/DH-SIZE.pmod $ sudo update-crypto-policies --set DEFAULT:DH-SIZE The issue is already reported to the service desk. Lumír On 10/1/20 7:50 AM, Lumír Balhar wrote: Hello. I've upgraded to Fedora 33 beta and I've discovered a problem with Thunderbird. All email accounts work well except the Red Hat one with mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail). The problem is that Thunderbird does not show any error message but it's not able to communicate with the IMAP server. I'm not able to receive any message from the server. I'm able to send a message but a copy is then not saved to sent folder for the same reason. My first thought was that the problem is caused by a downgrade from 68.11 to 68.10 because Thunderbird currently FTBFS in Fedora 33 but it does not seem to be so. I've also tried to remove the account and add it back but it did not help because I was no longer able to log in to my account without any particular error message. I've also tried to delete the server's certificates. The problem seems to be caused by strict crypto policies in Fedora 33 and too small DH key provided by the server. $ update-crypto-policies --show DEFAULT $ openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername mail.corp.redhat.com CONNECTED(0003) depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = info...@redhat.com verify return:1 depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority verify return:1 depth=1 O = Red Hat, OU = prod, CN = Certificate Authority verify return:1 depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information Technology, emailAddress = serviced...@redhat.com, CN = mail.corp.redhat.com verify return:1 139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:ssl/statem/statem_clnt.c:2149: --- $ sudo update-crypto-policies --set LEGACY Setting system policy to LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername mail.corp.redhat.com CONNECTED(0003) depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = info...@redhat.com verify return:1 depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority verify return:1 depth=1 O = Red Hat, OU = prod, CN = Certificate Authority verify return:1 depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information Technology, emailAddress = serviced...@redhat.com, CN = mail.corp.redhat.com verify return:1 --- ... ... --- * OK IMAP4 ready As you can see above, the DH key provided by the server is too small so the SSL verification fails. Setting the crypto policies to LEGACY solves the issue for me and I am again able to recreate my Red Hat account in Thunderbird. Hope this helps. I'm going to report this problem to service desk. Lumír ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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
Thunderbird with mail.corp.redhat.com does not work on Fedora 33
Hello. I've upgraded to Fedora 33 beta and I've discovered a problem with Thunderbird. All email accounts work well except the Red Hat one with mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail). The problem is that Thunderbird does not show any error message but it's not able to communicate with the IMAP server. I'm not able to receive any message from the server. I'm able to send a message but a copy is then not saved to sent folder for the same reason. My first thought was that the problem is caused by a downgrade from 68.11 to 68.10 because Thunderbird currently FTBFS in Fedora 33 but it does not seem to be so. I've also tried to remove the account and add it back but it did not help because I was no longer able to log in to my account without any particular error message. I've also tried to delete the server's certificates. The problem seems to be caused by strict crypto policies in Fedora 33 and too small DH key provided by the server. $ update-crypto-policies --show DEFAULT $ openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername mail.corp.redhat.com CONNECTED(0003) depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = info...@redhat.com verify return:1 depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority verify return:1 depth=1 O = Red Hat, OU = prod, CN = Certificate Authority verify return:1 depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information Technology, emailAddress = serviced...@redhat.com, CN = mail.corp.redhat.com verify return:1 139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:ssl/statem/statem_clnt.c:2149: --- $ sudo update-crypto-policies --set LEGACY Setting system policy to LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername mail.corp.redhat.com CONNECTED(0003) depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = info...@redhat.com verify return:1 depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority verify return:1 depth=1 O = Red Hat, OU = prod, CN = Certificate Authority verify return:1 depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information Technology, emailAddress = serviced...@redhat.com, CN = mail.corp.redhat.com verify return:1 --- ... ... --- * OK IMAP4 ready As you can see above, the DH key provided by the server is too small so the SSL verification fails. Setting the crypto policies to LEGACY solves the issue for me and I am again able to recreate my Red Hat account in Thunderbird. Hope this helps. I'm going to report this problem to service desk. Lumír ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On 9/30/20 10:28 PM, Elliott Sales de Andrade wrote: On Wed, 30 Sep 2020 at 18:27, Marius Schwarz wrote: The working/non-working procedure is: Power on ... inserting the stick OK, but why insert the USB stick after power on? Wouldn't it be less trouble to insert beforehand so that the firmware will always see it? He was saying that if he puts the stick in earlier, it's less likely to be able to boot. It's not about the firmware seeing it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, 30 Sep 2020 at 18:27, Marius Schwarz wrote: > > Am 01.10.20 um 00:19 schrieb Elliott Sales de Andrade: > > Could it be a timing issue of some kind? > > the sooner i hit the boot from usb button, after the stick got inserted, > the higher is the propability to start. > > Are you saying you insert the USB stick _after_ turning on the > machine? Otherwise I don't understand the correlation between the > insertion and pressing a boot from USB button. > > > The working/non-working procedure is: > > Power on > ... > inserting the stick OK, but why insert the USB stick after power on? Wouldn't it be less trouble to insert beforehand so that the firmware will always see it? > Marius -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, Sep 30, 2020 at 4:22 PM Marius Schwarz wrote: > > Am 01.10.20 um 00:02 schrieb Chris Murphy: > > I made some more tests. It's a race, 1 out of 10 tries succeeds and the > chance that it does is improoved by inserting the usb drive while being > in the bios. > > The F31 grub files i exchanged do not seem to have something to do with it. > > The race happens with the same probability regardless of GRUB Fedora > release version? > > No, F31 boots everytime under any condition. It's only for F32/33 afaict. > > I tested it with the same stick, to avoid a problem with the stick > electronics itself. OK so some kind of regression in GRUB, but also a firmware bug because otherwise many other people would run into this. It's GRUB 2.02 in Fedora 31 and GRUB 2.04 in Fedora 32. So it could be an upstream bug. Where I'd start is making a livecd-iso-to-disk based USB stick, from the Fedora 32 ISO that you already know fails, and make sure it still fails when created this way. If it doesn't, then it's probably not GRUB it's something else about the image. But assuming it fails, you now have an easily modifiable USB stick, it's read-writable, so you can just copy each test grubx64.efi binary onto the stick. You could start with this, pretty sure it'll fail too. So just extract the grubx64.efi from grub2-efi-x64-2.04-1.fc32.x86_64.rpm and replace the one on the USB stick. https://koji.fedoraproject.org/koji/buildinfo?buildID=1356278 -- 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: LTO and F33
On 9/30/20 7:39 AM, Robert-André Mauchin wrote: On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote: So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of have been resolved (by opting the package out of LTO). I still expect some LTO issues will pop up as packages fix things like missing dependencies, cmake macros, etc. I continue to be available to investigate potential LTO issues, but package maintainers will need to contact me as I'm not actively looking for new LTO issues. My focus is now turning to the packages with LTO opt-outs. I'll be extracting bug reports for upstream (primarily GCC), trying simple workarounds for old style symbol versioning, identifying backports from upstream GCC that allow us to remove LTO opt-outs and the like. So there should be a trickle of opt-outs removed, but otherwise should largely be invisible to the F33 release process. I'd like to thank everyone involved for being patient while we worked through various issues and I look forward to continuing to make incremental improvements now that the bulk of the LTO work has landed. jeff I have an issue with both Clementine and Strawberry (a fork of Clementine) in F33 and above, users reported that disabling LTO fixes the problem. Can you run objdump -CR on the executable and send me the result privately? That will be enough to verify its the same problem with the same solution as kstars. Jeff ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 7:14 PM, Colin Walters wrote: That's not true, you can `rpm-ostree override remove`. It'd still be there in the ostree repository on disk, but you don't see it in the "deployment" (what you actually boot into). Few people care about disk space that much, and if you do you can do custom builds. ...but can we can do that and will updates to FCOS work after? I am pretty sure currently the answer is no, unless I don't fully understand the impacts of https://github.com/coreos/fedora-coreos-tracker/issues/400 I would be making tons of package changes to my deployment of FCOS but the chance of breaking updates isn't worth it. Even after this split happens and you can install systemd-networkd will I break my updates then too? About half the people on this thread are living the experience ofhttps://xkcd.com/386/ Ehh. There has been a lot of talking past each other in this thread and in https://github.com/coreos/fedora-coreos-config/pull/574 which is the reason for this thread in the first place. All of this grief and extra work could have be avoided if we added added the ~1M of hacked out systemd-networkd binaries back into FCOS and moved on with our lives... but here we are! Joe -- Joe Doss j...@solidadmin.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
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 4:36 PM, Neal Gompa wrote: On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote: "All Fedora variants, both with ostree and without..." maybe? OSTree-based variants are also "regular Fedora". I would only even remotely consider agreeing with that premise for Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in my view, since they completely sidestep the normal release engineering process, don't use the same repositories, and have the power to include and exclude packages from the total available package set at their leisure. There is no expectation with those variants that anything you do will necessarily show up there. Heck, Fedora CoreOS is reverting a system-wide change in its variant (SQLite rpmdb), and had previously also reverted another one (cgroup v2). The merits of those changes aside, this makes the experience materially different than everything else we have. This is a pretty good point Neal. Let's take cgroups v2 for example. The expectation of Fedora 32 having cgroups v2 is pretty clear, but stable FCOS which is based off of Fedora 32 has cgroups v1 enabled instead. This is a pretty jarring experience when you are moving from say Fedora 32 Cloud to FCOS 32.20200907.3.0. Both say Fedora 32 in their versions, but have a totally different technical experience when it comes to cgroups. Same can be said with systemd-networkd, but I won't rehash what is already said in https://github.com/coreos/fedora-coreos-config/pull/574 FCOS and Fedora IOT carry the Fedora name but they break ranks with the rest of Fedora in terms of packages, release engineering, and Fedora wide changes. This leads to frustrating experiences as a Fedora user because the technical expectations of what should be Fedora wide technical stances are a moving target for these variants. Joe -- Joe Doss j...@solidadmin.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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Tuesday, September 29, 2020 9:36:38 AM MST Dan Williams wrote: > On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote: > > > On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski- > > Szmek > > wrote: > > > > > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote: > > > > > > > > > > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro > > > > wrote: > > > > > > > > > > > > > You can do this, but again, you need to use the command line. > > > > > E.g. > > > > > 'resolvectl dns tun0 8.8.8.8' > > > > > > > > > > We're actually no longer debating how systemd-resolved works; > > > > > rather, > > > > > we're now debating how NetworkManager chooses to configure > > > > > systemd-resolved. systemd-resolved just does what it's told to > > > > > do. It's > > > > > > > > > > actually NetworkManager that decides to split DNS according to > > > > > routing > > > > > by default as a matter of policy. It could do otherwise if it > > > > > wanted > > > > > to, but I think this is a good default. Nothing stops you from > > > > > changing > > > > > > > > > > it though. :) > > > > > > > > > > > > Michael, > > > > By what mechanism does NetworkManager "split DNS according to > > > > routing"? If > > > > it hasn't already made a request from both your cleartext and > > > > your VPN > > > > connection's DNS servers, it has no way of knowing what network > > > > should be > > > > used to get the right results. Routing and DNS are unrelated. > > > > > > > > > NetworkManager pushes DNS server configuration (and associated bits > > > like > > > domain search and routing domains) over dbus to resolved. That way > > > it > > > "[tells resolved how to] split DNS according to routing". Of > > > course, after > > > the name has been resolved to an IP address, the packets to that IP > > > address > > > are routed too. So there is "routing" in the sense of deciding > > > which > > > interface is appropriate for a given DNS name and "routing" in the > > > sense of > > > deciding which interface is appropriate for a given IP address. > > > > > > It seems that the terminology is fairly confusing, considering it's > > right > > alongside actual routing configuration.. Okay, so "routing" means > > something > > wildly different than you'd think with systemd-resolved, got it. > > > > In most cases, in order to get to a DNS server inside a VPN, your > > packets have > > to have a route which can reach the IP of that server for that > > interface, > > which is configured using NetworkManager (or a VPN config file, > > imported into > > NM). Anyone that understands basic networking will likely be confused > > by this > > terminology. > > > > That aside, where in NetworkManager do these "routing domains" get > > specified? > > > In the connection itself (GUI or CLI), or they come from DHCP or SLAAC > or the VPN. > > nmcli con mod rh-openvpn ipv4.dns-search "foobar.com" > nmcli con mod rh-openvpn ipv4.never-default true > > combined with having a local caching DNS server (or resolved) enabled > will route queries for those search domains only to the VPN-provided > DNS servers. > > There are corresponding GUI boxes for these in nm-connection-editor, > GNOME network settings, and KDE. Dan, This would require a list of search domains a mile long, and for the end user to know what needs to go over the VPN anyway. Additionally, this may well break scripts that expect a given short name complication, but end up getting it from a different domain, since they're all in search domains now. -- 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020, at 5:20 PM, Neal Gompa wrote: > Regular Fedora variants are installed via normal package management > actions and have full granularity. RPM-OSTree reduces the granularity > of the operating system to a singular image that you layer on top. But > you cannot pull out stuff from the image. That's not true, you can `rpm-ostree override remove`. It'd still be there in the ostree repository on disk, but you don't see it in the "deployment" (what you actually boot into). Few people care about disk space that much, and if you do you can do custom builds. About half the people on this thread are living the experience of https://xkcd.com/386/ ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:systemd-resolved
On Wed, Sep 30, 2020 at 7:34 pm, Colin Walters wrote: I know this is already an epic thread but, just a FYI: This type of thing will completely not work on an rpm-ostree based system because the %post is run server side. It can't compute anything based on per-user data (and that's *also* true even when doing client side layering - the `/etc` that the `%post` script sees is the defaults, not anything a user has customized). In general, any upgrade logic that needs to take into account user configuration needs to be a systemd unit, not a `%post`. Hmmm, that probably means that users who upgrade Silverblue from F32 -> F33 will be broken. ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:systemd-resolved
On Wed, Sep 30, 2020, at 4:17 PM, Michael Catanzaro wrote: > On Wed, Sep 30, 2020 at 9:58 pm, Petr Menšík > wrote: > > Shouldn't it change resolv.conf only in case NM is active AND > > resolv.conf is generated by Network Manager? > > Correct, that's indeed what it does. (Since Zbigniew changed it > yesterday. Previously, it did not check if NM is active.) I know this is already an epic thread but, just a FYI: This type of thing will completely not work on an rpm-ostree based system because the %post is run server side. It can't compute anything based on per-user data (and that's *also* true even when doing client side layering - the `/etc` that the `%post` script sees is the defaults, not anything a user has customized). In general, any upgrade logic that needs to take into account user configuration needs to be a systemd unit, not a `%post`. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 01.10.20 um 00:19 schrieb Elliott Sales de Andrade: >> Could it be a timing issue of some kind? >> >> the sooner i hit the boot from usb button, after the stick got inserted, >> the higher is the propability to start. >> > Are you saying you insert the USB stick _after_ turning on the > machine? Otherwise I don't understand the correlation between the > insertion and pressing a boot from USB button. > The working procedure is: Power on entering Bios switching to boot manager page inserting the stick waiting until it gets powered on swiping the usb storage boot entry to left acknowledging the usb boot. None working procedure: Power on Inserting stick switching to bios switching to boot manager page swiping the usb storage boot entry to left acknowledging the usb boot. ... none secure boot message from bios reset. Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 01.10.20 um 00:02 schrieb Chris Murphy: >> I made some more tests. It's a race, 1 out of 10 tries succeeds and the >> chance that it does is improoved by inserting the usb drive while being >> in the bios. >> >> The F31 grub files i exchanged do not seem to have something to do with it. > The race happens with the same probability regardless of GRUB Fedora > release version? > No, F31 boots everytime under any condition. It's only for F32/33 afaict. I tested it with the same stick, to avoid a problem with the stick electronics itself. best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, 30 Sep 2020 at 17:42, Marius Schwarz wrote: > > Am 30.09.20 um 23:00 schrieb Chris Murphy: > > > > > > And then these are current > > grub2-efi-x64-2.04-31.fc33.x86_64 > > grub2-efi-x64-2.04-23.fc32.x86_64 > > grub2-efi-x64-2.02-110.fc31.x86_64 > > > > I wonder if the affected hardware is adversely affected by all three > > of these versions of GRUB? > > > > I made some more tests. It's a race, 1 out of 10 tries succeeds and the > chance that it does is improoved by inserting the usb drive while being > in the bios. > > The F31 grub files i exchanged do not seem to have something to do with it. > > Could it be a timing issue of some kind? > > the sooner i hit the boot from usb button, after the stick got inserted, > the higher is the propability to start. > Are you saying you insert the USB stick _after_ turning on the machine? Otherwise I don't understand the correlation between the insertion and pressing a boot from USB button. > I think we can rule out signing here as the surface is in none secure > boot mode and it starts ( screenshot available). > > So what else could cause this? > > best regards, > Marius > ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 11:49 pm, Björn Persson wrote: So there's no need to revert any changes to /etc/nsswitch.conf? I've seen some discussion about that file in relation to systemd-resolved. It seemed far from easy to understand how to make it work correctly. You don't have to touch /etc/nsswitch.conf because it's designed to work with or without systemd-resolved running: resolve [!UNAVAIL=return]. If it's not running it will fall back to nss-myhostname and then nss-dns. WARNING: Do not make manual changes to /etc/nsswitch.conf! Remember to edit /etc/authselect/user-sswitch.conf instead, then run 'sudo authselect apply-changes' ___ 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: F33 update stuck for past 6 days in request for testing->stable
On 30. 09. 20 22:54, Tony Asleson wrote: I posed the question on IRC if this fix-up script gets run after freeze and the answer was it could. I don't want to get caught with this again, so I'm in the process of adding epoch and rolling new releases across the board as it seems like the safest approach. Just wish I had done this as I had planned 4+ weeks ago. I'm sincerely sorry that I have caused you this much trouble with my advice :( -- 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: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, Sep 30, 2020 at 3:42 PM Marius Schwarz wrote: > > Am 30.09.20 um 23:00 schrieb Chris Murphy: > > > > > > And then these are current > > grub2-efi-x64-2.04-31.fc33.x86_64 > > grub2-efi-x64-2.04-23.fc32.x86_64 > > grub2-efi-x64-2.02-110.fc31.x86_64 > > > > I wonder if the affected hardware is adversely affected by all three > > of these versions of GRUB? > > > > I made some more tests. It's a race, 1 out of 10 tries succeeds and the > chance that it does is improoved by inserting the usb drive while being > in the bios. > > The F31 grub files i exchanged do not seem to have something to do with it. The race happens with the same probability regardless of GRUB Fedora release version? > > Could it be a timing issue of some kind? > > the sooner i hit the boot from usb button, after the stick got inserted, > the higher is the propability to start. > > I think we can rule out signing here as the surface is in none secure > boot mode and it starts ( screenshot available). > > So what else could cause this? Sounds like a firmware bug. I wonder if it's strictly USB related or if it's at all triggered by the isohybrid nature of our ISOs - maybe it's more or less likely to happen if the USB stick were created using livecd-iso-to-disk with '--format --efi' options and allow it to blow away the entire USB stick. -- 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Michael Catanzaro wrote: > On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski > wrote: > > What if I'm using NetworkManager and dnssec-trigger? This has been > > working very well for me for the last couple of releases and I'd hate > > to be forced to manually reconfigure things so that it starts working > > again. > > The upgrade process is designed to do the right thing for users who > stick with our defaults. Manual intervention is required for unusual > cases like this. You'll need to manually disable systemd-resolved after > upgrade, restore /etc/resolv.conf from the backup file that will be > created during upgrade, and restart NetworkManager. That would look > something like: > > # systemctl disable systemd-resolved.service > # systmectl stop systemd-resolved.service > # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf > # systemctl restart NetworkManager.service So there's no need to revert any changes to /etc/nsswitch.conf? I've seen some discussion about that file in relation to systemd-resolved. It seemed far from easy to understand how to make it work correctly. Björn Persson pgp5_2mAhEYOs.pgp Description: OpenPGP digital signatur ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Mon, 2020-09-28 at 16:50 +0200, Jan Kratochvil wrote: > > For example during Fedora Package Review Process do some packages get > rejected > because they would make the distribution too large? Not worth of > including > such new package? I am not aware of such decision and it even sounds > funny to > me. But that is what you choose here by enforcing DWZ no matter how > little > savings it has. > I'm not aware of this ever happening. What has happened is packages being dropped from the installation images because it makes them too large -- is that perhaps what you're referring to? Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 2:34 PM, Paul Wouters wrote: > And as I indicated earlier, most server installs have no use for > systemd-resolved. Yes it can be disabled, but we didn't go all the > way to virtual servers and containers to have to install things > we will never use. +1, & simply 'minimal' installs ... > The ask I have is very small. When I install and upgrade, no? > a server via kickstart, > I want to be able to do a minimum install, and that it should be > possible that this does not include systemd-resolved". it'd be nice-to-have to have that level of granularity/selection in an Anaconda minimal server install, as well. > I have explained my use case, and I believe it is _very_ common use case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 30.09.20 um 23:00 schrieb Chris Murphy: > > > And then these are current > grub2-efi-x64-2.04-31.fc33.x86_64 > grub2-efi-x64-2.04-23.fc32.x86_64 > grub2-efi-x64-2.02-110.fc31.x86_64 > > I wonder if the affected hardware is adversely affected by all three > of these versions of GRUB? > I made some more tests. It's a race, 1 out of 10 tries succeeds and the chance that it does is improoved by inserting the usb drive while being in the bios. The F31 grub files i exchanged do not seem to have something to do with it. Could it be a timing issue of some kind? the sooner i hit the boot from usb button, after the stick got inserted, the higher is the propability to start. I think we can rule out signing here as the surface is in none secure boot mode and it starts ( screenshot available). So what else could cause this? best regards, Marius ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote: > > On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote: > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > > (rpm)ostree variants are Fedora variants - please don't using phrasing > > > implying otherwise. > > > IOW you just say: *all* Fedora variants use NetworkManager. > > They are not the same. Regular Fedora is considerably more > > customizable post-installation than OSTree-based variants. That's why > > I made that point. > > "All Fedora variants, both with ostree and without..." maybe? OSTree-based > variants are also "regular Fedora". > I would only even remotely consider agreeing with that premise for Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in my view, since they completely sidestep the normal release engineering process, don't use the same repositories, and have the power to include and exclude packages from the total available package set at their leisure. There is no expectation with those variants that anything you do will necessarily show up there. Heck, Fedora CoreOS is reverting a system-wide change in its variant (SQLite rpmdb), and had previously also reverted another one (cgroup v2). The merits of those changes aside, this makes the experience materially different than everything else we have. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Neal Gompa wrote: since it's only a couple of binaries averaging 2MB with a few unit files. My reply was aimed at Peter saying he'd like to not ship resolved, and I'm saying that we should *not* do that, because it makes things even harder and more complicated. These two statements cannot both we true. And as I indicated earlier, most server installs have no use for systemd-resolved. Yes it can be disabled, but we didn't go all the way to virtual servers and containers to have to install things we will never use. So I would like to know more about how this would "make things even harder and more complicated". The ask I have is very small. When I install a server via kickstart, I want to be able to do a minimum install, and that it should be possible that this does not include systemd-resolved". I have explained my use case, and I believe it is _very_ common use case. Paul ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote: > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > (rpm)ostree variants are Fedora variants - please don't using phrasing > > implying otherwise. > > IOW you just say: *all* Fedora variants use NetworkManager. > They are not the same. Regular Fedora is considerably more > customizable post-installation than OSTree-based variants. That's why > I made that point. "All Fedora variants, both with ostree and without..." maybe? OSTree-based variants are also "regular Fedora". -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 4:45 PM PGNet Dev wrote: > > anyone else more confused? > > On 9/30/20 1:26 PM, Neal Gompa wrote: > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and*will be removed eventually*. > > is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct > dependency on systemd-resolved -- considered 'legacy'? > NetworkManager never uses networkd. But when I refer to legacy setups, I'm referring to everything related to ifcfg and legacy network-scripts. Insofar as networkd goes, I wouldn't consider it legacy, but I would also not consider it contemporary, since nobody bothered to make it useful enough to support all the cases that Wicked and NetworkManager support. > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > > how 'bout I turn the question around ... > > what specific steps must be done POST- F32->F32 upgrade to > > (1) not use NetworkManager > (2) not use systemd-resolved > > (3) return/preserve local configs for systemd-networkd & 'enterprise' > (own resolver) DNS configs? > > ? > > > Regular Fedora is considerably more > customizable post-installation than OSTree-based variants. > > For those of us that don't live&breathe the lingo, it's not exactly clear > what 'Regular Fedora' is. > Regular Fedora variants are installed via normal package management actions and have full granularity. RPM-OSTree reduces the granularity of the operating system to a singular image that you layer on top. But you cannot pull out stuff from the image. > Is there _any_ variant of Fedora that's immune now, and in the planned > future, from "use NetworkManger" and (therefore) systemd-resolved? > > Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade > maintenance that apparently needs to be planned for -- as long as its still > doable. > > If/when does that no longer remain an option? If you want to deactivate resolved and use something else, you can. If you did so prior to upgrading to F33, that will persist. Only users who didn't do anything would get the change. One of my machines uses dnsmasq and I have NetworkManager configured with that. That does not break with the move to Fedora 33, since I set it up that way. I'm sure there are people running NetworkManager with unbound, and I expect that to stay working too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 01:45:13PM -0700, PGNet Dev wrote: > anyone else more confused? > > On 9/30/20 1:26 PM, Neal Gompa wrote: > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and*will be removed eventually*. > > is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct > dependency on systemd-resolved -- considered 'legacy'? NM does not wrap systemd-networkd. Both remain fully independent ways to configure networking. The future of systemd-networkd is unclear: it is being developed upstream, but is largely unused in Fedora. It does work well in certain scenarios, as you know. I don't think there's any plan to change this. > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > > how 'bout I turn the question around ... > > what specific steps must be done POST- F32->F32 upgrade to > > (1) not use NetworkManager > (2) not use systemd-resolved > > (3) return/preserve local configs for systemd-networkd & 'enterprise' > (own resolver) DNS configs? I don't think there's anything special needed for (1) and (3). For (2), please create a preset to disable systemd-resolved. E.g.: echo 'disable systemd-resolved.service' >/etc/systemd/system-preset/20-resolved.preset This will start being enough with the next systemd build though. I just pushed a change to not create the symlink if resolved is disabled: https://src.fedoraproject.org/rpms/systemd/c/d3d43af8adf70974f5e52d31df0b46935ff2ded2?branch=f33. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, Sep 30, 2020 at 10:46 AM Stephen John Smoogen wrote: > > The Fedora secure boot signing keys were updated after F32 was initially released to deal with the grub2 problems found during the summer. I believe some systems have needed firmware updates from the manufacturer to work with the new key because they worked by white listing the old set, and don't know how to handle when a new key signed and authorized is presented. I don't know how the Surface Pro does its firmware updates and if one is needed. Fedora 31, 32, and 33 have: shim-x64-15-8.x86_64 koji date 2018-10-02 The signing keys haven't yet been updated in Fedora, they'd need to happen here. And then these are current grub2-efi-x64-2.04-31.fc33.x86_64 grub2-efi-x64-2.04-23.fc32.x86_64 grub2-efi-x64-2.02-110.fc31.x86_64 I wonder if the affected hardware is adversely affected by all three of these versions of GRUB? ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 12:59:20PM -0400, Matthew Miller wrote: > On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote: > > >The main systemd systemd package Obsoletes the -standalone- packages, so it > > >should smoothly replace them whenever it is pulled in. > > > > I am confused by this bit. If systemd package Obsoletes the > > -standalone- packages, installing them is not possible unless you > > explicitly exclude systemd from the transaction and keep it excluded > > for upgrades. > > I expect so, if the use case is containers that will be replaced instead of > upgraded. The idea is that if you have an installation which does not need systemd, but want sysusers or tmpfiles, then you can pull in the -standalone- versions. They both have files that conflict with the main package, and declare Conflicts with it. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F33 update stuck for past 6 days in request for testing->stable
On 9/30/20 3:37 PM, Kevin Fenzi wrote: > On Wed, Sep 30, 2020 at 09:27:33PM +0200, Kalev Lember wrote: >> >> Ahh, sure, if the previous package was uninstallable then it should be fine >> to not use epoch. > > I suppose... > >> So two options here: a) file a releng ticket ( >> https://pagure.io/releng/issues) and ask them to re-tag the other build, or >> b) just bump release and rebuild and submit it to bodhi once more. > > Go for the releng ticket. I think bodhi may tell you there's a newer > version and refuse to make your update. I posed the question on IRC if this fix-up script gets run after freeze and the answer was it could. I don't want to get caught with this again, so I'm in the process of adding epoch and rolling new releases across the board as it seems like the safest approach. Just wish I had done this as I had planned 4+ weeks ago. Thanks, Tony ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 30.09.20 um 18:45 schrieb Stephen John Smoogen: > > The Fedora secure boot signing keys were updated after F32 was > initially released to deal with the grub2 problems found during the > summer. I believe some systems have needed firmware updates from the > manufacturer to work with the new key because they worked by white > listing the old set, and don't know how to handle when a new key > signed and authorized is presented. I don't know how the Surface Pro > does its firmware updates and if one is needed. I have replaced the files grubia32.efi and grubx64.efi in ANADCONDA:/EFI/BOOT/ with the ones from the F31 image. After 2 tries, the surface pro 4 booted like a charm. @Elmar: can you confirm this for your surface device? Sidenote: the files on the iso9660 partition are unchanged (because it mounts obviously ro ) best regards, Marius PS: I'm really excited to make an iso, that boots into a working surface kernel with touch enabled etc. . Unfortunatly, that kernel isn't fedora complient license wise :( ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
anyone else more confused? On 9/30/20 1:26 PM, Neal Gompa wrote: > And like it or not, all our legacy network configuration mechanisms > are deprecated and*will be removed eventually*. is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct dependency on systemd-resolved -- considered 'legacy'? > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. how 'bout I turn the question around ... what specific steps must be done POST- F32->F32 upgrade to (1) not use NetworkManager (2) not use systemd-resolved (3) return/preserve local configs for systemd-networkd & 'enterprise' (own resolver) DNS configs? ? > Regular Fedora is considerably more customizable post-installation than OSTree-based variants. For those of us that don't live&breathe the lingo, it's not exactly clear what 'Regular Fedora' is. Is there _any_ variant of Fedora that's immune now, and in the planned future, from "use NetworkManger" and (therefore) systemd-resolved? Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade maintenance that apparently needs to be planned for -- as long as its still doable. If/when does that no longer remain an option? ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/2020 1:26 PM, Neal Gompa wrote: On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: On 9/30/20 2:19 PM, Michael Catanzaro wrote: On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. Indeed, but I was responding to this: On 9/30/20 1:35 PM, Neal Gompa wrote: > Please, no more package splitting. And NetworkManager is used across > all variants of Fedora, so resolved should be installed in all places > where NetworkManager is used. Which (to my reading) says that because NetworkManager is the *default* everywhere (even though it can be uninstalled), systemd-resolved should be *installed* everywhere (and should not be uninstallable). I don't follow that logic. There are not a ton of advantages for splitting it, since it's only a couple of binaries averaging 2MB with a few unit files. Given that we require it for default NetworkManager configurations now, there's not a lot of value in making that complicated. Splitting has a cost too, in the form of extra metadata, upgrade paths, etc. Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. NetworkManager's configuration will use resolved as a local resolver. Anything baked into an OSTree cannot be removed anyway. And like it or not, all our legacy network configuration mechanisms are deprecated and *will be removed eventually*. Literally the only reason networkd was split out was because Fedora CoreOS was chainsawing it out at image build time and making it impossible for people to use it. To be frank, I do not want more permutations this low in the stack. It makes life incredibly difficult for figuring out working network setups. Splitting it out this low in the stack makes it easier to support (and create) cases where it's not used. What Fedora decides here still has knock-on effects downstream, including what EL users deal with. If there's a logical separation (and there is, and always has been), then discrete packages allow competent SA's to reduce on-system complexity. That really should be all the justification necessary IMHO. -jc ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: > > >the systemd package is getting a systemd-networkd subpackage split out > >that will contain systemd-networkd, networkctl, and the associated data > >files. > >This was requested by coreos maintainers: NetworkManager is used and skipping > >systemd-networkd allows the installation footprint and potential user > >confusion > >to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > >The main systemd systemd package Obsoletes the -standalone- packages, so it > >should smoothly replace them whenever it is pulled in. > > In which package will systemd-resolved be? Still in the main rpm. I don't see a good reason to split it out. It can be installed without being enabled (*). And with it being enabled by default in F33, there's even less reason to do so. networkd is a few times larger and likely to grow (we're adding support for new tunnel types, new protocols, and new features all the time. systemd-resolved shouldn't grow too much beyond current size.) (*) In general, allowing packages to be installed without being active is much more robust. If we are depending on a package not being present, it is easy for things go south if something pulls it in as dependency, and we have huge dependency trees, it's sometimes it's impossible to uninstall something because of transitive dependencies. Package need to have a reliable way to preconfigure if they will become active after installation. In fact we already built a system like this presets. But I see you point: it should be possible to opt out of systemd-resolved, and right now that's not entirely functional, because presets only decide whether systemd-resolved.service will be enabled, and the resolv.conf symlink manipulation is not conditionalized on that. I'll make it conditional too. Zbyszek > With enterprise server deployments, DNS will be managed by the network > via resolve.conf to enterprise DNS servers. These servers tend to have > "bind views" for different category of deployments. These deployments > will have no VPN, no mDNS requirements etc. They also do not need (and > most likely do not want) DNS caching. > > I believe it would be useful for kickstart installs to not install > systemd-resolved for these kind of typical server deployments. I think > this is an important use case to support. > > For Desktop systems, it could default to installing systemd-resolved. It > could even default to it for all installs including Server, as long as > the administrator has the option to not install it via a kickstart file. > > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. > > If there are strong reasons not to split systemd-resolved in its own > package, I would like to better understand these reasons. > > Paul > ___ > 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: F33 update stuck for past 6 days in request for testing->stable
On Wed, Sep 30, 2020 at 09:27:33PM +0200, Kalev Lember wrote: > > Ahh, sure, if the previous package was uninstallable then it should be fine > to not use epoch. I suppose... > So two options here: a) file a releng ticket ( > https://pagure.io/releng/issues) and ask them to re-tag the other build, or > b) just bump release and rebuild and submit it to bodhi once more. Go for the releng ticket. I think bodhi may tell you there's a newer version and refuse to make your update. 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 4:29 PM Colin Walters wrote: > > > > On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote: > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > (rpm)ostree variants are Fedora variants - please don't using phrasing > implying otherwise. > > IOW you just say: *all* Fedora variants use NetworkManager. > They are not the same. Regular Fedora is considerably more customizable post-installation than OSTree-based variants. That's why I made that point. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote: > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree (rpm)ostree variants are Fedora variants - please don't using phrasing implying otherwise. IOW you just say: *all* Fedora variants use NetworkManager. ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > With enterprise server deployments, DNS will be managed by the network > via resolve.conf to enterprise DNS servers. These servers tend to have > "bind views" for different category of deployments. These deployments > will have no VPN, no mDNS requirements etc. They also do not need (and > most likely do not want) DNS caching. I think all enterprise servers can benefit from having a local DNS server, whether that server caches or not, because that is the best way to fix/work around the broken C APIs for name resolution that doesn't handle DNS server failover very well. That doesn't mean I'm against splitting out systemd-resolved into a separate package, though. ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: > >> And what about places where NetworkManager isn't used? (Just because > >> it's the default, doesn't mean that it's used everywhere.) > > > > NetworkManager is used everywhere by default. If you want to disable it, > > you have to do manual work to do that. If you do manual work to disable > > NetworkManager, you can also do manual work to disable systemd-resolved. > > Indeed, but I was responding to this: > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > Please, no more package splitting. And NetworkManager is used across > > all variants of Fedora, so resolved should be installed in all places > > where NetworkManager is used. > > Which (to my reading) says that because NetworkManager is the *default* > everywhere (even though it can be uninstalled), systemd-resolved should > be *installed* everywhere (and should not be uninstallable). I don't > follow that logic. There are not a ton of advantages for splitting it, since it's only a couple of binaries averaging 2MB with a few unit files. Given that we require it for default NetworkManager configurations now, there's not a lot of value in making that complicated. Splitting has a cost too, in the form of extra metadata, upgrade paths, etc. Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. NetworkManager's configuration will use resolved as a local resolver. Anything baked into an OSTree cannot be removed anyway. And like it or not, all our legacy network configuration mechanisms are deprecated and *will be removed eventually*. Literally the only reason networkd was split out was because Fedora CoreOS was chainsawing it out at image build time and making it impossible for people to use it. To be frank, I do not want more permutations this low in the stack. It makes life incredibly difficult for figuring out working network setups. My reply was aimed at Peter saying he'd like to not ship resolved, and I'm saying that we should *not* do that, because it makes things even harder and more complicated. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 30.09.20 um 20:54 schrieb Brian C. Lane: > On Wed, Sep 30, 2020 at 12:45:40PM -0400, Stephen John Smoogen wrote: >> The Fedora secure boot signing keys were updated after F32 was initially >> released to deal with the grub2 problems found during the summer. I believe >> some systems have needed firmware updates from the manufacturer to work >> with the new key because they worked by white listing the old set, and >> don't know how to handle when a new key signed and authorized is presented. >> I don't know how the Surface Pro does its firmware updates and if one is >> needed. > This would be my guess as well. If you install with secure boot disabled > and then turn it back on after doing a full update does it boot > correctly? > > Brian > BTW.. meine SB is off , the none signed kernel made for the surface won't boot due to not being signed. But that means, it can't be a signing issue at all. I'm now puzzeld. Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 30.09.20 um 18:45 schrieb Stephen John Smoogen: > > > > The Fedora secure boot signing keys were updated after F32 was > initially released to deal with the grub2 problems found during the > summer. I believe some systems have needed firmware updates from the > manufacturer to work with the new key because they worked by white > listing the old set, and don't know how to handle when a new key > signed and authorized is presented. I don't know how the Surface Pro > does its firmware updates and if one is needed. > It you have removed windows, there is no update mechanism for a surface pro 4 ,, at least , not out of the box. I will ask in the surface kernel group, they tend to know such things. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 30.09.20 um 17:17 schrieb Chris Murphy: > > That suggests the scary region of firmware, hybrid ISO, shim, and boot loader. > > The bug reports have the wrong component set on them, and aren't > discrete actionable bug reports. It's just saying "this doesn't work" which one do you suggest? >> An instant reset back into the bios happens if a usb boot is tried. > Sounds like both a regression and a firmware bug. Maybe we'll be lucky > and someone on the list has an idea already. But if not, someone with > the hardware will have to do the tedious work of figuring out exactly > where it's getting tripped up. I have one, just how do we do that? > > I have no idea what the LiveCD component is, but the bug report > contains so little information I also don't know what I'd reassign it > to. Asking about it on devel is probably the right thing to do for > now. > Thats because there isn't more to tell .. it resets on try :D No kernel message, not error message, only a reset. Wait, didn't you say shim... there was something a while ago, a bug with the shim loader or uefi ... "The Grub2 Fix from early august" But, as F32 doesn't boot too, i doN't think it has the shim in it's image. Best regards, Marius ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 9:58 pm, Petr Menšík wrote: Shouldn't it change resolv.conf only in case NM is active AND resolv.conf is generated by Network Manager? Correct, that's indeed what it does. (Since Zbigniew changed it yesterday. Previously, it did not check if NM is active.) The systemd RPM scriplet will run sed, sed will see "Generated by dnssec-trigger-script" and say "that's not "Generated by NetworkManager" and it will leave your resolv.conf alone. So you're right, you don't need to worry about resolv.conf. Even if it did try to remove the immutable /etc/resolv.conf, the upgrade script ignores failures, so you would see an error message in the middle of the transaction about rm failing but it wouldn't fail the whole upgrade. It *will* still 'systemctl enable systemd-resolved.service', though, so you'll still need to disable that or you'll indeed have a battle for port 53. It will indeed probably break any local resolver you have configured. ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/30/20 7:11 PM, Michael Catanzaro wrote: > On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev wrote: >> So the upgrade WILL ignore current F32 state -- systemd-resolved >> DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite >> (respectively) each, regardless of whether we're _using_ >> NetworkManager (afaict it's impossible to completely remove all NM* >> cruft)? > > It only touches your /etc/resolv.conf if you are using NetworkManager, > but I think it enables systemd-resolved regardless. You'll have to > disable it if you don't want it. Shouldn't it change resolv.conf only in case NM is active AND resolv.conf is generated by Network Manager? resolv.conf with dnssec-trigger is generated anyway, there is little need to backup it. It looks like: # Generated by dnssec-trigger-script nameserver 127.0.0.1 I haven't tested upgrade to f33 yet. dnssec-trigger also tries protect resolv.conf for overwriting by chattr +i /etc/resolv.conf. I think it would break upgrade if change was attempted by systemd. Also, it would battle for port 53 for anyone having already local resolver. It would just fail to start, if user enabled listening on any address. Which is now unfortunately default for dnsmasq. It might be a little random, which one would win on machine start. I guess systemd-resolved would win, because unlike named(bind) or unbound, it has before nss-lookup.target and network.target. Normal dns services start After=network.target. Fortunately, it would not conflict with resolvers listening on localhost only, because it listens on different IP address. But it is before dns in nsswitch.conf, so every query would be done before "proper" dns resolvers. I don't this that is correct, when resolved has serious limitations in security. I expect it would break any local resolver configured, unless it can detect existing resolver and avoid activation of systemd-resolved. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 2:19 PM, Michael Catanzaro wrote: On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. Indeed, but I was responding to this: On 9/30/20 1:35 PM, Neal Gompa wrote: > Please, no more package splitting. And NetworkManager is used across > all variants of Fedora, so resolved should be installed in all places > where NetworkManager is used. Which (to my reading) says that because NetworkManager is the *default* everywhere (even though it can be uninstalled), systemd-resolved should be *installed* everywhere (and should not be uninstallable). I don't follow that logic. -- In Soviet Russia, Google searches you! ___ 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: Packages in rawhide not showing in src.fedoraproject.org
On Wednesday, September 30, 2020 2:45:28 PM WEST Iñaki Ucar wrote: > The thing is that R(package) is meant to provide the original > versioning (which allows hyphens and stuff), while R-package takes the > adaptation to our versioning system. The problem is that we generally > declare dependencies with R-package instead of R(package), and that's > an issue in cases like this. I think that preserving the original > versioning is a good idea, but we just need to switch to using > R(package) to declare all dependencies, like Python, tex, etc., > already do. After all there are no problem on our side. The bug is in the upstream package metadata that wrongly replaced the dash by the dot. That also says something about this version scheme (it is confusing), in particular because it is not uniform. :-) -- José Abílio___ 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: F33 update stuck for past 6 days in request for testing->stable
On Wed, Sep 30, 2020 at 9:18 PM Miro Hrončok wrote: > On 30. 09. 20 21:12, Tony Asleson wrote: > > On 9/30/20 1:05 PM, Kalev Lember wrote: > >> Looks like your update briefly made it stable, but then the older build > >> (pywbem-1.0.1-1.fc33) was tagged back over the new one > >> (pywbem-0.14.6-6.fc33): > >> > >> $ koji list-history --tag f33 --package pywbem > >> Tue Feb 11 18:46:20 2020 package owner releng set for pywbem in f33 by > >> mohanboddu [still active] > >> Tue Feb 11 18:46:20 2020 package list entry created: pywbem in f33 by > >> mohanboddu [still active] > >> Tue Feb 11 19:20:52 2020 pywbem-0.14.6-2.fc32 tagged into f33 by > mohanboddu > >> Fri May 29 14:27:13 2020 pywbem-0.14.6-3.fc33 tagged into f33 by autopen > >> Sat Aug 1 20:48:49 2020 pywbem-0.14.6-4.fc33 tagged into f33 by > mohanboddu > >> [still active] > >> Mon Aug 10 07:14:46 2020 pywbem-1.0.1-1.fc33 tagged into f33 by bodhi > >> Tue Aug 11 17:38:36 2020 pywbem-0.14.6-2.fc32 untagged from f33 by oscar > >> Fri Sep 25 18:23:13 2020 pywbem-0.14.6-6.fc33 tagged into f33 by bodhi > >> [still active] > >> Sat Sep 26 20:14:34 2020 pywbem-1.0.1-1.fc33 re-tagged into f33 by kevin > >> Sat Sep 26 20:21:02 2020 pywbem-0.14.6-3.fc33 untagged from f33 by oscar > >> > >> The older build was tagged over the new one because Kevin ran a fixup > >> script to find packages where Bodhi accidentally pushed an older > version on > >> top of a new one (it's a long standing Bodhi issue during freezes). Your > >> build was caught in the fixup. > >> > >> However, before you go and ask releng to undo this, I believe what they > did > >> was actually correct. The EVR of a package should not go backwards like > you > >> pushed an older build there. Instead, you need to bump Epoch to 1 (in > both > >> F33 and master) and then do new builds and submit that to bodhi. This > >> should make the downgrade correctly happen. > >> > > > > I specifically asked about this: > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MAIHXM4CSZPPTHIB42AMUSWZTUFQESZU/ > > > > and was told to not bump the epoch and that all would be fine if I got > > this done before final freeze, which is what I'm trying to do. > > > > So what's the correct answer, because I'm running out of time? > > In my opinion, you should ask releng to undo this. > > But in case such fixups are done repeatedly (I assume they don't), bumping > the > epoch might be a way to prevent it. > > Note that I've advised not to bump the epoch, because there was no upgrade > path > issue at all (the package with higher EVR was not installable). > Ahh, sure, if the previous package was uninstallable then it should be fine to not use epoch. So two options here: a) file a releng ticket ( https://pagure.io/releng/issues) and ask them to re-tag the other build, or b) just bump release and rebuild and submit it to bodhi once more. -- Kalev ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. ___ 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: F33 update stuck for past 6 days in request for testing->stable
On 30. 09. 20 21:12, Tony Asleson wrote: On 9/30/20 1:05 PM, Kalev Lember wrote: On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote: On 9/11/20 5:07 PM, Kevin Fenzi wrote: On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote: This release: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b has been stuck waiting to get moved to stable. Is some error going on that isn't evident? We are in Beta freeze. Only packages that fix accepted blocker bugs or freeze break exceptions can go stable. https://fedoraproject.org/wiki/Milestone_freezes This was a release that I did to hopefully correct what is discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/ You can request a freeze break if you like: https://fedoraproject.org/wiki/Milestone_freezes#How_are_freeze_exceptions_proposed_and_granted.3F or just wait until after Beta is signed off on and updates will start flowing to stable again (until final freeze). I got an email on 9/25 that this issue was moved to stable. As of right now it's still appears to be in updates-testing. Using the following: https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html I would have thought that 9/29 this package would be in stable, but maybe beta has not been signed off? Hi Tony, Hi Kalev, Looks like your update briefly made it stable, but then the older build (pywbem-1.0.1-1.fc33) was tagged back over the new one (pywbem-0.14.6-6.fc33): $ koji list-history --tag f33 --package pywbem Tue Feb 11 18:46:20 2020 package owner releng set for pywbem in f33 by mohanboddu [still active] Tue Feb 11 18:46:20 2020 package list entry created: pywbem in f33 by mohanboddu [still active] Tue Feb 11 19:20:52 2020 pywbem-0.14.6-2.fc32 tagged into f33 by mohanboddu Fri May 29 14:27:13 2020 pywbem-0.14.6-3.fc33 tagged into f33 by autopen Sat Aug 1 20:48:49 2020 pywbem-0.14.6-4.fc33 tagged into f33 by mohanboddu [still active] Mon Aug 10 07:14:46 2020 pywbem-1.0.1-1.fc33 tagged into f33 by bodhi Tue Aug 11 17:38:36 2020 pywbem-0.14.6-2.fc32 untagged from f33 by oscar Fri Sep 25 18:23:13 2020 pywbem-0.14.6-6.fc33 tagged into f33 by bodhi [still active] Sat Sep 26 20:14:34 2020 pywbem-1.0.1-1.fc33 re-tagged into f33 by kevin Sat Sep 26 20:21:02 2020 pywbem-0.14.6-3.fc33 untagged from f33 by oscar The older build was tagged over the new one because Kevin ran a fixup script to find packages where Bodhi accidentally pushed an older version on top of a new one (it's a long standing Bodhi issue during freezes). Your build was caught in the fixup. However, before you go and ask releng to undo this, I believe what they did was actually correct. The EVR of a package should not go backwards like you pushed an older build there. Instead, you need to bump Epoch to 1 (in both F33 and master) and then do new builds and submit that to bodhi. This should make the downgrade correctly happen. I specifically asked about this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MAIHXM4CSZPPTHIB42AMUSWZTUFQESZU/ and was told to not bump the epoch and that all would be fine if I got this done before final freeze, which is what I'm trying to do. So what's the correct answer, because I'm running out of time? In my opinion, you should ask releng to undo this. But in case such fixups are done repeatedly (I assume they don't), bumping the epoch might be a way to prevent it. Note that I've advised not to bump the epoch, because there was no upgrade path issue at all (the package with higher EVR was not installable). -- 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: F33 update stuck for past 6 days in request for testing->stable
On 9/30/20 1:05 PM, Kalev Lember wrote: > On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote: > >> On 9/11/20 5:07 PM, Kevin Fenzi wrote: >>> On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote: This release: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b has been stuck waiting to get moved to stable. Is some error going on that isn't evident? >>> >>> We are in Beta freeze. Only packages that fix accepted blocker bugs or >>> freeze break exceptions can go stable. >>> >>> https://fedoraproject.org/wiki/Milestone_freezes >>> This was a release that I did to hopefully correct what is discussed >> here: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/ >>> >>> You can request a freeze break if you like: >>> >> https://fedoraproject.org/wiki/Milestone_freezes#How_are_freeze_exceptions_proposed_and_granted.3F >>> or just wait until after Beta is signed off on and updates will start >>> flowing to stable again (until final freeze). >> >> I got an email on 9/25 that this issue was moved to stable. As of right >> now it's still appears to be in updates-testing. >> >> >> Using the following: >> >> https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html >> >> >> I would have thought that 9/29 this package would be in stable, but >> maybe beta has not been signed off? >> > > Hi Tony, Hi Kalev, > Looks like your update briefly made it stable, but then the older build > (pywbem-1.0.1-1.fc33) was tagged back over the new one > (pywbem-0.14.6-6.fc33): > > $ koji list-history --tag f33 --package pywbem > Tue Feb 11 18:46:20 2020 package owner releng set for pywbem in f33 by > mohanboddu [still active] > Tue Feb 11 18:46:20 2020 package list entry created: pywbem in f33 by > mohanboddu [still active] > Tue Feb 11 19:20:52 2020 pywbem-0.14.6-2.fc32 tagged into f33 by mohanboddu > Fri May 29 14:27:13 2020 pywbem-0.14.6-3.fc33 tagged into f33 by autopen > Sat Aug 1 20:48:49 2020 pywbem-0.14.6-4.fc33 tagged into f33 by mohanboddu > [still active] > Mon Aug 10 07:14:46 2020 pywbem-1.0.1-1.fc33 tagged into f33 by bodhi > Tue Aug 11 17:38:36 2020 pywbem-0.14.6-2.fc32 untagged from f33 by oscar > Fri Sep 25 18:23:13 2020 pywbem-0.14.6-6.fc33 tagged into f33 by bodhi > [still active] > Sat Sep 26 20:14:34 2020 pywbem-1.0.1-1.fc33 re-tagged into f33 by kevin > Sat Sep 26 20:21:02 2020 pywbem-0.14.6-3.fc33 untagged from f33 by oscar > > The older build was tagged over the new one because Kevin ran a fixup > script to find packages where Bodhi accidentally pushed an older version on > top of a new one (it's a long standing Bodhi issue during freezes). Your > build was caught in the fixup. > > However, before you go and ask releng to undo this, I believe what they did > was actually correct. The EVR of a package should not go backwards like you > pushed an older build there. Instead, you need to bump Epoch to 1 (in both > F33 and master) and then do new builds and submit that to bodhi. This > should make the downgrade correctly happen. > I specifically asked about this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MAIHXM4CSZPPTHIB42AMUSWZTUFQESZU/ and was told to not bump the epoch and that all would be fine if I got this done before final freeze, which is what I'm trying to do. So what's the correct answer, because I'm running out of time? Thanks, Tony ___ 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: F33 update stuck for past 6 days in request for testing->stable
FYI: No need to cc me on list posts. I'm subscribed and read all the list posts. ;) On Wed, Sep 30, 2020 at 08:05:09PM +0200, Kalev Lember wrote: ...snip... > > The older build was tagged over the new one because Kevin ran a fixup > script to find packages where Bodhi accidentally pushed an older version on > top of a new one (it's a long standing Bodhi issue during freezes). Your > build was caught in the fixup. > > However, before you go and ask releng to undo this, I believe what they did > was actually correct. The EVR of a package should not go backwards like you > pushed an older build there. Instead, you need to bump Epoch to 1 (in both > F33 and master) and then do new builds and submit that to bodhi. This > should make the downgrade correctly happen. Yep. Exactly so... you will need a Epoch to go back to an otherwise "older" version. 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 1:35 PM, Neal Gompa wrote: Please, no more package splitting. And NetworkManager is used across all variants of Fedora, so resolved should be installed in all places where NetworkManager is used. And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) -- In Soviet Russia, Google searches you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, Sep 30, 2020 at 12:45:40PM -0400, Stephen John Smoogen wrote: > The Fedora secure boot signing keys were updated after F32 was initially > released to deal with the grub2 problems found during the summer. I believe > some systems have needed firmware updates from the manufacturer to work > with the new key because they worked by white listing the old set, and > don't know how to handle when a new key signed and authorized is presented. > I don't know how the Surface Pro does its firmware updates and if one is > needed. This would be my guess as well. If you install with secure boot disabled and then turn it back on after doing a full update does it boot correctly? Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 12:48 PM Peter Robinson wrote: > > > Hi Zbyszek, > > Would it make sense to do the same for systemd-resolved ? > > Sounds like it has similar impact/scope wrt coreos. > > Yes please, I would like this for Edge/IoT too (both network/resolved) > as there are use cases there where we'd like not to ship these too. > Please, no more package splitting. And NetworkManager is used across all variants of Fedora, so resolved should be installed in all places where NetworkManager is used. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 11:21 AM, Paul Wouters wrote: > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. Would separating the package preserve existing setups across upgrades? It's not simply Enterprise/Server 'or' Desktops that use "own validating resolvers". Here, that's standard/default for both. Ideally, a mechanism to "leave existing configs as is", without exceptional intervention -- using kickstart, re-UNinstalling or re-DISabling after upgrade -- would be preferred. I'm all for new capabilities. What's concerning is the insistence on monkeying with (long) established, and perfectly viable/standard configurations. ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: the systemd package is getting a systemd-networkd subpackage split out that will contain systemd-networkd, networkctl, and the associated data files. This was requested by coreos maintainers: NetworkManager is used and skipping systemd-networkd allows the installation footprint and potential user confusion to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. In which package will systemd-resolved be? With enterprise server deployments, DNS will be managed by the network via resolve.conf to enterprise DNS servers. These servers tend to have "bind views" for different category of deployments. These deployments will have no VPN, no mDNS requirements etc. They also do not need (and most likely do not want) DNS caching. I believe it would be useful for kickstart installs to not install systemd-resolved for these kind of typical server deployments. I think this is an important use case to support. For Desktop systems, it could default to installing systemd-resolved. It could even default to it for all installs including Server, as long as the administrator has the option to not install it via a kickstart file. It also allows those Destop users that want to use their own validating resolvers on the end node to uninstall systemd-resolved. If there are strong reasons not to split systemd-resolved in its own package, I would like to better understand these reasons. Paul ___ 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: F33 update stuck for past 6 days in request for testing->stable
On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote: > On 9/11/20 5:07 PM, Kevin Fenzi wrote: > > On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote: > >> This release: > >> > >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b > >> > >> has been stuck waiting to get moved to stable. Is some error going on > >> that isn't evident? > > > > We are in Beta freeze. Only packages that fix accepted blocker bugs or > > freeze break exceptions can go stable. > > > > https://fedoraproject.org/wiki/Milestone_freezes > > > >> > >> This was a release that I did to hopefully correct what is discussed > here: > >> > >> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/ > > > > You can request a freeze break if you like: > > > https://fedoraproject.org/wiki/Milestone_freezes#How_are_freeze_exceptions_proposed_and_granted.3F > > or just wait until after Beta is signed off on and updates will start > > flowing to stable again (until final freeze). > > I got an email on 9/25 that this issue was moved to stable. As of right > now it's still appears to be in updates-testing. > > > Using the following: > > https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html > > > I would have thought that 9/29 this package would be in stable, but > maybe beta has not been signed off? > Hi Tony, Looks like your update briefly made it stable, but then the older build (pywbem-1.0.1-1.fc33) was tagged back over the new one (pywbem-0.14.6-6.fc33): $ koji list-history --tag f33 --package pywbem Tue Feb 11 18:46:20 2020 package owner releng set for pywbem in f33 by mohanboddu [still active] Tue Feb 11 18:46:20 2020 package list entry created: pywbem in f33 by mohanboddu [still active] Tue Feb 11 19:20:52 2020 pywbem-0.14.6-2.fc32 tagged into f33 by mohanboddu Fri May 29 14:27:13 2020 pywbem-0.14.6-3.fc33 tagged into f33 by autopen Sat Aug 1 20:48:49 2020 pywbem-0.14.6-4.fc33 tagged into f33 by mohanboddu [still active] Mon Aug 10 07:14:46 2020 pywbem-1.0.1-1.fc33 tagged into f33 by bodhi Tue Aug 11 17:38:36 2020 pywbem-0.14.6-2.fc32 untagged from f33 by oscar Fri Sep 25 18:23:13 2020 pywbem-0.14.6-6.fc33 tagged into f33 by bodhi [still active] Sat Sep 26 20:14:34 2020 pywbem-1.0.1-1.fc33 re-tagged into f33 by kevin Sat Sep 26 20:21:02 2020 pywbem-0.14.6-3.fc33 untagged from f33 by oscar The older build was tagged over the new one because Kevin ran a fixup script to find packages where Bodhi accidentally pushed an older version on top of a new one (it's a long standing Bodhi issue during freezes). Your build was caught in the fixup. However, before you go and ask releng to undo this, I believe what they did was actually correct. The EVR of a package should not go backwards like you pushed an older build there. Instead, you need to bump Epoch to 1 (in both F33 and master) and then do new builds and submit that to bodhi. This should make the downgrade correctly happen. -- Hope this helps, Kalev ___ 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: F33 update stuck for past 6 days in request for testing->stable
On 9/11/20 5:07 PM, Kevin Fenzi wrote: > On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote: >> This release: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b >> >> has been stuck waiting to get moved to stable. Is some error going on >> that isn't evident? > > We are in Beta freeze. Only packages that fix accepted blocker bugs or > freeze break exceptions can go stable. > > https://fedoraproject.org/wiki/Milestone_freezes > >> >> This was a release that I did to hopefully correct what is discussed here: >> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/ > > You can request a freeze break if you like: > https://fedoraproject.org/wiki/Milestone_freezes#How_are_freeze_exceptions_proposed_and_granted.3F > or just wait until after Beta is signed off on and updates will start > flowing to stable again (until final freeze). I got an email on 9/25 that this issue was moved to stable. As of right now it's still appears to be in updates-testing. Using the following: https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html I would have thought that 9/29 this package would be in stable, but maybe beta has not been signed off? Thanks, Tony ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev wrote: So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite (respectively) each, regardless of whether we're _using_ NetworkManager (afaict it's impossible to completely remove all NM* cruft)? It only touches your /etc/resolv.conf if you are using NetworkManager, but I think it enables systemd-resolved regardless. You'll have to disable it if you don't want it. ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote: > >The main systemd systemd package Obsoletes the -standalone- packages, so it > >should smoothly replace them whenever it is pulled in. > > I am confused by this bit. If systemd package Obsoletes the > -standalone- packages, installing them is not possible unless you > explicitly exclude systemd from the transaction and keep it excluded > for upgrades. I expect so, if the use case is containers that will be replaced instead of upgraded. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/30/20 9:50 AM, Michael Catanzaro wrote: > You'll need to manually disable systemd-resolved after upgrade, restore > /etc/resolv.conf from the backup file that will be created during upgrade So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite (respectively) each, regardless of whether we're _using_ NetworkManager (afaict it's impossible to completely remove all NM* cruft)? ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 30. 09. 20 18:26, Zbigniew Jędrzejewski-Szmek wrote: The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. I am confused by this bit. If systemd package Obsoletes the -standalone- packages, installing them is not possible unless you explicitly exclude systemd from the transaction and keep it excluded for upgrades. Is that the idea? -- 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski wrote: What if I'm using NetworkManager and dnssec-trigger? This has been working very well for me for the last couple of releases and I'd hate to be forced to manually reconfigure things so that it starts working again. The upgrade process is designed to do the right thing for users who stick with our defaults. Manual intervention is required for unusual cases like this. You'll need to manually disable systemd-resolved after upgrade, restore /etc/resolv.conf from the backup file that will be created during upgrade, and restart NetworkManager. That would look something like: # systemctl disable systemd-resolved.service # systmectl stop systemd-resolved.service # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf # systemctl restart NetworkManager.service Michael ___ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
> Hi Zbyszek, > Would it make sense to do the same for systemd-resolved ? > Sounds like it has similar impact/scope wrt coreos. Yes please, I would like this for Edge/IoT too (both network/resolved) as there are use cases there where we'd like not to ship these too. Peter > On Wed, 2020-09-30 at 16:26 +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > the systemd package is getting a systemd-networkd subpackage split out > > that will contain systemd-networkd, networkctl, and the associated data > > files. > > This was requested by coreos maintainers: NetworkManager is used and > > skipping > > systemd-networkd allows the installation footprint and potential user > > confusion > > to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > > > Appropriate Obsoletes are added on both the main package and the new > > systemd-networkd subpackage, so the systemd-networkd subpackage should > > be installed on upgrades. In addition, the new subpackage has Recommends > > from > > the main package, so it will be installed in normal installations. The split > > affects installations with --setopt=install_weak_deps=False. Please make > > sure > > to pull in systemd-networkd.rpm independently if needed. Also note that > > systemd-networkd.service was preset as *disabled* in Fedora, which means > > that > > unless it was enabled by the user, the removal of systemd-networkd wouldn't > > have an effect. > > > > In addition, two more new subpackages are created: > > systemd-standalone-sysusers > > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > > systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in > > much > > less dependencies compared to the normal systemd package (only glibc, > > libselinux, > > and libacl). The goal here is to be able to use those packages in limited > > environments where systemd itself is not necessary. > > > > The main systemd systemd package Obsoletes the -standalone- packages, so it > > should smoothly replace them whenever it is pulled in. > > > > This change was done in systemd-246.6-2.fc34 in rawhide right now. (There > > are > > some cleanups to move more files to the -networkd subpackage in the works > > for > > 246.6-3.fc34). Please give this a spin and report any issues. > > > > The plan is to also do this split for F33 if no issues are noted in rawhide. > > > > Zbyszek > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, 30 Sep 2020 at 11:54, Erich Eickmeyer wrote: > On 9/30/2020 8:17 AM, Chris Murphy wrote: > > On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz > wrote: > >> Hi, > >> > >> the livecds from F32 and F33 are suffering from a problem not booting on > >> Microsoft device(s) > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1879921 > >> https://bugzilla.redhat.com/show_bug.cgi?id=1883593 > >> > >> F31 is booting fine, the newer ones not. Looks like a GrubBootloader > >> issue to me, as not even grub comes up. > > That suggests the scary region of firmware, hybrid ISO, shim, and boot > loader. > > > > The bug reports have the wrong component set on them, and aren't > > discrete actionable bug reports. It's just saying "this doesn't work" > > but the people most likely to figure out what *is* happening are those > > with this specific hardware. > > > >> An instant reset back into the bios happens if a usb boot is tried. > > Sounds like both a regression and a firmware bug. Maybe we'll be lucky > > and someone on the list has an idea already. But if not, someone with > > the hardware will have to do the tedious work of figuring out exactly > > where it's getting tripped up. > > > > > >> Unfortunatly the assignee is not reacting and i would really miss my > >> linux surface after upgrading to F32 :D > > I have no idea what the LiveCD component is, but the bug report > > contains so little information I also don't know what I'd reassign it > > to. Asking about it on devel is probably the right thing to do for > > now. > > I can confirm this bug does exist. Attempting to boot on my Surface Pro > 4 requires secure boot to be momentarily shut-off. SB actually is > reporting a secure boot violation for whatever reason. I have reason to > believe that the UEFI files are missing correct signing, or that signing > needs to be updated. > > I have also seen SB failures with my Dell laptop with SB enabled, but > those are easier to work around than going nuclear on a Surface Pro and > shutting-off secure boot. > > F31 and F32 are unaffected, this appears to have started with F33. > > The Fedora secure boot signing keys were updated after F32 was initially released to deal with the grub2 problems found during the summer. I believe some systems have needed firmware updates from the manufacturer to work with the new key because they worked by white listing the old set, and don't know how to handle when a new key signed and authorized is presented. I don't know how the Surface Pro does its firmware updates and if one is needed. > -- > Erich Eickmeyer > Project Leader Ubuntu Studio > Maintainer Fedora Jam > > ___ > 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wednesday, 30 September 2020 at 18:16, Neal Gompa wrote: [...] > If you're not using NetworkManager, this change has _zero_ impact. What if I'm using NetworkManager and dnssec-trigger? This has been working very well for me for the last couple of releases and I'd hate to be forced to manually reconfigure things so that it starts working again. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
Hi Zbyszek, Would it make sense to do the same for systemd-resolved ? Sounds like it has similar impact/scope wrt coreos. On Wed, 2020-09-30 at 16:26 +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > the systemd package is getting a systemd-networkd subpackage split out > that will contain systemd-networkd, networkctl, and the associated data files. > This was requested by coreos maintainers: NetworkManager is used and skipping > systemd-networkd allows the installation footprint and potential user > confusion > to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > Appropriate Obsoletes are added on both the main package and the new > systemd-networkd subpackage, so the systemd-networkd subpackage should > be installed on upgrades. In addition, the new subpackage has Recommends from > the main package, so it will be installed in normal installations. The split > affects installations with --setopt=install_weak_deps=False. Please make sure > to pull in systemd-networkd.rpm independently if needed. Also note that > systemd-networkd.service was preset as *disabled* in Fedora, which means that > unless it was enabled by the user, the removal of systemd-networkd wouldn't > have an effect. > > In addition, two more new subpackages are created: systemd-standalone-sysusers > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in much > less dependencies compared to the normal systemd package (only glibc, > libselinux, > and libacl). The goal here is to be able to use those packages in limited > environments where systemd itself is not necessary. > > The main systemd systemd package Obsoletes the -standalone- packages, so it > should smoothly replace them whenever it is pulled in. > > This change was done in systemd-246.6-2.fc34 in rawhide right now. (There are > some cleanups to move more files to the -networkd subpackage in the works for > 246.6-3.fc34). Please give this a spin and report any issues. > > The plan is to also do this split for F33 if no issues are noted in rawhide. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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
splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
Hi, the systemd package is getting a systemd-networkd subpackage split out that will contain systemd-networkd, networkctl, and the associated data files. This was requested by coreos maintainers: NetworkManager is used and skipping systemd-networkd allows the installation footprint and potential user confusion to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) Appropriate Obsoletes are added on both the main package and the new systemd-networkd subpackage, so the systemd-networkd subpackage should be installed on upgrades. In addition, the new subpackage has Recommends from the main package, so it will be installed in normal installations. The split affects installations with --setopt=install_weak_deps=False. Please make sure to pull in systemd-networkd.rpm independently if needed. Also note that systemd-networkd.service was preset as *disabled* in Fedora, which means that unless it was enabled by the user, the removal of systemd-networkd wouldn't have an effect. In addition, two more new subpackages are created: systemd-standalone-sysusers and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in much less dependencies compared to the normal systemd package (only glibc, libselinux, and libacl). The goal here is to be able to use those packages in limited environments where systemd itself is not necessary. The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. This change was done in systemd-246.6-2.fc34 in rawhide right now. (There are some cleanups to move more files to the -networkd subpackage in the works for 246.6-3.fc34). Please give this a spin and report any issues. The plan is to also do this split for F33 if no issues are noted in rawhide. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/30/20 9:16 AM, Neal Gompa wrote: > If you're not using NetworkManager, this change has _zero_ impact. perfect. clearly, i've missed or lost the obviousness of that incredibly useful tidbit in this novella :-/ thx! ___ 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: LTO and F33
On 30.09.2020 15:39, Robert-André Mauchin wrote: > I have an issue with both Clementine and Strawberry (a fork of Clementine) > in F33 and above, users reported that disabling LTO fixes the problem. I have the same issue with Telegram Desktop: https://bugzilla.redhat.com/show_bug.cgi?id=1880290 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 12:15 PM PGNet Dev wrote: > > Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ > is. > > What _is_ clear is that there's significant disagreement -- which, > unfortunately, has at times here become nasty & personal -- about needed vs > planned functionality, and, of late, regulatory compliance. > > And, iiuc, though obviously very much up in the air, this is all relevant to > F33 release, coming in weeks? > > Can someone please clarify, ideally with some level of certainty: > > If we've F32 systems in place, that do NOT use systemd-resolved &/or > NetworkManager, but rather our own/preferred DNS client implementations with > systemd-networkd, > > will a system *upgrade*, from F32 to F33, force/require any changes to those > configurations? or will systems be left as-is, and we can expect > uninterrupted functionality? > > which of these proposed systemd-resolved system-wide changes are NON-optional > in _usage_? can they _all_ be turned-off/disabled? > > bottom-line -- how much system breakage of existing infrastructure, if any, > should we be planning for with a F32 -> F33 upgrade path? If you're not using NetworkManager, this change has _zero_ impact. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ is. What _is_ clear is that there's significant disagreement -- which, unfortunately, has at times here become nasty & personal -- about needed vs planned functionality, and, of late, regulatory compliance. And, iiuc, though obviously very much up in the air, this is all relevant to F33 release, coming in weeks? Can someone please clarify, ideally with some level of certainty: If we've F32 systems in place, that do NOT use systemd-resolved &/or NetworkManager, but rather our own/preferred DNS client implementations with systemd-networkd, will a system *upgrade*, from F32 to F33, force/require any changes to those configurations? or will systems be left as-is, and we can expect uninterrupted functionality? which of these proposed systemd-resolved system-wide changes are NON-optional in _usage_? can they _all_ be turned-off/disabled? bottom-line -- how much system breakage of existing infrastructure, if any, should we be planning for with a F32 -> F33 upgrade path? ___ 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: F34 Change proposal: Debug Info LLDB Index (System-Wide change)
On 9/30/20 2:56 AM, Jan Kratochvil wrote: On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote: On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex Currently the change will affect only packages using: %global toolchain clang Those are currently only these packages being built by clang and using this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde wine FIXME: Which other Fedora packages are being built by clang? Should this be mentioned as part of some packaging guidelines? Especially as we expect more packages to use clang in the future. As long as the .spec file uses %global toolchain clang and the normal configuration variables %__cc %__cxx it all should work out of the box. Unfortunately for example for libcxxabi it does not work out of the box as overrides $CXXFLAGS somehow, I have to debug it. Yea. There's a variety of other packages that need the %toolchain bits, but aren't suffering too badly right now without it. american-fuzzy-lap, android-tools, clover2, hedgewars, & root are all in that position right now. There may be others, that's just the set I know about because they're explicitly mucking around with LTO flags rather than getting them right automagically via %toolchain. Jeff ___ 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: F34 Change proposal: Debug Info LLDB Index (System-Wide change)
On 9/30/20 2:33 AM, Jan Kratochvil wrote: On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote: Why don't you add an lldb-add-index tool to generate LLVM indexes for LLDB? Because doing it separately like GDB does is a wrong thing for edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR already in memory it can much more faster produce the index for it. With gdb-add-index it is questionable whether to use it or not for edit-compile-debug cycles. If you run debugger just once for the compiled program it is slower to generate + use the index just once than to run the debugger without any index. The index production performance does not matter much for rpmbuild as that takes a long time anyway. But keeping the end-user edit-compile-debug cycle unified with rpm build process makes the code path more tested and more simple. But there really isn't a edit-compile-debug cycle in play here -- so you may be right in the general case, but for RPM package builds it's a lot less clear. It also seems to me that we would want the index regardless of the toolchain being used to build the executable or DSO. I can't think of a good reason why someone who prefers lldb would have to suffer from worse performance because the system binary/library they need to debug was built with GCC. And ISTM that if we want both index styles on all binaries and DSOs, then using the post-install step like lldb-add-index would make a lot more sense. Jeff ___ 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: Packages in rawhide not showing in src.fedoraproject.org
On Wed, Sep 30, 2020 at 02:15:34PM +0100, José Abílio Matos wrote: > On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote: > > It actually queries bodhi and failing to find things in it, it fallsback to > > mdapi normally. > > Potential bug in the logic? > > Another example: > https://src.fedoraproject.org/rpms/texlive So after some search the answer is simple. There was no recent build of that package that went through bodhi, so the code falls back to mdapi. mdapi has no f34 branches: https://mdapi.fedoraproject.org/branches I'm looking at telling the api endpoint gathering the info to do something like: if the most recent Fedora release is not listed in mdapi's branches, consider it to be "rawhide". It seems to work, though the output surprises me a little bit: Fedora 34 texlive-tcolorbox-27.fc33 mdapi finds that the version of texlive is "tcolorbox" https://mdapi.fedoraproject.org/rawhide/srcpkg/texlive Not quite sure what's going on there. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On 9/30/2020 8:17 AM, Chris Murphy wrote: > On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz wrote: >> Hi, >> >> the livecds from F32 and F33 are suffering from a problem not booting on >> Microsoft device(s) >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1879921 >> https://bugzilla.redhat.com/show_bug.cgi?id=1883593 >> >> F31 is booting fine, the newer ones not. Looks like a GrubBootloader >> issue to me, as not even grub comes up. > That suggests the scary region of firmware, hybrid ISO, shim, and boot loader. > > The bug reports have the wrong component set on them, and aren't > discrete actionable bug reports. It's just saying "this doesn't work" > but the people most likely to figure out what *is* happening are those > with this specific hardware. > >> An instant reset back into the bios happens if a usb boot is tried. > Sounds like both a regression and a firmware bug. Maybe we'll be lucky > and someone on the list has an idea already. But if not, someone with > the hardware will have to do the tedious work of figuring out exactly > where it's getting tripped up. > > >> Unfortunatly the assignee is not reacting and i would really miss my >> linux surface after upgrading to F32 :D > I have no idea what the LiveCD component is, but the bug report > contains so little information I also don't know what I'd reassign it > to. Asking about it on devel is probably the right thing to do for > now. I can confirm this bug does exist. Attempting to boot on my Surface Pro 4 requires secure boot to be momentarily shut-off. SB actually is reporting a secure boot violation for whatever reason. I have reason to believe that the UEFI files are missing correct signing, or that signing needs to be updated. I have also seen SB failures with my Dell laptop with SB enabled, but those are easier to work around than going nuclear on a Surface Pro and shutting-off secure boot. F31 and F32 are unaffected, this appears to have started with F33. -- Erich Eickmeyer Project Leader Ubuntu Studio Maintainer Fedora Jam pEpkey.asc Description: application/pgp-keys ___ 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: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On 9/30/20 6:50 AM, Mark Wielaard wrote: Hi Neal, On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote: For the record, Mark has started implementing DWARF-5 support in dwz: https://sourceware.org/git/?p=dwz.git;a=log I think I would rather like to see a Change proposal to switch to DWARF-5 for Fedora 34, especially since it looks like dwz will be ready for it. That is indeed my goal, but I wasn't planning on filing a specific Change Proposal for it. First because as you observed in the past we did some of these debuginfo things Fedora first and then it took years (!) for some of the default settings we had changed and helper scripts to make it upstream. So I am concentrating on getting everything ready upstream first before making and proposing any changes for Fedora. Secondly I am hoping that because of the first point the GCC11 for Fedora 34 Change Proposal will simply say "-gdwarf-5 is now the default". In that change proposal can you add a sentence or two in the proposal indicating that I will do a test rawhide build with gcc-11 with dwarf5 on by default? My worry is that once Aldy/Andrew's Ranger work has finished that I'll forget the need for dwarf5 testing. jeff ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On 9/29/20 5:59 PM, Neal Gompa wrote: I feel like it's worth giving my perspective here as someone who has done similar work in other distributions. Thanks for that viewpoint. As a compiler optimizer junkie, I don't really follow things on the RPM side, so hearing about that process has played out is useful. For the record, Mark has started implementing DWARF-5 support in dwz: https://sourceware.org/git/?p=dwz.git;a=log I think I would rather like to see a Change proposal to switch to DWARF-5 for Fedora 34, especially since it looks like dwz will be ready for it. Yea, I think moving to dwarf-5 would be a good step forward. ISTM we ought to do a test mass build with dwarf-5 by default. I'm currently testing some bits for other GCC developers, but ought to be able to do a dwarf-5 spin in a week or so to get a sense any notable fallout. jeff ___ 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: LTO and F33
On 9/30/20 9:25 AM, Zbigniew Jędrzejewski-Szmek wrote: I pushed the following to fix build of sems: https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master Not my package, and the code is a bit iffy, so it's quite likely that the problem is in the package... Just letting you know in case you're still looking for failures. That is most likely a package issue that is just exposed by LTO. I'll take a look, but the QT singleton and gnulib regexp issues are higher priority right now. It'll show up in my opt-out scanner, so that guarantees it won't be lost -- which is important as that diagnostic can be an indicator of a security issue and disabling LTO wouldn't change the underlying potential security issue. Thanks, Jeff ___ 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: LTO and F33
I pushed the following to fix build of sems: https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master Not my package, and the code is a bit iffy, so it's quite likely that the problem is in the package... Just letting you know in case you're still looking for failures. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 10:05 am, Gerd Hoffmann wrote: Sorry, but that is not correct. NetworkManager can handle split-dns just fine, by using dnsmasq and reconfiguring it via dbus when vpn connections come and go. I can easily add more servers + zones by dropping a config file snippet into the /etc/NetworkManager/dnsmasq.d/ directory, for example to resolve the hostnames for my kvm guests on the libvirt network. That works for ages on my RHEL-7 workstation where systemd-resolved doesn't even exist ... We actually considered dnsmasq, but NetworkManager developers recommended systemd-resolved. See: https://pagure.io/fedora-workstation/issue/123#comment-621603 I agree dnsmasq would have been a lot better than the status quo prior to F33. We would probably have used that if systemd-resolved didn't exist. If we could have a do-over, we should have started using it long ago. So sending the requests to all available DNS servers in absence of better routing info is a great enabler: I fail to see why sending queries to all servers is a good plan. The redhat vpn dns servers surely can't resolve the hostnames for my local lan, and frankly they shouldn't even know which hosts I try to access. Likewise my ISP shouldn't know which non-public RH servers I try to access. I've tried to stop this line of discussion a bit earlier, since it's based on a misunderstanding of how NetworkManager uses systemd-resolved. I agree we should prioritize avoiding DNS leaks, and that's actually the primary motivating factor for the switch to systemd-resolved (you can see how much more attention I devote to this topic in the change proposal compared to the other benefits of systemd-resolved). NetworkManager will not configure systmed-resolved to send queries all over the place. We need a local resolver (systemd-resolved, dnsmasq, etc.) to ensure DNS queries go where users expect; it's not something we can do with traditional resolv.conf managed by NetworkManager. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz wrote: > > Hi, > > the livecds from F32 and F33 are suffering from a problem not booting on > Microsoft device(s) > > https://bugzilla.redhat.com/show_bug.cgi?id=1879921 > https://bugzilla.redhat.com/show_bug.cgi?id=1883593 > > F31 is booting fine, the newer ones not. Looks like a GrubBootloader > issue to me, as not even grub comes up. That suggests the scary region of firmware, hybrid ISO, shim, and boot loader. The bug reports have the wrong component set on them, and aren't discrete actionable bug reports. It's just saying "this doesn't work" but the people most likely to figure out what *is* happening are those with this specific hardware. > An instant reset back into the bios happens if a usb boot is tried. Sounds like both a regression and a firmware bug. Maybe we'll be lucky and someone on the list has an idea already. But if not, someone with the hardware will have to do the tedious work of figuring out exactly where it's getting tripped up. > > Unfortunatly the assignee is not reacting and i would really miss my > linux surface after upgrading to F32 :D I have no idea what the LiveCD component is, but the bug report contains so little information I also don't know what I'd reassign it to. Asking about it on devel is probably the right thing to do for now. -- 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 3:14 pm, Graham Leggett wrote: Regulations like the GDPR exist, and ignorance of them is not a defence. I am required by these regulations and many other regulations in multiple jurisdictions to make sure my users comply. If you have gone out of your way to break secure operation on Fedora, we will have to ban the use of Fedora by our users. I do not want to do that. As I said, this is not a technical discussion. You need to defer this to compliance people, who I predict will simply tell you “comply”. Sorry, but I have not the faintest clue how your comment is relevant to this discussion regarding systemd-resolved. Michael ___ 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
Summary/Minutes from today's FESCo Meeting (2020-09-30)
= #fedora-meeting-2: FESCO (2020-09-30) = Meeting started by mhroncok at 14:00:01 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-30/fesco.2020-09-30-14.00.log.html . Meeting summary --- * init process (mhroncok, 14:00:11) * #2474 F34 System-Wide Change: Rust Crate Packages For Release Branches (mhroncok, 14:03:54) * #2477 Fedora 33 schedule: Is it correct there is only one week between Beta and Final Freeze? (mhroncok, 14:11:04) * https://bodhi.fedoraproject.org/updates/?search=&status=pending&status=testing&releases=F33 (zbyszek, 14:21:23) * AGREED: Keep the bodhi time limit set for 3 days until the freeze (for this release cycle) +5.5,0.5,-0 (mhroncok, 14:30:22) * ACTION: nirik will add a comment with a pointer to this decision so no one changes it (mhroncok, 14:32:17) * #2476 systemd-resolved by default should be deferred to a future release (mhroncok, 14:32:31) * AGREED: Add #1879028 as FE, close 2476. (+5, 1, -0) (mhroncok, 14:49:09) * ACTION: zbyszek to mark 1879028 as a fesco accepted FE (mhroncok, 14:49:29) * ACTION: zbyszek to write a Fedora Magazine article (mhroncok, 14:49:50) * ACTION: zbyszek to make sure this gets into common bugs if it is not fixed (mhroncok, 14:50:11) * Next week's chair (mhroncok, 14:51:03) * ACTION: sgallagh will chair next meeting (mhroncok, 14:55:39) * Open Floor (mhroncok, 14:56:15) Meeting ended at 15:00:41 UTC. Action Items * nirik will add a comment with a pointer to this decision so no one changes it * zbyszek to mark 1879028 as a fesco accepted FE * zbyszek to write a Fedora Magazine article * zbyszek to make sure this gets into common bugs if it is not fixed * sgallagh will chair next meeting Action Items, by person --- * nirik * nirik will add a comment with a pointer to this decision so no one changes it * sgallagh * sgallagh will chair next meeting * zbyszek * zbyszek to mark 1879028 as a fesco accepted FE * zbyszek to write a Fedora Magazine article * zbyszek to make sure this gets into common bugs if it is not fixed * **UNASSIGNED** * (none) People Present (lines said) --- * mhroncok (105) * King_InuYasha (39) * zbyszek (29) * nirik (28) * dcantrell (27) * sgallagh (20) * decathorpe (19) * zodbot (17) * bcotton (16) * ignatenkobrain (0) * Conan_Kudo (0) * Eighth_Doctor (0) * cverna (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) -- 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: LTO and F33
On 9/30/20 7:39 AM, Robert-André Mauchin wrote:
On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:
So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
of
have been resolved (by opting the package out of LTO). I still expect
some LTO issues will pop up as packages fix things like missing
dependencies, cmake macros, etc. I continue to be available to investigate
potential LTO issues, but package maintainers will need to contact me as
I'm not actively looking for new LTO issues.
My focus is now turning to the packages with LTO opt-outs. I'll be
extracting
bug reports for upstream (primarily GCC), trying simple
workarounds for old style symbol versioning, identifying backports from
upstream GCC that allow us to remove LTO opt-outs and the like. So there
should be a trickle of opt-outs removed, but otherwise should largely be
invisible to the F33 release process.
I'd like to thank everyone involved for being patient while we worked
through
various issues and I look forward to continuing to make
incremental improvements now that the bulk of the LTO work has landed.
jeff
I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.
The package builds but segfaults with:
Thread 1 "clementine" received signal SIGSEGV, Segmentation fault.
0x777f7e5b in void doActivate(QObject*, int, void**) () from
/lib64/libQt5Core.so.5
(gdb) bt
#0 0x777f7e5b in void doActivate(QObject*, int, void**) () at
/lib64/libQt5Core
[ ... ]
The backtrace doesn't contain the value of the arguments, but there's a
very very good chance this is the same issue that I'm working on with
kstars and twinkle. We're getting multiple definitions of an object
that's supposed to be a singleton. If you've got a gdb session active,
the following would give me enough to conclude it's the same issue.
x/i $pc // Disassemble the current instruction
i r // Dump register state
--
I'd suggest disabling LTO while we sort that issue out via
%define _lto_cflags %{nil}
In the .spec file. That form of opt-out is flagged by my .spec file
scanner and once we fix the issue I can easily go back, retest and turn
LTO back on for those packages.
Jeff
___
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: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > > = What I am NOT working on > [...] > > - Any other tool, project not mentioned above or other > > native toolchains like golang, rust, clang/llvm or ocaml. > > I expect those to simply keep producing DWARF4. > > So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. > Despite clang supports DWARF-5 better and for a longer time than GCC. > > I did not take it to mean that. I took it to mean that he isn't going to tell other groups what to work on which a change request seems to have become. He instead expects them to keep doing what they are doing if they want versus getting forced to do what he is working on. > > Jan > ___ > 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, Sep 30, 2020 at 03:14:10PM +0200, Graham Leggett wrote: > I am required by these regulations and many other regulations in > multiple jurisdictions to make sure my users comply. If you have gone > out of your way to break secure operation on Fedora, we will have to > ban the use of Fedora by our users. I do not want to do that. Then don't ban them, and do your job instead? The fact of the matter is that using out-of-the-box Fedora configurations *today* can leak "private" DNS queries, and if VPNs are in use, it is a virtual certainty. To make Fedora "Compliant" using your definition, one already has to adjust the system configuration. This new approach, at worst, requires a slightly different configuration change to achieve the same results. > As I said, this is not a technical discussion. You need to defer this > to compliance people, who I predict will simply tell you “comply”. My $dayjob is headquartered in Europe and is in a _highly_ regulated, risk-adverse industry, with compliance officers coming out of the woodwork. Suffice it to say that what it means to "Comply" is highly context-sensitive. But you are correct, this is not a problem that can be solved via technical means -- Many legitimate use cases have diametrically-opposed needs, and there is no way for Fedora to know out-of-the-box which use case should apply as the general default. Moreover, at the granularity of specific DNS lookups, the general default can easily be wrong. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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: Packages in rawhide not showing in src.fedoraproject.org
On Wed, 30 Sep 2020 at 15:19, José Abílio Matos wrote: > > On Wednesday, September 30, 2020 12:39:15 PM WEST Fabio Valentini wrote: > > > If anything, this is a bug in the R-rprojroot package, because version > > 1.3.2 provides: "R(rprojroot) = 1.3-2", which is smaller than 1.3.2, > > and hence is not enough for >= 1.3.2. > > Thank you Fabio. Since this is done automatically in rpm macros, there is a > bug in there. > > I reported it to Elliot so now at the least the mystery is over. :-) The thing is that R(package) is meant to provide the original versioning (which allows hyphens and stuff), while R-package takes the adaptation to our versioning system. The problem is that we generally declare dependencies with R-package instead of R(package), and that's an issue in cases like this. I think that preserving the original versioning is a good idea, but we just need to switch to using R(package) to declare all dependencies, like Python, tex, etc., already do. -- 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
Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > = What I am NOT working on [...] > - Any other tool, project not mentioned above or other > native toolchains like golang, rust, clang/llvm or ocaml. > I expect those to simply keep producing DWARF4. So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. Despite clang supports DWARF-5 better and for a longer time than GCC. Jan ___ 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: LTO and F33
On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote: > So we're at a point where the F33 FTBFS issues related to LTO that I'm aware > of have been resolved (by opting the package out of LTO). I still expect > some LTO issues will pop up as packages fix things like missing > dependencies, cmake macros, etc. I continue to be available to investigate > potential LTO issues, but package maintainers will need to contact me as > I'm not actively looking for new LTO issues. > > My focus is now turning to the packages with LTO opt-outs. I'll be > extracting bug reports for upstream (primarily GCC), trying simple > workarounds for old style symbol versioning, identifying backports from > upstream GCC that allow us to remove LTO opt-outs and the like. So there > should be a trickle of opt-outs removed, but otherwise should largely be > invisible to the F33 release process. > I'd like to thank everyone involved for being patient while we worked > through various issues and I look forward to continuing to make > incremental improvements now that the bulk of the LTO work has landed. > > jeff > I have an issue with both Clementine and Strawberry (a fork of Clementine) in F33 and above, users reported that disabling LTO fixes the problem. The package builds but segfaults with: Thread 1 "clementine" received signal SIGSEGV, Segmentation fault. 0x777f7e5b in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 (gdb) bt #0 0x777f7e5b in void doActivate(QObject*, int, void**) () at /lib64/libQt5Core.so.5 #1 0x76984ee2 in QGuiApplication::screenAdded(QScreen*) () at /lib64/libQt5Gui.so.5 #2 0x7697523c in QWindowSystemInterface::handleScreenAdded(QPlatformScreen*, bool) () at /lib64/libQt5Gui.so.5 #3 0x7fffe3e992b0 in QXcbConnection::initializeScreens() () at /lib64/libQt5XcbQpa.so.5 #4 0x7fffe3e74bd0 in QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) () at /lib64/libQt5XcbQpa.so.5 #5 0x7fffe3e77853 in QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) () at /lib64/libQt5XcbQpa.so.5 #6 0x77fc746f in QXcbIntegrationPlugin::create(QString const&, QStringList const&, int&, char**) () at /usr/lib64/qt5/plugins/platforms/libqxcb.so #7 0x7697df4b in QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) () at /lib64/libQt5Gui.so.5 #8 0x76988690 in QGuiApplicationPrivate::createPlatformIntegration() () at /lib64/libQt5Gui.so.5 #9 0x76989ca0 in QGuiApplicationPrivate::createEventDispatcher() () at /lib64/libQt5Gui.so.5 #10 0x777cff86 in QCoreApplicationPrivate::init() () at /lib64/libQt5Core.so.5 #11 0x7698c5f4 in QGuiApplicationPrivate::init() () at /lib64/libQt5Gui.so.5 #12 0x76f4aef9 in QApplicationPrivate::init() () at /lib64/libQt5Widgets.so.5 #13 0x76651fa7 in QtSingleApplication::QtSingleApplication(int&, char**, bool) () at /lib64/libQt5Solutions_SingleApplication-2.6.so.1 #14 0x55819db4 in main(int, char**) (argc=, argv=0x7fffe4d8) at /usr/src/debug/clementine-1.4.0-2.rc1.20200617gitedb8c3b.fc33.x86_64/src/main.cpp:330 So right at the beginning of the main function and call to QtSingleApplication. Qtsingleapplication is old code, not touched in 8 years. Any ideas as to why LTO won't work with these packages? Best regards, Robert-André ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Tue, 29 Sep 2020 22:31:28 +0200, Mark Wielaard wrote: > Note that you are using -ffunction-sections together with -flto. > With -flto you don't need -ffunction-sections. > > -ffunction sections might cause functions to be dropped by the linker > without updating the DWARF DIEs, causing things like a zero > DW_AT_low_pc. > > Just using -flto should not cause such issues. Thanks for this investigation. You are right in gcc -flto binaries I cannot find these dead DIEs. Found C++ with LTO in libabigail, libreoffice, powertop. Surprisingly gcc has LTO turned off. Jan ___ 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: Packages in rawhide not showing in src.fedoraproject.org
On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote: > It actually queries bodhi and failing to find things in it, it fallsback to > mdapi normally. > Potential bug in the logic? Another example: https://src.fedoraproject.org/rpms/texlive -- José Abílio___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 29 Sep 2020, at 23:44, Michael Catanzaro wrote: > This is either a very strange misunderstanding, or trolling. I will assume > positive intent. Internet RFCs are not regulatory requirements. If you're > aware of some government regulation that requires us to forward RRSEC > records, I would be very surprised, but please do let us know. Regulations like the GDPR exist, and ignorance of them is not a defence. I am required by these regulations and many other regulations in multiple jurisdictions to make sure my users comply. If you have gone out of your way to break secure operation on Fedora, we will have to ban the use of Fedora by our users. I do not want to do that. As I said, this is not a technical discussion. You need to defer this to compliance people, who I predict will simply tell you “comply”. Regards, Graham — ___ 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
Non-responsive maintainer: jhogarth
Hi, in accordance with https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ this is a Non-responsive maintainer check for James Hogarth. Non-responsive bug: https://bugzilla.redhat.com/show_bug.cgi?id=1883892 Unactioned bugs (CVEs from 2019, oldest from 2017): https://bugzilla.redhat.com/show_bug.cgi?id=1471054 https://bugzilla.redhat.com/show_bug.cgi?id=1451237 https://bugzilla.redhat.com/show_bug.cgi?id=1410117 https://bugzilla.redhat.com/show_bug.cgi?id=1472721 https://bugzilla.redhat.com/show_bug.cgi?id=1498910 https://bugzilla.redhat.com/show_bug.cgi?id=1652067 https://bugzilla.redhat.com/show_bug.cgi?id=1586352 https://bugzilla.redhat.com/show_bug.cgi?id=1712550 https://bugzilla.redhat.com/show_bug.cgi?id=1763565 https://bugzilla.redhat.com/show_bug.cgi?id=1486729 https://bugzilla.redhat.com/show_bug.cgi?id=1813670 https://bugzilla.redhat.com/show_bug.cgi?id=1823048 https://bugzilla.redhat.com/show_bug.cgi?id=1210993 https://bugzilla.redhat.com/show_bug.cgi?id=1842886 https://bugzilla.redhat.com/show_bug.cgi?id=1697354 https://bugzilla.redhat.com/show_bug.cgi?id=1856025 https://bugzilla.redhat.com/show_bug.cgi?id=1697054 https://bugzilla.redhat.com/show_bug.cgi?id=1797336 https://bugzilla.redhat.com/show_bug.cgi?id=1876763 https://bugzilla.redhat.com/show_bug.cgi?id=1877020 https://bugzilla.redhat.com/show_bug.cgi?id=1877027 https://bugzilla.redhat.com/show_bug.cgi?id=1877028 https://bugzilla.redhat.com/show_bug.cgi?id=1877043 So, does anyone know how to contact James? Thanks, --Robbie 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: Packages in rawhide not showing in src.fedoraproject.org
On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote: > It actually queries bodhi and failing to find things in it, it fallsback to > mdapi normally. > Potential bug in the logic? I noticed it before, since at least June, in other packages so I would say yes. -- José Abílio___ 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: Packages in rawhide not showing in src.fedoraproject.org
On Wednesday, September 30, 2020 12:39:15 PM WEST Fabio Valentini wrote: > If anything, this is a bug in the R-rprojroot package, because version > 1.3.2 provides: "R(rprojroot) = 1.3-2", which is smaller than 1.3.2, > and hence is not enough for >= 1.3.2. Thank you Fabio. Since this is done automatically in rpm macros, there is a bug in there. I reported it to Elliot so now at the least the mystery is over. :-) -- José Abílio___ 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
Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
Hi Neal, On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote: > For the record, Mark has started implementing DWARF-5 support in dwz: > https://sourceware.org/git/?p=dwz.git;a=log > > I think I would rather like to see a Change proposal to switch to > DWARF-5 for Fedora 34, especially since it looks like dwz will be > ready for it. That is indeed my goal, but I wasn't planning on filing a specific Change Proposal for it. First because as you observed in the past we did some of these debuginfo things Fedora first and then it took years (!) for some of the default settings we had changed and helper scripts to make it upstream. So I am concentrating on getting everything ready upstream first before making and proposing any changes for Fedora. Secondly I am hoping that because of the first point the GCC11 for Fedora 34 Change Proposal will simply say "-gdwarf-5 is now the default". Lastly, and sadly, I find the whole Fedora change proposal debates extremely hostile. They often seem to quickly result in people attacking you because you made a choice to spend time to work on A and not their favorite feature B, and if they cannot have feature B then you should also not spend any more time on A. So I am happy to describe the work I am doing to try to get DWARF5 the default for GCC11 and by extension for the Fedora 34 default toolchain, but I will mainly do that work upstream and then see whether it is all ready on time to enable it for Fedora 34. But I am not interested in a heated debate on how I should prioritize my time and energy. = Why DWARF5 for GCC? - A couple of new tags and attributes make it easier/more accurate to describe some of the newer language features (although most were already covered by various GNU extensions) - A lot of GNU extensions to DWARF4 have been standardized in DWARF5. By adopting the standardized variant alternative toolchains will hopefully find it easier to support these features. - The representation of various data structures in DWARF5 is much more efficient causing a 25% on-disk size reduction (before any other compression method) for the .debug sections: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553527.html = DWARF5 for the (extended) GNU toolchain - binutils (gas) is responsible for turning part of the assembly produced by the compiler into a line table (.debug_line) and the linker sometimes reads parts of the DWARF (for example when producing warnings about where a symbol was defined). The just released binutils 2.35.1 should have all fixes necessary to support DWARF5. - gcc needs to use the new gas features. Jakub has a patch (not committed yet): https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553992.html - gdb seems ready except for one corner case with C++ static member variables in classes. This is because in DWARF5 these are represented not as variables, which might be optimized away when not used. In this case gcc probably shouldn't optimize out the unused variables (or gdb should not depend on being able to show optimized out static member variables). Ongoing debate how to resolve this: https://sourceware.org/bugzilla/show_bug.cgi?id=26525 https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html - The just released elfutils 0.181 seems to have all needed support, which should cover systemtap, dwarves, perf, systemd, libabigail. More testing ongoing. - For valgrind I initially wanted to switch the DWARF reader to an external helper program based on elfutils libdw. But to get a solution faster I will tweak the internal reader to deal with just the minimal DWARF5 as generated by gcc for now. I haven't started on this yet. = DWARF5 for the (Fedora) packaging tools - rpm debugedit has patches to support DWARF5 but we have to make sure they have testcases to work with gcc: http://lists.rpm.org/pipermail/rpm-maint/2020-August/014833.html - dwz is seeing active work towards supporting DWARF5: https://sourceware.org/pipermail/dwz/2020q3/000668.html I am hoping that by end of next week we have generic support. That might not do optimal compression yet and will probably need lots of testing (and bug fixing). = What I am NOT working on - We'll keep using .gdb_index for now, moving to .debug_names only when that is ready in gdb: https://sourceware.org/pipermail/gdb/2020-September/048879.html - Optional DWARF5 features like debug-types, forms, operations or index tables only used for split-dwarf by GCC (e.g. DW_FORM_strx, DW_FORM_addrx, DW_FORM_loclistx, DW_FORM_rnglistx, DW_OP_addrx, DW_OP_constx). - Any other tool, project not mentioned above or other native toolchains like golang, rust, clang/llvm or ocaml. I expect those to simply keep producing DWARF4. That doesn't mean I won't help with any of the above if others propose to do that work for the various pieces of the toolchain and packaging, but I currently don't have time for it and I d
Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Tue, 29 Sep 2020 22:35:14 +0200, Mark Wielaard wrote: > On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote: > > * DW_TAG_partial_unit should have DW_AT_language. > > * DW_TAG_partial_unit must contain only types (struct/class). > >Currently they contain for example also static constant variables but > > when > >you parse such independent DW_TAG_partial_unit into which dictionary you > >will register such variable? That makes no sense. > > You might want to look at the experiments to do something like that > from Tom de Vries: > https://sourceware.org/pipermail/dwz/2020q1/000579.html This is another extension of the DWZ tool and tags. The goal is to make the file format (and tooling) more fast and simple, not more slow and complex. > https://sourceware.org/pipermail/dwz/2020q1/000568.html This looks as the DWZ DW_AT_language problem #1 fix listed above. > Hacking on dwz and supporting partial units and DWARF supplemential > files in debugger like tools isn't trivial. But it is IMHO also not > such a big effort that we have to drop everything else. So why is Fedora stuck for 3.5 years on DWARF-4? I would switch Fedora to DWARF-5 long time ago but I could not as there isn't anyone willing to work on DWZ. Even now you want to port it to DWARF-5 but nothing more. It needs also to * fix bugs * support LLVM DWARF-5 * support .debug_names * support -fdebug-types-section (for reduction of size already during linking) * with all the effort it is a pity it gives up on large debuginfos as it would run out of memory DWZ could be a nice tool (not really critical but an interesting challenge) but it is not important enough to make people find time working on it. Jan ___ 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
Non-responsive maintainer: ichavero
Hi, This is a non-responsive maintainer check for ichavero, in accordance with policy [0]. I submitted 2 bugs [1][2] related to outdated nextcloud versions containing multiple (moderate) CVEs [3] about a month ago, but have not had any response. nextcloud has a huge number of open bugs [4], although most of them were reported against older nextcloud versions. Last activity from commit history was three months ago. Does anyone know how to contact the maintainer? Christopher [0] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1873705 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1873704 [3] https://nextcloud.com/security/advisories/ [4] https://bugzilla.redhat.com/buglist.cgi?component=nextcloud&list_id=11393781&product=Fedora [5] https://src.fedoraproject.org/rpms/nextcloud/c/a4e7ed8572f74a415bcf5fe57f84073989faf768?branch=master ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote: > -fdebug-types-section a supported option in the sense that it's in the > compiler and we'll fix bugs in it when we can. But the GCC community > doesn't really test that option and it's known to be broken with LTO. I believe you base this information on Jakub Jelinek's internal company mail: Message-ID: <20200710092926.GJ2363@tucnak> IIUC that mail contains incorrect information. My apologies if my deduction is incorrect, I am also writing "IIUC" here. I am basing my information on explanation by GCC developer Richard Biener: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878#c8 It is explained there "in_lto_p" means GCC is in second/later phase of LTO. Not that LTO is enabled at all (as Jakub Jelinek said in the internal mail). Also GCC does not produce ICEs (=compiler crash, (*)) Jakub Jelinek was claiming will happen during the 2+ packages rebuild with LTO and -fdebug-types-section I have done. So I really see no indication why GCC would not normally support -fdebug-types-section even with LTO. Also it is so simple optimization of DWARF there is no reason why there should be any longterm issues with it. Jan (*) There were 7 packages reproducing GCC crashes due to the following two GCC Bugs specific to -fdebug-types-section. That is unrelated to the topic of the "in_lto_p" condition discussed above. ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471 ICE: c++: dwarf2out_abstract_function, at dwarf2out.c: -g -fdebug-types-section https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96472 ___ 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
