Outage: Upgrading nagios - 2011-03-24 18:00 UTC
There will be an outage starting at 2011-03-24 18:00 UTC, which will last approximately X hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-03-24 18:00 UTC' Reason for outage: Moving from EL5 nagios to EL6 nagios Affected Services: Nagios Zodbot DHCP for PHX2 application network. Unaffected Services: BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ CVS / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ https://fedorahosted.org/fedora-infrastructure/ticket/2681#preview Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -- Stephen J Smoogen. Fedora Team "Tell me and I'll forget; show me and I may remember; involve me and I'll understand." Mencius “Let us be kind to one another, for most of us are fighting a hard battle.” -- Ian MacLaren signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updating SSL keys on fedorahosted.org
Various SSL keys are aging out so we will be updating them before anyone gets a page. The first server to be updated will be fedorahosted.org. The old certificate came from Equifax, was a 1024 bit key and had the fingerprint: SHA1 Fingerprint=CC:64:67:BE:90:50:79:ED:23:E8:C1:18:02:AB:AC:83:88:FC:6C:D8 The new certificate is issued by GeoTrust, Inc and is a 4096 bit key with the fingerprint: SHA1 Fingerprint=D1:54:82:77:77:F9:11:DF:E0:B1:14:37:B9:36:E2:09:20:B6:54:1D Please report any problems with these certificates to ad...@fedoraproject.org Stephen Smoogen * interim Infrastructure Chief Coffee Officer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updating SSL keys on fedoraproject.org 2011-03-10
Various SSL keys are aging out so we will be updating them before anyone gets a page. We have already updated fedorahosted.org and will now be updating the cert for the main site: fedoraproject.org. The old certificate came from Equifax, was a 1024 bit key and had the fingerprint: SHA1 Fingerprint=E7:6D:26:72:D6:A2:2D:7A:5C:CF:BB:D2:05:B9:8E:7C:49:F5:F8:A8 The new certificate is issued by GeoTrust, Inc and is a 4096 bit key with the fingerprint: SHA1 Fingerprint=F6:D6:28:85:64:B1:11:19:38:2A:82:EF:F8:F0:22:E8:27:4F:A5:CF Please report any problems with these certificates to ad...@fedoraproject.org The change in certs will happen around 2011-03-10 20:00 UTC Stephen Smoogen * Seasonal Infrastructure Chief Koffee Officer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: Serverbeach servers downtime 2011-03-16 03:00 UTC -> 2011-03-16 09:00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There will be an outage starting at 2011-03-16 03:00 UTC, which will last approximately 6 hours. [Outages should be only 10-30 minutes long but the window for the outage is 6 hours thus the large window.] To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-03-16 03:00 UTC' Reason for outage: Affected Services: DNS - ns1.fedoraproject.org, Fedora Hosted - https://fedorahosted.org/ Fedora Talk - http://talk.fedoraproject.org/ Email for fedoraproject.org Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. - -- Smooge [Temporary Interim Chief Cat Wranglger] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iJwEAQECAAYFAk16iskACgkQAsLqwWFAN9vihAQAhJH1+JaVMknFpopSzCFdx33w 9r/tjQDaqBb9k6Vud9fMjZAPjl14+2S6VuZvvwNnz3dVLr6KRCNbDnu04WA8K9Fp 59L+SZwhPSh6wS/S1WVaId946FlpinzsDeElN6JDoTxyo77stmRBqYXwx8xGcldW F1IQOzU3kz2TrXcI3j0= =Ddlu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Tue, 2 Apr 2013, Adam Williamson wrote: Date: Tue, 02 Apr 2013 15:18:55 -0700 From: Adam Williamson Reply-To: Development discussions related to Fedora To: devel@lists.fedoraproject.org Subject: Re: Expanding the list of "Hardened Packages" On 31/03/13 08:11 AM, Richard W.M. Jones wrote: However prelink does reduce the effectiveness of ASLR (a bit). See http://lwn.net/Articles/341440/ and follow-up conversation. Ignoring the silly stuff, it does seem that this is Yet Another Reason Prelink Is Bad, and we seem to keep bumping up against those. It does rather seem like we should consider just killing it, at least by default. At this point I have the feeling that Prelink is a cargo cult which we keep around to appease the Airplane Gods. -- Stephen John Smoogen RHCE: 805299440800213 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later
On Sun, 12 Mar 2023 at 11:43, Fabio Valentini wrote: > On Sat, Mar 11, 2023 at 6:58 PM Michael Catanzaro > wrote: > > > > On Fri, Mar 10 2023 at 04:17:13 PM -0500, Matthew Miller > > wrote: > > > Yeah, this is a change from previous guidance. Instead of trying to > > > calculate > > > the effect, just state what's there. Even if it makes the expression > > > kind of > > > long and unwieldy. > > > > > > > Just for avoidance of doubt: this guidance is completely impractical > > and it can only be followed for simple packages. > > I can only agree here. > For example, for many non-trivial Rust packages, just "listing what's > there" without doing some amount of simplification will result in > License tags that are >100 characters long. I don't know if there's > any limit to the length of RPM headers, but if there is, we might hit > the limit with the "guidance" ... > > That may be the case, but if something is that complicated in licensing.. not letting a downloader know about it is setting them and us up for problems. People have been boiling software together like licenses don't matter and mixing lots of things which may not be readily mixable. This makes the area ripe for submarine and similar nuisance lawsuits. It is our responsibility as packagers to be aware of this and try to make sure we are making smart choices for ourselves and our consumers. > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: htdig: about to orphan due to license issues, how to?
On Mon, 13 Mar 2023 at 09:10, Petr Menšík wrote: > Okay, thank you. Retired the package in rawhide and orphaned the > package. If the removal should be required also in stable releases, I > would have to take it again. It would be a part of f38 as it is now > sadly, should it be removed even when it is already in the final freeze? > > This is for the beta versus final release so I think a ticket to releng https://pagure.io/releng/ explaining the reason and why it needs to be removed should cover it. For F37 and F36, it is there and done. I would just let it 'time-out' in those releases. > I am not sure how much severe is the license problem. Should all stable > branches get it retired too? Should complete removal [1] apply to this > package? > > 1. > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal > > On 3/13/23 08:31, Florian Weimer wrote: > > * Petr Menšík: > > > >> Is it enough if I orphan that package? Is there any guidance where > >> existing package is found to have licensing problem, how should it be > >> solved? Should something be done to the stable branches also? Should > >> it be retired from all stable branches as well? How should I proceed > >> in this case? > > I think you should retire it from rawhide at least because it will fail > > to build after the C99 transition for Fedora 40 anyway. > > > > As far as I understand it, Fedora still has permission to distribute, we > > just don't like the license, so no special action is required from a > > licensing perspective. Neither Fedora Legal nor the packaging committee > > request removal in such cases or carry it out themselves. At most, a > > bug will be filed, but if the maintainer ignores it, basically nothing > > happens. > > > > Thanks, > > Florian > > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The nvme-cli package & the Fedora Server DVD on-media repositories
On Wed, 22 Mar 2023 at 08:00, wrote: > Hi! > > Recently we have been looking at this bug, currently reported on > Anaconda: > > https://bugzilla.redhat.com/show_bug.cgi?id=2178508 > > "missing packages:nvme-cli during the installation of Fedora 38 Server > Beta" > > In short, what happens is that starting with Blivet (the storage > library used by the Anaconda installer) 3.7.0 the nvme-cli tool will be > proposed for installation when NVME hardware is detected at > installation time. > > This effectively boils down to the nvme-cli package being added to the > installation RPM transaction. > > This works correctly on netinst images, as the nvme-cli package is > available from the Fedora online repositories. But it fails on the F38 > Server DVD image, as nvme-cli is *not* present in the on-media > repositories. > > My question is - how are the DVD image repositories defined ? How can > the nvme-cli package be added to them ? > > I believe they are defined by the kickstarts at https://pagure.io/fedora-kickstarts which for the server group is fairly simple and uses what is defined in 'comps' which is defined in https://pagure.io/fedora-comps . The instructions on how to do PR's for either of these seem to be documented in the README.md > Best Wishes > Martin Kolman > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
On Mon, 27 Mar 2023 at 10:29, Kevin Fenzi wrote: > On Mon, Mar 27, 2023 at 11:57:04AM -, Aleš Matěj wrote: > > > On Fri, Mar 24, 2023 at 05:25:17PM +, Mattia Verga via devel wrote: > > > I have a few additional questions: > > > > > > * How does this impact zchunk? or does it? > > > > I also think there shouldn't be any impact on zchunk. > > ok. Great to hear. > > > > * Kind of unrealted to this change, but I'll ask here as createrepo_c > > > folks might know off hand: Is it possible to decouple drpms from a > repo? > > > ie, if we had a updates repo and a completely seperate updates-drpms > > > repo with just drpms in it, what would it take to use that? Changes in > > > dnf I guess? but also changes in createrepo_c to generate repodata for > a > > > repo that was only drpms? > > > > Such repos can be created by createrepo_c and modifyrepo_c but it is a > bit awkward. > > Basically first create normal (coupled) repo and then extract the > prestodelta.xml and drpms > > into a new repo. Additionally createrepo_c API could be used to make it > more straight forward. > > Well, I was thinking of a completely disconnected process. ie, the drpms > are created compltely seperately from the main repo and a > prestodelta.xml is created there in the seperate repo. > > Or hear me out here for this wild thought: We stop offering drpms. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Tue, 4 Apr 2023 at 05:18, Neal Gompa wrote: > On Tue, Apr 4, 2023 at 3:38 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote: > > > The only benchmark that *I* am aware of is this one done by Martin > > > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/ > > > > This is very … underwhelming. x86-64-v2 is essentially identical to > x86-64-v1. > > x86-64-v3 is better. It even shows speed-ups of 20%, but only with > -Ofast. > > And -Ofast is not something that can be enabled as a default build flag, > > because it leads to surprising and unpredictable behaviour in some > cases. (*) > > At -O2, which we use, the speed up is maybe 10%. > > > > > tl;dr; v2 does not really bring notable improvements, only v3 but also > > > only in some selected synthetic benchmarks. > > > > > > openSUSE Tumbleweed went a different route and chose to utilize > > > glibc-hwcaps instead: > > > https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels > > > > https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD > > > > Yeah, I think that's the way to go. I think we should identify 100 > > shared libraries which would be positively impacted by x86-64-v3 > > and provide a -v3 subrpm for them. This would be a nice feature for > > F40. > > > > This is further confirmed by Arch's data that even x86_64-v3 isn't > necessarily great either: > > https://sunnyflunk.github.io/2023/01/15/x86-64-v3-Mixed-Bag-of-Performance.html > > It seems that moving to -O3 would provide more gains than x86_64-v3. > > Otherwise, the only thing you really get from moving subarches is > breaking lots of hardware. > > I think that we are seeing the 'long tail' of small/tiny performance increases on x86_64 due to multiple factors about the underlying architecture and the end of Moore's law. Basically a lot of things will be touted as big things and may be some improvement for specific workloads, but the majority of work will see nothing 'large' enough that people feel value for it after they paid for it. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Tue, 4 Apr 2023 at 08:52, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote: > > On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek > wrote: > > > On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote: > > > > The only benchmark that *I* am aware of is this one done by Martin > > > > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/ > > > > > > This is very … underwhelming. x86-64-v2 is essentially identical to > x86-64-v1. > > > x86-64-v3 is better. It even shows speed-ups of 20%, but only with > -Ofast. > > > And -Ofast is not something that can be enabled as a default build > flag, > > > because it leads to surprising and unpredictable behaviour in some > cases. (*) > > > At -O2, which we use, the speed up is maybe 10%. > > > > Given that GCC 12 and later autovectorizes at -O2, it might be more than > > 10%. > > > > > > tl;dr; v2 does not really bring notable improvements, only v3 but > also > > > > only in some selected synthetic benchmarks. > > > > > > > > openSUSE Tumbleweed went a different route and chose to utilize > > > > glibc-hwcaps instead: > > > > https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels > > > > > https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD > > > > > > Yeah, I think that's the way to go. I think we should identify 100 > > > shared libraries which would be positively impacted by x86-64-v3 > > > and provide a -v3 subrpm for them. This would be a nice feature for > > > F40. > > > > Why a subrpm? Should be possible to just arrange for one src.rpm to > > build the library twice and install the x86-64-v3 into > > /usr/lib64/glibc-hwcaps/x86-64-v3/ > > Perhaps come with some macro to simplify that for packagers. > > If we start compiling libaries twice, it'd double the package sizes > (or actually more than double, since in the benchmarks the code size > with -v3 is also increased slightly). I assume people would want to > get the optimized form split out to a subpackage so people who don't > use this, don't pay the price. If we use the new "dynamic subpackages" > feature of RPM, and some smart macros, this could even not be a big > packaging burden. > > My guess is that the burden would be shifted to the builders and the background storage. Won't package builds need to be done 'twice' for various parts to get two different sets of libraries? Memory and CPU usage of the builders will be impacted and so would storage size. Those aren't 'free' as a) X build taking N% longer means Y has to wait that much longer for their build to complete. b) koji storage of builds is finite and Fedora is hitting the limits regularly. This means build storage times will have to be shortened again so that builds can complete. Cleaning it out and moving things around take a significant amount of compute time on koji further slowing down things. c) there are a limited number of physical machines in Fedora and no room to add more. d) The resources needed for each build grows and so the virtual builders need to be segmented into fewer systems. e) Mirrors are impacted by the larger packages as it takes longer for them to sync out changes in Fedora. This doesn't mean this is a bad or impossible issue to deal with, but it needs to be clear what the costs are so when changes are needed to deal with those and other impacts, it doesn't come as a surprise to the packager community. > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > > > On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb wrote: > >> On 4/9/23 16:05, Ian McInerney via devel wrote: >> > I decided to put F38 onto my new machine from the start (so a clean >> > install), and now it seems to have some errors with DNF/RPM that I >> > haven't seen before on F37 when I tried the same thing. >> > >> > Specifically, I am trying to install packages from a 3rd-party >> > repository (the Intel oneAPI repo), and it is throwing errors like: >> > >> > package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA >> > signature: BAD (package tag 1002: invalid OpenPGP signature) >> >package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA >> > signature: BAD (package tag 1002: invalid OpenPGP signature) >> > >> > There are two things I don't understand here. >> > >> > The first is, why does DNF/RPM in F38 fail to parse this GPG signature, >> > while DNF/RPM on F37 does parse it? >> >> https://fedoraproject.org/wiki/Changes/RpmSequoia >> See the upgrade impact and user experience sections. >> >> You should contact Intel about fixing their packages. >> > > So we have pushed a change in Fedora where there is no nice way for a user > to workaround it except by complaining to a company that probably doesn't > care what normal users (e.g. non-paying customers) care about? > > Basically the problem is that several checksums and types of keys are considered highly insecure and will cause problems for large numbers of users who have systems which need to meet general security rules in various industries. These include the SHA1 and DSA encryption keys and there are requirements that operating systems no longer ship these as enabled for the operating system to be used in universities, health care, etc. Where in the past these sorts of things have been 'given' a long time for removal (aka the 10+ years for MD5), my understanding is that these are being pushed much faster and harder than before. [Mainly in that continued funding from both public and private organizations is tied to audits etc.] The push is going to come in several 'waves' with SHA1 and DSA marked as bad now and in 1-2 years, SHA256 and RSA keys below 4096. Like most rapid changes, there is always going to be a lot of grit in the gears for everyone trying to continue working outside of the change :/ > > After further experimentation, I finally did find a way to do what I want > (install these packages) - disable all package verification via the RPM > macro. I initially found the option `tsflags=nocrypto` for DNF, but after > putting that in the config file, it still didn't work (the man page for > dnf.conf seems to suggest this should disable the checks that were failing > here, but it didn't disable those). Falling back all the way to RPM with > the --nosignature argument isn't an option here, because installing ~60 RPM > packages manually is not going to fly. I eventually forced DNF to make RPM > do it by setting `%_pkgverify_level none` inside `macros.verify`. I really > don't want to use this large a hammer to fix this though, and would much > rather the nocrypto option actually worked with DNF, so I could then > disable it just for the one repo. > > -Ian > > >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > > > On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen > wrote: > >> >> >> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < >> devel@lists.fedoraproject.org> wrote: >> >>> >>> >>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb wrote: >>> >>>> On 4/9/23 16:05, Ian McInerney via devel wrote: >>>> > I decided to put F38 onto my new machine from the start (so a clean >>>> > install), and now it seems to have some errors with DNF/RPM that I >>>> > haven't seen before on F37 when I tried the same thing. >>>> > >>>> > Specifically, I am trying to install packages from a 3rd-party >>>> > repository (the Intel oneAPI repo), and it is throwing errors like: >>>> > >>>> > package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA >>>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>>> >package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA >>>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>>> > >>>> > There are two things I don't understand here. >>>> > >>>> > The first is, why does DNF/RPM in F38 fail to parse this GPG >>>> signature, >>>> > while DNF/RPM on F37 does parse it? >>>> >>>> https://fedoraproject.org/wiki/Changes/RpmSequoia >>>> See the upgrade impact and user experience sections. >>>> >>>> You should contact Intel about fixing their packages. >>>> >>> >>> So we have pushed a change in Fedora where there is no nice way for a >>> user to workaround it except by complaining to a company that probably >>> doesn't care what normal users (e.g. non-paying customers) care about? >>> >>> >> Basically the problem is that several checksums and types of keys are >> considered highly insecure and will cause problems for large numbers of >> users who have systems which need to meet general security rules in various >> industries. These include the SHA1 and DSA encryption keys and there are >> requirements that operating systems no longer ship these as enabled for the >> operating system to be used in universities, health care, etc. Where in the >> past these sorts of things have been 'given' a long time for removal (aka >> the 10+ years for MD5), my understanding is that these are being pushed >> much faster and harder than before. [Mainly in that continued funding from >> both public and private organizations is tied to audits etc.] The push is >> going to come in several 'waves' with SHA1 and DSA marked as bad now and in >> 1-2 years, SHA256 and RSA keys below 4096. Like most rapid changes, there >> is always going to be a lot of grit in the gears for everyone trying to >> continue working outside of the change :/ >> >> > This error has nothing to do with the crypto change that was made - I had > already reverted that change and pushed my crypto settings back to > DEFAULT:FEDORA32, and it still gave these errors. They are completely > caused by an RPM change. > > You are correct and I was wrong. I should have downloaded the RPM to see what the problem was first. The problem looks to be related to https://github.com/rpm-software-management/rpm/issues/2351 where certain code use to create 'PGP' signatures actually does not conform to the OpenPGP standard. # rpm -vvvK intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm D: loading keyring from rpmdb D: PRAGMA secure_delete = OFF: 0 D: PRAGMA case_sensitive_like = ON: 0 D: read h# 148 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-eb10b464-6202d9c6 to keyring intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 7e6c5dbe: NOKEY Header SHA256 digest: OK Header SHA1 digest: OK Payload SHA256 digest: OK RSA signature: BAD (package tag 1002: invalid OpenPGP signature) MD5 digest: OK I can't see if the code was using the gocrypt code or something else but it looks like https://github.com/sylabs/golang-x-crypto/commit/374053ea96cb300f8671b8d3b07edeeb06e203b4#diff-47e53358306da9dcb5ca7dd110d31067d11f231fc3baed4f51e4026e26b521bfL506 -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Looking to orphan perl-Net-TELNET
I am looking over various packages I own, and realized I was the sole maintainer for the perl-Net-TELNET package. I do not use this package and the fact that I forgot I had maintenance of this.. says I am a 'poor' maintainer. I would like someone else to take over this package and will either add someone or orphan this in the coming 2 weeks. Thank you -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking to orphan perl-Net-TELNET
On Fri, 14 Apr 2023 at 12:37, Emmanuel Seyman wrote: > * Stephen Smoogen [14/04/2023 12:20] : > > > > I would like someone else to take over this package and will either add > > someone or orphan this in the coming 2 weeks. > > I will gladly take it (fas name: eseyman). > > I have added you at admin level. > Emmanuel > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, 20 Apr 2023 at 17:21, Matthew Miller wrote: > > It’s time to transform the Fedora devel list into something new > === > > I hate to ask this but could you give a more summarized version of this email? I realize you had a lot of reasoning you wanted to cover on the why's but I frankly got lost several times. That makes it really hard not to respond in ways which are overly emotional and not helpful. Anything I wrote would start with me trying to summarize what was written but failing to do so, or I would end up trying to pick apart different paragraphs in non-helpful ways. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, 20 Apr 2023 at 18:47, Matthew Miller wrote: > On Thu, Apr 20, 2023 at 05:39:51PM -0400, Stephen Smoogen wrote: > > I hate to ask this but could you give a more summarized version of this > > email? I realize you had a lot of reasoning you wanted to cover on the > > why's but I frankly got lost several times. That makes it really hard not > > to respond in ways which are overly emotional and not helpful. Anything I > > wrote would start with me trying to summarize what was written but > failing > > to do so, or I would end up trying to pick apart different paragraphs in > > non-helpful ways. > > Sure. I realize it is quite long. > > I am proposing that over the course of 2023, starting with the Changes > process, we move Fedora development conversations from this mailing list to > the Discourse-based Fedora Discussion. > > Many Fedora folks, new and old, can't keep with this list. The number of > participants is down over time (even as the number of threads has risen). > Many teams are moving away from devel list anyway -- using various > scattered > bug trackers as their effective "forum". > > Discourse gives us better tools for the conversations we need to have as a > project. I know it takes some getting used to, but I strongly believe it > will be worth it. > > Devel list actually covers a lot of different topics. Discourse lets us > categorize those better while still keeping it all together. > > The first thing I suggest moving is discussion around proposed Changes. > This > is a FESCo decision. The rest I won't duplicate here. > > Thank you. I have a better understanding of where you are coming from, and what this meant to do. I don't like the solution, but I know all too well that the current mailman3 solution works on a wing and a prayer. It has been running an EOL version of the software for a long time and there are not enough infrastructure resources to do all the things that are needed for an upgrade AND keep builds going. I also understand that the general community of the lists has shrunk over the last 10 years with it becoming more and more 'the same old people complaining about the same old things'. That said, I don't think I will be greatly active after the move. I have tried Discourse for a year, but have found it to be like every forum and BBS I have tried for the last 30 years.. frustrating and needy. I get tired and angry after 30 minutes and my replies start becoming the problem you don't want. [I realize this is how many people feel about email which causes them to drop out there.] If that lack of engagement requires me to orphan packages or other items, I completely understand. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, 21 Apr 2023 at 14:07, Ralf Corsépius wrote: > > > Am 21.04.23 um 16:15 schrieb Solomon Peachy via devel: > > On Fri, Apr 21, 2023 at 11:42:20AM +0200, Aleksandra Fedorova wrote: > > >> In all seriousness, I would advise you to hang out at the current > >> discussion.fedoraproject.org and feel the vibe a bit. > > > > You kinda just demonstrated my point -- "hanging out at > > and feel the vibe" is going to take time, attention, and distruption. > > Absolutely. > > The proposal is harmful to Fedora and likely based on the distorted view > of somebody lacking of expericence on practical distribution work. > > I am going to say that comment is Wrong in multiple ways. Both Matthew and Aleksandra have done deep and practical distribution work. You may not like their proposal, and it may not be how you or I find communication to be useful, BUT making comments about a person's abilities is out of line. > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora magazine site down
There was a general outage at wordpress causing many sites hosted there to be offline. https://wpenginestatus.com/incidents/478228 I would like to thank the Red Hat Open Source Program Office (OSPO) for working on what the issue was, and answering questions in the Fedora Infrastructure ticket system. On Fri, 21 Apr 2023 at 23:09, Luna Jernberg wrote: > Seems to be up now again, atleast from my end here in Sweden with > Telia as an ISP > > On 4/21/23, Barry wrote: > > > > I see wordpress error page for https://fedoramagazine.org/ > > > > There has been a critical error on this website. > > > > Learn more about troubleshooting WordPress. > > > > Barry > > > > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, 21 Apr 2023 at 17:20, Florian Weimer wrote: > > > For lists that are active, the split is confusing — when should > > something be on the packaging list rather than devel? What happens when > > something is related to both Cloud and Server, or Workstation and KDE? > > One can post to both lists, but if someone replies and isn’t subscribed > > to both, the conversation gets split. > > Do Fedora mailing lists reject mail from non-members, and redirect > follow-ups? > > Yes we have to. Most of the email coming to any of the fedora mailing lists is spam email from non-subscribers. A good portion of it is 'smart' SPAM where it replies to a specific email with headers to make it pop into an existing thread. Fiddling with various spam controls to better handle that has continually caused important developers emails to start being marked as SPAM. The first thing we did was to have non-member email moderated for the lists. This sounds great but the amount of queued email on many lists is in the order of 100k or more emails. The problem is that the version of mailman3 uses some sort of linked list to keep track of all those queued emails. Every email seems to get checked against that queue which then slows down the overall system. Last year we were getting hour long timeouts on mailman3, and I then spent about 3 man-weeks of volunteer time to go through only about 100 mailing lists to clean out the 100k queues on each of them. I stopped when the timeouts got down to a 'normal' amount but the amount of junk email on the many email lists is a lot. There are probably ways to do this directly in the postgres database, but my attempts required restores from backups due to 'differences between our beta setup and what is expected'. Trying to upgrade mailman3 to a version which may be better has been,I think, a 5 year task of continual frustration. When I was in infrastructure, everyone always had about 10 other tasks of higher priority that HAD to be done to keep other parts of Fedora running. When I left infrastructure, that increased the tasks for the remaining people to 20. Hiring in a replacement just found more things which needed to be kept running so we have looked for volunteers for a while. Several attempts have been made by volunteers, but real life and the overall complexity of modern email kills it every time. Running mailman3 is a nearly full time job to keep it working versus the lackadaisical mailman2 it replaced. Because it is trying to be both a webforum to catch that 'I don't want to use email' audience, a better archiver, and various other tooling, Things like system accounts, authentication, postgres databases, etc They are all needed to make it work. Outside of that DNS has many new fields which need to be implemented or added to deal with slightly conflicting standards which cause various sites to not accept email if they aren't implemented in their version. New fields are added and changed regularly which require dealing with people complaining that their email is now marked as SPAM, they aren't getting the email anymore, or that we have lost email because the queues on our systems overflowed due to various people subscribing to the SCM mailing list but having a quota too small. In any case, the issue is that there have not been for about 8 years to run this well. The task gets harder and harder over time due to complex DNS needs for email to work these days to just general time needed to clean up existing spam, deal with ham being marked as spam, etc. And when it comes down to 'does Infrastructure have time to keep builds, composes, and the 100 services running that are needed to do that' or 'does Infrastructure work on some part of an undocumented email system'.. the answer is always going to be get the daily builds out as developers complain a lot more about that than email. It is time to explore other options. One of them is the proposal that Matthew and I guess the Council have come up with. It is using a resource which is paid for, has an open source background, and is willing to make some changes to better accommodate other workflows. If people want something else they are going to need to come up with a proposal which does not include using existing burned out resources to accomplish it. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Sat, 22 Apr 2023 at 13:03, Richard W.M. Jones wrote: > > I would also be one of those people who would be much less engaged -- > even disengage -- if everything moved to a website. > > I have one thing to add that I don't think was covered: > > Can we make contributing to the mailing list easier? > > One thing we have done in a community I manage is *not* to require any > sign up to the mailing list before posting. They are invited to > simply email the list address. The flip side to this is obviously > that "someone" (cough, me) has to filter out a lot of spam carefully. > It's not too bad in that small community, but might be a lot more work > in Fedora. But it ought to reduce the barrier to entry to "able to > send an email" which is IMHO pretty low. > > Fedora mailman gets a lot of emails. Generally we would see about 900 emails per day that would need to be dealt with per day for the devel list and 1600 emails per day for users. The lower end mailing lists see about 200 emails a day that come in and get dropped from non-subscribers. Processing those is not a fast issue with mailman3 because of database and schema issues. It generally takes 20 to 30 seconds to delete or accept a held email. Trying to do them in bulk halts ALL other transactions as it has to lock various tables. Some of these issues may be fixed in a newer version of mailman3, but we can't just update to any newer version because our database schema was a prerelease. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Mon, 24 Apr 2023 at 09:38, Simo Sorce wrote: > On Sat, 2023-04-22 at 12:16 -0700, Adam Williamson wrote: > > On Sat, 2023-04-22 at 10:37 -0700, Kevin Fenzi wrote: > > > On Fri, Apr 21, 2023 at 02:30:45PM -0700, Adam Williamson wrote: > > > > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote: > > > > > > > > > > > For lists that are active, the split is confusing — when should > > > > > > something be on the packaging list rather than devel? What > happens when > > > > > > something is related to both Cloud and Server, or Workstation > and KDE? > > > > > > One can post to both lists, but if someone replies and isn’t > subscribed > > > > > > to both, the conversation gets split. > > > > > > > > > > Do Fedora mailing lists reject mail from non-members, and redirect > > > > > follow-ups? > > > > > > > > Many lists *hold* mail from non-members, because mailing lists get > tons > > > > of spam. So the mail won't get through until an admin approves it. > That > > > > might happen right away...or it might happen in two days, when the > mail > > > > is no longer relevant. We can't really just let all mails from non- > > > > members through because...spam. > > > > > > Right. I don't think we have many (or possibly any) lists that still > > > hold email from non-members. The flood of spam is just too high for > that > > > for the last N years. So, almost all our lists are set to reject non > > > member posts. :( > > > > ah, I hadn't noticed that change :/ I could've sworn I still sometimes > > get hold notices when I send meeting announcements to lists I'm not > > subscribed to... > > In theory we could make it simpler by sending back a message that > requires just a click to subscribe/authorize the email by a real user, > if they intend to do so, on their first email to a mailing list. > We could also allow posting to other mailing lists if the email address > is subscribed to any other list. > > We had this running for a bit where we would send back emails saying this is held. 99% of the emails would then go sit in queue on bastion slowing down regular deliveries. We are talking hundreds of emails a day on 'good' days and tens of thousands on 'bad' days. Trying to deal with this is a full time job that no one is paid (and my volunteer time is limited) to do. Trying to fix in better ways is usually a massive project because you need to think out the total email flow plan and needs. Email is no longer the old 'set up a mail server and let it live'. It is 'why do we have 10,000 queued emails today?' 'why aren't redhat.com emails getting delivered today?' 'oh look 2 new DNS features to 'deal' with SPAM', 'oh spamassassin needs new setup and fixes', 'why is email stuck here?' 'why is X sending email to google.com but we are getting errors from gandhi.net or protonmail.com'. The software which runs mailing lists is also much more complicated than it was 20 years ago. You need to deal with backend databases, caching web servers, internal search engines, message tooling, spam deletion, account acceptance, etc. That takes constant learning and dedicated 'brain' space for admins to keep it working. In order to keep email working, it takes dedicated and hard work and decisions to make it happen. I realize this would require working on mailman and that is probably > something we do not want to spend time on ... > > After all you have to subscribe to discourse as well to be able to post > ... so there is no huge difference here. > > -- > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is texlive-was-9 retired for Fedora 38?
On Tue, 25 Apr 2023 at 14:13, stan via devel wrote: > On Tue, 25 Apr 2023 17:30:28 + (UTC) > Globe Trotter via devel wrote: > > > Is texlive-was-9 retired for Fedora 38? My package did not upgrade > > from F37 and so I was wondering about it. > > As near as I can tell, there is no package in fedora called > texlive-was-9. > > In Fedora 37 base there was: ``` /srv/web/pub/fedora/linux/releases/37/Everything/x86_64/os/Packages/t/texlive-was-svn21439.0-59.fc37.noarch.rpm Name: texlive-was Epoch : 9 Version : svn21439.0 Release : 59.fc37 Architecture: noarch Install Date: (not installed) Group : Unspecified Size: 14330 License : Public Domain Signature : RSA/SHA256, Tue 02 Aug 2022 08:31:29 GMT, Key ID f55ad3fb5323552a Source RPM : texlive-2021-59.fc37.src.rpm Build Date : Mon 01 Aug 2022 16:30:45 GMT Build Host : buildvm-ppc64le-37.iad2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://tug.org/texlive/ Bug URL : https://bugz.fedoraproject.org/texlive Summary : A collection of small packages by Walter Schmidt Description : A bundle of packages that arise in the author's area of interest: compliance of maths typesetting with ISO standards; symbols that work in both maths and text modes commas for both decimal separator and maths; and upright Greek letters in maths. ``` These were built out of the main texlive package. This package was also in the F38 repository /pub/fedora/linux/releases/38/Everything/x86_64/os/Packages/t/texlive-was-svn64691-65.fc38.noarch.rpm so it should have been updated unless some other package problem stopped it. Try doing a `dnf reposync` > There is a package > texlive-wasy-10:svn53533-65.fc38.noarch.rpm > that contains > /usr/share/texlive/texmf-dist/fonts/source/public/wasy/wasy9.mf > in F38. > https://koji.fedoraproject.org/koji/rpminfo?rpmID=33307983 > > Is that what you mean? It seems to be there in F38. Is it possible > that it has conflicts, and so wasn't updated? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is texlive-was-9 retired for Fedora 38?
On Tue, 25 Apr 2023 at 14:43, Globe Trotter via devel < devel@lists.fedoraproject.org> wrote: > Thank you for this! > > I set up > > > $sudo dnf reposync > > and it is going on to do some sort of download for 69,222 (!) package? > > Is this correct? I seem to think that there are a bit more than 2,000 RPMs > installed in my system! > > I am perplexed, so I just wanted to make sure that this is what I should > be doing. > > No that is me typing instructions while on pain management medicine. dnf distro-sync is what I should have typed. My apologies for the mixup. > Thanks again! > > > > > > > > > > > On Tuesday, April 25, 2023 at 01:17:56 PM CDT, Stephen Smoogen < > ssmoo...@redhat.com> wrote: > > > > > > > > On Tue, 25 Apr 2023 at 14:13, stan via devel < > devel@lists.fedoraproject.org> wrote: > > On Tue, 25 Apr 2023 17:30:28 + (UTC) > > Globe Trotter via devel wrote: > > > >> Is texlive-was-9 retired for Fedora 38? My package did not upgrade > >> from F37 and so I was wondering about it. > > > > As near as I can tell, there is no package in fedora called > > texlive-was-9. > > > > > In Fedora 37 base there was: > > ``` > > /srv/web/pub/fedora/linux/releases/37/Everything/x86_64/os/Packages/t/texlive-was-svn21439.0-59.fc37.noarch.rpm > Name: texlive-was > Epoch : 9 > Version : svn21439.0 > Release : 59.fc37 > Architecture: noarch > Install Date: (not installed) > Group : Unspecified > Size: 14330 > License : Public Domain > Signature : RSA/SHA256, Tue 02 Aug 2022 08:31:29 GMT, Key ID > f55ad3fb5323552a > Source RPM : texlive-2021-59.fc37.src.rpm > Build Date : Mon 01 Aug 2022 16:30:45 GMT > Build Host : buildvm-ppc64le-37.iad2.fedoraproject.org > Relocations : (not relocatable) > Packager: Fedora Project > Vendor : Fedora Project > URL : http://tug.org/texlive/ > Bug URL : https://bugz.fedoraproject.org/texlive > Summary : A collection of small packages by Walter Schmidt > Description : > A bundle of packages that arise in the author's area of > interest: compliance of maths typesetting with ISO standards; > symbols that work in both maths and text modes commas for both > decimal separator and maths; and upright Greek letters in > maths. > ``` > > These were built out of the main texlive package. This package was also in > the F38 repository > > > /pub/fedora/linux/releases/38/Everything/x86_64/os/Packages/t/texlive-was-svn64691-65.fc38.noarch.rpm > > so it should have been updated unless some other package problem stopped > it. Try doing a `dnf reposync` > > > There is a package > > texlive-wasy-10:svn53533-65.fc38.noarch.rpm > > that contains > > /usr/share/texlive/texmf-dist/fonts/source/public/wasy/wasy9.mf > > in F38. > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=33307983 > > > > Is that what you mean? It seems to be there in F38. Is it possible > > that it has conflicts, and so wasn't updated? > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > > > > > > -- > > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Maili
Re: It’s time to transform the Fedora devel list into something new
On Wed, 26 Apr 2023 at 08:44, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Josh Boyer wrote: > > Ah. May or may not. That gives me hope at least. > > Well, considering that we have hundreds of existing contributors, who all > may or may not be willing to adapt to a platform that is clearly not > designed for them (Discourse is very strongly newbie-centric, see the > "achievements" and all the other hand-holding), I think it is safe to > assume > that several important contributors WILL leave, tone down their > participation, and/or miss some important communication (leading to > breakage > in the distribution, e.g., broken dependencies making it into Rawhide) if > Fedora makes the switch. > > I may be in that list of toning down, but that is OK. Look it's really time for new people to come in and break things. It is the only way they really learn if something is something that should be really avoided or was a taboo we had from the 1990's which we can't see as cargo culting anymore. Maybe a bunch of packages will be dropped and Fedora will become 'useless' to some of us older contributors. This isn't the first time that has happened with the distribution (we saw large drop-offs after we stopped Xen and when we changed desktops to GNOME3.) and if the distribution is to last as an institution, it won't be the last. We who aren't happy with it can either make do with something else, adapt, or finally retire to grow potatoes like all the programmers I knew from the 1980s who had gotten tired of all the changes over the years. Normally this is where I would clip the rest of the message, but I want to say something about a later section, so please scroll. > > > > It's a barrier to entry problem. If we, as the experienced and capable > > contributor base, can adapt to something and lower the barrier to entry > > then it benefits us all. > > Again, I do not see the communication platform as the main barrier to > entry > for Fedora at all. Where is the evidence for that claim? > > As I see it, the main roadblocks for new packagers are: > * accepting the FPCA, > * getting sponsored, > * learning the Packaging Guidelines, and > * getting their package(s) through review, > and that last point can be a roadblock even for existing packagers > (because > we do not trust even experienced provenpackagers and/or packager sponsors > to > review their own packages). > > Those points are all there for a reason (the FPCA for legal coverage, the > sponsorship process so new contributors are mentored and their > trustfulness > verified, the Packaging Guidelines to ensure a certain package quality for > our end users, and the review process to ensure that the Packaging > Guidelines are actually followed and as another check that nothing > malicious > sneaks in), but they are the barrier to entry, not the communication > platform. > > I want to say that I agree with Kevin Kofler on this. We have a lot of other barriers for entry which I have found to be higher on getting new contributors into the distribution. Unless we have some field in the discussion site with interested and energized people who can help mentor future packagers.. we aren't addressing the real problem. That said, this discussion hasn't been about how to fix that problem either here OR the forum. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Wed, 26 Apr 2023 at 15:28, Maxwell G wrote: > On Wed Apr 26, 2023 at 18:04 +0200, Vitaly Zaitsev via devel wrote: > > On 20/04/2023 23:20, Matthew Miller wrote: > > > It’s time to transform the Fedora devel list into something new > > > > I think such serious questions should be put to a vote. Not a FESCo > > vote, but a vote for all Fedora contributors (can be combined with the > > next FESCo elections). > > I think having this as a "ballot referendum" of sorts is a good idea. > > So let us say it is voted on and the answer is keep the mailing lists. What are the next steps to fixing the mail system which is held together by duct-tape and bailing wire? It is a seriously large task to get done with everything from someone getting all the packages back into Fedora, architecting how email should flow, getting a documented system and tooling, then dumping the current system, fixing the schema changes, importing the system into a new mail system, and doing that 6 or 7 times to get it actually working. It is a set of tasks needing senior programmers, some DBA time, and senior system administration. It will take about 3 to 6 months of dedicated work to get done. If done on volunteer time, I would put it at 12 months. After that it needs a regular redo and cleanup of code or we will be back where we are currently very fast. Where we are currently is a system running on old dead code, can't be reinstalled, with a possibly slightly corrupted disk partition (though I think I fixed all of the items) and needing to be coddled regularly to keep going. It has hundreds of thousands of 'held' dead spam messages, similar number of bounces for dead accounts (mailman3 did not implement auto-unsubscribe til after the version we are running) and other oddities. Or the infrastructure team can work on keeping the build system running which is also fairly touchy with daily restarts, random reboots, etc. That is also more than a full-time job for both the volunteers and dedicated people. Look I am not wanting to move to discourse, but voting is not going to fix anything. > -- > Maxwell G (@gotmax23) > Pronouns: He/They > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning despite having maintainers?
On Wed, 26 Apr 2023 at 22:32, Alexander Bokovoy wrote: > On ke, 26 huhti 2023, Kevin Fenzi wrote: > >On Wed, Apr 26, 2023 at 07:23:10PM +0100, Chris Kelley wrote: > >> One thing I still don't understand is why all of our java packages are > >> orphan-affected by the orphaning of java-1.8.0-openjdk. None of them > >> BuildRequires a JDK, and the source/target/release values for the > packages > >> range from 6 to 17. Can anyone shed some light on this please? > > > >What do you mean by 'orphan-affected'? > > > >I only see java-1.8.0-openjdk orphaned... what are the other packages > >you see and how are they affected? > > Packager dashboard shows that resteasy is depending on > java-1.8.0-openjdk but it is not. When I don't have java-1.8.0-openjdk > installed and attempt to install build dependencies for resteasy > package, I don't see it pulling in java-1.8.0-openjdk: > > Doesn't that also need to cover all of the build requires for those components also? It isn't just that a package may need it in an install, it may also need it to be rebuilt. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Wed, 26 Apr 2023 at 23:58, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > I may be in that list of toning down, but that is OK. Look it's really > > time for new people to come in and break things. It is the only way they > > really learn if something is something that should be really avoided or > > was a taboo we had from the 1990's which we can't see as cargo culting > > anymore. > > > > Maybe a bunch of packages will be dropped and Fedora will become > 'useless' > > to some of us older contributors. This isn't the first time that has > > happened with the distribution (we saw large drop-offs after we stopped > > Xen and when we changed desktops to GNOME3.) and if the distribution is > to > > last as an institution, it won't be the last. We who aren't happy with it > > can either make do with something else, adapt, or finally retire to grow > > potatoes like all the programmers I knew from the 1980s who had gotten > > tired of all the changes over the years. > > But what if the major influx of new contributors that you proponents of > this s/you/the/; I am NOT a proponent of this proposal. I don't want to go to Discourse. Web interfaces like that cause me cognitive pain and grumpiness to use longer than a few minutes. As such I know my involvement with Fedora will go down further. If it comes across that I am for this change, it is because I am tired and frustrated. The mailman system has been running on inertia since at least February 2018, when the last software updates to the mailman software were done. Over the last 5 years, the system has mostly run, but in the last year has increasingly had longer and longer outages. My tiredness comes from spending most of my Thanksgiving and Winter breaks trying to find reasons and then doing whatever cave-man hacks I could to fix it without breaking mail altogether. My frustration and anger comes from the fact that I spent most of the last 5 years assuming that it was somebody else's problem and they would take care of it so I could focus on keeping other things running. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Mon, 8 May 2023 at 15:58, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > > > I'd like to note that making this blocking doesn't waive any kind of > > magic wand that makes our infrastructure more reliable. ;) > > The container build pipeline is a long collection of fragile things. > > It may well result in us slipping more based on things not working. ;( > > Hmm, quoting from https://pagure.io/releng/issue/11092: > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we > >> should probably try to do a full redeploy :-( > > We can't upgrade it from f33 because docker is no longer in f34+ and > > openshift origin / 3.11 doesn't support any newer either. > > Is this still true? I don't think we want to make the Fedora release > process contingent on something that requires F33. > > ``` $ sudo -i ssh osbs-aarch64-node01.iad2.fedoraproject.org cat /etc/system-release Fedora release 33 (Thirty Three) ``` My memory of this is that this is not an easy thing to 'fix'. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Mon, 8 May 2023 at 19:35, Demi Marie Obenour wrote: > On 5/8/23 19:09, Neal Gompa wrote: > > On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour > wrote: > >> > >> On 5/8/23 18:49, Kevin Fenzi wrote: > >>> On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: > >>>> Dear Kevin, > >>>> > >>>>>> Hmm, quoting from https://pagure.io/releng/issue/11092: > >>>>>>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we > >>>>>>>> should probably try to do a full redeploy :-( > >>>>>>> We can't upgrade it from f33 because docker is no longer in f34+ > and > >>>>>>> openshift origin / 3.11 doesn't support any newer either. > >>>>>> > >>>>>> Is this still true? I don't think we want to make the Fedora release > >>>>>> process contingent on something that requires F33. > >>>>> > >>>>> yes, it's still true. Note thats the aarch64 osbs cluster. > >>>>> The x86_64 one is rhel7. > >>>> > >>>> Might it be possible to replace Docker with CRI-O on the OpenShift > >>>> cluster? > >>> > >>> Nope. openshift 3 / osbs1 uses docker. :( > >>> > >>> kevin > >> > >> alias docker=podman > > > > Using Podman with it through Podman's implementation of the Docker > > Host protocol *may* work, but a version of Podman that has it is not > > currently available for RHEL 7 (which is what OpenShift 3.11 runs on). > > Time for an OpenShift upgrade? > > I realize people are trying to help with suggestions, but the problem is that this is not a simple solution or it would have been done years ago. The Fedora Build System is a very complicated set of applications all tied together with custom scripting, schema, and various updates over time. There are somewhere around 40 core services and 30 more subsidiary ones which need to be continually working to allow for the daily builds for multiple releases. Many of those services have been added in at different times with different operating systems and rules. In order to work with each other a lot of 'glue' scripting, libraries and such are needed. You upgrade podman/docker in one section and you find that the message bus isn't sending in another because an API call isn't there anymore. You try putting in something which says it has a koji plugin and you find it doesn't work with our koji and then you need to extend the plugin 40 ways to work with bodhi, pdc, fedmsg and fedora-messaging, and a dozen other things which all are the actual build system. Once those get fixed, you find that it is now causing other glue parts to fail in odd ways no one remembers why without some archaeological coding. When dealing with the Build system side of things there is currently 1 senior system administrator and 1 senior release engineer. There are some volunteers who can work on subparts but mainly have day jobs doing other things. Looking at IRC, most of the 10-12 hour work day is dealing with compose problems, build issues, hardware failures, and similar things. Most of the 40 component subsystems like the Open Shift Build System (OSBS) are brought in by a dedicated team who have a budget time to get it working and into place. Once that time is done, any fixes are on the Fedora staff or working with available time from whatever team. tl;dr: The Fedora Build System is in total a very complicated set of tools where changing or upgrading any one part tends to cascade to fixing lots of glue throughout the system. Instead of looking to upgrade things to add more deliverables, it may be better to look at other ways to get those deliverables built. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: it builds in copr epel-9 (with RHEL-9) but fail to build on koji
On Tue, 9 May 2023 at 14:20, Sérgio Basto wrote: > Hi, > it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji > [2] > > COPR is using DEBUG util.py:445: xorg-x11-server-Xvfb x86_64 1.20.11-17.el9 appstream 897 k EPEL at the time you tried the build was using DEBUG util.py:445: xorg-x11-server-Xvfbx86_64 1.20.11-11.el9 build 895 k which says to me that the CDN sync from Red Hat isn't complete so koji may have some 9_2 and some 9.1 items in its build root. [Although I did not see any 9_2 in the koji output but did see them in the COPR one.] I think the Fedora infrastructure is trying to get a download for koji which may take some time. Try again tomorrow > the test with xvfb-run seg fault and fails on koji [3] any idea why ? > > Thank you > > > > [1] > https://copr.fedorainfracloud.org/coprs/build/5901019 > > [2] > https://koji.fedoraproject.org/koji/taskinfo?taskID=100929278 > > [3] > xvfb-run -a -s '-screen 0 1024x768x24 -ac +extension GLX +render - > noreset' pytest PyOpenGL-3.1.6/tests > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: it builds in copr epel-9 (with RHEL-9) but fail to build on koji
On Tue, 9 May 2023 at 14:33, Stephen Smoogen wrote: > > > On Tue, 9 May 2023 at 14:20, Sérgio Basto wrote: > >> Hi, >> it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji >> [2] >> >> > COPR is using > > DEBUG util.py:445: xorg-x11-server-Xvfb x86_64 1.20.11-17.el9 > appstream 897 k > > EPEL at the time you tried the build was using > DEBUG util.py:445: xorg-x11-server-Xvfbx86_64 1.20.11-11.el9 >build 895 k > > which says to me that the CDN sync from Red Hat isn't complete so koji may > have some 9_2 and some 9.1 items in its build root. [Although I did not see > any 9_2 in the koji output but did see them in the COPR one.] > > I think the Fedora infrastructure is trying to get a download for koji > which may take some time. Try again tomorrow > > Looks like the sync is done already. I see that the `xorg-x11-server-Xvfb x86_64 1.20.11-17.el9` is now downloaded. If retriggering does not work I would put in a release engineering ticket to see if koji needs something 'kicked'. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to get a rawhide i686 VM?
On Mon, 15 May 2023 at 07:45, Dmitry Belyavskiy wrote: > Dear Peter, > > On Mon, May 15, 2023 at 1:06 PM Peter Robinson > wrote: > > > > On Mon, May 15, 2023 at 11:39 AM Dmitry Belyavskiy > wrote: > > > > > > Dear colleagues, > > > > > > What is the simplest way to get a rawhide i686 VM? I came across a > > > nasty architecture-specific bug, and the code investigation isn't of > > > much help. There is no obvious way to access a core dump via mock > > > (could you please ping me if it exists?) and the VM looks like a > > > reasonable choice. > > > > run an i686 userspace in a x86_64 is about the best option these days. > > Is there a guideline on how to do it? > > Miroslav Suchy's answer earlier is the best one: ``` mock -r fedora-rawhide-i386 --no-cleanup-after foo.src.rpm mock -r fedora-rawhide-i386 install mock -r fedora-rawhide-i386 shell cd /builddir/build ``` -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: java-1.8.0-openjdk orphaned Re: Orphaned packages looking for new maintainers
nt-api > > rrelyea: java-1.8.0-openjdk, plexus-component-api > > rstoyanov: libvirt-sandbox > > rstrode: paktype-naskh-basic-fonts, ucs-miscfixed-fonts, sil-padauk- > > fonts > > runcom: gomtree > > rvykydal: ucs-miscfixed-fonts > > sagitter: f2c > > salimma: et, python-blosc > > sayanchowdhury: python-stomper > > sbluhm: java-1.8.0-openjdk, plexus-component-api > > sdgathman: java-1.8.0-openjdk, plexus-component-api > > sergesanspaille: clang10 > > sergiomb: java-1.8.0-openjdk, paktype-naskh-basic-fonts, sil-padauk- > > fonts, > > plexus-component-api > > sergiopr: python-blosc > > sgallagh: python-blosc > > sharkcz: mingw-gstreamer1 > > shlomiya: dmtcp > > slagle: ucs-miscfixed-fonts > > slankes: choqok > > slp: ucs-miscfixed-fonts > > smani: python-flask-login, mingw-gstreamer1-plugins-base, mingw- > > gstreamer1, > > gtksourceviewmm3 > > spike: java-1.8.0-openjdk, plexus-component-api > > spot: plexus-component-api, paktype-naskh-basic-fonts, mingw- > > gstreamer1, > > java-1.8.0-openjdk, genders, maven2, sil-padauk-fonts > > spstarr: genders > > stahnma: ruby-augeas > > stefw: ucs-miscfixed-fonts > > stevetraylen: java-1.8.0-openjdk, python-blosc, plexus-component-api > > susmit: openmolar > > tagoh: paktype-naskh-basic-fonts, sil-padauk-fonts > > tdawson: python-stomper > > tdecacqu: ucs-miscfixed-fonts > > terjeros: java-1.8.0-openjdk, ruby-augeas, plexus-component-api > > teuf: mingw-gstreamer1-plugins-base, mingw-gstreamer1 > > than: java-1.8.0-openjdk, plexus-component-api > > thrnciar: python-blosc > > tlavocat: ucs-miscfixed-fonts > > tmraz: java-1.8.0-openjdk, plexus-component-api > > tomegun: ucs-miscfixed-fonts > > tpopela: java-1.8.0-openjdk, plexus-component-api > > treydock: genders > > ttorling: java-1.8.0-openjdk, plexus-component-api > > twaugh: python-stomper > > vakwetu: java-1.8.0-openjdk, plexus-component-api > > van: java-1.8.0-openjdk, plexus-component-api > > vanessakris: python-blosc > > vascom: reaver, ucs-miscfixed-fonts > > victortoso: mingw-gstreamer1-plugins-base, mingw-gstreamer1 > > virtmaint-sig: ucs-miscfixed-fonts > > vishalvvr: lohit-malayalam-fonts, paktype-naqsh-fonts, paktype-ajrak- > > fonts, > > paktype-tehreer-fonts, lohit-nepali-fonts, paktype-naskh-basic-fonts, > > lohit-tamil-classical-fonts > > vladimirslavik: ucs-miscfixed-fonts > > vokac: edg-mkgridmap > > vpavlin: spin-kickstarts > > vpodzime: ucs-miscfixed-fonts > > vpolasek: ucs-miscfixed-fonts > > vponcova: ucs-miscfixed-fonts > > walters: java-1.8.0-openjdk, maven2, plexus-component-api > > wilqu: java-1.8.0-openjdk, plexus-component-api > > wsato: paktype-naskh-basic-fonts, ucs-miscfixed-fonts, sil-padauk- > > fonts > > wwoods: python-stomper, ucs-miscfixed-fonts > > xavierb: paktype-naskh-basic-fonts, sil-padauk-fonts > > yanqiyu: stardict > > yselkowitz: tse3 > > zbyszek: ViTables, python-blosc, ucs-miscfixed-fonts > > zmiklank: java-1.8.0-openjdk, plexus-component-api > > zuul: ucs-miscfixed-fonts > > > > -- > > The script creating this output is run and developed by Fedora > > Release Engineering. Please report issues at its pagure instance: > > https://pagure.io/releng/ > > The sources of this script can be found at: > > https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py > > > > Report finished at 2023-05-01 19:45:39 UTC > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Planned Outage of s390x affecting all koji 2023-06-01
Planned Outage - koji/s390x - 2023-06-01 05:00 UTC There will be an outage starting at 2023-06-01 05:00 UTC, which will last approximately 24 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-06-01 05:00UTC' Reason for outage: The Red Hat Westford location will have more power line work done. This will require the building to be powered down in places which will affect various services like network connections and s390x builders. Affected Services: koji builds and composes will be affected with builds waiting until the s390x builders are able to complete the work. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11345 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Plans for dhclient / ISC dhcp?
On Tue, 30 May 2023 at 08:46, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > It seems as if the ISC dhcp package has been EOL'd upstream: > > > > https://www.isc.org/dhcp/ > > I'm a little surprised that nobody has forked this to continue > maintaining it. dhcpd is widely used, and kea is far from a drop-in > replacement. > > It is also not sexy software and you have to deal with a very hornery set of bug reports where everything going wrong in any office is of course blamed on DHCP. [You also need to know about the deep intricacies of a ton of flags and settings which may have stated RFC uses but have been misused for decades because some hardware decided to reuse a flag for a boot-time option. You 'fix' an issue and you usually find you broke some key infrastructure no one 'knew' about except someone who retired 4 to 10 years ago. With that, I can see why ISC is 'burying' the software for some poor sucker to take up. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Plans for dhclient / ISC dhcp?
On Tue, 30 May 2023 at 14:45, Chris Adams wrote: > Once upon a time, Florian Weimer said: > > * Chris Adams: > > > > > Once upon a time, Richard W.M. Jones said: > > >> It seems as if the ISC dhcp package has been EOL'd upstream: > > >> > > >> https://www.isc.org/dhcp/ > > > > > > I'm a little surprised that nobody has forked this to continue > > > maintaining it. dhcpd is widely used, and kea is far from a drop-in > > > replacement. > > > > It's … just not very good. A lot of the logic resides in a shell script > > that runs as root, uses bash arithmetic expansion, and processes > > untrusted data from the network. That's not a good combination at all. > > Well, I was really talking about dhcpd, not dhclient. > > Yes. My apologies to you and everyone else. You said that several times and I just went blathering on dhcpd versus dhclient. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen wrote: > Lets not make this a drama. > > Package maintenance changes have never gone through change proposals. > > I am sorry, but this was made into a drama by the way this was executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise. This isn't just package maintenance. This is a major change in what is expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through. It is also drama because people in the community have no idea what else will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it. Could we try something different for future changes? 1. Announce that Red Hat will be moving from owning said packages and dependencies on X date. 2. Let people grieve about things for a short while but make it clear its happening. See if community members or other companies will take up the burden 3. Do the orphan or hand over of packages to the new group. Instead of 3,1,2? > > However, it surprises me that for a package, that is part of the > deliverables of Fedora releases, no coordination effort was made to > transition the package from Red Hat maintenance to Fedora maintenance. > > My email is that effort. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Fri, 2 Jun 2023 at 09:40, Peter Robinson wrote: > On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen > wrote: > > > > > > > > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen wrote: > >> > >> Lets not make this a drama. > >> > >> Package maintenance changes have never gone through change proposals. > >> > > > > I am sorry, but this was made into a drama by the way this was > executed. Surprise is the opposite of engagement and dropping a ton of > packages and their dependencies and then announcing it is absolute surprise. > > > > This isn't just package maintenance. This is a major change in what is > expected to be included in the next workstation editions with the removal > of expected functionality. If the packages are not picked up within a > certain amount of time or can be rebuilt it means many packages will need > to be edited. Those changes need to be researched, announced, and pushed > through. > > > > It is also drama because people in the community have no idea what else > will take place? When uncertainty and doubt are allowed into the > conversation, people jump to the extremes so they can feel ready to deal > with it. > > > > Could we try something different for future changes? > > 1. Announce that Red Hat will be moving from owning said packages and > dependencies on X date. > > 2. Let people grieve about things for a short while but make it clear > its happening. See if community members or other companies will take up the > burden > > 3. Do the orphan or hand over of packages to the new group. > > > > Instead of 3,1,2? > > That may not always be possible, sometimes it involves departure or > changes of roles for people and those can be delicate and are not > always notifiable. I'm not sure that is the case here but I do know, > from a blog post [1], that the previous maintainer is no longer at Red > Hat. > > Yes, I did engage mouth before brain on this. It isn't alway possible, and real life is messy. My apologies to Matthias in my wording makes it sound like this dropping was his decision and the way it was executed was his doing and fault. > Peter > > [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro wrote: > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > wrote: > > zlib should be added to the standard freedesktop.org runtime if it is > > not > > already included. > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > nobody should need to bundle it. > > Michael > > The problem I see in these conversations are: 1. What is a flatpak and what does it mean to have an application in it? Is it everything bundled in it or does it use layers? 2. So there are these 'SDKs' that people mention? What is in them? How are they built? How are they updated? Who maintains them and how can we 'verify' in the 'trust and verify' method (aka source code, build flags, build system). I think a FAQ around these and others would probably cut down a lot of the uncertainty and doubt people feel. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Mon, 5 Jun 2023 at 14:10, Steve Grubb wrote: > On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote: > > On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro > > > > wrote: > > > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > > > > > > wrote: > > > > zlib should be added to the standard freedesktop.org runtime if it > is > > > > not > > > > already included. > > > > > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > > > nobody should need to bundle it. > > > > > > Michael > > > > The problem I see in these conversations are: > > > > 1. What is a flatpak and what does it mean to have an application in it? > Is > > it everything bundled in it or does it use layers? > > 2. So there are these 'SDKs' that people mention? What is in them? How > are > > they built? How are they updated? Who maintains them and how can we > > 'verify' in the 'trust and verify' method (aka source code, build flags, > > build system). > > > > I think a FAQ around these and others would probably cut down a lot of > the > > uncertainty and doubt people feel. > > Yes. And how does it's security model work? > > What is the root of trust? Are they signed by a Fedora key that I already > have? How can we verify it's integrity? Once installed, how do I verify > it's > integrity? How do I check if anything has been modified? Does it integrate > well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system, > are > there sysctls that I have undo such as user namespaces? If an app > coredumps, > does a problem report get generated? Who gets it? > > How can I tell what the security policy that the upstream chose to implement for me. > -Steve > > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Mon, 5 Jun 2023 at 16:14, Michael Catanzaro wrote: > > > On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen > wrote: > > > > 1. What is a flatpak and what does it mean to have an application in > > it? Is it everything bundled in it or does it use layers? > > Two layers: > > * Runtime (base platform, responsibility of runtime maintainers) > * Application (including bundled dependencies not present in the > runtime) > > It's a compromise between traditional distribution-style dynamic > linking for the most common dependencies (the runtime), plus bundling > for the less-common dependencies the application needs that are not > present in the runtime. > > I just wanted to say thank you for taking the time to answer these questions. It was very helpful. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Copr builders updated to Fedora 38
On Tue, 13 Jun 2023 at 08:21, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Gary Buhrmaster wrote: > > Well, EL6 ELS support is still available for (around) > > another year, so it is a nice to have to support those > > limping along with EL6, but I would generally agree > > with the principal that if supporting a product past > > official EOL becomes overly onerous that support > > should end, or be explicitly funded out of the ELS > > fees if the ELS community needs that support. > > EPEL is not covered by ELS, hence EPEL is already EOL. > > If we are going to support distros that had their EOL 2½ years ago, I want > my Fedora 31 to 36 buildroots back! (Fedora 31 had its EOL only 6 days > before EPEL 6, Fedora 32 to 36 had theirs more recently.) > > I am in agreement with Kevin on this. While there are people who might still want to build for their EL6 systems (including myself *cough*), I think there is a point where its usage of the COPR project's limited resources. If you really need to build stuff against end of life releases, then one needs to do the work themselves or join together with other people who can help pay for those resources. > > I do not consider setting gpgcheck=0 overly > > onerous for EPEL6 > > I consider it a security risk and a no go. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Modules without modularity
On Thu, 15 Jun 2023 at 03:04, Petr Pisar wrote: > V Thu, Jun 15, 2023 at 01:33:38AM +0200, Kevin Kofler via devel napsal(a): > > Petr Pisar wrote: > > > and accept that > > users now have to explicitly opt in to those modules. > > That's exactly what killed the current modularity. Nobody felt a presure to > fix the tooling because Modularity was off by default. > > I don't think anyone felt pressure to fix it before it was off by default. Fixes to problems with Fedora MBS were always 'coming real soon' for multiple releases before this decision was made. There have been multiple outages or slowdowns in the Fedora Build System over the years due to MBS issues which only got 'fixed' by herculean last minute efforts. The truth is that this has been a vicious loop from the beginning. There was a general feeling with many developers inside and outside of Red Hat that no matter what problems they saw, they were going to have to like it or lump it. People who were proponents from the start got burned out either by the lack of fixes to the tooling or community pushback. People working on it felt like they were having to put parts of it in before it was ready but also left to handle the fallout from things not working well. Reviewing the past 3+ years, I would say that modularity would only work well if the entire 'build system' and work flow around it was built with that in mind. The Fedora system had nearly 20 years of established work flows, tooling and ideas when modularity was added and it never worked well. The CentOS Stream build system was designed from scratch but with many of the tools Fedora already used, and MBS worked better but still has had many issues of square peg in round hole. Remi's modularity seems to have worked best because of at least two things: 1. He designed his entire build workflow to work with his modularity system. He redesigned how he was going to package and how he was going to deal with modules with tools which fit his workflow. 2. He controls what goes into his build system, when it goes into, and how packages look. 3. When it breaks, he is the only person affected by any breakage (aka there aren't 4000 developers trying to build other things at the same time). In many ways I think that the first 2 items are the core to making modularity work anywhere. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Announcing fmt library soversion bump
On Wed, 28 Jun 2023 at 04:20, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 28/06/2023 08:32, Vitaly Zaitsev wrote: > > How I can fix that? > > Steps how to fix such issues for historical purposes: > > 1. Create a new side tag. > 2. Introduce compatibility fmt9 package. > 3. Build fmt9 compatibility package. > 4. Build fmt 10. > 5. Rebuild dnf5 against fmt 10. > 6. Untag fmt9 from this side tag. > 7. Retire fmt9 compatibility package. > Thanks for documenting this for other people to find in the future. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
On Thu, 29 Jun 2023 at 10:48, Bastien Nocera wrote: > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. > > 1. Thank you for all the work you have done on these and other packages in Fedora. The Bluetooth stack is not easy. 2. Thank you for announcing this early and allowing a quick transfer. 3. Good luck with the new team, they are lucky to have you. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On Fri, 30 Jun 2023 at 11:39, Ian Pilcher wrote:
> On 6/30/23 10:22, Jonathan Wakely wrote:
> > On Mon, 26 Jun 2023 at 19:10, Miro Hrončok wrote:
> >> We would also need to ensure UTC work even without tzdata installed.
> >
> > Yes, that would be useful.
> >
> > Although IMHO even that seems like a nice-to-have not an absolute
> > showstopper. Most containerized workloads that don't need time zone
> > info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
> > they're probably not using ZoneInfo at all.
> >
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the
> upstream
> >> window for changes like this has already closed for Python 3.12.
>
> Rather than expecting runtimes and applications to be fixed to work
> without any timezone information, perhaps the best way forward would be
> to create a tzdata-utc (and similar Java and Python packages).
>
> (Sorry if this has already been suggested & rejected. I don't remember
> seeing it in this thread, but ...)
>
>
I have not seen it and I think it is probably the best way to deal with
this. Going from how many sysadmin tasks I have dealt with where tzdata is
broken on a system.. a LOT of existing code being used in a lot of places
is silently relying on it.. usually in ways where you end up with a bad
crash long after startup, etc. A bare set of whatever fulfills utc and/or
defaults from LANG=C would at least get them working.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On Fri, 30 Jun 2023 at 11:50, Jonathan Wakely wrote: > On Fri, 30 Jun 2023 at 16:38, Ian Pilcher wrote: > > Rather than expecting runtimes and applications to be fixed to work > > without any timezone information, perhaps the best way forward would be > > to create a tzdata-utc (and similar Java and Python packages). > > > > (Sorry if this has already been suggested & rejected. I don't remember > > seeing it in this thread, but ...) > > From the change proposal: > > == Feedback == > In June of 2021, we proposed creating a new tzdata sub-package that > would only provide the UTC timezone. As part of the discussion around > this proposal, it was recommended that we completely remove tzdata. We > appreciated this input and welcome additional feedback. > > Thanks, I have enrolled in a basic reading and comprehension program since I missed this twice on read-through. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
On Sat, 3 Dec 2022 at 11:55, Neal Gompa wrote: > On Sat, Dec 3, 2022 at 11:25 AM Sérgio Basto wrote: > > > > On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote: > > > On 03/12/2022 00:30, Sérgio Basto wrote: > > > > The proposal now is to keep ImageMagick 6 and make a new package > > > > with > > > > ImageMagick 7 , when we have all applications use only ImageMagick > > > > 7, > > > > we move the sources from ImageMagick7 to ImageMagick > > > > > > I think it would be better to update the ImageMagick package to > > > version > > > 7 and create a compatibility package ImageMagick6. > > > > Anyone is going to review the package or not ? > > > > I already explain the situation in the other emails on this thread . > > > > I estimate that I will need about 200 hours to do what your brilliants > > minds ask . > > > > Really? "200 hours"? Not a chance. Upgrading ImageMagick to v7 and > Patches please, Neal to help Sergio cut it down then. He is saying he needs that time to make it work for all the problems he is seeing. Your commentary and others are coming across as lambasting him when he is wanting help. While your and other comments seem clear to you.. code would be clearer. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
On Mon, 5 Dec 2022 at 06:45, Terry Barnaby wrote: > Hi, > > With the latest release of Fedora37 we were hit with an issue where the > ncurses-compat-libs > RPM had been depreciated. Due to this some of the tools we use would no > longer install from their respective RPM's or their tar based installs > would not run as they needed the libncurses*5.so shared libraries. > > We use a number of software packages for Electronics and Software > development, some of which are developed by organisations and companies > outside of Fedora. This includes things like ARM GCC compilers, FPGA > compilers, PCB tools, manufacturers utilities etc. Many of these are built > for Redhat7, being a good general and stable base Linux system for these > companies/organisations to target. There are a few shared libraries that > are commonly used and ncurses is one of these. > > I am wondering what Fedora's policy is on depreciated old shared libraries > and particularly compat RPM's ? > > The policy is that if there are packagers who are actively going to be able to maintain the code, AND the code can be built with the current tools in the build system, it is kept. If the packagers want it but the code can't be built, then it is removed. If the packagers don't want it but the code could still be built, it is still removed. Sometimes the packager isn't willing anymore because they don't need it anymore in their work. Other times it is because they asked on a list and no one answered. Or a dozen other reasons. Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29 weeks. Getting code to compile for it on newer OS's is harder and packagers volunteer time is limited. > If there isn't one, for the benefit of users and making Fedora OS more > generally useful, can I suggest that relatively often used compat RPMS are > kept available at least while a major base system such as Redhat7 is still > widely used as a build platform for external companies/organisations and/or > perhaps for at least 15? years (or some defined time) after they become > compat RPM's ? > > Terry > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
On Mon, 5 Dec 2022 at 08:56, Florian Weimer wrote: > * Stephen Smoogen: > > > Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29 > > weeks. Getting code to compile for it on newer OS's is harder and > > packagers volunteer time is limited. > > For official information on support life-cycles, please consider this > official resource: > > Red Hat Enterprise Linux Life Cycle > <https://access.redhat.com/support/policy/updates/errata/> > > In particular the “Life-cycle Dates” page. > > I was going from Maintenance SupportRed Hat Enterprise Linux VersionGeneral availabilityFull support endsMaintenance Support 1 endsMaintenance Support or Maintenance Support 2 endsExtended life cycle support (ELS) add-on endsExtended life phase endsFinal minor release 7 June 10, 2014 August 6, 2019 August 6, 2020 June 30, 2024 June 30, 2026 Ongoing 7.9 While there is ELS going to 2026, that is an additional contract outside of general service. > Thanks, > Florian > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora/CentOS planned outage 2022-12-08 19:00 UTC
lanned Outage - IAD2 Outage - 2022-12-08 19:00 UTC There will be an outage starting at 2022-12-08 19:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2022-12-08 19:00 UTC' Reason for outage: There will be a multi hour outage as a hardware firewall is changed out of the IAD2 data center where most Fedora systems are housed. Outages should be in short cycles as the firewall is changed over to new hardware and rules are tested and confirmed. Affected Services: Most Fedora and CentOS Services will be affected Build systems for s390x will need to be restarted as NFS will break Builds in CentOS Stream and other infrastructure will be blocked during this time. Ticket Link: https://pagure.io/fedora-infrastructure/issue/ Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
On Tue, 6 Dec 2022 at 13:50, Josh Boyer wrote: > On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa wrote: > > > > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer > wrote: > > > > > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby > wrote: > > > > > > > > On 05/12/2022 16:00, Jarek Prokop wrote: > > > > > > > > > > > > On 12/5/22 14:57, Peter Robinson wrote: > > > > > > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel > > > > wrote: > > > > I wouldn't expect them to build for a Fedora version. I also wouldn't > > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to > > > work on Fedora either. > > > > > > > As a practical matter, I generally *do* expect them to be compatible > > at some level. RHEL is a derivative of Fedora. Otherwise it gets very > > difficult to use commercial software on a Fedora system. I know plenty > > of ISVs that have a similar expectation. > > That compatibility degrades over time though. At this point in time, > with RHEL 7 being almost 9 years old, I would not expect software > built on RHEL 7 to work on any supported Fedora version. If it does > work, that's fantastic and a testament to Fedora, but people should > not have that expectation. Terry is politely asking for a policy that > would set that expectation. I think the intention is good, but I > don't believe it to be realistic. > > I think he would be happy with the policy spelled out in any form. Something like: While the Fedora Project is the upstream of CentOS Stream and Red Hat Enterprise Linux, it does not give any guarantees of its releases being compatible with either. Software built in either may not work due to missing dependencies, changes in kernel, compile time or library options, or similar issues. > To perhaps illustrate the point further, Red Hat Enterprise Linux does > not support applications built on version X-1 running on X unless it > is constrained to using a very very small set of dependencies (glibc, > libgcc/libstdc++, and a few smaller libraries). Again, it may work > fine but the expectation and support policies set for RHEL are > (simplified) build on X, run on X where X is within a major version. > Our full documentation on this is available in the Application > Compatibility Guides. > > josh > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora/CentOS planned outage 2022-12-08 19:00 UTC
Due to some issues, this "lanned" outage has to be delayed to 2022-12-13 at the same time. On Mon, 5 Dec 2022 at 10:14, Stephen Smoogen wrote: > > lanned Outage - IAD2 Outage - 2022-12-13 19:00 UTC > > There will be an outage starting at 2022-12-13 19:00 UTC, > which will last approximately 4 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2022-12-13 19:00 UTC' > > Reason for outage: > > There will be a multi hour outage as a hardware firewall is changed out of > the IAD2 data center where most Fedora systems are housed. Outages should > be in short cycles as the firewall is changed over to new hardware and > rules are tested and confirmed. > > Affected Services: > > Most Fedora and CentOS Services will be affected > Build systems for s390x will need to be restarted as NFS will break > Builds in CentOS Stream and other infrastructure will be blocked during > this time. > > Ticket Link: > > https://pagure.io/fedora-infrastructure/issue/11031 > > Please join #fedora-admin or #fedora-noc on irc.libera.chat > or add comments to the ticket for this outage above. > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
On Wed, 7 Dec 2022 at 15:45, Terry Barnaby wrote: > On 06/12/2022 20:21, Josh Boyer wrote: > > On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen > wrote: > >> > >> > >>> > >> I think he would be happy with the policy spelled out in any form. > Something like: > >> > >> While the Fedora Project is the upstream of CentOS Stream and Red Hat > Enterprise Linux, it does not give any guarantees of its releases being > compatible with either. Software built in either may not work due to > missing dependencies, changes in kernel, compile time or library options, > or similar issues. > > Ah! Yes, making that clear would be good. > > As a guideline that sound a bit woolly to me and doesn't sound useful to > maintainers. As an rough idea either: > > While the Fedora Project is the upstream of CentOS Stream and Red Hat > Enterprise Linux it does not attempt to provide any compatibility with any > major current and past versions of Red Hat Enterprise Linux (currently 7, > 8, 9) or any other Linux distribution. Software binaries built for these > generic systems may or may not work. > > or > > The Fedora project attempts to provide a small degree of binary program > compatibility by means of compat libraries for the major current and past > versions of Red Hat Enterprise Linux (currently 7, 8, 9) and the past 2 > releases of Fedora only for reasonably some well used (by means of user > feed back) external/commercial applications for 2 years after their > publication date where this is easy of achieve as simple compat shared > library additions and the maintainers of the required packages are willing > to provide such packages. > > > That's probably a bit much for some, but some watered down derivative :) > Having a degree of binary compatibility aids external/commercial producers > and makes Fedora more useful to more people. > Just my view. > > The first would be more likely to be accepted over the second. The second requires packagers to actually test binaries from these other operating systems, and that is extra work for volunteers. Fedora is a stone soup project. If people want software to be in the operating system, they have to bring it and keep it working themselves. Once it is in, people will try to help out when they can, but time resources to use stuff outside of what they normally do is usually not wanted. There are probably 8 people who are paid to work 'full-time' on Fedora, and most of their work is just keeping the build systems going. Everyone else is a volunteer or paid to work on it after everything else they have done is finished. > Actually is there some mechanism that Fedora could work out how many are > using compat RPM's ? > I guess this would require some system used by mirrors that would report > back number of downloads of each package. Obviously this wouldn't get > everything (we have a cache of packages that we user across systems to > reduce downloads across the Internet), but might give some metrics to > automate such things. > No, there is no method to see what software is installed or used on workstation systems. The community has been overall very adverse to wanting that, and when we had some software which did act as a 'this is what is used' actively filled its database full of crap data. Attempts to add things like 'popcorn' and such usually end with long legal discussions and promises to revisit filling out crap data. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
#x27;work'* is to ship a minimal set of drivers for some 'chosen' hardware and then you have a bloated kitchen-sink iso which has all the drivers in it. The chosen hardware could be a 'defined' virtual environment which needs a minimal set of firmware, languages, etc. Everything else can be done in the install for getting languages, extra firmware, etc. The kitchen-sink.iso is going to be one which we know is going to be large. Now I have doubled the QA, releng, and product work.. I would say we would focus most of the work on the mini-installer, but we all know that all the work will be in the kitchen-sink one. * for some small definition of 'work' -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Starting Flatpak SIG
On Thu, 8 Dec 2022 at 13:00, Maxwell G via devel < devel@lists.fedoraproject.org> wrote: > On Thu Dec 8, 2022 at 17:29 +, Timothée Ravier wrote: > > > Do we need a mailing list? My initial gut feeling is no, but I'm > > > interested in what other people think. > > > > I think we don't. Tracking conversations and issues is much easier with > a tracker than mailing lists. > > I think it's helpful to have a mailing list for discussion and leave the > issue tracker for tracking bugs/RFEs or other work that's already agreed > upon. > Going from history, let us start getting people actually interested and showing up to see what might be done. Then we can look at mailing lists and other communication methods to help track things like builds, bugs, and such. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Starting Flatpak SIG
On Thu, 8 Dec 2022 at 14:39, Onuralp SEZER wrote: > Hello Kalev, > Please see pagure IRC is place for new channels and etc : > https://pagure.io/irc (that is a better place for track IRC stuff as > well) > > My apologies.. I sent Kalev to the wrong place. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora/CentOS planned outage 2022-12-08 19:00 UTC
On Wed, 7 Dec 2022 at 11:37, Stephen Smoogen wrote: > > Due to some issues, this "lanned" outage has to be delayed to 2022-12-13 > at the same time. > > Due to additional timing issues, the planned outage has been moved to 2023-01-10 at the same time. Updates and more information will be added to https://pagure.io/fedora-infrastructure/issue/11031 > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: copr and centos9 ?
On Wed, 21 Dec 2022 at 11:05, Michael J Gruber wrote: > > The devel package are not included in CentOS repositories unless > requested > > Yes, but Mark reports that his package builds "with EPEL, but not with > CentOS". As for as I know, we have the following in copr: > > chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL > chroot "centos stream 9" has base CentOS Stream 9 and repos > base+AppStream+Extras+CRB > > So, where do the devel packages in Mark's build come from? They can't be > in EPEL if the lib is in RHEL. > > Also: What is the "devel" repo mentioned in the centos FAQ, i.e. what is > the proper dnf repo name and which copr chroot uses it? Every time I think > I figured out the EL landscape it gets more complex ... > The devel repo was something that was meant to be a stop-gap for packages needed for EPEL early on. It no longer exists and should be removed from the FAQ. I don't see any scotch package in RHEL-9, CentOS Stream-9, OR EPEL-9 repositories. I don't know how this build was working previously. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: copr and centos9 ?
On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote: > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > > this: > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > I was mistaken about it working with epel-9. It also fails to load > > there. So I guess my question has now evolved to "what replaces > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > dnf --enablerepo=crb install librepo-devel > No. I do not think that will not work as a replacement. scotch is used for graph functions and not 'librepo'. The package scotch and related packages are NOT in EL9, and nothing 'replaces' them. Instead someone will need to build them for either the COPR project they are using or EPEL. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: copr and centos9 ?
On Wed, 21 Dec 2022 at 12:32, Mark Olesen wrote: > Yup, scotch doesn't seem to be in CBR either. > Doesn't even seem to be a metis library anymore either. This all seems > to be a bit odd - how do people manage domain decomposition without > metis, or scotch (and ptscotch)? Or is it expected that we should be > rolling this thirdparty software into our own builds? > Not bellyaching, just don't understand the roadmap here. > > To answer the first question about 'domain decomposition'.. I don't think it is something that 'most' or 'many' customers deal with. The fact that the software was only in 'Code Ready Builder' in EL8 means that it came with 'low' update/support mainly because it had been a build requirement of some other software in BaseOS or Appstream. The fact that it isn't in EL9 says that build requirement no longer exists and so the package was not needed to be built at all. In that case, the usual method is 'build it yourself' or 'work with others to build it in a 3rd party repository' like EPEL or similar ones. The reasons for software not being in future RHEL is usually a split thing.. There are customers who want a specific version in RHEL and there are customers who do not unless because it is not the version they wanted. That usually makes the choice toward not including something because then no one is equally unhappy. > /mark > > On 12/21/22 18:11, Stephen Smoogen wrote: > > > > > > On Wed, 21 Dec 2022 at 12:03, Sérgio Basto > <mailto:ser...@serjux.com>> wrote: > > > > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > > Checking my copr log, it seems that centos-stream-8 (and epel-8) > has > > > this: > > > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > > > I was mistaken about it working with epel-9. It also fails to load > > > there. So I guess my question has now evolved to "what replaces > > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > > > dnf --enablerepo=crb install librepo-devel > > > > > > No. I do not think that will not work as a replacement. scotch is used > > for graph functions and not 'librepo'. > > > > The package scotch and related packages are NOT in EL9, and nothing > > 'replaces' them. Instead someone will need to build them for either the > > COPR project they are using or EPEL. > > > > -- > > Stephen Smoogen, Red Hat Automotive > > Let us be kind to one another, for most of us are fighting a hard > > battle. -- Ian MacClaren > > -- > Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services ESI > Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 > 9710 149 | mark.ole...@esi-group.com www.openfoam.com | > www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de > Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas Renner > Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 > USt.-IdNr.: DE113842129 > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, 22 Dec 2022 at 10:24, Elizabeth K. Joseph wrote: > > This might not be as niche as you might think. I'm one of the > > Linux kernel maintainers for s390. Many of us do the vast majority of > > their development work natively on s390 systems via SSH from Fedora > > laptops. > > I first wanted to echo and confirm what Niklas says here. > > The crux of this issue seems to be "the code in the X server that does > this is virtually untested" so would more attention being paid to this code > help? I can't make any promises, but it would be valuable to know if this, > or something else, is needed. I will also bring this to the attention of > the Open Mainframe Project Linux Distributions Working Group, since all of > the distros use this byte-swapped code. > The people I learned coding and how to break code in the 80's always looked at byte-swapping in any project for problems. Most of the code was usually cargo culted from other projects or some sci.comp newsgroup. It might work but it would usually then be plastered in with fragile code or you would find that something 3 or 4 layers up broke. Currently there is only one byte-swapped architecture which Fedora runs on. There are about 82 Fedora instances on it and ~900 instances using EPEL. However, I think this request is coming more from the current maintainers of X. They also do not have ready access to byte-swapped systems so have no way to say 'oh this works' or not. I think X and other code fixed to deal with byte-swapping is going to need focus as I expect this change will 'filter' into other operating systems over time. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, 28 Dec 2022 at 08:45, Peter Boy wrote: > > > > Am 28.12.2022 um 13:00 schrieb Ralf Corsépius : > > > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > >> It is a good idea to make the timeout configurable. But the default > timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > for no obvious reasons. > > Yes, but instead of just „pulling the plug“ wouldn’t it be better to hunt > for the reasons? > > Most of the time, system administrators don't have time to hunt for the reasons because something else is going to happen (like a UPS dropping power) or a dozen other things. And once that is fixed the server is going to stay up until the next major crap I need to have everything rebooted/off in an outage window. Theoretically this testing should be done in in a staging environment, but I have only seen 3 places in 40 years with any time or ability to do so. Most of the places I have worked have had 'staging' environments which are really spare parts for production or actually in some level of production for other departments to 'stage' their code. I think 30 seconds is going to be a better fit for most services. Ones which need a longer time can override it in their service files and those will be easier to find. > > > And as you asked: On my (bare metal) servers, Im am occasionally > experiencing delayed shutdowns in the order of several minutes. > > > > This is simply inacceptable! > > Yes, but then always simply pulling the plug is not acceptable either, I > think. > > > > -- > Peter Boy > https://fedoraproject.org/wiki/User:Pboy > p...@fedoraproject.org > > Timezone: CET (UTC+1) / CEST (UTC+2) > > > Fedora Server Edition Working Group member > Fedora docs team contributor > Java developer and enthusiast > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > tl;dr: you want to fix changelog entries. That's supported by saving the > > generated changelog to 'changelog' file and doing whatever edits you want > > there. > > > > With that approach, you can do arbitrary formatting and fixups. The > > advantage compared to status quo (non-autochangelog) is that you only > need > > to do it if the autogenerated changelog is deficient for whatever > reasons. > > In the default case you can use autochangelog, and fall back to the > manual > > version when necessary. > [snip] > > Rpmautospec allows you to have a part or parts of a commit message that > > end up in the changelog, and parts that do not, see > > > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages > > All in all a very complicated and error-prone process just to save some > extremely lazy packagers a 5-second copy&paste. I really do not see why > that > should be the default and recommended process. > > The rules how to format the commit message are error-prone, and if you get > them wrong, you usually only notice when it is too late to fix it (because > force-pushes are not allowed). Yes, you can manually run "rpmautospec > generate-changelog", but that is actually no less effort than just taking > care of the changelog manually to begin with. > My main questions are what is this supposed to fix long term? I have guessed that it has to do with automation, the shrinking number of active packagers in operating systems, and the exploding number of packages in requested languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say "HOW" this gets to dealing with this long term. It also isn't clear what the underlying remaining active packagers want to be part of. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote: > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote: > > > - fedpkg mockbuild > > > > But it doesn't work correctly (will always use Release: 1) if you run > > "rpmbuild -bs foo-bar.spec" which is a very common scenario. > > "Doctor, it hurts when I do that." > > 'rpmbuild -bs' is broken. Don't use it. > > Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so] -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: old llvm/clang (14.0.6) in current epel9 build system while mock build has new version of clang/llvm (15.0.1)
On Tue, 3 Jan 2023 at 07:55, Than Ngo wrote: > Hi, > > our current build system for epel9 contains old version (14.0.6) of > llvm/clang while mock build has the new version of clang/llvm (15.0.1). > there is bug in llvm 14.0.6 that causes linking error when building > chromium. The bug was fixed in llvm-15.x. > > The EPEL build system has been pushed to the CDN for RHEL9 which is currently 14.0.6. Is your mock build using the CDN or somehow using either CentOS Stream 9 or some other package set? You will either need to: 1. Wait until LLVM-15 is released for RHEL-9 (which looks like 9.2 in October/November) 2. Aim your builds at epel-next so it is using the CentOS Stream 9 packages 3. Work with whatever team 'owns' llvm and see if they can get a fix out to the 9.1 stream 4. something else? > Is it possible to get new version of llvm/clang (15.0.1) in build system > for epel9? > > Than > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Tue, 3 Jan 2023 at 08:14, Stephen Smoogen wrote: > > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > >> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote: >> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote: >> > > - fedpkg mockbuild >> > >> > But it doesn't work correctly (will always use Release: 1) if you run >> > "rpmbuild -bs foo-bar.spec" which is a very common scenario. >> >> "Doctor, it hurts when I do that." >> >> 'rpmbuild -bs' is broken. Don't use it. >> >> > Could you please elucidate why the command that people have used for > nearly 30 years and is the most documented on how to build rpms is broken? > And how people should use instead when they may be dealing with an > environment which doesn't allow fedpkg to work? [AKA I am working on a > package which I want to submit for review so I need to build a @$@$% src > RPM somehow and I am being told I can't use the built in command to do so] > > > OK I have started off the year with a cranky email. My apologies for that as I should have gone back to read the context which this was being said in. [I am usually all for removing extra stuff from an email to make it short and sweet, and then go read what I might have missed.. however in this case I didn't and just barked like a mad dog.] > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, 5 Jan 2023 at 08:20, David Cantrell wrote: > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > [...] > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > We don't have ppc64 builds anymore and I don't know the last release > we had > > > that was ppc64, but it was a long time ago now. All current POWER > systems are > > > ppc64le. > > > > > > And everything else we have as primary or alternative architectures is > little > > > endian, except s390x. I do view this as a risk for s390x because of > all the > > > architectures we build for, this one is the most difficult to use > graphically. > > > Exporting your display is still the convenient method for this > platform. > > > > > > Given that this change proposal affects default behavior, I don't see a > > > problem with it. s390x users can drop the configuration change in > xorg.conf.d > > > to regain the functionality. If that can be conditionally enabled for > s390x > > > at package build time, that might make things easier (but wouldn't you > need to > > > make the change on both the s390x host and your non-s390x > workstation?). > > > > The X protocol works that the first byte of the connection request is a > > either 'l' or 'B', telling the server that the client is little or Big > > endian. The client has no information on the server's endianess. > > > > This means the configuration needs to be done wherever your X server > > runs, so the (little-endian) thing you're sitting in front of. Which is > > also why compile-time defaults are difficult, at compile time we cannot > > know that eventually you may want to connect from an s390x. > > Reasonable. The runtime configuration change I can make locally to allow > me > to run X programs on an s390x and display them locally is sufficient for > me. > Wasn't there a concern that you can do this if you are running a desktop with X, but if you are using Xwayland it isn't easy (or maybe possible) as the configuration to do that was either hardcoded or not fully documented on how to do that? >From Peter Hutterer earlier: ``` but you don't necessarily have access to how Xwayland is started (mutter certainly is hard-coded). ``` -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On Tue, 10 Jan 2023 at 11:55, Stuart S wrote: > I've just tried this for Fed 35 >> Fed 37 > > Got the following errors > > Problem: conflicting requests > - nothing provides module(platform:f35) needed by module > php:remi-7.4:20230104141955:.x86_64 > You have an outside module installed on the system. Going from the name I would expect it is the remi PHP ones. You will need to disable that module and/or replace it with the f37 one to get things going. > Error: > Problem 1: package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 > requires php(api) = 20190902-64, but none of the providers can be installed > - package php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 requires > php(zend-abi) = 20190902-64, but none of the providers can be installed > - php-common-7.4.33-2.fc35.remi.x86_64 does not belong to a distupgrade > repository > - problem with installed package > php-pecl-imagick-im6-3.7.0-1.fc35.remi.7.4.x86_64 > Problem 2: package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires > libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers > can be installed > - package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 requires > qt5-qtbase(x86-64) = 5.15.2, but none of the providers can be installed > - qt5-qtbase-5.15.2-31.fc35.x86_64 does not belong to a distupgrade > repository > - problem with installed package qt5-qtenginio-1:1.6.2-36.fc35.x86_64 > (try to add '--skip-broken' to skip uninstallable packages) > > > I know this is not a help page but can someone point me in right direction > as I can't find it... > > Cheers > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Porting Fedora for the LoongArch architecture.
On Tue, 10 Jan 2023 at 17:37, Richard W.M. Jones wrote: > Hi, > > ... clipped as I want to focus on this part. > (4) As another reply mentioned, to get LoongArch as a primary Fedora > architecture, an essential requirement is 19" rackable server-class > hardware. It needs to be fully manageable through a BMC. Fedora will > probably need a few such servers to be donated. > > This is usually the major hanging point for bringing up it as a 'main' OS. I am going to outline in depth what it takes from an operational side to get any new 'deliverable' into Fedora currently. I am not doing so to say 'this can't be done' as much as to explain why it can't usually be done at the speed most people seem to think can be done. The complete Fedora koji build system has a lot of assumptions of being in the same datacenter with just one set of hardware remote and 'breaking' regularly due to that (mounts are being done over NFS over ssh and disconnect regularly.. connections between the main DC and other places may time out etc.). The build system is generally locked together so that if one architecture has slowness/problems it affects all builds on the other arches. Adding more architectures to this tends to add a non-linear complexity in places. [The opposite of having multiple koji's adds a different level of complexity and requires more dedicated people time which is in even shorter supply.] The main DC is in the continental United States and in a 'lights' out facility (aka there are no hands in the facility regularly). This means that the hardware needs to be able to be managed remotely and be redundant so that it can 'work' in a degraded shape for weeks until replacements can be reached. There is no 'lab' for fixing equipment so the parts generally need to have a dedicated tech to fix. [Practically this means the hardware in the facility needs to be rated and insurable for this sort of data-center. Certain hardware is rated only for 'labs' or places where someone can unplug quickly if it smokes.. this is not that kind of place.] The next issue is space to put more equipment into this facility. Pretty much every build architecture takes at least 1 full sized rack for the number of systems needed to keep up with builds. That requires additional planning as the space used is shared between multiple groups and may not be possible to add in quickly (or at all). Other solutions are possible but would require additional work and time. There are also the requirements for additional NFS storage, power, etc etc that each deliverable requires. Those all need to be added, budgeted for and purchased. [What has happened several times to slow things down is that it wasn't ordered/budgeted/purchased/put-in-place.. and well 6-12 months got lost making it happen.] That all sounds like a lot of 'no' wrapped up in a 'it depends', but it can be done. In general it can be a 2-5 year process from when someone says 'Hey wouldn't it be great to build X' to getting the 'factory' built and working with the rest of the build system. During that time, usually a secondary external build system may be built elsewhere using shadow-koji or some other build tools to keep up and work out a lot of the bugs in the many parts of the build system (bodhi, koji, pungi, odcs, osbs, git, bugzilla, messaging system, pdc, mbs, oci, signing-infra, qa, koschei, and various things which are containers that affected/are affected by any build). Doing that allows for the eventual infusion of the arch into the main Fedora to take weeks versus months/year. > This is the main reason why RISC-V isn't a primary Fedora architecture > yet, although progress is happening. > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automation of Fedora SCM requests
On Thu, 12 Jan 2023 at 09:27, Jonathan Wright via devel < devel@lists.fedoraproject.org> wrote: > Just got the following error: > https://pagure.io/releng/fedora-scm-requests/issue/50417 > > I'm pretty sure I've always requested branches as someone with "commit" > access and never had them rejected. > > So what I think is being exposed is more of the 'errors/problems' that whoever was doing this in releng ran into at times. Hopefully this will allow for work on getting the lower level issues fixed or replaced. > On Thu, Jan 12, 2023 at 3:30 AM Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: > >> On Wednesday, 11 January 2023 at 17:13, Michal Konecny wrote: >> > Hi everyone, >> > >> > all the remaining issues were solved and the bot is now processing >> > tickets as it should. I will watch the SCM request repository for next >> > few days to see if everything is working as it should. >> > Thanks for your patience. >> >> Thank you Michal and the CPE Team. Automating this part is a very >> welcome improvement. >> >> Regards, >> Dominik >> -- >> Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org >> There should be a science of discontent. People need hard times and >> oppression to develop psychic muscles. >> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > > > -- > Jonathan Wright > AlmaLinux Foundation > Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HyperKitty: Thread tree broken?
On Thu, 12 Jan 2023 at 11:34, Jun Aruga (he / him) wrote: > I see one issue on HyperKitty on the Fedora project. > > Below is thread 1 and 2 for the actual thread: "RISC-V -- are we ready > for more, and what do we need to do it?" Do you know why it's not one > thread page? > > 1. > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z2RR2OE5TAQH5CVJ5VB5T3R7OM5ULYPQ/#QZUTH6DSULKYBMGPPYNZMPX7YSYKOBTT > 2. > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL/#2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL > > It seems that the Message-ID header's value of the almost last email: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QZ5WZ33D2NZXR4O447WD3ELV2BTC5VJY/ > is referred to by the following email by the References header's value. > > And do you know where I can report this issue related to the > HyperKitty running on the Fedora Project? > > The hyperkitty running on Fedora Project is 'dead' code in the sense it is an ancient branch with changes which were either not upstreamed or reinvented there. It needs a complete redo and fixing but that requires dedicated resources in the form of several python engineers and sysadmins. You should probably report it to Fedora infrastructure, as it can help weigh it as something to focus more on in future time frames. > Thanks. > > -- > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for > the timezone. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -fno-omit-frame-pointer does not work as advertised
On Sun, 15 Jan 2023 at 03:33, Daniel Alley wrote: > > Hi, > > > > > Frame pointers sound like a simple solution to unwinding, but they are > not. > > They are no complete replacement for unwinding information. > > > > Kevin Kofler > > I don't think anyone ever argued that frame pointers were a complete > replacement for unwinding information. Maybe I missed that part of the > discussion? > I doubt that they did so in so many words, but it sure has felt that way with some of the conversations. I think that comes from the fact the arguments have gotten very heated and people aren't fully communicating facts as much as emotions. At this point, it doesn't matter. The changes will go into the mass rebuild, and we will see how many packages actually build, and how much work is needed to get the rest to work. After that we can get a beta out and see if the slowdowns are shattering. Then we will get a release out in April/May and call it Fedora 38. At which point we can really see if the slow downs are bad enough to make it 'unusable' or the data gotten by the changes are 'able to improve things'. People like me who are not happy about the way this change has been pushed through will either stay on F36/F37 until we are feeling things are improved, or moving to a different operating system for the time being. It happens, and is a good thing. I like to consider it self-imposed exile where I get to experience a different 'culture' of a different city-state's way of doing things (like an Athenian going to Corinth, Sparta, or some island city.) You then come back with new ideas on how to improve things and sometimes then end up being the next big change everyone in Fedora-Athens is unhappy with. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi slow with 504 gateway timeouts
On Tue, 17 Jan 2023 at 08:55, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 17, 2023 at 07:49:48AM -0600, Richard Shaw wrote: > > On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar wrote: > > > > > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a): > > > > Is anyone but me experiencing this? I want to know before I call C > Spire. > > > > > > > Since yesterday I randomly experience long delays between sending a > query > > > and > > > receiving the response. However, no HTTP errors. > > > > > > > I only got the timeout once, but it's been very slow and not properly > > loading completely. I'm trying bodhi command line for an update and > having > > similar issues but I think my update did finally get created though. > > > > One of the attempts from the command line it spit back HTML saying > > "Application is not available". > > Bodhi is slow for me. Some pages loaded slowly and without icons and > stuff. But > I also had timeouts on pagure.io today, so I was suspecting some network > issue. > > So bodhi and pagure are at different datacenters with hopefully different network paths. Could people do some mtr or traceroutes from their locations so we can see if this can be ironed out. Currently the limited tools we have in Fedora Infra for checking this all show 'green' so the 'interconnects' between the services are working. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bodhi slow with 504 gateway timeouts
On Tue, 17 Jan 2023 at 09:19, Arthur Bols wrote: > On 17/01/2023 14:57, Stephen Smoogen wrote: > > So bodhi and pagure are at different datacenters with hopefully different > > network paths. Could people do some mtr or traceroutes from their > locations > > so we can see if this can be ironed out. Currently the limited tools we > > have in Fedora Infra for checking this all show 'green' so the > > 'interconnects' between the services are working. > > > Fedora infra is usually very slow for me, but Bodhi seemed much slower > than usual (taking a full minute to load). > > After being really slow, I had a bunch of 503's (not 504) for a while, > but now it seems to work fine: > - /releases takes 10 seconds (and had a 500 error once) > - /updates seems fast with 2.2 seconds > > Please note that from other announcements bodhi was updated today to 7.0.1. The slowdowns may have been due to that. However I notice both you and Richard have large packet drops on twelve99.net ip addresses. I don't know yet if that is an additional problem or not. > > $ mtr bodhi.fedoraproject.org -r -G > Start: 2023-01-17T15:14:31+0100 > HOST: MarkV Loss% Snt Last Avg Best Wrst StDev >1.|-- ptr-82pqtg1hqu6kedca1n3.1 90.0%106.0 6.0 6.0 6.0 0.0 >2.|-- ptr-377wgf58htvrzp7oh0ch. 20.0%10 13.7 15.3 12.7 20.1 > 2.7 >3.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 >4.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 >5.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 >6.|-- 2001:730:2302::d52e:a209 0.0%10 16.3 18.0 13.1 24.9 > 3.5 >7.|-- 2001:730:2302:1::d52e:a20 0.0%10 17.9 17.4 13.4 20.4 > 2.7 >8.|-- prs-bb1-v6.ip.twelve99.ne 10.0%10 61.1 31.3 16.4 62.1 > 17.8 >9.|-- ash-bb2-v6.ip.twelve99.ne 0.0%10 105.2 108.7 104.0 > 118.7 5.0 > 10.|-- lax-b22-v6.ip.twelve99.ne 90.0%10 160.2 160.2 160.2 > 160.2 0.0 > 11.|-- a100-ic325183-las-b24.ip. 0.0%10 175.7 162.1 158.0 > 175.7 5.2 > 12.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 13.|-- 2620:107:4000:8006::1260.0%10 182.8 187.3 177.4 > 199.7 7.1 > 14.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 15.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 16.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 17.|-- 2620:107:4000:c5e0::f3fd: 0.0%10 188.3 188.2 182.0 > 192.4 2.8 > 18.|-- 2620:107:4000:a090::f000: 0.0%10 185.3 185.5 182.5 > 187.6 1.6 > 19.|-- 2620:107:4000:cfff::f200: 0.0%10 183.1 185.7 181.9 > 192.2 3.3 > 20.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 21.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 > 22.|-- 2620:107:4000:4205:8000:0 0.0%10 182.8 188.9 182.0 220.5 > 11.5 > 23.|-- 2600:1f14:fad:5c02:7c8a:7 0.0%10 188.2 187.1 180.4 > 210.5 8.5 > > > $ traceroute bodhi.fedoraproject.org > traceroute to bodhi.fedoraproject.org (8.43.85.67), 30 hops max, 60 byte > packets > 1 _gateway (192.168.0.1) 6.347 ms 10.770 ms 11.768 ms > 2 d51A4C401.access.telenet.be (81.164.196.1) 20.244 ms 22.376 ms > 22.311 ms > 3 * * * > 4 * * * > 5 be-dgb01a-rb1-ae-19-0.aorta.net (213.46.162.9) 23.660 ms 23.584 > ms 27.996 ms > 6 be-bru02a-ra1-vl-6.aorta.net (213.46.162.14) 29.026 ms 21.811 ms > 18.822 ms > 7 prs-bb1-link.ip.twelve99.net (62.115.116.238) 22.234 ms 19.546 ms > 25.043 ms > 8 ash-bb2-link.ip.twelve99.net (62.115.112.242) 116.324 ms 117.718 > ms 114.206 ms > 9 ash-b2-link.ip.twelve99.net (62.115.123.125) 117.633 ms 117.595 > ms 117.555 ms > 10 viawest-svc073699-ic361683.ip.twelve99-cust.net (213.248.67.199) > 117.473 ms 117.424 ms 117.385 ms > 11 be23.bbrt01.iad10.flexential.net (66.51.1.148) 129.400 ms 130.492 > ms 130.451 ms > 12 be209.bbrt02.ral01.flexential.net (66.51.5.117) 120.744 ms 120.705 > ms 120.597 ms > 13 * be32.crrt02.ral01.flexential.net (148.66.238.113) 119.944 ms > 122.230 ms > 14 128.136.224.140 (128.136.224.140) 112.075 ms 111.922 ms 110.807 ms > 15 8.43.84.1 (8.43.84.1) 176.779 ms 203.379 ms 205.480 ms > 16 8.43.84.3 (8.43.84.3) 122.495 ms 120.608 ms 122.398 ms > 17 8.43.84.4 (8.43.84.4) 215.289 ms 215.232 ms 211.599 ms > 18 ip-8-43-86-126.foo.bar (8.43.86.126) 124.226 ms 126.584 ms 142.354 ms > 19 proxy14.fedoraproject.org (8.43.85.67) 134.550 ms !X 116.964 ms > !X 121.806 ms !X > > > -- > Arthur Bols > fas/irc: principis > __
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Tue, 31 Jan 2023 at 03:37, Niklas Schnelle wrote: > On Thu, 2023-01-19 at 19:46 +1000, Peter Hutterer wrote: > > On Fri, Jan 06, 2023 at 11:13:14AM +1000, Peter Hutterer wrote: > > > On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote: > > > > On Thu, 5 Jan 2023 at 08:20, David Cantrell > wrote: > > > > > > > > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > > > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > > > > > [...] > > > > > > > > So I guess this means no remoting into ppc64 or s390x > machines from > > > > > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > > > > > > > > > We don't have ppc64 builds anymore and I don't know the last > release > > > > > we had > > > > > > > that was ppc64, but it was a long time ago now. All current > POWER > > > > > systems are > > > > > > > ppc64le. > > > > > > > > > > > > > > And everything else we have as primary or alternative > architectures is > > > > > little > > > > > > > endian, except s390x. I do view this as a risk for s390x > because of > > > > > all the > > > > > > > architectures we build for, this one is the most difficult to > use > > > > > graphically. > > > > > > > Exporting your display is still the convenient method for this > > > > > platform. > > > > > > > > > > > > > > Given that this change proposal affects default behavior, I > don't see a > > > > > > > problem with it. s390x users can drop the configuration > change in > > > > > xorg.conf.d > > > > > > > to regain the functionality. If that can be conditionally > enabled for > > > > > s390x > > > > > > > at package build time, that might make things easier (but > wouldn't you > > > > > need to > > > > > > > make the change on both the s390x host and your non-s390x > > > > > workstation?). > > > > > > > > > > > > The X protocol works that the first byte of the connection > request is a > > > > > > either 'l' or 'B', telling the server that the client is little > or Big > > > > > > endian. The client has no information on the server's endianess. > > > > > > > > > > > > This means the configuration needs to be done wherever your X > server > > > > > > runs, so the (little-endian) thing you're sitting in front of. > Which is > > > > > > also why compile-time defaults are difficult, at compile time we > cannot > > > > > > know that eventually you may want to connect from an s390x. > > > > > > > > > > Reasonable. The runtime configuration change I can make locally > to allow > > > > > me > > > > > to run X programs on an s390x and display them locally is > sufficient for > > > > > me. > > > > > > > > > > > > > Wasn't there a concern that you can do this if you are running a > desktop > > > > with X, but if you are using Xwayland it isn't easy (or maybe > possible) as > > > > the configuration to do that was either hardcoded or not fully > documented > > > > on how to do that? > > > > > > > > From Peter Hutterer earlier: > > > > ``` > > > > but you don't necessarily have > > > > access to how Xwayland is started (mutter certainly is hard-coded). > > > > ``` > > > > > > Correct, the Wayland compositor is responsible for starting up XWayland > > > and that's not always configurable. I've filed bugs for mutter, kwin > and > > > wlroots so the developers are aware and that should cover the majority > > > of Wayland use-cases once fixed. > > > > just a minor follow-up: mutter has that feature merged now for GNOME 43 > > [1] so a once-off gsettings call should do the trick there: > > > > $ gsettings set org.gnome.mutter.wayland > xwayland-allow-byte-swapped-clients true > > > > Cheers, > > Peter > > > Thanks for opening the BZs and creating these settings. So, this means > at le
Re: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases
On Tue, 7 Feb 2023 at 07:38, Dan Čermák wrote: > Hi Lokesh, > > Lokesh Mandvekar writes: > > > Hi, > > > > We (podman upstream and fedora maintainers) are hoping to disable i686 > > and 32-bit arm builds for Podman and some related tools under > > https://github.com/containers org. We would like to do this also for > > released Fedora versions, and not just the upcoming ones. > > > > What Fedora paperwork do we need in place to get this going? > > I would suggest to file a self-contained change proposal to get some > visibility for this change in the official release notes. But afaik all > you have to do is to define `ExclusiveArch:` or `ExcludeArch:` in your > spec file. > > Depending on where it might have been 'defined', it may need some fiddling in releng scripts or releng pungi. As part of the self-contained change proposal make sure you file the requisite releng ticket to make sure they are aware that the change will be happening, why it is happening (various software in the chain of dependencies compiles/works on 32 bit), and what parts will be affected. > > Hope this helps, > > Dan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Planned Outage - s390x builders - 2023-02-10 08:00 UTC -> 22:00 UTC
Planned Outage - s390x builders - 2023-02-10 08:00 UTC There will be an outage starting at 2023-02-11 08:00 UTC, which will last approximately 12 to 24 hours. Systems will be powered off and then power to the facility will be dropped. After electrical work is completed work on some network equipment may extend the outage due to a different planned outage. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-02-10 08:00UTC' Reason for outage: The facility that houses the Fedora s390x builders will be taking down power and network in order to troubleshoot current state and problems of the power infrastructure there. This data will hopefully allow fixes/solutions to make the power distribution there most robust and reliable. After power is restored, there are additional network upgrades and replacements which are planned to occur but have been delayed due to the other work. Affected Services: s390x koji builders. Jobs will queue up, but not be processed until the builders are back online. Maintainers are urged to just avoid submitting builds just before and during this outage. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11082 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
FIXED: Planned Outage - s390x builders - 2023-02-10 08:00 UTC
Planned Outage - s390x builders - 2023-02-10 08:00 UTC There will be an outage starting at 2023-02-10 08:00 UTC, which will last approximately 12 to 24 hours. Systems will be powered off and then power to the facility will be dropped. After electrical work is completed work on some network equipment may extend the outage due to a different planned outage. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-02-10 08:00UTC' Reason for outage: The facility that houses the Fedora s390x builders will be taking down power and network in order to troubleshoot current state and problems of the power infrastructure there. This data will hopefully allow fixes/solutions to make the power distribution there most robust and reliable. After power is restored, there are additional network upgrades and replacements which are planned to occur but have been delayed due to the other work. Affected Services: The s390x koji builders will be unavailable. This will cause nearly all rpmbuilds in koji to queue up until the s390x builders are back online. Maintainers are urged to just avoid submitting builds just before and during this outage. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11082 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TSS maintainer volunteer
On Fri, 10 Feb 2023 at 14:56, Simo Sorce wrote: > On Fri, 2023-02-10 at 19:49 +, Kenneth Goldman wrote: > > I would like to volunteer to maintain the two TSS packages in Fedora: > tss2, tss2-devel. > > > > I currently maintain the source. > > > > I would appreciate any tips on what steps I should take. > > I think you should contact the current maintainer first. > > The package tss2 is currently orphaned. I think that is why they are asking here. Keith, The first step you will need to do is create a Fedora account and working with a packager on how Fedora packages things up and getting packager status. tss2 and tss2-devel are built from the tss2 package https://src.fedoraproject.org/rpms/tss2 (that is the canonical place for the RPM spec file). > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
On Mon, 13 Feb 2023 at 11:28, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Kevin Kofler via devel wrote:
> > We need to be much stricter on size increases! In Fedora 9 (when the xz
> > compression for live images was introduced, which made it smaller than
> > Fedora 7 or 8), the x86_64 KDE Spin was 729272320 bytes.
>
> I have to correct myself: Fedora 9 was not where xz was introduced. The xz
> compression was introduced in Fedora 15. At that point, the x86_64 KDE
> Spin
> was 725614592 bytes (with more applications on it than in Fedora 9), and
> that was also the size in Fedora 17 in May 2012.
>
> > In Fedora 38 Branched, it is now 2418429952 bytes.
>
> So, in only 11 years, the live image size has grown by a factor of almost
> exactly 3⅓ (the exact ratio starts with: 3.3329…)!
>
>
I did a check on some.. I only downloaded 3 isos so this isn't a complete
set.
# Fedora KDE Live Sizes
Fedora-7-KDE-Live-x86_64.iso 2007-05-25 831M
Fedora-8-Live-KDE-x86_64.iso 2007-11-02 805M
Fedora-9-x86_64-Live-KDE.iso 2008-05-08 695M
F10-x86_64-Live-KDE.iso2008-11-19 684M
Fedora-11-x86_64-Live-KDE.iso 2009-06-04 693M
Fedora-12-x86_64-Live-KDE.iso 2009-11-09 685M
Fedora-13-x86_64-Live-KDE.iso 2010-05-13 700M
Fedora-14-x86_64-Live-KDE.iso 2010-10-21 687M
Fedora-15-x86_64-Live-KDE.iso 2011-05-13 692M 1064 pkgs 2.4 GB
uncompressed
Fedora-16-x86_64-Live-KDE.iso 2011-11-03 696M 1125 pkgs 2.7 GB ump
Fedora-17-x86_64-Live-KDE.iso 2012-05-22 692M
Fedora-18-x86_64-Live-KDE.iso 2013-01-09 831M
Fedora-Live-KDE-x86_64-19-1.iso2013-06-27 878M
Fedora-Live-KDE-x86_64-20-1.iso2013-12-12 928M
Fedora-Live-KDE-x86_64-21-5.iso2014-12-03 953M
Fedora-Live-KDE-x86_64-22-3.iso2015-05-21 1.1G
Fedora-Live-KDE-x86_64-23-10.iso 2015-10-29 1.2G
Fedora-KDE-Live-x86_64-24-1.2.iso 2016-06-14 1.3G
Fedora-KDE-Live-x86_64-25-1.3.iso 2016-11-15 1.3G
Fedora-KDE-Live-x86_64-26-1.5.iso 2017-07-05 1.4G
Fedora-KDE-Live-x86_64-27-1.6.iso 2017-11-05 1.5G
Fedora-KDE-Live-x86_64-28-1.1.iso 2018-04-25 1.8G
Fedora-KDE-Live-x86_64-29-1.2.iso 2018-10-25 1.8G
Fedora-KDE-Live-x86_64-30-1.2.iso 2019-04-26 1.8G
Fedora-KDE-Live-x86_64-31-1.9.iso 2019-10-23 1.7G
Fedora-KDE-Live-x86_64-32-1.6.iso 2020-04-22 1.8G
Fedora-KDE-Live-x86_64-33-1.2.iso 2020-10-19 1.8G 1705 pkgs 5.1 GB
Fedora-KDE-Live-x86_64-34-1.2.iso 2021-04-23 2.0G
Fedora-KDE-Live-x86_64-35-1.2.iso 2021-10-26 2.0G
Fedora-KDE-Live-x86_64-36-1.5.iso 2022-05-04 2.1G
The 20 largest packages on 15 is:
[root@ssmoogen-rh /]# rpm -qa --qf='%{SIZE} %{NAME}\n' | sort -n | tail -n
20
22089642 kdenetwork
22148990 kipi-plugins
23597199 amarok
23750667 hugin-base
23805685 kdeedu-marble
24864336 python-libs
25621700 PyKDE4
26997652 oxygen-icon-theme
2705 foomatic-db-ppds
28157021 opencv
28565722 digikam
29756278 mysql
32095877 kdebase-workspace
33988848 qt-x11
34693072 mesa-dri-drivers
43929551 mysql-server
44714663 perl
47397440 kdelibs
110104945 kernel
112442467 glibc-common
The 20 largest packages on 33 is:
32294003 libkdegames
32371175 python3-libs
34121537 libicu
38648170 qt-x11
39173022 mariadb
47955205 qt5-qtwebkit
60158710 webkit2gtk3
62712603 geolite2-city
68540278 mesa-dri-drivers
76958332 foomatic-db-ppds
77983261 kernel-core
84432783 gcc
87571216 llvm-libs
95909527 mariadb-server
115301235 iwl7260-firmware
136611853 google-noto-sans-cjk-ttc-fonts
165482197 qt5-qtwebengine
227552812 glibc-all-langpacks
271515808 firefox
286752620 linux-firmware
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
On Mon, 13 Feb 2023 at 13:56, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > I did a check on some.. I only downloaded 3 isos so this isn't a complete > > set. > > > > As for qt5-qtwebkit, I am not sure what dragged this in on F33. We have > been > trying to get rid of QtWebKit uses. I do not know yet what dragged this in > on F33 and whether that has been fixed since. > > The following is from the F38 image from last week? dnf remove qt5-qtwebengine Error: Problem: The operation would result in removing the following protected packages: plasma-desktop > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
On Mon, 13 Feb 2023 at 15:56, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > The following is from the F38 image from last week? > > > > dnf remove qt5-qtwebengine > > Error: > > Problem: The operation would result in removing the following protected > > packages: plasma-desktop > > QtWebEngine is the native web engine of the KDE desktop and the one that > should be there. (qt5-qtwebengine should eventually be replaced by > qt6-qtwebengine though, but we are not there yet.) The older QtWebKit is > what should be gone. > > My apologies. I should have double checked before sending. [root@fedora ~]# dnf remove qt5-qtwebkit-5.212.0-0.72alpha4.fc38.x86_64 Dependencies resolved. PackageArchitecture Version RepositorySize Removing: qt5-qtwebkit x86_64 5.212.0-0.72alpha4.fc38@anaconda 46 M Removing dependent packages: kaccounts-providersx86_6422.12.2-1.fc38 @anaconda384 k kio-gdrive x86_6422.12.2-1.fc38 @anaconda419 k kwebkitpartx86_64 1.4.0-0.13.20190110.fc38 @anaconda1.2 M Removing unused dependencies: kf5-kdewebkit x86_645.103.0-1.fc38 @anaconda213 k signon-ui x86_640.15-19.fc38 @anaconda293 k Transaction Summary ======== Remove 6 Packages -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openexr: Any s390x people in the house?
On Tue, 14 Feb 2023 at 08:21, Richard Shaw wrote: > I currently have to disable tests for s390x[1] (and ppc64le) for likely > endianess issues. > > Well if it is failing for the same reason on s390x (big endian) and ppc64le (little endian).. I don't think the problem is all about endian parts. > Troubleshooting these is more than a little outside of my wheelhouse. > > I hate keeping them disabled so I wanted to see if anyone could spare a > few cycles to investigate. > > Thanks, > Richard > > [1] https://github.com/AcademySoftwareFoundation/openexr/issues/1175 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Thu, 16 Feb 2023 at 05:56, Richard W.M. Jones wrote: > On Wed, Feb 15, 2023 at 02:02:54PM -0500, Ben Cotton wrote: > > In accordance with FESCo's Inactive Packager Policy[1], packagers that > > have been identified as inactive have a ticket in the > > find-inactive-packagers repo[2]. One week after the final release, > > packagers who remain inactive will be removed from the packager group. > > (Note that pagure.io is one of the systems checked for activity, so > > commenting on your ticket that you're still around will prevent you > > from showing up in the second round.) > > > > If you have suggestions for improvement, look for the open feature > > issues[3] and file an issue in the find-inactive-packagers repo[4] if > > it's not there already. > > Just an FYI, I was talking to armbru about this ticket: > > https://pagure.io/find-inactive-packagers/issue/1181 > > Although he does not mind losing packager status, he does say that he > did not receive any email to the @redhat.com address about this > ticket. > > It may be that the email was lost in a filter as somtimes happens. > But maybe we're not sending out emails to the packagers? > > So this may be a problem with how pagure recognizes 'users' it can expand with @. If you notice in that ticket the account is not 'blue' or highlighted. Contrast that with https://pagure.io/find-inactive-packagers/issue/1436 where gotmax23bot is expandable. What this means is that the pagure database knows the link between gotmax23bot and an email address, but had no way of knowing armbru was an actual user. I believe the Pagure database does not automatically link @ with fas accounts so I expect we have a bunch of tickets which aren't useful. > Rich. > > > For the curious, here are the stats from today's run: > > > > ### Found 2129 users in the packager group. ### > > ### Found 914 users with no activity in pagure/src.fp.org over the > > last year. ### > > ### Found 845 users which also show no activity in Bodhi over the last > year. ### > > ### Found 812 users which show also no activity in mailing lists over > > the last year. ### > > ### Found 812 users which also show no activity in Bugzilla over the > > last year. ### > > > > As we approach > > > > [1] > https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ > > [2] > https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&status=Open > > [3] https://pagure.io/find-inactive-packagers/issues?tags=feature > > [4] https://pagure.io/find-inactive-packagers/new_issue > > > > > > -- > > Ben Cotton > > He / Him / His > > Fedora Program Manager > > Red Hat > > TZ=America/Indiana/Indianapolis > > ___ > > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fe
Re: Inactive packager check for F38
On Thu, 16 Feb 2023 at 08:25, Stephen Smoogen wrote: > > > On Thu, 16 Feb 2023 at 05:56, Richard W.M. Jones > wrote: > >> On Wed, Feb 15, 2023 at 02:02:54PM -0500, Ben Cotton wrote: >> > In accordance with FESCo's Inactive Packager Policy[1], packagers that >> > have been identified as inactive have a ticket in the >> > find-inactive-packagers repo[2]. One week after the final release, >> > packagers who remain inactive will be removed from the packager group. >> > (Note that pagure.io is one of the systems checked for activity, so >> > commenting on your ticket that you're still around will prevent you >> > from showing up in the second round.) >> > >> > If you have suggestions for improvement, look for the open feature >> > issues[3] and file an issue in the find-inactive-packagers repo[4] if >> > it's not there already. >> >> Just an FYI, I was talking to armbru about this ticket: >> >> https://pagure.io/find-inactive-packagers/issue/1181 >> >> Although he does not mind losing packager status, he does say that he >> did not receive any email to the @redhat.com address about this >> ticket. >> >> It may be that the email was lost in a filter as somtimes happens. >> But maybe we're not sending out emails to the packagers? >> >> > So this may be a problem with how pagure recognizes 'users' it can expand > with @. If you notice in that ticket the account is not 'blue' or > highlighted. Contrast that with > https://pagure.io/find-inactive-packagers/issue/1436 where gotmax23bot is > expandable. > > What this means is that the pagure database knows the link between > gotmax23bot and an email address, but had no way of knowing armbru was an > actual user. I believe the Pagure database does not automatically link @ > with fas accounts so I expect we have a bunch of tickets which aren't > useful. > > > OK looking through the tickets, most of the ones I clicked on did not have 'accounts' that the backing pagure.io thought were expandable. I believe another method is going to be needed to get in touch with these individuals. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
On Sat, 18 Feb 2023 at 14:40, Gordon Messmer wrote: > On 2023-02-18 10:33, Kevin Fenzi wrote: > > > > - What Fedora release(es) are you targeting here? > > I'd appreciate guidance from more senior project members on that point. > > > - You mention "over the course of two releases" but don't mention what > >is done in each one? > > I don't know the specifics of how package builds are ordered in a mass > rebuild, so I tend to think the safest rollout is a slow one: enable the I think they are usually done 'alphabetically' with various subgroups done in 'order by the maintainer' beforehand (or afterwards if the mass rebuild broke it) as additional side-tags. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
On Tue, 21 Feb 2023 at 15:48, Matthew Miller wrote: > I was asked to weigh in on https://pagure.io/releng/issue/7215 as a > priority. Last time we talked about this we didn't really get anywhere... > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E > > ... and that ticket hasn't moved, because fixing it isn't trivial. > > So do we kill it for: F39/F40 and beyond? F38 and beyond? X-date and all releases? > > What we're doing now — as has been the case for several years, already > noted > in the previous discussion — has very little end-user value. Also as noted > in that thread (as in the ticket)... that's unfortunate, because it did > bring some real benefits (and could possibly do even more.) > > But, I think it's time to move on. We have ostree and various > container-delta approaches. We should focus on those — and give DeltaRPMs a > sad, fond farewell. > > -- > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
On Wed, 22 Feb 2023 at 15:56, Daniel Alley wrote: > Well, regarding the "based on something", you can hand off a list of > packages to createrepo_c with --pkglist, and avoid the need to download > files with --update + --skip-stat. Unfortunately that doesn't help you > with the package file management. In a vacuum --baseurl would help here > because you could have one root directory, however in reality it breaks > repository mirroring because any mirror be telling clients to fetch the > packages from the source-of-truth. > > I'm not 100% sure how --basedir works, the description is a bit vague. > > Another option is to use something like Pulp which stores all the > information required for metadata generation inside Postgresql and thus can > do so without ever touching the packages / headers again. That approach > isn't necessarily free of downsides either, but it does abstract the whole > file management problem. > I think we need to begin by figuring out what happens in at least the 'pungi' part of the daily 'let's make updates and rawhide'. There are a LOT of things which are going on which interrelate with each other and are prone to cascading breakage when something is 'added', 'removed', 'fixed', or 'changed'. There are also some hard resource limitations on how much CPU/disk/memory is available, how close things must be to 'work', and places where things break a lot but trying to remove/fix/change would require longer downtimes than the project has allowed in the past. I say this from having done all of the above at one point or another and caused all kinds of chaos in doing so. I have probably used up more of Kevin's patience on those than was right. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
On Mon, 27 Feb 2023 at 03:03, Petr Pisar wrote: > V Sat, Feb 25, 2023 at 09:52:03PM -0800, Gordon Messmer napsal(a): > > On 2023-02-22 02:47, Petr Pisar wrote: > > > V Mon, Feb 20, 2023 at 11:48:26AM -0800, Gordon Messmer napsal(a): > > > > > > > > First, the bug. From these results, it looks like rpminspect is only > > > > comparing the primary package to the old build. I do see a result > for the > > > > package "nghttp2", but I don't see an rpminspect result for > "libnghttp2". > > > > Are sub-packages not tested, or are the results simply not exposed? > (Or am > > > > I simply missing the path to find them?) > > > > > > > > ... > > > > > > > > Should I report those in bugzilla, and if so, against what component? > > > I think David prefers < > https://github.com/rpminspect/rpminspect/issues/>. > > > > > > Thanks. I'll file the RFE there. But, with regard to the bug: offhand, > if > > this is a bug, it seems like a bug in the koji CI scripts and not in > > rpminspect, doesn't it? > > It's not Koji CI. The CI is more bound to Bodhi than to Koji. Though CI > people > would probably argue that it's a completely independnent beast. > > This is a general problem I see with many discussions in infrastructure. Developers shorthand a LOT of the parts of how a build occurs as 'koji' when it can be many of a lot of components inside or related partially to the build system: - koji (tool which runs the builders) - src.fedoraproject.org (pkgs) - bodhi (Business logic system for artifacts) - pdc (Product Definition Center?) - zuul (not run by Fedora Infrastructure but called by parts) - openqa - koschei (system which rebuilds packages regularly for testing) - pungi/compose - builders talked to by koji - sign-vault/sign-bridge/autosign - mbs (module build system) - kojipkgs - oci (open container index) - odcs (?) - osbs (open shift build system) - debuginfod - fedimg (seems to push ami images?) - download servers (mainly when a packager can't find something they built) - various parts in openshift I am not sure of (would be good to get a list). > > Where would I find the definition of the > > "fedora-ci.koji-build.rpminspect.static-analysis" stage for review? > > I know about <https://pagure.io/fedora-ci/general/issues/> which I use for > reporting issues in Fedora CI. There are more CI trackers on Pagure in > fedora-ci name space, but I don't understand the CI internals to give you > a more focused answer. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unable to install locally built rpms
On Tue, 28 Feb 2023 at 07:18, Ralf Corsépius wrote: > > > Am 28.02.23 um 10:34 schrieb Kamil Paral: > > > That's most certainly this problem: > > > https://ask.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/31594 > < > https://ask.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/31594 > > > > > Yes, it certainly is this problem. > > AFAICT, the cause seems to be my old gpg-signing key (created 2013) is > using "digest algo 2" signature digests (whatever this means). > > I think that means the key is using SHA-1 keys (going from https://bfh.science/OLD/software/gnupg/best-practice.html) It looks like you can update a GPG key to the newer hash with something like https://wiki.ubuntu.com/SecurityTeam/GPGMigration (or https://old.nixaid.com/gpg-migration-sha1-to-sha2/ though lots of ads ) > > I don't understand these security measures much, but creating a new key > > using modern tools should be sufficient to resolve this. > > Which tools whould you suggest? So far, for me, all such attempts, using > seahorse on fc37 failed. > > Though the newly created key seems to comply to the new rules, now gpg > -sign and rpm --resign fail: > > > # rpm --resign libmail-2.3.5-1.fc38.x86_64.rpm > libmail-2.3.5-1.fc38.x86_64.rpm: > gpg: signing failed: Permission denied > gpg: signing failed: Permission denied > error: gpg exec failed (2) > > No idea, about what's going on. > > > See the article > > to learn how to detect and uninstall already affected packages present > > on your system first. > > Well, ... > > IMHO, this stuff + FC38's rpm and dnf are not in a release-ready shape. > Too many cryptic and non-understandable/non-readable error messages, far > too radical changes, far too little backward compatibility and far too > little help. > > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
On Fri, 3 Mar 2023 at 15:56, Ben Cotton wrote: > The current target release date is the early target date (2023-03-14). > The Go/No-Go meeting will be Thursday! > > Action summary > > > Accepted blockers > - > > 1. distribution — Workstation boot x86_64 image exceeds maximum size — POST > ACTION: gdb maintainers to remove the 'Recommends' for gcc-gdb-plugin from > gdb > > 2. crypto-policies — Insecure installed RPMs (like Google Chrome) > prevent system updates in F38, can't be removed — NEW > ACTION: Upstream to implement MR #129 > > > 2. crypto-policies — https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > — NEW > Insecure installed RPMs (like Google Chrome) prevent system updates in > F38, can't be removed > > Some third-party repos (including Google Chrome) that sign packages > with SHA-1 cannot be uninstalled, which breaks upgrades. This was > designated a blocker by FESCo. Work is in progress upstream to allow > RPM to permit SHA-1 in the default policy while third-party repos > update to a supported hash function: > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 I think the issue is 'larger' than SHA-1. Google Chrome and some other 3rd party software seem to be signed with keys which are both SHA1 and DSA keys. Either one of these would cause the problem with not being able to update/uninstall/etc and since one is a checksum and the other is an encryption type need possibly different solutions. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dogtag-pki is not installable on F38/Rawhide because it fails the GPG check even if you attempt to skip the check
On Thu, 9 Mar 2023 at 05:15, Chris Kelley wrote: > Hi all! > > TL;DR dogtag-pki is not installable on F38/Rawhide because it fails the > GPG check (F37 and prior are fine), even if --nogpgcheck is specified, and > I don't understand why. > 1) Why does the key not work? > 2) Why does --nogpgcheck not work? > > This repo is probably using DSA and/or SHA1 in its keys. The rpm in Fedora 38 and beyond uses the central policies for encryption while previous versions did not. Currently the system policy does not allow for SHA1, DSA and other keys which were allowed previously but currently only allow for SHA2 and stronger encryption algorithms. The keys need to be regenerated in COPR I believe to fix this. The error I get is: > > [root@fedora ~]# dnf copr enable @pki/master; dnf install dogtag-pki > > Importing GPG key 0x20DE059C: > Userid : "@pki_master (None) <@pki#mas...@copr.fedorahosted.org>" > Fingerprint: B023 2014 243E 33DA CFBA 5269 94CF 0B2D 20DE 059C > From : > https://download.copr.fedorainfracloud.org/results/@pki/master/pubkey.gpg > Is this ok [y/N]: y > Key imported successfully > Import of key(s) didn't help, wrong key(s)? > Problem opening package > dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm. > Failing package is: > dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64 > GPG Keys are configured as: > https://download.copr.fedorainfracloud.org/results/@pki/master/pubkey.gpg > Problem opening package > dogtag-ldapjdk-5.4.0-0.1.alpha1.20230127155101UTC.ea85ad3a.fc38.noarch.rpm > Problem opening package > dogtag-tomcatjss-8.4.0-0.1.alpha1.20230120164140UTC.a5ca31ab.fc38.noarch.rpm > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: GPG check FAILED > > > I see that the key is new, generated yesterday: > https://download.copr.fedorainfracloud.org/results/%40pki/master/ > What causes this key to be (re)generated? I looked for docs around this > but couldn't find anything to help me. > > To move things along, I tried to work around this with --nogpgcheck ,which > led to a different error: > > Running transaction check > Transaction check succeeded. > Running transaction test > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: Transaction test error: > package > dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64 does not > verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD > package > dogtag-ldapjdk-5.4.0-0.1.alpha1.20230127155101UTC.ea85ad3a.fc38.noarch does > not verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD > package > dogtag-tomcatjss-8.4.0-0.1.alpha1.20230120164140UTC.a5ca31ab.fc38.noarch > does not verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD > > ...which looks like it is still attempting to do some kind of verification > of the key. > > I have tried setting both gpgcheck=0 and repo_gpgcheck=0 in the repo file, > but this does not change the result. Am I misunderstanding the > purpose/scope of this option? > > Does anyone have any idea why this key does not work, or have some doc I > can look at to try figure it out myself? > Likewise for the workaround, anyone have any insight there? > > Thanks for your patient reading if you go this far :-) I'm hoping this is > a lack of familiarity on my part with GPG. > > Cheers, > > Chris > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Degradated modules support
On Wed, 8 Mar 2023 at 10:12, Petr Pisar wrote: > For module maintainers, module users, and flatpak maintainers: > > Fedora infrustructure has long-standing problems with supporting modules. > > Namely, MBS is unable to build modules with deep dependencies > <https://pagure.io/fm-orchestrator/issue/1759> and Bodhi is unable to > accept > multicontext modules <https://github.com/fedora-infra/bodhi/issues/4198>. > > This results into inability to support affected modules. E.g. it's > impossible > to build perl-CGI:5.54 for Fedora 39, and it's impossible to update > perl-Date-Manip:6.86 in stable Fedoras. > > Because nobody has tried to tackle these infrastructure deficiencies, > module > maintainers have hard times to support the modules, and as a result users > can expect dropping of numerous modules from Fedora. If there remain no modules, > Fedora project might consider removing Modularity from Fedora > infrastructure. > > Most of the work needed to get these worked on successfully requires: 1. Nothing being higher priority for Fedora Infra, Fedora Releng, Red Hat MBS team, and other parts of the build system that this ties into. 2. Schedules being aligned between the 3-4 teams that this is a priority to work on for a 4 to 6 week period. Most of the Fedora Infrastructure and Releng work is tied up in: 1. getting a daily compose out the door (Monday through Sunday). 2. getting a release out in some form (beta/final) every 12 weeks. 3. keeping 40+ services over a couple hundred systems working to meet 1&&2. The above is done by about 2.5 people (counting multiple volunteers as 1 person). This goes up at times and goes down but for the last year has been about that. I don't think this is unique to Fedora Infra/Releng. The teams which have supported MBS, Koji, PDC, ODCS, etc have their own goals they need to accomplish and it is hard to get their time to sync up with the usual short periods that Fedora Infra can 'slow-down' (usually after a release). I don't have any easy solutions on how to fix this. Even 'turn off modularity' isn't probably easy. Too many services are tied into the Fedora build system framework in a way that expects something from other parts even if they don't seem connected. You turn off one service, and you find out that 3 other things don't work weeks later because they expected some sort of 'heart-beat' or some other message. > That could also affect seemingly unrelated parts of Fedora like Flatpaks > whose build process is based on modularity. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: discuss f41 schedule adjustment for branching
On Tue, 9 Jul 2024 at 14:58, Kevin Fenzi wrote: > > Hey folks. > > I happened to notice the other day that f41 branching is currently > scheduled for 2024-08-06. This is the day before flock. > > https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html > > I don't think this is a good time. :) > > While Samyak (who will be doing most/all of the releng work for > branching) is unfortunately not going to be able to attend flock, there > are often issues or things that need adjustment from others, and I think > it's pretty unreasonable to ask those people to do these things and also > be present at flock. > > So, we could: > > 1. Do nothing, but branching may be in a weird state or messed up or > people going to flock may not be able to give their talks or interact > with others because they are fixing things. > > 2. Move the branching a week later: 2024-08-13 > and just leave it at that. That would leave one less week to clean up > branching stuff and get updates through before bodhi enablement. > > 3. Move the branching a week later: 2024-08-13 > and move the entire rest of the schedule out a week. > > 4. Move the branching a week sooner: 2024-07-30 > and leave everything the same after. This would mean less time for the > mass rebuild fixes, less time for maintainers to land changes that they > wanted to land before branching. > > I probibly like 3 the best myself, with 2 pretty close. I don't like 1 > or 4 much at all. :) > Going from the many previous releases, I also think #3 is the best option. The others have pretty much always caused more long term problems. > Thoughts? > > kevin > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Thu, 11 Jul 2024 at 11:34, Josh Boyer wrote: > > On Wed, Jul 10, 2024 at 12:46 PM Daniel P. Berrangé > wrote: > > > > On Wed, Jul 10, 2024 at 09:36:35AM -0400, Stephen Gallagher wrote: > > > I'm guessing Josh's response was an attempt to use AI to generate a > > > summary. In the future, please label it as such, so people will read > > > it with a critical eye. It has some flaws which I will address inline: > > > > If content is labelled as written by AI I'd skip reading it entirely. > > Reading "with a critical eye" implies we have to either guess (or > > research) which parts are accurate and which are wrong, neither option > > being desirable. > > > > I'd ask for human written summaries, or none at all, in prefence to > > misleading AI summaries. > > Human in the loop is of course important. The intention would be to > have FESCo review any AI generated content for accuracy before sending > it out. From a consumer perspective, you get content that has been > validated by a human and you should be able to trust it like you would > any other email sent. > > If FESCo doesn't want to use AI at all, I don't care. I just want > better summaries than what zodbot is currently providing (which aren't > reviewed either afaics...) > The 'summaries' are just what the person running the meeting is collecting during the meeting while trying to also keep the meeting running AND be a participant of the meeting. The person doing this is a volunteer and generally has zero training in note taking, running meetings or a dozen other things which are expected. If better notes are expected, then better training or having an agreed upon professional whose sole job is this task is generally needed. I don't know if the AI summary came from the general notes of the meeting or if it was built off the actual conversations between people. If it was built off of https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.txt like a professional transcriber (or whatever the role is called these days), then the next step is to send it around to the participants for 'approval'. This is why various meetings start off with a 'approval of the previous minutes' at the start of a meeting so that people who need to make corrections can do so and corrections can be voted on as needed. If LLMs become this 'professional' body, then there will probably need to be an open way to know their 'credentials' to make sure that summaries are fair. What was the tool and dataset used What was the 'meeting' data fed to the tool What was the query (or queries) used What were the retraining queries used to change 'summaries' that were found to be wrong. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Thu, 11 Jul 2024 at 13:47, Josh Boyer wrote: > > On Thu, Jul 11, 2024 at 12:08 PM Stephen Smoogen wrote: > > > > On Thu, 11 Jul 2024 at 11:34, Josh Boyer wrote: > > > > > > On Wed, Jul 10, 2024 at 12:46 PM Daniel P. Berrangé > > > wrote: > > > > > > > > On Wed, Jul 10, 2024 at 09:36:35AM -0400, Stephen Gallagher wrote: > > > > > I'm guessing Josh's response was an attempt to use AI to generate a > > > > > summary. In the future, please label it as such, so people will read > > > > > it with a critical eye. It has some flaws which I will address inline: > > > > > > > > If content is labelled as written by AI I'd skip reading it entirely. > > > > Reading "with a critical eye" implies we have to either guess (or > > > > research) which parts are accurate and which are wrong, neither option > > > > being desirable. > > > > > > > > I'd ask for human written summaries, or none at all, in prefence to > > > > misleading AI summaries. > > > > > > Human in the loop is of course important. The intention would be to > > > have FESCo review any AI generated content for accuracy before sending > > > it out. From a consumer perspective, you get content that has been > > > validated by a human and you should be able to trust it like you would > > > any other email sent. > > > > > > If FESCo doesn't want to use AI at all, I don't care. I just want > > > better summaries than what zodbot is currently providing (which aren't > > > reviewed either afaics...) > > > > > > > The 'summaries' are just what the person running the meeting is > > collecting during the meeting while trying to also keep the meeting > > running AND be a participant of the meeting. The person doing this is > > a volunteer and generally has zero training in note taking, running > > meetings or a dozen other things which are expected. If better notes > > are expected, then better training or having an agreed upon > > professional whose sole job is this task is generally needed. > > I don't agree with this at all. I served on FESCo for years. I know > what the existing summaries represent, how they're generated, and what > the dynamics of the meetings are. You don't need training and > professional people to improve things as a project. > My apologies, I wasn't clear. I consider bringing a GPT into the mix the same as having a professional on it. It is a 'service' which is paid for in some way which is 'trained' to do a particular job well. The example you gave was better detailed (if flawed) than I think I have ever seen a FESCO or Council meeting annotated excluding ones by specific people who have either training or a knack on doing this well. That was the level of detail I was thinking was wanted and not something I expect someone who is volunteering to do this and trying to get information out before their day job takes over to do as well. Again my apologies for not being clear. > Honestly, I'm not finding fault with FESCo. I'm saying the thing they > are doing today is not really valuable for a consumer base that wasn't > in the meeting. If they want to make it better, AI is a tool that is > actually pretty simple to use to do that without a ton of effort. If > they don't want to make it better, then maybe just stop publishing the > summary emails entirely and save themselves and others time. The > meeting logs will still be there. > > josh > -- > ___________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: whatcanidoforfedora.org is stale
On Fri, 12 Jul 2024 at 03:06, Zbigniew Jędrzejewski-Szmek
wrote:
>
> I looked at the page today, and it advertises:
> - modularity
> - in the python section:
> - abrt (attention here would be welcome, but isn't the project mostly dead?)
> - dnf (not in Python anymore…)
> - portingdb ("a dynamic database of Python 2 packages needing to be updated
> to Python 3")
>
> Rust is not mentioned. Neither are other new(ish) things…
>
> I think the page was/is a nice idea, but right now it's as likely to
> discourage and confuse as to help somebody.
>
I think this was a page we had from a summer project years ago. We
have a LOT of such domains and pages spread around the project which
probably all need to be cleaned up and redirected to something (that
will get redirected later).
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Enable Drm Panic (system-wide)
On Mon, 15 Jul 2024 at 13:28, Jocelyn Falempe wrote: > > > > On 15/07/2024 18:13, Barry wrote: > > > >> On 15 Jul 2024, at 14:05, Jocelyn Falempe wrote: > >> > >> If you want to see the kernel boot log, before userspace is started, > >> you can add "init=/does_not_exist drm.panic_screen=kmsg" to the kernel > >> command line. It will panic, and you will see all relevant logs with > >> drm_panic. > >> It's not ideal, but that should at least allows to see those logs. > > > > And if the kernel hangs without panic then we have a blank screen to stare > > at right? > > Yes, but I don't think this happens often in practice. And in this case > there is little chance the kernel logs will help you much anyway, > because when it hangs, you don't have the call trace, and the last > kernel log might be unrelated. > For this case, if you have an older kernel that boots, you can run a > bisection, and find the root cause reliably. > > > This is going to make Fedora very hard to support and push users to another > > distro without this “feature” I suspect. > > I hope most Fedora users experience a clean boot, and don't have to > change the kernel command line in grub to debug. Most Fedora users probably do not have to do so as much as they would in the past, but I can say that many Fedora developers may have to regularly do so. Depending on the hardware, I have to do this at least once a major kernel update or updates to systemd, dracut or related packages. That said, I needed to talk my 78 year old Dad through command line grub debug issues about 3 times in the last year with needing to get to a VT in order to debug things due to various boot-time bugs that made it into Fedora after release. His laptop is a Dell Latitude so not that odd but video drivers went odd and another time dracut didn't grab a driver needed. > Also the bugs found with drm_panic will be fixed upstream, for all > distro, so the whole ecosystem will benefit from that. > > I will also check if I can patch VT_CONSOLE, so that it can be disabled > on the kernel command line, instead of compile time, to avoid this gap. > > I'm currently preparing a test kernel, so that you can test on your own, > and report if there are other corner cases to fix. > > > > > Barry > > > Best regards, > > -- > > Jocelyn > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
