[EPEL-devel] Re: proposal: EPEL 8 Next
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel. 1. EPEL Steering Committee approves the proposal 2. koji changes: - create CentOS Stream 8 external repo - create epel8-next build target (inheriting from epel8) - dist macro override for that target 3. create PDC entries 4. update fedscm-admin with branch SLAs 5. configure dist-git to allow branch name 6. update pungi config 7. add epel-next-repo subpackage to epel-release 8. add epel8-next release in bodhi 9. document in the wiki 10. announcement email Please let me know if I'm missing anything. On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > I agree, using .el8.next for the dist macro makes the most sense. This will > enable maintainers to use a similar workflow to Fedora branches, where older > branches can be fast forwarded, and the same commit can be built for > different targets but still have different NVRs in Koji. Here is an example > workflow for a fictional foo package that already exists in Fedora. > > - request epel8 branch > - merge master branch to epel8 branch > - build epel8 branch, resulting in foo-1-1.el8 > - realize it won't install on CentOS Stream due to a library difference > - request epel8-next branch > - merge epel8 branch to epel8-next branch > - build epel8-next branch, resulting in foo-1-1.el8.next > > After the next RHEL 8 minor release (when that library difference affects > everyone), the maintainer can increment the release on the epel8 branch and > proceed as usual. > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > At the EPEL Steering Committee last week, we had an extensive discussion > > > of > > > this proposal, specifically focused on how to handle the dist macro. I > > > believe these are the possible choices. > > > > > > * keep dist the same as epel8 (.el8) > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 > > > for > > > dist. It would make sense to continue using the same dist for EPEL Next. > > > However, this would put a little more work on packagers. They would not > > > be > > > able to build the same commit for both EPEL and EPEL Next because the NVR > > > will conflict in Koji. In simple rebuild situations, this is not a > > > problem > > > because at a minimum the release will be higher. But if a packager wanted > > > to update the package in both EPEL and EPEL Next, they will need to first > > > update and build it in EPEL, then bump the release and build it in EPEL > > > Next. This isn't ideal, but isn't terrible either, and can be partially > > > mitigated by good documentation around EPEL Next workflows. > > > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > > > In EPEL Next we could define dist to a string that RPM evaluates higher > > > than > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to > > > be > > > in sync and the same commit could be built for both targets. The higher > > > dist would ensure the upgrade path works. > > > > I think this makes the most sense and will help packages workflows the > > best. > > > > kevin > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > > > > -- > Carl George -- Carl George ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-10-02 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/10/02/report-389-ds-base-1.4.4.4-20201001git7275ce9.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
GitHub CLI was Re: Orphaning 'hub' (the git wrapper for Github)
On 9/29/20 12:07 PM, Joe Doss wrote: On 9/29/20 10:44 AM, Rich Megginson wrote: Is there a plan to package `gh` in Fedora? https://bugzilla.redhat.com/show_bug.cgi?id=1803302 I am slogging through it slowly. OK, I have things built for Rawhide and F33. You can check it out here https://copr.fedorainfracloud.org/coprs/jdoss/github-cli/builds/ if you want to give it a spin. I will file the BZ new package paperwork to get the 11 new RPMs reviewed once I emotionally recover from this Golang RPM packaging adventure in the next day or so. Oh, and if we want it in F32 sooner rather than later this needs some Karma: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c199daf5b3 A special shout out to Robert-André Mauchin for helping me off list with all of my go2rpm / Golang RPM questions. 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
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 --- Comment #8 from Fedora Update System --- FEDORA-2020-31b5a0d352 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-31b5a0d352` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-31b5a0d352 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- FEDORA-2020-65c3e7223d has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-65c3e7223d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-65c3e7223d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 --- Comment #7 from Fedora Update System --- FEDORA-2020-d9daf21032 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d9daf21032` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d9daf21032 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: In which order does ELN build packages, what build root is it using?
On 9/22/20 1:19 PM, Stephen Gallagher wrote: On Mon, Sep 21, 2020 at 9:55 AM Miro Hrončok wrote: On 21. 09. 20 15:40, Mark Wielaard wrote: Hi, I couldn't build elfutils because of an annobin bug that showed up on ppc64le. Nick was nice enough to fix it and push a new annobin version: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e So I could build elfutils again: https://bodhi.fedoraproject.org/updates/FEDORA-2020-06dafb46c1 But now I am getting notices about the ELN build failures: https://koji.fedoraproject.org/koji/buildinfo?buildID=1613859 Which is clearly because it doesn't have the new annobin package. In this case, the build fails, which is the better outcome. However recently, I've rebuild redhat-rpm-config with this change: https://src.fedoraproject.org/rpms/redhat-rpm-config/c/0d621460 And later I've built python3.9 with the new macro to actually deliver the change. In order to make it work, I've run: $ koji wait-repo f34-build --build=redhat-rpm-config-172-1.fc34 $ koji wait-repo eln-build --build=redhat-rpm-config-172-1.eln103 before building python3.9 in rawhide. But I wondered: In case I would have not run the ELN waitrepo, would ELN possibly rebuild python3.9 before the new redhat-rpm-config was available in the ELN buildroot? Yes, this race is possible if the time it takes ELN to complete the rebuild of the first package is longer than the time it takes the second package to build and then also trigger the ELN build. It's unlikely to occur often, but it is a possibility. I'm not sure how to avoid it since without a side-tag we can't know which builds might be dependent on one another. For those grouped builds that use a side-tag, we're going to be monitoring those and rebuilding them in the same order as they are submitted. We can also add a waitrepo to our behavior to ensure that we don't start newer builds before the prior ones succeed. Thanks for bringing this up! I think I have another build ordering issue. Recently libevent had a soname bump and deps were built in a side tag. However, in ELN openmpi-4.0.5-2.eln103 (which was the release bump for the libevent rebuild) was built before libevent-2.1.12-2.eln103 was. Now I'm getting spammed every couple of hours with netcdf and vtk ELN build failures due to broken deps on libevent (and others). Are we now stuck with bumping the release for openmpi again for the ELN build? Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1883370] perltidy-20201001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883370 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perltidy-20201001-1.fc34|perltidy-20201001-1.fc34 ||perltidy-20201001-1.fc33 Resolution|--- |ERRATA Last Closed||2020-10-02 00:34:42 --- Comment #5 from Fedora Update System --- FEDORA-2020-14cb2245b0 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1883498] perl-Module-Load-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883498 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Module-Load-0.36-1.fc3 |perl-Module-Load-0.36-1.fc3 |4 |4 ||perl-Module-Load-0.36-1.fc3 ||3 Resolution|--- |ERRATA Last Closed||2020-10-02 00:34:54 --- Comment #5 from Fedora Update System --- FEDORA-2020-017a46fd23 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1881646] perl-version-0.9928 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1881646 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-version-0.99.28-1.fc34 |perl-version-0.99.28-1.fc34 ||perl-version-0.99.28-1.fc33 Resolution|--- |ERRATA Last Closed||2020-10-02 00:33:51 --- Comment #3 from Fedora Update System --- FEDORA-2020-edf7262def has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Am 01.10.20 um 19:45 schrieb Vitaly Zaitsev via devel: > On 01.10.2020 17:46, Neal Gompa wrote: >> They also completely break most VPNs and corporate network setups, so... > It will not, because Fedora will use opportunistic mode by default. > DoT won't break anything, it's blockable by an admin in the firewall, unlike DoH, which uses port 443. 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 33 System-Wide Change proposal: systemd-resolved
Am 01.10.20 um 17:44 schrieb Vitaly Zaitsev via devel: > On 01.10.2020 16:54, Petr Menšík wrote: >> But DNS over TLS does not bring you more privacy usually. > It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy > on you and sell the collected data to third parties. > ... if you changed the dns servers manually to other != isp caches. ;) 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
Am 01.10.20 um 19:36 schrieb Simo Sorce: > That said, > if it really is an internal DNS and there are strong policies around it > I assume that the perimeter or the local machine firewall will be > configured to block UDP packets to port 53 to any other external > servers ... > > This leaves out only some machines or some cases where a > misconfiguration may cause this fallback to kick in. The occurrence is > probably rare enough not to be a problem in practice at least from the > pov of GDPR. you know, that you contradict yourself here? :) If the corp has blocked port 53 except for the internal dns server, how should the fallback packet get out? I think, it's not important how often the default is used, it's the fact that it's hidden and therefor surprising for the corp itself, which makes it even more risky to run the os, than it's worth giving ( or in your example not to give ) the 0.1% a fallback answere. IRL admins who know about it, as we all do now, we can avoid the problem. But for a company, which has to justify the surprising result of a DP audit, it will not be an easy talk with the dp buero. Just for the lols, I will ask our highest federal dp advocate tomorrow, what he thinks about 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
Am 01.10.20 um 16:36 schrieb Alexander Bokovoy: > > You can also drop a configuration snippet in > /etc/systemd/resolved.conf.d/ to contain > > FallbackDNS= > > This will disable global DNS servers for any case. > if that would be the default, it would be ok. Am 01.10.20 um 16:03 schrieb Michael Catanzaro: > We are not going to patch out fallback to Cloudflare or Google because > it is a non-issue. Fallback only happens when you have zero other DNS > servers configured. When was the last time you connected to a network > and there's no DHCP, no nothing? The number of users without some > other working DNS is probably under 0.1%. BTW: thumbs up for the DOT proposal. I will make it very clear and easy: O== Situation for Germany GDPR is in place as a EU LAW. The protection rules are only active for companies or organizations, not for private people. 2013 a german court (Kammergericht Berlin) ruled, that IP addresses are Personal Data. It has never been overruled. Personal Data can only be send to none eu countries and corporations, if there is a data protection law in place that has the same or better level of protection as the eu law has ( or if it's necessary to buy stuff (a house, car, whatever ). The pact the EU did with the US was called Privacy Shield. It imploded (for the second time) a few months ago. From the moment the eu court rule was public, transfer of personal data into the us was illegal. If you send a DNS REQUEST to a US DNS server from within a company network, and with ipv6 the internal ip is sent out i learned lately, you have sent personal data which is protected under the GDRP. It's not unlikely to use company pcs for private webvisits while having a meal break. Therefor, a os that has google and cloudflare as a default, even if it's unlikely to happen as you point out, which sends out dns with personal data in it to a us dns server, brings the company in great trouble with the law. In the end, this means, you as a company/org need to pay a (possibly) shitload of money as a fine and therefor they can't use this os anymore. (someone else on the list pointed this out too.) The consequence is, Fedora is a juristic risk. [The fine is higher, if you as corp/org did not document this data transfer in your data protection memos] Of course a working dns setup will prevent this problem, but thats not the point. Activists in germany and other countries try to get more and more gov projects to OSS due to privacy issues with M$. It would be a shame if Fedora would also count as a potential problem. Do we all really want this, for the benefit on 0.1%(as you say) have a dns lookup instead of a hint, that their systems are broken? Pls remember: I'm just the messenger, Í didn't write the laws ;) Funfact: last time I checked the northern germany police pc in my city, they used a fedora based desktop system. I like that fact :D But i'm pretty sure, they don't like a cloudflare fallback dns once they reach F33 ( if ever ). best regards, Marius Schwarz ___ 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2020-10-02 from 21:00:00 to 22:00:00 UTC At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9722/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: LTO and F33
On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote: 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 Ah, this isn't a Fedora package. That's why it didn't show in Florian's symbol search or my dynamic relocation search. What you want to do to fix this is force -fPIC into the build flags. That inhibits local symbol resolution and the copy relocs that are so problematical for QT. You can see examples of how to do this in the clementine package. 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
FedoraRespin-32-updates-20201001.0 compose check report
Missing expected images: Xfce live x86_64 Failed openQA tests: 4/37 (x86_64) ID: 683018 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/683018 ID: 683034 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/683034 ID: 683042 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/683042 ID: 683045 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/683045 Soft failed openQA tests: 2/37 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 683016 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/683016 ID: 683029 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/683029 Passed openQA tests: 31/37 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO and F33
On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote: 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 ACK. I'll verify it's the same issue and that the fix we're using for kstars, twinkle, etc works for the telegram desktop. 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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On 01/10/2020 20:02, Simo Sorce wrote: You mean Fedora 33 release notes ? We already blocked things like TLS1.0/1.1 in previous Fedras, and that had a larger impact on legacy enterprise laggards, I do not know if this specific case is worth that much. Actually TLS1.0 and 1.1 are still allowed - that's something else that changes in F33 ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thu, 2020-10-01 at 18:08 +, Gary Buhrmaster wrote: > On Thu, Oct 1, 2020 at 5:21 PM Simo Sorce wrote: > > > Note that at this point in time (2020), this is a server bug not a > > Fedora policy problem. > > Regardless, as (especially) corporate services tend > to have lives that are excessively longer than updates > in security policies, it might deserve a special mention > in the release notes that some (especially) corporate > systems may fail to connect due to the change in > Fedora security policies, because it may impact the > user experience in a very negative way. You mean Fedora 33 release notes ? We already blocked things like TLS1.0/1.1 in previous Fedras, and that had a larger impact on legacy enterprise laggards, I do not know if this specific case is worth that much. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
On Wed, Sep 30, 2020 at 11:50:00AM -0500, 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 After the latest updates, this should not necessary (though it will still work). Instead, specify a preset (before the upgrade): sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable systemd-resolved.service" >/etc/systemd/system-preset/20-systemd-resolved-disable.preset' This is also described in https://fedoraproject.org/wiki/Changes/systemd-resolved#Fully_opting_out_of_systemd-resolved_use 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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thu, Oct 1, 2020 at 5:21 PM Simo Sorce wrote: > Note that at this point in time (2020), this is a server bug not a > Fedora policy problem. Regardless, as (especially) corporate services tend to have lives that are excessively longer than updates in security policies, it might deserve a special mention in the release notes that some (especially) corporate systems may fail to connect due to the change in Fedora security policies, because it may impact the user experience in a very negative way. ___ 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 10/1/20 5:52 AM, Marius Schwarz wrote: Is it possible to boot from the stick and then perform a grub-install with an old grub? This attempt failed too: # grub2-install /dev/sda grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert nicht. Bitte geben Sie --target oder --directory an. and that file seems not to be part of any package. There is only one for "i386-pc". You can't (and must not!) use grub2-install on an EFI system. ___ 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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thu, 2020-10-01 at 14:01 -0400, Simo Sorce wrote: > On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote: > > On 01. 10. 20 19:20, Simo Sorce wrote: > > > and the policy affects all software on the system, not just thunderbird > > > ... > > > > Is it possible to workaround the problem in Thunderbird only? > > Only if thunderbrind provides a configuration option to set it and then > instructs NSS, afaik. > > CCing Bob, in case he knows of other ways. Adding back context for Bob, this is about enabling 1024 DH, because some IMAP servers are still badly configured ... The q. is if this can be done exclusively for thunderbird instead of changing the system crypto policy for all TLS applications. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote: > On 01. 10. 20 19:20, Simo Sorce wrote: > > and the policy affects all software on the system, not just thunderbird ... > > Is it possible to workaround the problem in Thunderbird only? Only if thunderbrind provides a configuration option to set it and then instructs NSS, afaik. CCing Bob, in case he knows of other ways. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On 01. 10. 20 19:20, Simo Sorce wrote: and the policy affects all software on the system, not just thunderbird ... Is it possible to workaround the problem in Thunderbird only? -- 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 33 System-Wide Change proposal: systemd-resolved
On 01.10.2020 17:46, Neal Gompa wrote: > They also completely break most VPNs and corporate network setups, so... It will not, because Fedora will use opportunistic mode by default. -- 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 Thu, 2020-10-01 at 09:03 -0500, Michael Catanzaro wrote: > On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz > wrote: > > I think, he meant the systemd-resolved fiallback to Cloudflare and > > Google. Is that in the fedora build? If so, i suggest to patch it out. > > That will fix the issue for me in perspective of the GDPR. > > Unless you explain this *very* clearly, I'm going to ignore it, because > it seems farfetched. Fedora is not operating its own DNS server or > collecting any sort of DNS-related data from you. > > We are not going to patch out fallback to Cloudflare or Google because > it is a non-issue. Fallback only happens when you have zero other DNS > servers configured. When was the last time you connected to a network > and there's no DHCP, no nothing? The number of users without some other > working DNS is probably under 0.1%. Even then, I think you also have to > disable NetworkManager for systemd-resolved to ever use its fallback > DNS, because NetworkManager will configure a ~. DNS domain, causing > systemd-resolved to never use its global DNS settings. (I think. That's > my reading of the manpage. Testing welcome from anyone who wants to > confirm that.) > > So (if I'm right) we are talking about the exceeding rare combination > of (a) no DNS set by DHCP, and also (b) user manually disabled > NetworkManager. If you're really going to do (b) you will probably also > disable systemd-resolved, right? Or make the one-line config file > change to remove the fallback DNS? Or just manually set some DNS > server? Seriously, this is a silly thing to worry about. > > Finally, in the extremely unlikely event you do somehow wind up with > Cloudflare and Google DNS, then you should *celebrate*, because they > have extremely strong privacy policies for their DNS. Unless you think > they are just lying about their data collection practices -- which they > are not -- you have nothing to worry about from their DNS [1][2]. In > contrast, your ISP is probably selling your DNS queries to advertisers. > If you disagree, doesn't matter, because you're probably never going to > see this fallback. Michael, I think the issue here is not Google DNS vs ISP DNS, but internal DNS vs spilling it out to Google/Cloudflare. That said, if it really is an internal DNS and there are strong policies around it I assume that the perimeter or the local machine firewall will be configured to block UDP packets to port 53 to any other external servers ... This leaves out only some machines or some cases where a misconfiguration may cause this fallback to kick in. The occurrence is probably rare enough not to be a problem in practice at least from the pov of GDPR. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F33 update stuck for past 6 days in request for testing->stable
On 9/30/20 5:03 PM, Miro Hrončok wrote: > 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 :( > Thanks, but don't stress and no worries. You gave advice that was correct, it just didn't work in the presence of some overrides manually done to workaround other bugs. I learned quite a bit in the process. Leveraging epoch, the pitfalls of epoch, and using side tags and multi-builds. It's all good. -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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
Note that at this point in time (2020), this is a server bug not a Fedora policy problem. I also heartily approve of using a custom policy change rather than switching to legacy, and hopefully people will quickly be able to remove that custom change too because that DH size is simply too weak for today standard, and the policy affects all software on the system, not just thunderbird ... Simo. On Thu, 2020-10-01 at 08:18 +0200, Lumír Balhar wrote: > 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: >
[Bug 1879741] CVE-2014-10402 perl-dbi: Incomplete fix for CVE-2014-10401
https://bugzilla.redhat.com/show_bug.cgi?id=1879741 Todd Cullum changed: What|Removed |Added Depends On||1884324, 1884325, 1884326 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1879741] CVE-2014-10402 perl-dbi: Incomplete fix for CVE-2014-10401
https://bugzilla.redhat.com/show_bug.cgi?id=1879741 Todd Cullum changed: What|Removed |Added Fixed In Version|perl-DBI 1.632 | -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Oct 1, 2020 at 3:48 PM Neal Gompa wrote: > > On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel > wrote: > > > > On 01.10.2020 16:54, Petr Menšík wrote: > > > But DNS over TLS does not bring you more privacy usually. > > > > It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy > > on you and sell the collected data to third parties. > > > > They also completely break most VPNs and corporate network setups, so... Well, as much else, whether it breaks a VPN or corporate network, or even a countries attempt to use DNS for blocking purposes depends on the details of implementation, and what tools are available at the various levels to influence the resolver behaviours to implement whatever the entities are trying to accomplish. It should come to no real surprise to those on this list that newer tech can certainly require existing practices to be forced to adopt, nor that those that want things to stay the same need to get used to disappointment. ___ 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 Thu, Oct 01, 2020 at 12:08:19PM -0400, Paul Wouters wrote: > Clearly, there is a case for making systemd-resolved "default with > an option to opt-out". It makes no sense that these deployments > must install and ensure to then disable and keep disabled, the > systemd-resolved daemon. I fully agree that an opt-out should be possible. I don't think anyone suggested differently. On normal upgrades following the transition to F33, nothing special needs to be done. The only exception is the first upgrade to F33, where we reset systemd-resolved.service enablement and adjust resolv.conf symlink. Those changes are conditionalized on systemd-resolved.service being enabled in presets. To opt out, create a local preset which disables systemd-resolved. I now added a section about this to the Change page: https://fedoraproject.org/w/index.php?title=Changes%2Fsystemd-resolved=revision=589756=588639 (There's also the question of changes to /etc/nsswitch.conf. Those are currently done unconditionally based on the premise that nss-resolve has no effect if systemd-resolved.service is not running. We can adjust that too if needed.) 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:^M^J systemd-resolved
On Thu, 1 Oct 2020, Michael Catanzaro wrote: We are not going to patch out fallback to Cloudflare or Google because it is a non-issue. Fallback only happens when you have zero other DNS servers configured. When was the last time you connected to a network and there's no DHCP, no nothing? The number of users without some other working DNS is probably under 0.1%. DNS discovery is currrently a hot topic at the IETF and there are various proposals circulating on how a client should behave to find its best DNS resolver. Please see the ADD and DPRIVE working groups and their documents. I posted a few direct links in the last few days already. I think a mechanism that has been architectured by a wider group of engineers from a large number of different backgrounds and use cases would be a more appropriate venue to address this complex policy issue. Personally, I prefer to prompt the user for permission before deciding to send their personal data to (mostly US based) entities. And while the majorit of desktop users _might_ be okay with this implicit decision, it is always better to confirm that explicitely. You might think that UI is as bad as the COOKIE popups we now get, but lawyers disagree with us - whether we like or not that is a universe we live in. Fruthermore it seems the servers running this will almost always never want this to happen, as most enterprises these days, especially in light of TLS 1.3 and encrypted SNI, are more and more reliant on using the DNS stream as an active firewall. 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 Thu, 1 Oct 2020, Neal Gompa wrote: Essentially, split-horizon DNS setups on Fedora systems become possible with this change. As reported by libreswan and openvpn developers already in the last two days, these are already possible without systemd-resolved and people have relied on that for years. We have also seen reports like one where servers in an Active Directory domain with systemd-resolved have broken DNS due to load issues. Clearly, there is a case for making systemd-resolved "default with an option to opt-out". It makes no sense that these deployments must install and ensure to then disable and keep disabled, the systemd-resolved daemon. The argument against this so far has been "it makes things more complicated". I have asked for specific details on this so we can talk about potentially addressing those complications and make everybody happy. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel wrote: > > On 01.10.2020 16:54, Petr Menšík wrote: > > But DNS over TLS does not bring you more privacy usually. > > It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy > on you and sell the collected data to third parties. > They also completely break most VPNs and corporate network setups, so... -- 真実はいつも一つ！/ 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 33 System-Wide Change proposal: systemd-resolved
On 01.10.2020 16:54, Petr Menšík wrote: > But DNS over TLS does not bring you more privacy usually. It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy on you and sell the collected data to third parties. -- 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: Error creating the package RPM: make:*** No rule to make target 'install'.
On Thu, Oct 01, 2020 at 03:20:19PM -, Helg Green via devel wrote: > What is meant by 'strip the binary file'? Binaries can be built to include debug information. This makes them (sometimes a lot) bigger, so it's customary to build them without that information for production use. (Or to build with that information and then strip it out.) However, in Fedora, instead of doing it that way, you should build *with* the debug information included in the binaries, because there's a magic system which extracts that and puts it into separate debuginfo rpms which can be installed separately when debuging is needed. So, find what in the build process for your app is doing this, and give a parameter or patch the makefile to not do it. (Possibly oversimplfying a bit too much here, but this is the general idea.) -- 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: Error creating the package RPM: make:*** No rule to make target 'install'.
What is meant by 'strip the binary file'? ___ 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 33 System-Wide Change proposal: systemd-resolved
DNS over TLS is offered already by package called stubby. But DNS over TLS does not bring you more privacy usually. It only allows moving (some) queries away from your ISP to somewhere else, but always someone can read them. On 4/14/20 9:33 PM, Michael Cronenworth wrote: > On 4/14/20 2:23 PM, Ben Cotton wrote: >> === DNS over TLS === >> >> systemd-resolved supports DNS over TLS (different from DNS over >> HTTPS). Although this feature will not initially be enabled by >> default, using systemd-resolved will enable us to turn on DNS over TLS >> in a future Fedora release, providing improved security if the user's >> DNS server supports DNS over TLS. > > Why wait? > > This is something I've been interested in and was interested in > implementing in Fedora. -- 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
On to, 01 loka 2020, Michael Catanzaro wrote: On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz wrote: I think, he meant the systemd-resolved fiallback to Cloudflare and Google. Is that in the fedora build? If so, i suggest to patch it out. That will fix the issue for me in perspective of the GDPR. Unless you explain this *very* clearly, I'm going to ignore it, because it seems farfetched. Fedora is not operating its own DNS server or collecting any sort of DNS-related data from you. We are not going to patch out fallback to Cloudflare or Google because it is a non-issue. Fallback only happens when you have zero other DNS servers configured. When was the last time you connected to a network and there's no DHCP, no nothing? The number of users without some other working DNS is probably under 0.1%. Even then, I think you also have to disable NetworkManager for systemd-resolved to ever use its fallback DNS, because NetworkManager will configure a ~. DNS domain, causing systemd-resolved to never use its global DNS settings. (I think. That's my reading of the manpage. Testing welcome from anyone who wants to confirm that.) We use the drop-in snippet configuration file in /etc/systemd/resolved.conf.d/zzz-ipa.conf to configure this behavior on IPA servers which deploy integrated DNS server. It works, so there is a confirmation. So (if I'm right) we are talking about the exceeding rare combination of (a) no DNS set by DHCP, and also (b) user manually disabled NetworkManager. If you're really going to do (b) you will probably also disable systemd-resolved, right? Or make the one-line config file change to remove the fallback DNS? Or just manually set some DNS server? Seriously, this is a silly thing to worry about. You can also drop a configuration snippet in /etc/systemd/resolved.conf.d/ to contain FallbackDNS= This will disable global DNS servers for any case. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
Zbigniew Jędrzejewski-Szmek writes: > On Thu, Oct 01, 2020 at 01:25:13PM +0200, Ondřej Lysoněk wrote: >> Fabio Valentini writes: >> >> > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: >> >> >> >> Fabio Valentini writes: >> >> >> >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> >> >> done now in the side tag. I've tried to merge the side tag by creating >> >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> >> >> does not have commit access rights to ...'. So I guess I'll need proven >> >> >> packager help again. >> >> >> >> >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> >> >> >> >> Thanks! >> >> > >> >> > Done! >> >> > >> >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update >> >> > libevent to version 2.1.12. This update includes a rebuild of >> >> > dependent packages due to an soname bump." >> >> > >> >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 >> >> >> >> Thanks, Fabio. >> >> >> >> I just noticed that it says in the update that it cannot be pushed: >> >> "This update cannot be pushed to stable. These builds >> >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 >> >> tag." >> >> >> >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 >> >> after it has been rebuilt in the libevent side tag. >> >> >> >> Not sure what we should do about it. Should we perhaps pull in the new >> >> protobuf into the libevent side tag and rebuild community-mysql again? >> > >> > Ugh. Has the new protobuf been merged into rawhide yet, or is it still >> > in its own side tag? >> >> It has been merged as far as I can tell. >> >> > If it's already merged to rawhide, you can just submit another rebuild >> > of community-mysql for your own side tag, and I can hopefully refresh >> > the bodhi update. >> >> Oh, right. The new protobuf will appear in my side tag by inheritance, >> correct? Great. >> >> community-mysql owners, please rebuild your package once more in the >> side tag: >> >> fedpkg build --target=f34-build-side-30069 > > It's building. I see that the update is stable now. Thank you all. Ondrej ___ 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 10/1/20 8:20 AM, Peter Robinson 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 > > IoT is *NOT* side stepping the normal release engineering process, > we're using exactly the same process, it just runs independently, just > cloud cloud and container images do nightlies post release. Fedora CoreOS does differ here. We use a build pipeline that runs inside of Jenkins on top of OpenShift. All it's doing in the background is running coreos-assembler, which anyone can easily do on their laptop. One of the guiding principles when we first started was we wanted it to be dead simple for anyone to develop and build FCOS locally so we pursued this path. https://github.com/coreos/coreos-assembler > >> 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. > > Fedora IoT uses the same repositories, we don't have seprate, we do > have an overrides repo so we can get fixes quicker. Same for Fedora CoreOS. We use the exact same RPMs built by release engineering and we pull from the same repositories to seed our pipelines but we do have a different cadence for releases (i.e. bake time) and the flexibility to pin or fast-track packages based on needs. > > Matthew has expressed interest in *any* spin to be able to release > whenever they are ready to enable them to release on a schedule that > suits them, IoT is being uses as the proving ground for that. It > doesn't mean we can pull in whatever we want and have different > repositories. Please get your facts correct! > >> 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. ___ 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 10/1/20 12:00 AM, Joe Doss wrote: > 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 You can `rpm-ostree override remove` without making upgrades less reliable, assuming you don't remove a core component. The less reliable part comes when you package layer a new package on top that wasn't in the base. We're fixing that issue very soon 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz wrote: I think, he meant the systemd-resolved fiallback to Cloudflare and Google. Is that in the fedora build? If so, i suggest to patch it out. That will fix the issue for me in perspective of the GDPR. Unless you explain this *very* clearly, I'm going to ignore it, because it seems farfetched. Fedora is not operating its own DNS server or collecting any sort of DNS-related data from you. We are not going to patch out fallback to Cloudflare or Google because it is a non-issue. Fallback only happens when you have zero other DNS servers configured. When was the last time you connected to a network and there's no DHCP, no nothing? The number of users without some other working DNS is probably under 0.1%. Even then, I think you also have to disable NetworkManager for systemd-resolved to ever use its fallback DNS, because NetworkManager will configure a ~. DNS domain, causing systemd-resolved to never use its global DNS settings. (I think. That's my reading of the manpage. Testing welcome from anyone who wants to confirm that.) So (if I'm right) we are talking about the exceeding rare combination of (a) no DNS set by DHCP, and also (b) user manually disabled NetworkManager. If you're really going to do (b) you will probably also disable systemd-resolved, right? Or make the one-line config file change to remove the fallback DNS? Or just manually set some DNS server? Seriously, this is a silly thing to worry about. Finally, in the extremely unlikely event you do somehow wind up with Cloudflare and Google DNS, then you should *celebrate*, because they have extremely strong privacy policies for their DNS. Unless you think they are just lying about their data collection practices -- which they are not -- you have nothing to worry about from their DNS [1][2]. In contrast, your ISP is probably selling your DNS queries to advertisers. If you disagree, doesn't matter, because you're probably never going to see this fallback. Michael [1] https://developers.google.com/speed/public-dns/privacy [2] https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/ ___ 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: Planned Outage - pagure.io - 2020-10-01 08:00 UTC
On Thu, Oct 1, 2020 at 5:28 AM Miro Hrončok wrote: > > On 30. 09. 20 9:38, Pierre-Yves Chibon wrote: > > We are moving the service to a new server running RHEL8 and python3. > > I don't understand why you do this. It worked just fine on Python 2! > Thanks for that, Miro. I just did a spit-take when I read this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Planned Outage - pagure.io - 2020-10-01 08:00 UTC
On Thu, Oct 01, 2020 at 11:27:08AM +0200, Miro Hrončok wrote: > On 30. 09. 20 9:38, Pierre-Yves Chibon wrote: > > We are moving the service to a new server running RHEL8 and python3. > > I don't understand why you do this. It worked just fine on Python 2! It did and now it works fine on python 3 ;-) 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Am 30.09.20 um 17:13 schrieb Michael Catanzaro: > > 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. I think, he meant the systemd-resolved fiallback to Cloudflare and Google. Is that in the fedora build? If so, i suggest to patch it out. That will fix the issue for me in perspective of the GDPR. 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: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 05th October
Hello everyone, Few of the links seems to have been truncated in the previous email, here's the announcement again in all its glory :) Please join us at the next Open NeuroFedora team meeting next week on *Monday 05th October at 1300UTC* in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. https://webchat.freenode.net/?channels=#fedora-neuro The channel is bridged to Telegram, so you can also join us there on the @NeuroFedora group: https://t.me/NeuroFedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 next Mon' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting=20201005T13=%3A=1 The meeting will be chaired by @purusharths. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/fedora-neuro/2020-09-21/neurofedora.2020-09-21-13.06.log.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Open bugs check: https://tinyurl.com/neurofedora-bugs - CompNeuro lab compose a status check for F33/F34. - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks & Regards, Purusharth S (He / Him / His) Time zone: Asia/Kolkata On Thu, 1 Oct 2020 at 18:09, Purusharth Saxena wrote: > Hello everyone, > > Please join us at the next Open NeuroFedora team meeting next week on > *Monday 05th October at 1300UTC* in #fedora-neuro on IRC (Freenode). The > meeting is a public meeting, and open for everyone to attend. > > https://webchat.freenode.net/?channels=#fedora-neuro > > The channel is bridged to Telegram, so you can also join us there on the > @NeuroFedora group: > https://t.me/NeuroFedora > > You can convert the meeting time to your local time using this command > in a terminal: > $ date --date='TZ="UTC" 1300 next Mon' > > or you can use this link: > https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Mee. > .. > > The meeting will be chaired by @purusharths. The agenda for the meeting > is: > > - New introductions and roll call. > - Tasks from last week's meeting: > https://meetbot.fedoraproject.org/fedora-neuro/2020-09-21/neurofedora.202. > .. > - Open Pagure tickets: > https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+... > - Open bugs check: https://tinyurl.com/neurofedora-bugs > - CompNeuro lab compose a status check for F33/F34. > - Neuroscience query of the week. > - Next meeting day, and chair. > - Open floor. > > We hope to see you there! > > You can learn more about NeuroFedora here: > https://neuro.fedoraproject.org > > -- > Thanks & Regards, > Purusharth S (He / Him / His) > Time zone: Asia/Kolkata > ___ 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 Thu, Oct 1, 2020 at 9:06 AM Peter Robinson wrote: > > On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa wrote: > > > > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > > > > > On Wed, Sep 30, 2020 at 9:27 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. > > > > > > > > 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. > > > > > > So you're saying that if this doesn't work for IoT and actively causes > > > deployment problems, potentially across millions of devices, we can't > > > turn it off, change the option and have to basically suck it up and > > > deal with all the problems? Well that makes Fedora completely > > > unappealing and I feel against the project of people being able to > > > choose. It will make people go elsewhere and frankly so will I! > > > > If there are problems with our configuration for your use-case, the > > idea is to actually report the issue and/or fix them. It's not like we > > don't have systemd engineers in Fedora. If there is some fatal flaw, > > then I would *love* to know, but so far, there doesn't seem to be one. > > > > And throwing around "millons of devices" as a reason for me to care > > about IoT more than anything else is not a good way for me to care > > more about you. You can't prove it to me, and it's easy to prove more > > devices *not* running it than running it. > > It's not a way "to care about IoT more than anything else" it's used > as an example to allow Spins/Editions to make the decisions that are > the best for the users even if it's different for the whole. There are > not millions of devices running Fedora IoT *now*, I never said that, > but there are companies looking at doing so. I'm not asking for anyone > to care more about IoT than anything else, I'm purely asking that the > IoT SIG can make their own decisions, which I believe we're actively > allowed to do, rather than having something rammed down our collective > throat if it doesn't work for us. > > > To be blunt, I expect IoT environments to be even worse off in terms > > of taking advantage of DNS security features, because they often rely > > on mobile networks (which don't have any DNS security features) and > > tunnels over those networks (which usually can't have DNS security > > features) to communicate. In that case, what we have here would > > improve that situation for you. > > A lot of those devices use VPN to
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa wrote: > > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > > > On Wed, Sep 30, 2020 at 9:27 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. > > > > > > 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. > > > > So you're saying that if this doesn't work for IoT and actively causes > > deployment problems, potentially across millions of devices, we can't > > turn it off, change the option and have to basically suck it up and > > deal with all the problems? Well that makes Fedora completely > > unappealing and I feel against the project of people being able to > > choose. It will make people go elsewhere and frankly so will I! > > If there are problems with our configuration for your use-case, the > idea is to actually report the issue and/or fix them. It's not like we > don't have systemd engineers in Fedora. If there is some fatal flaw, > then I would *love* to know, but so far, there doesn't seem to be one. > > And throwing around "millons of devices" as a reason for me to care > about IoT more than anything else is not a good way for me to care > more about you. You can't prove it to me, and it's easy to prove more > devices *not* running it than running it. It's not a way "to care about IoT more than anything else" it's used as an example to allow Spins/Editions to make the decisions that are the best for the users even if it's different for the whole. There are not millions of devices running Fedora IoT *now*, I never said that, but there are companies looking at doing so. I'm not asking for anyone to care more about IoT than anything else, I'm purely asking that the IoT SIG can make their own decisions, which I believe we're actively allowed to do, rather than having something rammed down our collective throat if it doesn't work for us. > To be blunt, I expect IoT environments to be even worse off in terms > of taking advantage of DNS security features, because they often rely > on mobile networks (which don't have any DNS security features) and > tunnels over those networks (which usually can't have DNS security > features) to communicate. In that case, what we have here would > improve that situation for you. A lot of those devices use VPN to communicate with some things, such as internal systems, messaging endpoints etc, and the direct internet for things like updates to make use of CDNs and other such technologies to push large data updates as close to the devices as possible, AFAICT from the thread in some/a lot, that use case alone is
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > On Wed, Sep 30, 2020 at 9:27 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. > > > > 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. > > So you're saying that if this doesn't work for IoT and actively causes > deployment problems, potentially across millions of devices, we can't > turn it off, change the option and have to basically suck it up and > deal with all the problems? Well that makes Fedora completely > unappealing and I feel against the project of people being able to > choose. It will make people go elsewhere and frankly so will I! If there are problems with our configuration for your use-case, the idea is to actually report the issue and/or fix them. It's not like we don't have systemd engineers in Fedora. If there is some fatal flaw, then I would *love* to know, but so far, there doesn't seem to be one. And throwing around "millons of devices" as a reason for me to care about IoT more than anything else is not a good way for me to care more about you. You can't prove it to me, and it's easy to prove more devices *not* running it than running it. To be blunt, I expect IoT environments to be even worse off in terms of taking advantage of DNS security features, because they often rely on mobile networks (which don't have any DNS security features) and tunnels over those networks (which usually can't have DNS security features) to communicate. In that case, what we have here would improve that situation for you. -- 真実はいつも一つ！/ 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)
> > Is it possible to boot from the stick and then perform a grub-install > with an old grub? > This attempt failed too: # grub2-install /dev/sda grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert nicht. Bitte geben Sie --target oder --directory an. and that file seems not to be part of any package. There is only one for "i386-pc". 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: Error creating the package RPM: make:*** No rule to make target 'install'.
Please tell me how to do this? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 05th October
Hello everyone, Please join us at the next Open NeuroFedora team meeting next week on *Monday 05th October at 1300UTC* in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. https://webchat.freenode.net/?channels=#fedora-neuro The channel is bridged to Telegram, so you can also join us there on the @NeuroFedora group: https://t.me/NeuroFedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 next Mon' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Mee... The meeting will be chaired by @purusharths. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/fedora-neuro/2020-09-21/neurofedora.202... - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+... - Open bugs check: https://tinyurl.com/neurofedora-bugs - CompNeuro lab compose a status check for F33/F34. - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks & Regards, Purusharth S (He / Him / His) Time zone: Asia/Kolkata ___ 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 Thu, Oct 01, 2020 at 12:55:40PM +0200, Petr Pisar wrote: > On Wed, Sep 30, 2020 at 04:26:39PM +, Zbigniew Jędrzejewski-Szmek wrote: > > In addition, two more new subpackages are created: > > systemd-standalone-sysusers > > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > > systemd-tmpfiles binaries. > > root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd > |grep systemd-sysusers > /usr/bin/systemd-sysusers > /usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service > /usr/lib/systemd/system/systemd-sysusers.service > /usr/share/man/man8/systemd-sysusers.8.gz > /usr/share/man/man8/systemd-sysusers.service.8.gz > root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list > systemd-standalone-sysusers |grep systemd-sysusers > /usr/bin/systemd-sysusers > > I think systemd-standalone-sysusers package is missing the manual pages. I think that's ok. The -standalone- packages are supposed to be minimal. Also, people would use them in minimal images that are also missing man. 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)
Am 01.10.20 um 07:22 schrieb Chris Murphy: > 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. It's M$ firmware, so be sure it has bugs. ( could tell you about one very nasty ) Until F32 i had no problem booting any livedisk, so something changed. > 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 > > I replace anything besides boot and grub.cfg , and it's the same .. inserted before powerup => not working, inserted while in bios => working and this does not change if altered or unaltered. AFAIk the MBR ( or alike ) has a portion of code in it. sure it's not there and the bootloader needs to be updated to have effect? Is it possible to boot from the stick and then perform a grub-install with an old grub? 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 9:27 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. > > 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. So you're saying that if this doesn't work for IoT and actively causes deployment problems, potentially across millions of devices, we can't turn it off, change the option and have to basically suck it up and deal with all the problems? Well that makes Fedora completely unappealing and I feel against the project of people being able to choose. It will make people go elsewhere and frankly so will I! ___ 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+
> > > > > 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 IoT is *NOT* side stepping the normal release engineering process, we're using exactly the same process, it just runs independently, just cloud cloud and container images do nightlies post release. > 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. Fedora IoT uses the same repositories, we don't have seprate, we do have an overrides repo so we can get fixes quicker. Matthew has expressed interest in *any* spin to be able to release whenever they are ready to enable them to release on a schedule that suits them, IoT is being uses as the proving ground for that. It doesn't mean we can pull in whatever we want and have different repositories. Please get your facts correct! > 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 ___ 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. > > > > 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. Both Editions and Spins are allowed to deviate from defaults, like Server uses XFS and Desktops now use btrfs for filesystems. ATM I intended to leave it as it is but I want the option to be able to exclude it, and if it's not in use and we don't ship it means if there's 1000s of systems we don't need to patch if there's a CVE in those components. I think the ability to shrink and not include things not in use is important, that is the whole point of the minimisation objective after all. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Error creating the package RPM: make:*** No rule to make target 'install'.
Hi! On Thu, Oct 1, 2020 at 1:15 PM Helg Green via devel < devel@lists.fedoraproject.org> wrote: > The program is installed in the folder > /opt/simplest_studio/bin/simplest_studio > > A strange error also appeared: > . > . > . > RPM build errors: > Empty %files file > /home/helg/rpmbuild/BUILD/simplest-studio-1.1/debugsourcefiles.list > I think that's because you strip the binary file. Avoid that and the issue will go away. BR, Andrea ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
On Thu, Oct 01, 2020 at 01:25:13PM +0200, Ondřej Lysoněk wrote: > Fabio Valentini writes: > > > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: > >> > >> Fabio Valentini writes: > >> > >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be > >> >> done now in the side tag. I've tried to merge the side tag by creating > >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek > >> >> does not have commit access rights to ...'. So I guess I'll need proven > >> >> packager help again. > >> >> > >> >> Can someone please merge the f34-build-side-30069 side tag? > >> >> > >> >> Thanks! > >> > > >> > Done! > >> > > >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > >> > libevent to version 2.1.12. This update includes a rebuild of > >> > dependent packages due to an soname bump." > >> > > >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 > >> > >> Thanks, Fabio. > >> > >> I just noticed that it says in the update that it cannot be pushed: > >> "This update cannot be pushed to stable. These builds > >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 > >> tag." > >> > >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 > >> after it has been rebuilt in the libevent side tag. > >> > >> Not sure what we should do about it. Should we perhaps pull in the new > >> protobuf into the libevent side tag and rebuild community-mysql again? > > > > Ugh. Has the new protobuf been merged into rawhide yet, or is it still > > in its own side tag? > > It has been merged as far as I can tell. > > > If it's already merged to rawhide, you can just submit another rebuild > > of community-mysql for your own side tag, and I can hopefully refresh > > the bodhi update. > > Oh, right. The new protobuf will appear in my side tag by inheritance, > correct? Great. > > community-mysql owners, please rebuild your package once more in the > side tag: > > fedpkg build --target=f34-build-side-30069 It's building. 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Thu, Oct 1, 2020 at 6:21 AM Ondrej Dubaj wrote: > My apologies, of course we are aiming to package the unversioned symbolic > links to the "real" libraries to *-devel package. I thought it was clear > from the beginning. > Ahh... I didn't get that from the initial message, I haven't looked into the package and assumed the soversion didn't exist, because why else would the .so files be in the main package to begin with. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Rebuild of dependent packages with the new unixODBC seems to be quite optimistic. The are only few failures and none of them seems to be caused by some missing libraries. We can now discuss only about the runtime problems, as it seems, almost no buildtime problems occurred https://copr.fedorainfracloud.org/coprs/odubaj/unixODBC/builds/ On Thu, Oct 1, 2020 at 1:20 PM Ondrej Dubaj wrote: > My apologies, of course we are aiming to package the unversioned symbolic > links to the "real" libraries to *-devel package. I thought it was clear > from the beginning. > > Why should we hack the soversion ? There are no changes to the soname or > ABI compatibility coming, we want to just package the unversioned symbolic > links to the "real" libraries to *-devel package. > > On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > >> Adding my $0.02 here... >> >> Since they are real libraries, they don't belong in a -devel package, the >> intent is to package the unversioned symbolic links to the "real" >> libraries. A end user package should never require a -devel package to run. >> >> One option would be to hack in a soversion to the build process. I did >> this for many years with openCOLLADA, and used either >> abi-compliance-checker or abipkgdiff to determine when a soversion bump was >> required. >> >> Thanks, >> Richard >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
Fabio Valentini writes: > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: >> >> Fabio Valentini writes: >> >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: >> >> >> >> Hi, >> >> >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> >> done now in the side tag. I've tried to merge the side tag by creating >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> >> does not have commit access rights to ...'. So I guess I'll need proven >> >> packager help again. >> >> >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> >> >> Thanks! >> > >> > Done! >> > >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update >> > libevent to version 2.1.12. This update includes a rebuild of >> > dependent packages due to an soname bump." >> > >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 >> >> Thanks, Fabio. >> >> I just noticed that it says in the update that it cannot be pushed: >> "This update cannot be pushed to stable. These builds >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 >> tag." >> >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 >> after it has been rebuilt in the libevent side tag. >> >> Not sure what we should do about it. Should we perhaps pull in the new >> protobuf into the libevent side tag and rebuild community-mysql again? > > Ugh. Has the new protobuf been merged into rawhide yet, or is it still > in its own side tag? It has been merged as far as I can tell. > If it's already merged to rawhide, you can just submit another rebuild > of community-mysql for your own side tag, and I can hopefully refresh > the bodhi update. Oh, right. The new protobuf will appear in my side tag by inheritance, correct? Great. community-mysql owners, please rebuild your package once more in the side tag: fedpkg build --target=f34-build-side-30069 Thanks! Ondrej ___ 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
My apologies, of course we are aiming to package the unversioned symbolic links to the "real" libraries to *-devel package. I thought it was clear from the beginning. Why should we hack the soversion ? There are no changes to the soname or ABI compatibility coming, we want to just package the unversioned symbolic links to the "real" libraries to *-devel package. On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > Adding my $0.02 here... > > Since they are real libraries, they don't belong in a -devel package, the > intent is to package the unversioned symbolic links to the "real" > libraries. A end user package should never require a -devel package to run. > > One option would be to hack in a soversion to the build process. I did > this for many years with openCOLLADA, and used either > abi-compliance-checker or abipkgdiff to determine when a soversion bump was > required. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Error creating the package RPM: make:*** No rule to make target 'install'.
The program is installed in the folder /opt/simplest_studio/bin/simplest_studio A strange error also appeared: . . . RPM build errors: Empty %files file /home/helg/rpmbuild/BUILD/simplest-studio-1.1/debugsourcefiles.list ___ 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 33 System-Wide Change proposal: systemd-resolved
On Tue, Sep 01, 2020 at 02:28:57PM +0200, Florian Weimer wrote: > There are also concerns that the DNS infrastructure cannot > handle the load unless there is one level of shared caching betweeen the > endpoints and the authoritative servers. Those DNS caches certainly > suppress some of the problematic client behavior (but they also add > their own share of broken queries, of course). Well, all that distributed caching hierarchy is undermined by some auxiliary non-DNS Google project anyway: https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/ ___ 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Adding my $0.02 here... Since they are real libraries, they don't belong in a -devel package, the intent is to package the unversioned symbolic links to the "real" libraries. A end user package should never require a -devel package to run. One option would be to hack in a soversion to the build process. I did this for many years with openCOLLADA, and used either abi-compliance-checker or abipkgdiff to determine when a soversion bump was required. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Error creating the package RPM: make:*** No rule to make target 'install'.
On Thu, Oct 01, 2020 10:40:10 -, Helg Green via devel wrote:
> The error occurs at the stage
>
> %install
> mkdir -p %{buildroot}
> make install INSTALL_ROOT=%{buildroot}
Yes, as Kamil said: since your Makefile is in the "app" directory, you
need to enter the directory again to run the make command.
You can/should perhaps use:
%build
%make_build -C app
%install
%make_install -C app
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Dne 01. 10. 20 v 0:10 Michael Catanzaro napsal(a): > 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' I would appreciate if somebody took care about authselect tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1878752 The file you have referenced apparently lives in vacuum. You refer to it, but nobody owns it. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 10:26 PM, Neal Gompa wrote: > > 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. I think one more subpackage can won't break anything. Metadata for it is quite small. Is extra metadata and upgrade path more than one time only? Can you specify what else would be required, but Recommends: systemd-networkd in NetworkManager package? As long as disabled resolved is considered supported variant, it should not really differ. Can you be more specific about requirements? > > 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. All non-OSTree Fedora variants can uninstall NetworkManager just fine, they use *NetworkManager by default*. We would like systemd-resolved uninstallable the same way. Because it is not the best available resolver and has long standing bugs, some of them not properly addressed. Especially to ensure systemd-resolved would not become the only one supported variant, just a default one. Is dnsmasq or unbound support considered deprecated? NetworkManager != systemd-resolved. I think NetworkManager should just Recommend: systemd-resolved. As long as [main] dns=dnsmasq or dns=unbound is still supported by NetworkManager, I think alternatives must be uninstallable. Both support split-DNS, just have missing NetworkManager configuration layer. I am dnsmasq maintainer and unbound comaintainer and I am willing to help with its implementation. I just need to know way to push information from NM to them. > > 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. Things are already hard with name resolution. They are not going better with systemd upstream ignoring research of DNS specialists and instead pushing its own 'correct' ideas. And that precisely what we demand. If disabling systemd-resolved should work and be tested, it should be the same with resolved not installed. We just fear waiving disabled resolved as unsupported a bit later. -- 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 Wed, Sep 30, 2020 at 04:26:39PM +, Zbigniew Jędrzejewski-Szmek wrote: > In addition, two more new subpackages are created: systemd-standalone-sysusers > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > systemd-tmpfiles binaries. root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd |grep systemd-sysusers /usr/bin/systemd-sysusers /usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service /usr/lib/systemd/system/systemd-sysusers.service /usr/share/man/man8/systemd-sysusers.8.gz /usr/share/man/man8/systemd-sysusers.service.8.gz root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd-standalone-sysusers |grep systemd-sysusers /usr/bin/systemd-sysusers I think systemd-standalone-sysusers package is missing the manual pages. -- Petr 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: Error creating the package RPM: make:*** No rule to make target 'install'.
Indeed, I added the cd app and the package build continued. ...But a new error has already appeared: . . . + exit 0 RPM build errors: File not found: /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64/usr/bin/simplest-studio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Error creating the package RPM: make:*** No rule to make target 'install'.
The error occurs at the stage
%install
mkdir -p %{buildroot}
make install INSTALL_ROOT=%{buildroot}
___
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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Dne 01. 10. 20 v 12:28 Dan Horák napsal(a): > On Thu, 1 Oct 2020 12:06:51 +0200 > Ondrej Dubaj wrote: > >> I see no other discussion here and related arguments not to make this >> update. I know it might break other packages, but it needs to be done >> to be according to the guidelines. I do not see it as a big problem to > for the record - compliance with the guidelines isn't the only criteria > for doing packaging changes, there can be reasonable exceptions agreed > or the guidelines can be modified. > I think this is a call to revisit this package and identify if there are reasonable exceptions. The arguments for the way the package is currently done, which I were able to collect, were always vague. In once case the reason was bug and it was corrected. I have yet to see any real evidence for the exception provided here or elsewhere. The status quo itself is not the reason. Vít > Dan > >> rebuild the dependend packages with additional dependency on >> unixODBC-devel package, if it will be needed. Or if there will be some >> runtime problem, it can be easily fixed by editing the config file and >> dlopening the versioned libraries. If there will be a big need not to >> edit the config files, there is nothing simpler than installing >> unixODBC-devel package and everything works again. >> >> Am I missing some other cases ? >> >> Thanks for your ideas. >> >> >> On Mon, Sep 21, 2020 at 8:13 AM Ondrej Dubaj wrote: >> >>> any other suggestions here ? I will be glad, if maintainers of dependent >>> packages will share their opinions. If we fix this issue and it breaks >>> dependent packages, simple workaround via symlink is available until the >>> problems will be solved, so I see no reason for ignoring this problem. >>> >>> On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: >>> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): > * Tom Hughes via devel: > >> On 11/09/2020 07:13, Ondrej Dubaj wrote: >> >>> There seemed to be no big reason for moving the libraries to the >>> main package in the past, so I consider f34 as a good candidate for >>> such a change. It would be great, if you share your opinions and >>> concerns for this topic. >> Tom Lane has explained the reason on the ticket, it's because the >> library is often dlopened by a client application instead of being >> linked to. "often" is relative. I see this mentioned for following packages: java-1.5.0-ibm-jdbc java-1.6.0-sun-jdbc java-1.5.0-bea-jdbc Which probably shares common history and at least one of them admitted the mistake [1] and started to use the versioned .so file. So are there any other cases? > Yes, that is sufficient reason not to do the move. Third-party > applications will break. And they should be fixed. I understand there is never the right time to fix this, but if not now, then when? > Some people also really dislike installing > *-devel packages in production, so there might not be an easy fix for > them. > > The library probably should not have a versioned soname in the first > place, with backwards compatibility achieved by different means. But > that does not matter now. > > Thanks, > Florian Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24 ___ 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 ___ 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Thu, 1 Oct 2020 12:06:51 +0200 Ondrej Dubaj wrote: > I see no other discussion here and related arguments not to make this > update. I know it might break other packages, but it needs to be done > to be according to the guidelines. I do not see it as a big problem to for the record - compliance with the guidelines isn't the only criteria for doing packaging changes, there can be reasonable exceptions agreed or the guidelines can be modified. Dan > rebuild the dependend packages with additional dependency on > unixODBC-devel package, if it will be needed. Or if there will be some > runtime problem, it can be easily fixed by editing the config file and > dlopening the versioned libraries. If there will be a big need not to > edit the config files, there is nothing simpler than installing > unixODBC-devel package and everything works again. > > Am I missing some other cases ? > > Thanks for your ideas. > > > On Mon, Sep 21, 2020 at 8:13 AM Ondrej Dubaj wrote: > > > any other suggestions here ? I will be glad, if maintainers of dependent > > packages will share their opinions. If we fix this issue and it breaks > > dependent packages, simple workaround via symlink is available until the > > problems will be solved, so I see no reason for ignoring this problem. > > > > On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: > > > >> > >> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): > >> > * Tom Hughes via devel: > >> > > >> >> On 11/09/2020 07:13, Ondrej Dubaj wrote: > >> >> > >> >>> There seemed to be no big reason for moving the libraries to the > >> >>> main package in the past, so I consider f34 as a good candidate for > >> >>> such a change. It would be great, if you share your opinions and > >> >>> concerns for this topic. > >> >> Tom Lane has explained the reason on the ticket, it's because the > >> >> library is often dlopened by a client application instead of being > >> >> linked to. > >> > >> > >> "often" is relative. I see this mentioned for following packages: > >> > >> > >> java-1.5.0-ibm-jdbc > >> > >> java-1.6.0-sun-jdbc > >> > >> java-1.5.0-bea-jdbc > >> > >> > >> Which probably shares common history and at least one of them admitted > >> the mistake [1] and started to use the versioned .so file. > >> > >> So are there any other cases? > >> > >> > >> > Yes, that is sufficient reason not to do the move. Third-party > >> > applications will break. > >> > >> > >> And they should be fixed. I understand there is never the right time to > >> fix this, but if not now, then when? > >> > >> > >> > Some people also really dislike installing > >> > *-devel packages in production, so there might not be an easy fix for > >> > them. > >> > > >> > The library probably should not have a versioned soname in the first > >> > place, with backwards compatibility achieved by different means. But > >> > that does not matter now. > >> > > >> > Thanks, > >> > Florian > >> > >> > >> Vít > >> > >> > >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24 > >> > >> ___ > >> 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: Error creating the package RPM: make:*** No rule to make target 'install'.
On Thursday, October 1, 2020 11:50:02 AM CEST Helg Green via devel wrote:
> %build
> cd app
> make %{?_smp_mflags}
>
> %install
I guess that `cd app` is missing here?
Kamil
> mkdir -p %{buildroot}
> make install INSTALL_ROOT=%{buildroot}
>
> %post
> # Setup icons
> touch -c /usr/share/icons/hicolor
> if command -v gtk-update-icon-cache >/dev/null 2>&1; then
> gtk-update-icon-cache -tq /usr/share/icons/hicolor 2>/dev/null ||:
> fi
___
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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
I see no other discussion here and related arguments not to make this update. I know it might break other packages, but it needs to be done to be according to the guidelines. I do not see it as a big problem to rebuild the dependend packages with additional dependency on unixODBC-devel package, if it will be needed. Or if there will be some runtime problem, it can be easily fixed by editing the config file and dlopening the versioned libraries. If there will be a big need not to edit the config files, there is nothing simpler than installing unixODBC-devel package and everything works again. Am I missing some other cases ? Thanks for your ideas. On Mon, Sep 21, 2020 at 8:13 AM Ondrej Dubaj wrote: > any other suggestions here ? I will be glad, if maintainers of dependent > packages will share their opinions. If we fix this issue and it breaks > dependent packages, simple workaround via symlink is available until the > problems will be solved, so I see no reason for ignoring this problem. > > On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: > >> >> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): >> > * Tom Hughes via devel: >> > >> >> On 11/09/2020 07:13, Ondrej Dubaj wrote: >> >> >> >>> There seemed to be no big reason for moving the libraries to the >> >>> main package in the past, so I consider f34 as a good candidate for >> >>> such a change. It would be great, if you share your opinions and >> >>> concerns for this topic. >> >> Tom Lane has explained the reason on the ticket, it's because the >> >> library is often dlopened by a client application instead of being >> >> linked to. >> >> >> "often" is relative. I see this mentioned for following packages: >> >> >> java-1.5.0-ibm-jdbc >> >> java-1.6.0-sun-jdbc >> >> java-1.5.0-bea-jdbc >> >> >> Which probably shares common history and at least one of them admitted >> the mistake [1] and started to use the versioned .so file. >> >> So are there any other cases? >> >> >> > Yes, that is sufficient reason not to do the move. Third-party >> > applications will break. >> >> >> And they should be fixed. I understand there is never the right time to >> fix this, but if not now, then when? >> >> >> > Some people also really dislike installing >> > *-devel packages in production, so there might not be an easy fix for >> > them. >> > >> > The library probably should not have a versioned soname in the first >> > place, with backwards compatibility achieved by different means. But >> > that does not matter now. >> > >> > Thanks, >> > Florian >> >> >> Vít >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24 >> >> ___ >> 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
Error creating the package RPM: make:*** No rule to make target 'install'.
Hi!
I try to create an RPM package and get an error:
[helg@localhost SPECS]$ rpmbuild -ba simplest_studio.spec
.
.
.
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.MRg9OD
+ umask 022
+ cd /home/helg/rpmbuild/BUILD
+ '[' /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64 '!=' / ']'
+ rm -rf /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64
++ dirname /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64
+ mkdir -p /home/helg/rpmbuild/BUILDROOT
+ mkdir /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64
+ cd simplest-studio-1.1
+ mkdir -p /home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64
+ make install
INSTALL_ROOT=/home/helg/rpmbuild/BUILDROOT/simplest-studio-1.1-1.fc32.x86_64
make: *** No rule to make target 'install'. Stop.
error: Bad exit status from /var/tmp/rpm-tmp.MRg9OD (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.MRg9OD (%install)
Here is my source data:
BUILD/
BUILDROOT/
RPMS/
SOURCES/simplest-studio-1.1.tar.gz (contains Makefile in a folder
'app/Makefile')
SPECS/simplest_studio.spec
SRPMS/
# simplest_studio.spec
Summary:Audio encoder
Name: simplest-studio
Version:1.1
Release:1%{?dist}
License:GPL-3
Group: Applications/Audio
URL:https://github.com/SimplestStudio/%{name}
Source0:%{name}-%{version}.tar.gz
BuildRequires: gcc
Requires: qt5-qtbase-common
Requires: libmediainfo-devel
Requires: ffmpeg>=4.2
BuildArch: noarch
%description
Simplest Studio is an application that allows you to convert audio files.
%prep
# nothing here
%setup -q
# nothing here
%build
cd app
make %{?_smp_mflags}
%install
mkdir -p %{buildroot}
make install INSTALL_ROOT=%{buildroot}
%post
# Setup icons
touch -c /usr/share/icons/hicolor
if command -v gtk-update-icon-cache >/dev/null 2>&1; then
gtk-update-icon-cache -tq /usr/share/icons/hicolor 2>/dev/null ||:
fi
# Setup desktop file
if command -v update-desktop-database >/dev/null 2>&1; then
update-desktop-database -q /usr/share/applications 2>/dev/null ||:
fi
%postun
# nothing here
%clean
rm -rf %{buildroot}
%files
%doc ABOUT LICENSE
/usr/bin/%{name}
%changelog
* Wed Sep 30 2020 Simplest Studio
- Initial package for Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proven packager help needed to merge libevent 2.1.12 side tag
On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: > > Fabio Valentini writes: > > > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: > >> > >> Hi, > >> > >> So all the required rebuilds for the libevent 2.1.12 rebase should be > >> done now in the side tag. I've tried to merge the side tag by creating > >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek > >> does not have commit access rights to ...'. So I guess I'll need proven > >> packager help again. > >> > >> Can someone please merge the f34-build-side-30069 side tag? > >> > >> Thanks! > > > > Done! > > > > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > > libevent to version 2.1.12. This update includes a rebuild of > > dependent packages due to an soname bump." > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 > > Thanks, Fabio. > > I just noticed that it says in the update that it cannot be pushed: > "This update cannot be pushed to stable. These builds > community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 > tag." > > And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 > after it has been rebuilt in the libevent side tag. > > Not sure what we should do about it. Should we perhaps pull in the new > protobuf into the libevent side tag and rebuild community-mysql again? Ugh. Has the new protobuf been merged into rawhide yet, or is it still in its own side tag? If it's already merged to rawhide, you can just submit another rebuild of community-mysql for your own side tag, and I can hopefully refresh the bodhi update. Fabio ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
Fabio Valentini writes: > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: >> >> Hi, >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> done now in the side tag. I've tried to merge the side tag by creating >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> does not have commit access rights to ...'. So I guess I'll need proven >> packager help again. >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> Thanks! > > Done! > > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > libevent to version 2.1.12. This update includes a rebuild of > dependent packages due to an soname bump." > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 Thanks, Fabio. I just noticed that it says in the update that it cannot be pushed: "This update cannot be pushed to stable. These builds community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 tag." And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 after it has been rebuilt in the libevent side tag. Not sure what we should do about it. Should we perhaps pull in the new protobuf into the libevent side tag and rebuild community-mysql again? Ondrej ___ 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 Thu, Oct 01, 2020 at 11:05:18AM +0200, Petr Menšík wrote: > > > On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote: > > 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.) > Why is it important to require resolved in main package? See the extensive replies from Neal Gompa in the other part of the thread. Each split brings a maintenance cost and cognitive overhead for users. So the question is always "why should we split this out", and not "why shouldn't we"? Even for the -networkd it's almost a wash. We split it out to undo a long-standing problem in coreos. Without that preexisting history [1], it wouldn't have been split out. Thankfully we don't have a similar situation with resolved. > It contains > both daemon and lookup tool, couple of bash completion scripts and > manual pages. Reason to split it out was stated already: some people > won't be using it. It is not so small, 650k deserves own package IMHO. It's a judgment call. Apart from the problems mentioned above, since it is a default in F33+ now, after splitting it out we'd need to make sure that it is almost always pulled in. Sorry, no, that's too much fragility to save <1MB. Zbyszek [1] https://github.com/coreos/fedora-coreos-config/pull/574 ___ 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: Planned Outage - pagure.io - 2020-10-01 08:00 UTC
On 30. 09. 20 9:38, Pierre-Yves Chibon wrote: We are moving the service to a new server running RHEL8 and python3. I don't understand why you do this. It worked just fine on Python 2! -- 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
Fedora-Cloud-32-20201001.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200930.0): ID: 682197 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/682197 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote: > 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.) Why is it important to require resolved in main package? It contains both daemon and lookup tool, couple of bash completion scripts and manual pages. Reason to split it out was stated already: some people won't be using it. It is not so small, 650k deserves own package IMHO. I think only nss-resolve has reason to be kept in main package to prevent issues with nsswitch configuring. I think over half megabyte tool, which only says: not running, sorry!, is not useful. > > (*) 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. We don't talk about allowing it installed. We demand possibility to uninstall it. systemd itself should be installed everywhere for a good reason. There is no alternative for it in Fedora. That is not true for systemd-resolved. It must not be hardwired. There exist more alternative resolution paths. It has to be possible to switch between them. Just for that reason, it should be in separate and uninstallable package. To ensure it is not too hardwired into the distribution without a good reason. > > 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. Weird postinstall snippets are good reason to move it into separate subpackage. It makes it clear which part is related to systemd-resolved, which part is related to systemd itself. > > 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. Please make. Are there bugs for it? Can we help? > > Zbyszek > Cheers, Petr -- 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: Proven packager help needed to merge libevent 2.1.12 side tag
On Thu, Oct 1, 2020 at 10:39 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Oct 01, 2020 at 10:32:44AM +0200, Fabio Valentini wrote: > > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: > > > > > > Hi, > > > > > > So all the required rebuilds for the libevent 2.1.12 rebase should be > > > done now in the side tag. I've tried to merge the side tag by creating > > > an update in Bodhi as described in [1], but Bodhi tells me 'olysonek > > > does not have commit access rights to ...'. So I guess I'll need proven > > > packager help again. > > > > > > Can someone please merge the f34-build-side-30069 side tag? > > > > > > Thanks! > > > > Done! > > > > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > > libevent to version 2.1.12. This update includes a rebuild of > > dependent packages due to an soname bump." > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 > > BTW, the intructions say: > Once you have built all the packages in your side-tag, you can create the > bodhi update for this side-tag using either: > - the bodhi web UI, in the new update form use the Use Side Tag button > - the bodhi CLI bodhi updates new --from-tag > > So the second option works. But I don't see any "Use Side Tag button" > under https://bodhi.fedoraproject.org/updates/new. Am I looking in the > wrong place? No, the button works, but only if you created side tags yourself, and it only shows side tags you yourself have created. For side tags created by other users, you need to use the bodhi CLI, I think. Fabio ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
On Thu, Oct 01, 2020 at 10:32:44AM +0200, Fabio Valentini wrote: > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: > > > > Hi, > > > > So all the required rebuilds for the libevent 2.1.12 rebase should be > > done now in the side tag. I've tried to merge the side tag by creating > > an update in Bodhi as described in [1], but Bodhi tells me 'olysonek > > does not have commit access rights to ...'. So I guess I'll need proven > > packager help again. > > > > Can someone please merge the f34-build-side-30069 side tag? > > > > Thanks! > > Done! > > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > libevent to version 2.1.12. This update includes a rebuild of > dependent packages due to an soname bump." > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 BTW, the intructions say: Once you have built all the packages in your side-tag, you can create the bodhi update for this side-tag using either: - the bodhi web UI, in the new update form use the Use Side Tag button - the bodhi CLI bodhi updates new --from-tag So the second option works. But I don't see any "Use Side Tag button" under https://bodhi.fedoraproject.org/updates/new. Am I looking in the wrong place? 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: Proven packager help needed to merge libevent 2.1.12 side tag
On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: > > Hi, > > So all the required rebuilds for the libevent 2.1.12 rebase should be > done now in the side tag. I've tried to merge the side tag by creating > an update in Bodhi as described in [1], but Bodhi tells me 'olysonek > does not have commit access rights to ...'. So I guess I'll need proven > packager help again. > > Can someone please merge the f34-build-side-30069 side tag? > > Thanks! Done! $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update libevent to version 2.1.12. This update includes a rebuild of dependent packages due to an soname bump." https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 Fabio ___ 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
Proven packager help needed to merge libevent 2.1.12 side tag
Hi, So all the required rebuilds for the libevent 2.1.12 rebase should be done now in the side tag. I've tried to merge the side tag by creating an update in Bodhi as described in [1], but Bodhi tells me 'olysonek does not have commit access rights to ...'. So I guess I'll need proven packager help again. Can someone please merge the f34-build-side-30069 side tag? Thanks! [1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/#_how_does_gating_multi_builds_updates_work Ondrej Lysonek ___ 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
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 --- Comment #4 from Fedora Update System --- FEDORA-2020-31b5a0d352 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-31b5a0d352 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 --- Comment #5 from Fedora Update System --- FEDORA-2020-d9daf21032 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d9daf21032 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thu, 2020-10-01 at 15:28 +0800, Harish Pillay wrote: > Same thing applies to mutt. I've filed this bz: > https://bugzilla.redhat.com/show_bug.cgi?id=1883976 Hi, every application which uses library which complies to system crypto policies is "affected". For more information: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 Also see the "Upgrade/compatibility impact" section there. Bye, Milan ___ 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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On Thursday, October 1, 2020 7:50:49 AM CEST Lumír Balhar wrote: > 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). I asked a few days back if the crypto on the mail server could be updated to comply with F33 (internal ticket INC1447620). Pavel > 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
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 --- Comment #3 from Fedora Update System --- FEDORA-2020-65c3e7223d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-65c3e7223d -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-File-Listing-6.07-1.fc ||34 --- Comment #2 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
| 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. Same thing applies to mutt. I've filed this bz: https://bugzilla.redhat.com/show_bug.cgi?id=1883976 Harish 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
[Bug 1883959] perl-File-Listing-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1883959 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1884124] New: perl-Gnome2-Canvas-1.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1884124 Bug ID: 1884124 Summary: perl-Gnome2-Canvas-1.004 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Gnome2-Canvas Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 1.004 Current version/release in rawhide: 1.003-1.fc34 URL: http://search.cpan.org/dist/Gnome2-Canvas/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2926/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
