Re: LLVM Packaging Ideas for Fedora 41
On Mon, Apr 29, 2024 at 4:38 PM Vitaly Zaitsev via devel wrote: > Both of my LLVM dependent packages: iwyu and pocl. On every LLVM major > release they break and I have to wait for the upstream to release a new > version. I would hope that there are more examples than O(1), as processes should not be determined by O(1) numbers. In any case, since this is *every* release, is there any good reason these are not somewhere in the LLVM CI/QA workflows? Sounds like good test cases, and good test cases are typically hard to find. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: LLVM Packaging Ideas for Fedora 41
On Mon, Apr 29, 2024 at 2:25 PM Tulio Magno Quites Machado Filho wrote: > Considering that LLVM releases usually happen very late in Fedora's > development cycle, if the default LLVM version is changed, packages may > start to FTBFS very late in the development cycle if they buildrequire > the default LLVM version. > > Notice that, in this proposal, packages that would prefer to use the new > version may still update them by buildrequiring the new versioned package. I would rather see the llvm base package(s) always be the latest (and perhaps greatest), and for there to be something like a llvm-not-the-latest (or some other well known name) so that those whose packages are known to be llvm version sensitive can make a one-time change to use the not-the-latest version of llvm (i.e. put the onus of using not-the-latest with the package(r)s that need not-the-latest, or some specific version) so that they can be more assured of not having last minute FTBFS issues. Do we have any idea how many code bases are actually sensitive to the specific llvm version? I suspect that there are a few likely well known and expected code bases, and most code bases are (mostly) agnostic. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 do minor bump using %autorelease?
On Mon, Apr 29, 2024 at 11:44 AM Fabio Valentini wrote: > No, this will make a Release like 2.1.fc40 - which is not what's > needed (which would be 1.fc40.1). > So it doesn't work because -e adds a component *before* the dist-tag, > *and* because the main number is still incremented. Since [.minorbump] is a documented method for packaging, if autorelease does not support it is feature incomplete. If one wants/needs to use [.minorbump] now, or in the future, autorelease is not currently the tool to use. I'll let the autorelease authors decide whether autorelease needs to be updated to support [.minorbump]. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 there a policy for branches being merged or not
On Mon, Apr 29, 2024 at 11:35 AM Richard W.M. Jones wrote: > > On Sun, Apr 28, 2024 at 10:27:26AM +0200, Julian Sikorski wrote: > > > I know this is just a cosmetic issue, but choices made by the > > primary maintainers should be respected IMO. > > I agree in general, but sometimes if you're making mechanical changes > across 100s of packages it's hard to do this in practice. I make sure to read the (bulk) change proposals and if I care about how they may impact my packages I will try to perform the changes in advance (so any mechanical changes find nothing to do). Choosing to let the automation do whatever it is going to do is still a choice. I attempt to choose wisely. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [HEADS-UP] openexr so name bump heading Rawhide and f40
On Mon, Apr 22, 2024 at 12:15 PM Josef Řídký wrote: > > Hi folks, > > this is in advance notice about the upcoming rebase of the openexr package in > Fedora Rawhide and f40. > I note that there is a patent clause which allows DreamWorks to revoke the patent grants under some conditions for the lossy compression. Has Fedora Legal reviewed the revocable patent license language, and does there need to be a (new) SPDX license to include that patent grant (BSD-3-Clause-Patent?) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: network service removed in Fedora 40 without a Change proposal(?)
On Fri, Apr 12, 2024 at 9:41 PM Adam Williamson wrote: > > Michel Lind just prompted me to notice that the 'network' service > appears to have been removed from initscripts in Fedora 40+. > Should this have been a Change? How worried are we about it going out > in Fedora 40 without having been through the Change process? I think it should have been better documented (i.e. called out in a change proposal for feedback), but I am going to suggest systemd-networkd as the longer term better solution (but that would be for another day). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Fri, Apr 12, 2024 at 4:05 PM Kevin Fenzi wrote:
> So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
> whatever, right now that would require some work on some scripting,
> which I guess would remove people without otp? But then there would
> still be a window when the user was added and before the script removed
> them. Or some way for sponsors to check otp status before sponsoring
> someone, but if thats manually it could be missed.
>
> I think in any case it might be good to find all the {proven}packager
> members without otp and perhaps email them a note about how to set
> things up, etc.
Finding the (proven)package
members without 2FA might be a
useful thing to know in order to
influence any decision or the
implementation time frame (is it
20% or 80% of (P)Ps?).
That said, I would rather see any
such follow up directed email
happen after a FESCo decision
about 2FA is made in order to
avoid possible multiple emails
(one sent soonish saying that
you *could* add 2FA, should you
want to, and another, should
the decision be made to require
2FA, to say that you will be
required to add 2FA after some
date; one email is better).
That does presume that FESCo
will make a decision in the near
term such that any email text
can be appropriately crafted.
While there will always be some
window/edge cases, I think we
should start with the presumption
that most (proven)packagers will
wish to do the right thing, and
will use 2FA if that is the stated
requirement. After the fact
cleanup/removals as the community
now does for inactive packages
may not be ideal but is arguable
sufficient as a first step.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Apr 13, 2024 at 8:44 AM Richard W.M. Jones wrote: > I sometimes think how hard it would be to explain all of this to my > mother. I don't understand why 2FA needs to be so obscure and clumsy > to use. FIDO2 (Apple branded[0] as "passkeys") is not that hard to use, or explain. The problem is that (a) passkeys are not yet universally supported (and, in this case specifically, by FAS[1]), and (b) unlike Apple (macOS, iOS, etc.), Microsoft (Windows), and Android, where the passkey is integrated into the OS inside a protected enclave, there is no trusted integrated support in Linux without an external FIDO2 key[2][3] or using the "scan a QR code" workaround with a mobile device which does support use of passkeys. Unless your mother is using Linux (and while Mrs. Roberts has been using Linux for a long time, most moms don't), this is likely a time limited issue as more and more sites support passkeys and from the consumer point of view it all mostly just works. I would like to imagine that FAS' current 2FA will eventually also be reasonably easy with FIDO2/passkeys, which is why I occasionally ask about the FIDO2 support status. [0] I don't remember if there was any official assignment of the branding, but I heard that Apple was the org that suggested the name. [1] As I understand it, if/when some of the FAS IdP moves to keycloak, FIDO2 2FA *could* be supported. However, there is no current schedule for that move that I am aware of, and unless Fedora uses the RHBK runtime, building keycloak from source for Fedora can be a real PITA (at least last I looked at it, maybe it has gotten easier). [2] As I understand it, the issue is the lack of the required trusted environment in generic Linux. There are software implementations that do not have the hardware enclave protections, [3] External FIDO2 keys are also not free, although I did see a $10 Adafruit FIDO2 key, which is the cheapest I have seen. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel wrote: > 2FA in a lot of cases is just access to a different account (e.g. email > or even SMS) and these normally aren't unique. Sure, there are other > ways like FIDO2, but these are not necessarily used (or liked, quite > frankly I know a lot of people who would loose them on a monthly basis, > but still are quite smart about other stuff). Given that FIDO2 credentials can be stored on your mobile device (and exchanged with other devices), if those people are losing their mobile devices every month they likely have other issues (including a very expensive mobile device replacement budget) for which there is likely no viable solution. FAS' use of TOTP 2FA is not a great solution compared to FIDO2, and there are well known attacks against TOTP 2FA, but even TOTP 2FA can reduce the doorknob rattling exploits. As TOTP 2FA generators exist for most mobile devices one will tend to have a TOTP 2FA generator with one most of the time. To the Fedora leadership: What is the best way to formally propose that 2FA is required for packagers after some date (I suppose we could have different dates for PPs vs others if we wanted to do that in order to get started sooner). Do we need a formal Change Proposal to be voted on by someone? It does not really seem like a FESCo issue to me, but more of a policy issue that might need to go to the Council? I have no doubt that such a proposal will be controversial with some, and all those issues should get a (re-)airing in front of those making the decision. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: convert everything to rpmautospec?
On Mon, Apr 8, 2024 at 2:26 PM Tom Hughes via devel wrote: > > On 08/04/2024 14:47, Fabio Valentini wrote: > > > It is already supposed to be default / preferred since this Fedora 38 > > Change: > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > > I find that quite interesting because while I may have read it at > the time I had certainly long since forgotten that. I read it at the time, and it was promised (at the time) that rpmautospec would be a recommendation, and not a requirement. I would have strongly objected to a MUST. That rpmautospec works fine for some is great (for them). And it can be a good default for many (if someone asked me how to package something new, I would suggest they consider rpmautospec). However, as long as it does not work 100% of the time in 100% of the use cases (and by it's nature, it can't) means that it should never (can never) move forward to a MUST. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: convert everything to rpmautospec?
On Sun, Apr 7, 2024 at 3:23 PM Miroslav Suchý wrote: > > Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a): > > I think it's time to switch to rpmautospec completely. > > -1 from me. > > While I enjoy simplicity of rpmautospec in some of my packages. > > I have bunch of packages where the spec is present also in upstream and the > package is build for epel7 too. And I build the package locally (outside of > dist-git) often. The enforcement would complicate my life. +1 to the -1 (for basically the same reasons). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
On Tue, Apr 2, 2024 at 3:12 PM Dmitry Belyavskiy wrote: > Third-party engines may be a problem but as we don't break ABI, it's not a > problem of the moment. The fact you are removing the headers means it is a problem for 3rd party engines who build from source (and everyone should at least occasionally be building from source as part of their CI). I consider removing the headers as breaking the API, as the headers define the API. The headers already mark the engine APIs as deprecated. Orgs with resources should be starting their migration, although some will defer it to the next quarter (and the next) I expect you have no visibility into 3rd party engines, nor how big an issue this will be (and can make no statistically valid claim it will not be an issue unless you have real numbers to share). However, *after* RHEL10 is released with engine support removed RH's TAMs may have a better idea (I am WAGing most 3rd party engines will be being used by large customers, and they are likely to make any concerns known). I believe this should be part of OpenSSL 4.0. It will be a clear change. There is no compelling reason for this to happen today via the headers. Instead this should be a marketing campaign by OpenSSL to remind everyone that engines are going away with OpenSSL 4.0 with every new set of release notes (first item, in double bold), and that orgs need to start their migration. And then do it again. And then do it again. And when OpenSSL 4.0 is released, you can remind everyone you warned them. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: xz backdoor
On Mon, Apr 1, 2024 at 9:17 PM Matthew Miller wrote: > > On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote: > > It does bring up a potential point that perhaps > > Fedora should have an additional repo (let's > > call it "emergency fixes") that is not community > > mirrored (so any mirrors for load sharing > > would be fully controlled by the project), with > > a short refresh time, and containing only > > packages that need to get out immediately. > > If a critical fix needs to get out to the > > community it could be (almost) immediately > > available. After a few days (when public > > mirrors would be expected to have updated) > > those packages could be removed (reducing > > the load on this repo). For the next time, of > > course (and there will be a next time, there > > is always a next time). > > https://pagure.io/releng/issue/5886 > > (This was after Heartbleed, FWIW.) > I am glad to know "it's all good" :-( -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: xz backdoor
On Mon, Apr 1, 2024 at 5:27 PM Kevin Fenzi wrote: > Yes. The downgrade was pushed out on friday along with the f40 one. Of course, your mirror may vary as to availability (as I recall, in my particular case, my test VM for rawhide did not get the update for a day or so). It does bring up a potential point that perhaps Fedora should have an additional repo (let's call it "emergency fixes") that is not community mirrored (so any mirrors for load sharing would be fully controlled by the project), with a short refresh time, and containing only packages that need to get out immediately. If a critical fix needs to get out to the community it could be (almost) immediately available. After a few days (when public mirrors would be expected to have updated) those packages could be removed (reducing the load on this repo). For the next time, of course (and there will be a next time, there is always a next time). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]
On Mon, Apr 1, 2024 at 4:42 PM Adam Williamson wrote: > I think we *are* part of a supply chain, regardless of any handwaving > about The Open Source Model. And, more importantly, the industry has agreed to use the term supply chain. Is the term perhaps overloaded, or perhaps too ill-defined/imprecise? Sure. But if one wants to use a different term one would need to work across the industry to change the term, and that is not going to happen. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 5:35 PM Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > Do we require 2FA for provenpackager yet? > > No. I am a provenpackager and do not have 2FA enabled (nor do I want it to > be). Whenever 2FA comes up, the requirement for provenpackages to have it enabled has always come out very high on the list of first steps. I still recommend that. PP is a privilege, not a right. With privileges often comes additional responsibilities, and 2FA should absolutely be one of them. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 8:58 AM Adam Williamson wrote: > 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still > don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE > COMPULSORY 2FA FOR FEDORA PACKAGERS*. What is the status of the FIDO2 implementation in the authentication processes? Whenever 2FA comes up I agree with the principal, but ask for an update on FIDO2. Last I knew, it was still a under-resourced WIP. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 9:38 AM Richard W.M. Jones wrote: > > I'm not pretending these will solve everything, but they should make > attacks a little harder in future. Thanks for starting the discussion. A well resourced supply chain attack is probably not preventable (no matter how many eyes are looking). That does not mean we should not try to minimize the likelihood of future such attacks. > (3) We should have a "security path", like "critical path". > . > > Should we have a higher level of attention to these packages? We > already have "critical path", but that's a broad category now. These > seem like they are "security path" packages, an intentionally small > subset associated with very secure services which are enabled by > default. > Obligatory xkcd: https://xkcd.com/2347/ What I do think we should start with is look at the list of dependencies in the list of whatever we can agree are security critical packages (running as root and opening network ports is always a good start) and dependencies which are not supported by a large-ish organization (even if only informal), with a set of experienced developers, and sufficiently funded to continue support of the package, and has a good security reporting and response process in place. xz would not seem to meet that vague hand waving criteria, and so it should either be replaced with something else (if possible) or get it (or in this case, likely its new team) resourced to its level of importance in the ecosystem. I expect, with a critical eye, other such projects will be identified. The response to Heartbleed was (among other things), resourcing OpenSSL. If a decision is made that xz needs to stay as part of the critical chain, it needs to be resourced too (although, as others have suggested, removing xz from that chain may be a better choice). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F41 Change Proposal: Switch to DNF 5 (System-Wide)
On Mon, Mar 25, 2024 at 4:59 PM Vít Ondruch wrote: > > Previously, I had issues that migration from DNF4 to DNF5 left a lot of data > in /var/cache. How is this going to be addressed? I don't think it is fair to > leave those behind and waste disk space for regular users. > Are you suggesting the dnf(4) should have an additional stanza in the %postun scriptlet something of the form (following not tested, validated, or run, just prototype): if [ -d /var/cache/dnf && "$1" -eq "0" ] ; then rm -r /var/cache/dnf || : fi ? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Redis will no longer be OSS... now what?
On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel wrote: > We will see whether that or redict will get the most attention. Cloud > companies like Amazon will probably prefer BSD, whereas contributors worried > about another "Redis, Inc." coming up and taking their forked code > proprietary too will most likely prefer the LGPL fork (redict) (unless they > are unhappy about the use of version 3.0 only of the LGPL by that fork). "It is hard to make predictions, especially about the future", but it appears that many of the recent non-redis contributors are cloud company entangled (and were previously willing to contribute under the BSD-3-Clause license). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 1:36 PM Dmitry Belyavskiy wrote: > > As I understand, upstream is going to remove engines but it wouldn't happen > before OpenSSL 4.0 > I don't think Fedora should wait for that. We definitely want to land > no-engine in RHEL10 so Fedora should be ready for that. > What is the targeted time frame for release of OpenSSL 4.0? Last I knew it was not soon(ish). And (for Fedora), I would expect for a number of years distros are likely going to have to ship both openssl 3.x and openssl 4.x libraries for compatibility (just as many still ship openssl 1.1), and engine support may be a compatibility requirement. I would think the OpenSSL 4.0 timeframe is when engine support should be dropped (I believe the 3.x headers already warn about deprecation, and people have the option to start porting code now, although many are likely to not do so until it breaks). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 container images no longer include gzip?
On Sun, Mar 17, 2024 at 11:55 PM Adam Williamson wrote: > > On Sun, 2024-03-17 at 23:12 +, Gary Buhrmaster wrote: > > > > Did I miss an announcement (very possible), > > or did something else change to no longer > > pull in gzip (also possible)? > > Almost certainly. What changed is > https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages - these > images (all 'Cloud' and 'Container' images) are now built with Kiwi > instead of ImageFactory/oz. I had remembered that the builder was changing, but, in hind sight, incorrectly presumed that would not change what packages ended up in the container. > This probably wasn't intentional, and we can probably get it put > back... Thanks for looking into this. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora container images no longer include gzip?
It appears that the quay.io container images for F40 (and F41/rawhide) do not contain the gzip package. I noticed due to an indirect use of tar with a gzip archive on a github workflow (the checkout failed due to no gzip). Did I miss an announcement (very possible), or did something else change to no longer pull in gzip (also possible)? If it was not intentional, I would like to petition to have gzip added back explicitly. If it was intentional, I'll adjust my workflow accordingly. Thanks. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Login issues to lists.* and src.*? Any outages?
On Thu, Feb 22, 2024 at 8:20 PM Christopher wrote: > > Are there any known issues right now for logging in to > lists.fedoraproject.org or src.fedoraproject.org? > Do we have a page for known outages? https://status.fedoraproject.org/ It currently reports all systems operational > I can log in to accounts.fedoraproject.org, so I know my password and 2FA > token still works, but not to src.f.o or lists.f.o. > I tried to disable my 2FA in there, to see if that had an effect, but it > wouldn't let me (I thought it was optional?) Enrolling in 2FA is a one-way action (like Hotel California, you can never leave). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 F39 to F40
On Wed, Feb 21, 2024 at 7:12 AM Miroslav Suchý wrote: > > Do you want to make Fedora 40 better? Please spend 1 minute of your time and > try to run: > No problems experienced on my primary desktop. Thanks! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Wed, Feb 21, 2024 at 5:50 PM Maxwell G wrote: > > Report started at 2024-02-21 17:04:45 UTC > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > perl-SOAP-Litemspacek, orphan, pghmcfc,0 weeks ago Too many things I use need this. Taken. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Does ccache ever help with kernel mock build?
On Tue, Feb 13, 2024 at 9:52 AM Miroslav Suchý wrote: > > Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a): > > Could this be the reason for ccache not working? > > I wonder whether it is Mock problem, Ccache issue or problem in packaging? > Does the ccache speadup the build when you > run it with plain rpmbuild and ccache on host? I have lost track of the details (and the version of ccache when the issue was addressed/patched), but ccache at one time included SOURCE_DATE_EPOCH in the default hash, resulting in no cache hits. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: exiv2 and protobuf hard to do soname bump without turbulence
On Fri, Feb 9, 2024 at 4:23 PM Sérgio Basto wrote: > > Hi, > > I'd like to bring to your attention that Fedora would benefit with > update of exiv2 [1] and protobuf [2] but these packages have lots of > dependencies and the update of the dependent packages is not trivial . > tips, ideas and opinions ? to do these soname updates > While understandably annoying, last I knew the patent issue IRT BMFF was not yet resolved for exiv2 (waiting on RH legal). As I understand it, once the issue is raised, one is required to wait for a formal decision to be made, and there no time frame for that to occur. If you are willing to strip the sources of the BMFF support until such time as a decision as to whether to allow it to be included is made that should be a way forward more quickly. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[HEADS UP] [SONAME BUMP] libcbor will be updated to 0.11.0 in rawhide with a soname bump
libcbor will be updated to 0.11.0 in rawhide in the next week or so, which includes a soname bump. The list of affected packages in rawhide are: libfido2 fwupd I will rebuild libfido2. For fwupd, I will need the maintainers (CC'ed) or a proven packager's assistance. I have used the Mass Prebuild tool (mpb) to verify that all the packages rebuild successfully, so I do not anticipate any surprises. Please use the side tag f40-build-side-82971 Thanks! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Sun, Feb 4, 2024 at 9:04 PM Kevin Kofler via devel wrote: > > Jonathan Bennett via devel wrote: > > the KDE SIG doesn't have a track record of handing those kind of bans out > > flippantly. > > That is what they want you to believe. Sure, this used to be the case, a few > years ago. > “Understanding is a three-edged sword: your side, their side, and the truth.” - JMS I am uninterested in your side, nor their side, and I do not believe anyone has the full truth to share. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Sat, Feb 3, 2024 at 2:32 AM Kevin Kofler via devel
wrote:
>
> Gary Buhrmaster wrote:
> > For something that has the potential to
> > impact KDE users that would choose to
> > remain on X11, I would absolutely hope
> > there is more than just you involved in
> > the effort (busses, and vacations, happen).
> >
> > Having something like a KDE-X11-SIG
> > team (made up name), with a few known
> > active members, would probably go a long
> > way to reduce the concerns of others
> > regarding tracking (and taking) bugs, and
> > lack of timely updates, for something as
> > visible as the entire desktop.
>
> I welcome any comaintainers to the {kwin,plasma-workspace}-x11 packages (as
> long as they do not intend to abuse their access to retire the package
> without my agreement, of course). More helping hands = less work per person.
So, just to be clear, and to eliminate any
possible misinterpretation, you are
stating this is a one-person show at
this time?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 2, 2024 at 1:51 AM Kevin Kofler via devel
wrote:
> Unlike you ("you" = the KDE SIG), I actually believe I can probably keep my
> *-x11 packages on life support for some time even if and when KDE upstream
> drops their X11 support. Kinda like I have been doing for, e.g., Blogilo.
> Realistic would be until the release of Plasma 7, unless some Plasma 6.x
> introduces major changes that make it impractical. But I hope this is not
> going to be a concern for Fedora 40.
For something that has the potential to
impact KDE users that would choose to
remain on X11, I would absolutely hope
there is more than just you involved in
the effort (busses, and vacations, happen).
Having something like a KDE-X11-SIG
team (made up name), with a few known
active members, would probably go a long
way to reduce the concerns of others
regarding tracking (and taking) bugs, and
lack of timely updates, for something as
visible as the entire desktop.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Re: A reminder: you cannot just "revert" package version bumps
On Thu, Feb 1, 2024 at 3:11 AM Kevin Kofler via devel wrote: > > If the distro-sync (which should be the default way to do updates > at least on Rawhide, if not everywhere) mentions a package being downgraded, > that is much more likely to be noticed. > I look forward to your formal change proposal to replace what we know of today as upgrade to be distro-sync. While I will reserve judgement on the proposal until I see the full details, I am going to say that as today I am dubious that that is the right way forward. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Re: A reminder: you cannot just "revert" package version bumps
On Thu, Feb 1, 2024 at 1:53 AM Kevin Kofler via devel wrote: > And the proposed "solution" of bumping Epoch fixes none of that. It just > introduces an Epoch that we will be stuck with forever. It will not > magically make the downgrade safe in any of the 3 situations you describe. While I don't like epochs, there is nothing intrinsically wrong with an epoch bump when a packager determines that they need to downgrade because the testing for the upgrade was insufficient or inadequately performed and the packager found that there was no way forward with fixes to the new versions (either from upstream, or by the packager). Sometimes the packager (or upstream) screws up, and the epoch bump is the "get out of jail (mostly) free card" for the packager. If you don't want a "get out of jail (mostly) free card", more power to you, for you are committing to fix any/all issues. Sometimes not every Fedora packager has commit access to the upstream sources. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Jan 30, 2024 at 1:46 PM Stephen Gallagher wrote: > One additional point I forgot to address: the initial concern was that > the KDE SIG would be implicitly responsible for maintaining these > packages if they are included in the main repository. From a purely > technical perspective, I think that we should state clearly that the > KDE SIG would be required only to provide advance notice of major > changes but would NOT be responsible for ensuring that these packages > adapt to them. Of course, communicating that to users is harder (and > they'll naturally report bugs to the wrong place in many cases), but I > think the KDE SIG is completely permitted to refuse and retarget any > issues that come up to the appropriate group. I would suggest that it is entirely reasonable that there be a threshold where if users continually report bugs that the KDE SIG must deal with (i.e. someone else's packages are causing excessive overhead for the SIG, even just to close/retarget the bugs/issues) that they can petition that the offending packages get suspended/removed. I don't know what that threshold will be, but I suspect the SIG will know it when they see it. I would suggest that the packager of those other packages monitors all new bugs/issues and "takes" them early and often to insure that the SIG is not unduly burdened, and the threshold petition would never need to be considered. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Sun, Jan 28, 2024 at 8:15 PM Neal Gompa wrote: > We cannot change this without breaking backward compatibility. It'll > have to stay that way until RHEL 9 falls out of support. Is someone collecting the cleanup TODO list for ~ mid-2032? (schedules subject to change, of course) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > One additional item to consider is to review the packager guidelines for use of /sbin (and /usr/sbin) in additional locations from those involved directly with installing binaries. In particular, I am thinking of the sysusers examples where the use of /sbin/nologin should, perhaps, be changed to /usr/bin/nologin. There are almost certainly other places in the docs/guidelines. The documentation updates are always the most annoying in my experience. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Staled PRs at https://src.fedoraproject.org/rpms/
On Thu, Jan 25, 2024 at 7:07 AM Miroslav Suchý wrote: > I understood that it may happen that you miss the notification. Or postponed > the work because you were busy and later > forget about it... Lots of valid reasons. While I am certainly not in favor of more "Are we there yet?" emails, I wonder if a gentle reminder every few months might not be appropriate if there are open PR's, as, as you say, sometimes there are valid reasons. I also wonder if a PR open for more than, say, 18 months might trigger a check to make sure the packager is still active. Both are un-resourced ideas, of course. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Tue, Jan 9, 2024 at 5:51 PM Zbigniew Jędrzejewski-Szmek wrote: > $ dnf5 repoquery --whatprovides '/usr/sbin/exabpg-*' > (no answer) > If you spell exabgp correctly (not exabpg) it works somewhat better. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 8, 2024 at 9:43 PM Zbigniew Jędrzejewski-Szmek wrote: > Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp. > Either a bug or I'm doing something wrong. And while I can hope that exabgp might be the singleton case, I really don't think you, or I, or other packagers (or FESCo), want to be surprised as to the potential impacts. Thanks for being willing to look further. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Jan 07, 2024 at 03:47:25PM +, Gary Buhrmaster wrote:
> > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote:
> > >
> > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > >
> >
> > I do not see as part of the plan a process to
> > go through all Fedora packages and identifying
> > binaries in /usr/bin that have the same name
> > as a binary in /usr/sbin (from the same, or
> > different packages) such that the packager
> > (or the multiple packages) will need to
> > coordinate the changes (perhaps by engaging
> > upstream).
>
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Scope
> lists 9 packages that was aware of that use usermode.
>
> $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf
> '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort | uniq
> -c | rg -w 2
>
> says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> need just to be dropped to prevent a FTBFS. I added this list with
> four packages to the Scope section.
Thanks, but I think the query does not produce
all possible results, as I know for a fact that there is
a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
and a (different) /usr/bin/exabgp-healthcheck file
(which is why I prompted my query, as I expect
there might be others (I plan to fix exabgp)).
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin > I do not see as part of the plan a process to go through all Fedora packages and identifying binaries in /usr/bin that have the same name as a binary in /usr/sbin (from the same, or different packages) such that the packager (or the multiple packages) will need to coordinate the changes (perhaps by engaging upstream). I agree that there should be few, but identifying impacts in advance provides for a better decision process, and minimizes the last minute work that packagers need to do (they will have a longer warning and preparation time). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Fri, Dec 29, 2023 at 12:31 PM Neal Becker wrote: > > On a philosophical note, I once worked on Apollo workstations. These could > switch behavior between sysv and bsd unix. To do this, the kernel would > interpret e.g. /usr/bin/$arch, substituting the env variable arch. At least > that is my recollection of how this worked. Elegant I think, but some might > see this as a security problem. > The AFS file system has a similar approach for its sysname, where the special value @sys is substituted by the kernel for files in that filesystem. A common way it was used was that something like /usr/local/bin was a symlink to /usr/local/.@sys/bin and the @sys variable would contain the architecture (and/or OS variant) redirect. The @sys value can contain a list of values to search for existence (exposed in /proc/fs/afs/sysname). On x86_64 I believe the default is amd64_linux26 (for historical reasons). For some large (often HPC) sites, which can have multiple system architectures and OS variants, having one common file system with software and libraries which can be selected by the client systems sysname "flavor" is valuable. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Sat, Dec 23, 2023 at 8:28 PM Christopher Klooz wrote: > Btw, does anyone know if this (in the practically-same manner) is really > already introduced in Windows, Mac, Android by default? There is a draft RFC for randomizing MAC addresses https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/ which also has references for Windows, Mac, and Android implementations. There are some issues with some implementations (iOS will create an entirely new MAC address if it has not connected to the named WIFI in some number of weeks, which can require all new device registrations for users). In any case, changing defaults that can impact user experience (or are required to be turned off, as some organizations document one needs to do for their use cases) should come with an additional toggle in the appropriate network configuration GUI menu. None of the examples of existing implementations for popular consumer platforms requires one to go into the terminal window and directly manipulate files. They all have a GUI toggle. Apple has their toggle called "Private Addresses"; Windows has their toggle called "Random Hardware Address"; Android has their toggle called "Privacy/Use Device MAC address" (at least that is what I think the names are, I don't actually have all of those platforms to test). It would be my recommendation that the various network configuration GUIs that are part of an official Fedora edition MUST have a GUI toggle to turn off MAC address randomization (I would guess under the Security tab?), and such a toggle SHOULD be included for all official spins. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
On Wed, Dec 20, 2023 at 7:51 PM Chris Adams wrote: > > Once upon a time, Aoife Moloney said: > > Enable IPv4 Address Conflict Detection by default in NetworkManager. > > Huh, I didn't realize NM didn't already do this... ye olde > network-scripts did. > As I recall, depending on configuration(s), systemd-networkd has done so for quite some time. Off hand I do not recall its various values, but it might make sense to align the settings. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel wrote: > > On 21/12/2023 14:33, Steven A. Falco wrote: > > On 12/21/23 08:53 AM, Neal Gompa wrote: > >> On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott > >> wrote: > >>> > >>> I'm -1 for this change, it shouldn't be enabled by default as it will > >>> cause issues for users using router mac filtering. > >> > >> What this seems to state is that the MAC address would be unique for > >> each SSID, but once it's picked, it would be locked in. That should > >> still make router-level MAC filtering possible, since the MAC address > >> would be stable for that network. > > > > What would happen on a network where I've set up the DHCP server in my > > router to map mac addresses to static IP addresses? Sounds like I'd > > have to disable the feature, at least on my home network. > > Either that or you would make a one off change to your DHCP server > to use the new per-network MAC address instead of the old one. Would it not have to be done every time one reinstalls their system? And on each SSID one connects to (so connect to your HOME-5G (for your 5GHz AP), and HOME-2.4G (for your 2.4GHz AP), wifi networks would get different MAC addresses as the SSID is different?) (side note: some DHCP servers may not like assigning different MACs to the same IP address to allow individuals to choose their own access point frequency range based SSID). While doing so as an individual would probably be minorly annoying, for some orgs, "re-imaging" a system is the standard practice for repair (or redeployment, or for each reboot for guest systems) and having a stable MAC address (whether wired or wireless) is necessary for institutional requirements. And for some orgs with advanced 802.1x network access controls, changing MAC addresses may result in even more additional tasks across different parts of the organization (yes, one should not use mac authentication alone for 802.1x, but that is a different topic). For orgs with a more sophisticated process, updating their ansible provisioning scripts to change the NetworkManager to use the hardware address may be possible, although for others, that will be one more step for tech support to have to do manually (and, of course, occasionally forget to do, as they are always overworked), but at the very least the proposal should probably call out that change requirement more explicitly for such orgs. Given the unknown impact on larger organization customers (rather than individuals taking their own devices to an overpriced coffee shop), I am currently leaning on the -1 side. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Proven to be sickened
On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto wrote: > Maybe we should have a flag in the src.fp.o package for the maintainer > to request a PR before committing to have a window for review, or like > me, the maintainer would like to not be bothered with things that > proven package can do by itself . > > Another thing is some proven packager which wants force the move to > autothings , which I don't like use it, ATM, because in my opinion > still have many problems . I think there is a difference between changes that have a formal change proposal (I am thinking something like removing make from the buildroot, which required many packages to add a BR: make, and for which PP's did a lot of the work for some packages), for which packagers were given a sufficient period of time to make the change on their own, and "philosophical"/"syntactical sugar" changes, such as the current "autothings", for which there is not an approved change for all packages (FD: I would object to making the "autothings" mandatory). If a proven packager changes the syntactical sugar without agreement by the current packager via a PR they have exceeded their mandate, and should be (first) asked to revert and formally apologize, and if they repeat such, removed from the PP list (fool me once, shame on you, fool me twice shame on me). FTBFS issues are, admittedly, complicated, but such updates SHOULD be via a PR. If a PP wants to claim they cannot follow that process, they need to demonstrate that a particular packager is not responsive (there is a process for that) rather then just deciding themselves it is too much trouble. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Proven to be sickened
On Tue, Dec 5, 2023 at 3:48 AM Kevin Kofler via devel wrote: > My pet peeve is provenpackagers or comaintainers who add unwanted automagic > (autorelease, autosetup, autochangelog) to my packages. I do not want any of > that in my packages, it just makes my work harder (or in practice, just > wastes my time for the revert that I am inevitably going to do). I do not have a dog in this particular fight, but I do have a strong belief that the primary developer of a package, or the primary admin of a package, gets to decide the syntactical "sugar" of the code(s) involved (I have seen PR's based on capitalization styles, and indentation styles, too). Those that want to change those need to arrange to take formal ownership of the development codes and/or packaging before they get change what the primary has decided to do. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Making -Wmissing-include-dirs an error?
On Mon, Nov 13, 2023 at 5:16 PM Jonathan Wakely wrote: > > Typically, yes, I'd expect a failure. But it's possible for code to do: > > #if __has_include() > # include > // use features in that header > #else > // roll your own inferior version > #endif And in the particular case of the Qt private headers (where this started) I have seen this, or an equivalent construct, used to not support a feature at all. And yes, I do believe Qt places some things into private headers that they should probably provide a public API to access, but that is a different issue. In *theory* the application would report that feature X is disabled or unavailable during configuration and/or during the checks, and the packager would be expected to realize the implications, but for large apps such messages might be missed or not understood. I am slightly in favor of making missing headers an error as long as it is easy enough to override that to at least provide a few more guard rails. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 39 Final blocker status summary #3
On Fri, Oct 20, 2023, 16:56 Adam Williamson wrote: > We're still kinda kicking around ideas for "fixing" this, but I think > if push comes to shove, we'll wind up revoting or waiving it as not > practically fixable. How about something of the form of an ExecStartPre expression (or script) that tests the date and if less than then (say) 2023-01-01 sets the date to the expected release date of F39 (via timedatectl)? Not quite right, but it would likely pass the gpg tests It can (hopefully) be replaced by something better in the future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 4:08 PM Chris Adams wrote: > Certainly - I was just looking for a more general solution to non-RTC > systems going forward. Ideally, there could be something triggered by a > lack of an RTC, but it looks like systemd path units cannot work based > on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that > would make it easy. I believe negation works (not tested) as in: ConditionPathExists=!/dev/rtc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 9:35 AM Tomasz Torcz wrote: > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. Personally, I have been using systemd-timesyncd for quite some time on the vast majority of my systems and am quite satisfied with it, but I believe that changing from chrony to systemd-timesyncd was considered too big of a last minute change since we are in the final blocker stage of a release. I believe that a change proposal (for F40) to change to systemd-timesyncd, or fake-hwclock (or some other agreed upon solution) by default should be created so the non-RTC systems will work properly at future upgrades (converting existing systems from chrony to systemd-timesyncd can be complicated if the systems has modified the default chrony config or is not a (pure) client, so that may only be a longer term fix). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: SPDX short name for "Redistributable, no modification permitted" (firmware)
On Sun, Oct 15, 2023 at 4:26 PM Jerry James wrote: > > On Sun, Oct 15, 2023 at 3:13 AM Robert-André Mauchin > wrote: > > I'm doing a MR on an old package that contains firmware data. > > > > I wanna convert to SPDX, what is the equivalent to "Redistributable, no > > modification > > permitted" in SPDX. > [snip] > > What can I use for SPDX? > > According to > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_redistributable_no_modification_permitted, > you should submit this license for review. See > https://docs.fedoraproject.org/en-US/legal/license-review-process/. I believe there is already an open issue for this: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Intention to tighten RPM crypto-policy back
On Tue, Sep 26, 2023 at 5:40 PM Kevin Kofler via devel wrote: > I am still opposed, because it is still a backwards-incompatible change that > breaks existing repositories (such as my Calcforge one) just so that someone > can tick a checkbox on some "security" checklist. Are you saying you need assistance to generate modern keys? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Fri, Sep 15, 2023 at 8:23 PM Neal Gompa wrote: > I will also point out the last time we followed RHEL into something, > we got the modularity system. That itself is an indicator that > inverting the relationship for decision-making is a bad idea. In theory, I like the concept of modularity. But, as we all know, theory and practice are not always the same, and modularity was a bridge too far. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: An update on RHEL moving to issues.redhat.com
On Wed, Sep 13, 2023 at 3:27 AM Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > IIRC it was a condition of that proposal that we wind up on a hosted > > version of the *open source* release of gitlab > > "hosted version" and "open source" is already a contradiction by itself. > https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html > > The Fedora Project's increasing reliance on third-party SaaS is a problem, > not a solution. Even if the server software happens to be FOSS, that is of > no help if you do not control the server and hence cannot control what > version is deployed. As (I think it was Ben who reminded us), the Fedora Council adopted (in 2018) the following statement: "The Fedora Project wants to advance free and open source software and as a pragmatic matter we recognize that some infrastructure needs may be best served by using closed source or non-free tools today. Therefore the Council is willing to accept closed source or non-free tools in Fedora’s infrastructure where free and open source tools are not viable or not available." If you don't agree with that decision, run for the council, or vote for representatives on the council who agree with your point of view and will work to rescind that statement. Until that happens, the statement stands as adopted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: An update on RHEL moving to issues.redhat.com
On Sat, Sep 9, 2023 at 1:05 AM Brendan Conoboy wrote: > RHEL making this change does not imply or require that Fedora do the same. I am neither suggesting Fedora should do so, or not do so, but just as a hypothetical, should Fedora choose to do so, do you know if RedHat would be amenable for such use of issues.redhat.com for Fedora bug tracking(*). My concern is that especially for packages that end up being both in Fedora, and in EPEL (of which I have a few) there are occasionally tightly related RHEL issues, and the advantages of having "one pane of glass" to follow the dependencies has had some advantages for me personally. (*) I am not a strong fan of jira, but neither am I a strong fan of bugzilla. Both have certain goodness, and badness, and ugliness. But they both mostly work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 F38 to F39
On Wed, Aug 23, 2023 at 6:23 PM Miroslav Suchý wrote: > * this command found zero issues on my personal system - great work all > everybody! On my small handful of systems I found zero issues (well, one issue on two systems with a 3rd party repo (which was actually my own local repo, so hoisted on my own petard since I had not yet rebuilt for F39 and the various app/lib uplifts)). Looks good to me. Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: PR to update exiv2 in Rawhide
On Mon, Aug 21, 2023 at 7:02 PM Michel Alexandre Salim wrote: > > Dear all, > > exiv2 has had a new release for a few months now - 0.28.0 - which causes > an soname bump. > > I've put up a PR for the update - > https://src.fedoraproject.org/rpms/exiv2/pull-request/3 - would > appreciate people taking a close look at this; I'll also prepare a COPR > with the dependent packages rebuilt > > In the meantime, there's a 0.27.7 bugfix release, any objection to > getting that packaged for stable releases? Per https://bugzilla.redhat.com/show_bug.cgi?id=1979565#c12 there appears to still be a pending legal review issue and you may need to scrub the sources of the BMFF parts before uploading to dist-git. I believe legal was pinged recently as to the status of the BMFF question. I have CC: the legal mailing list in case they have any input. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unannounced soname bump: libotf
On Wed, Jul 26, 2023 at 1:56 PM Michal Schorm wrote:
>
> My apologies !
> I built the new version when cleaning old PRs and I failed to check
> for the soname bump.
> Thank you for cleaning up after me. I will try my best to remember to
> check it next time.
I have found that using something like
libfoo.so.X{,.*}
in the %files directive can be a useful
reminder (enforcer) to reduce such
surprises (that particular glob presumes
semantic versioning, and that minor
and patch level updates do not require
rebuilds, but that is true much of the time).
To be fair, I have sometimes forgotten to
change the glob when I have intended to
bump the package/soname version in an
update, but at least I did get the intended
reminder!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On Sat, Jun 24, 2023 at 3:05 PM Michael Catanzaro wrote: > But in practice, we actually currently have a lot of desynced packages > where RHEL is ahead of CentOS Stream for various reasons. I believe > most such cases are mistakes that need to be corrected, not intentional > delays. E.g. if a particular developer just forgets to fix the CVE in > CentOS Stream, currently nobody is checking to catch that and complain > and get things fixed. Red Hat needs to catch and fix these issues > proactively, but is not currently doing so. Since only Red Hat is able > to commit to CentOS Stream, the community is limited to tracking > desyncs and complaining when it happens. (That would be really valuable > to do IMO.) Most of the time, as you say, things work well (at least in my experience). If one does find a security update that did not get streamed, is there a way for a non-customer[0] to open an appropriate ticket both now, and in the future when RH moves their internal bug tracker to jira[1]? [0] There are those that have used the clones and streams for some time without having to sign up with RH. [1] It is not clear to me if one will need a formal support contract in order to open tickets into the future jira instances. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Sat, Jun 10, 2023 at 4:36 PM Kevin Kofler via devel wrote: > Considering that Fedora buildroots always get killed off within days of the > EOL, I do not see why you are keeping epel-6 buildroots active 2½ years (!) > after its EOL. 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. I do not consider setting gpgcheck=0 overly onerous for EPEL6, but I do think we should want to avoid such actions becoming the expected behavior for the next time (and there will be a next time), where the workarounds might require a much bigger 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
Re: Plans for dhclient / ISC dhcp?
On Tue, May 30, 2023 at 11:08 AM Richard W.M. Jones wrote: > We really need just a dhcp client, no baggage. Busybox distributes Udhcpc, a small dhcp client intended for embedded systems, and perhaps might be a longer term viable solution for minimal appliances. And while I never looked at them, both perl and python have dhcp client libraries that might be able to be part of a possible solution. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, May 30, 2023 at 10:57 AM Florian Weimer wrote: > systemd-networkd has an integrated DHCP client, hasn't it? Yes (and I have migrated a number of my systems to using systemd-networkd), but Richard said systemd is not an option. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
On Mon, May 29, 2023 at 3:28 AM Kevin Kofler via devel wrote: > > Gary Buhrmaster wrote: > > RH's staff redundancies > > The position was clearly NOT redundant. The word (and all words are made up) is used by organizations to meet certain legal requirements (talk to *your* lawyer for a better explanation of all the details and subtleties of employment law if you don't understand employment law, as it is complex (and even more complex in multi- national organizations such as IBM and RH as some countries have "interesting" requirements); my understanding is based on occasional discussions with my employment lawyer colleagues, and I have mostly decided that is not a field I wish to become an expert in). > This is just RH unilaterally killing > jobs including a central Fedora position in order to increase IBM's profits. Any particular position (in a large enough company like IBM, or RH) has about zero impact on any organization's profits. It *may* indicate priorities (which is a completely different discussion, and which you might, legitimately, ask if IBM and RH is committed, and at what level, to Fedora in the long term(*)). Personally, I think the Fedora Program Manager (as embodied most recently in Ben) provided value to the Fedora community, as some of the work being done was something that volunteers cannot easily pick up (simply due to available time (resources)). I fervently hope that the council members will not (in the long term) try to "make do" with fewer people (asking others to do 130%), but will either offload to the community, or drop (after consultation with the community) some of the work the Program Manager or other members of the Council did (there needs to be a prioritized list of work and reassigments). If no one is willing/able to step up, some functions will need to be terminated for the good of the work/life balance of the remaining Council members (yes, some people live to work, and work to live, but that is not something we should expect of our hatters.). (*) Someone, and I am not sure of the process or protocol, should ask RH what they see and want Fedora to be, and how they intend to support (fund) that going forward. It is, perhaps, not a place I (or you) wish to be, but right now all we really know is that RH has decided to de-commit some resources. Perhaps they intend to add more resources in a different way. I would like to think that discussion may have happened (or at least started) at the RH summit, but as I do not not attend (no one is paying my attendance), I have no idea. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: SecureBoot certificates
On Fri, May 26, 2023 at 2:20 PM Steve Grubb wrote: > > Hello, > > I was poking around a F38 system to look over the Secure Boot certificates and > found something that may warrant attention. > I *suspect* this is all wrapped into the issue that shims must now have/use NX support to be signed, and that first requires the kernel patches that support NX to be merged. The thread about the NX requirement and the kernel patch is included (although a bit hard to find) in the ticket https://bugzilla.redhat.com/show_bug.cgi?id=2113005 I do not know where in the process the kernel patch currently is (last I knew, it was still in review). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Election Status?
On Thu, May 25, 2023 at 8:58 PM Justin W. Flory (he/him) wrote: > > The elections are now scheduled to start on Monday, 29 May and end on Sunday, > 11 June. Documentation and schedules are being updated. > > On Thu, May 25, 2023 at 6:55 AM Josh Boyer wrote: >> >> On Wed, May 24, 2023 at 9:34 PM Gary Buhrmaster >> wrote: >> > >> > I do understand why RedHat itself will not announce >> > who got laid off, but the Council members should have >> > been informed (I hope!) at the time, and should have >> > worked on an announcement to the community, even >> > if all they could say was "stay tuned, we are working >> > it out". >> >> The Council members were not informed in advance. They found out >> about the layoffs at the same time the public did, and also found out >> about Ben's specific role only after he informed others he was >> impacted. > > > This isn't incorrect but I do want to clarify the timeline because it is what > I would have wanted to know as a community member and there are events that > may appear to be conflicting in the timeline (e.g. Ben's blog and my LinkedIn > recommendation for him). We did have some advance notice before the general > public. Ben mentioned the Red Hat reductions were announced in the US on 24 > April and that was when we found out. We knew Ben's last day was 12 May. That > was as much advance notice that we had. > > The week of 24 April was not productive. It was a shocking week for nearly > everyone. But we did start transitioning Ben's work before his final day and > his blog post, which is why you are seeing incredibly helpful Fedorans who > are stepping up right now and picking up the slack in Ben's absence (thank > you folks!). There are going to be gaps. Some things will fall through the > cracks. But we will get through this. Calling out slippage as Fedora Council > tickets is likely the most effective way for (1) problems to be identified > and noticed, and (2) for Fedora leadership to take steps at resolving those > problems. And, while I can understand that the days after April 24th may not have been comfortable, and taking advantage of access to Ben while he was still available was a good thing, I do believe some member of the Council should have started working on the note to the Community to be sent on (or about) May 15th with something of the form that RH's staff redundancies have resulted in the elimination of the position of Fedora Program Manager, and the Council is working through how the existing roles and responsibilities of the Council will be revised (downwards?), and redistributed given the reduction of staffing, and if anyone sees something getting dropped, create a ticket (properly wordsmithed by someone with actual skills in writing words, of course). I think we all appreciate that everyone is stepping up and trying their best. Thank you! But I will continue to believe that we(*) should not have had to find out about the changes when the elections did not happen, which was the point of my request that this be taken as a learning opportunity about better communications for the next time (which may have nothing to do with future redundancies, as people can leave, or have life emergencies, and those can impact ongoing activities). Thank you for your consideration. (*) I was aware of it personally because it was posted elsewhere, but clearly a lot of people seemed to have been surprised. I do not believe that should happen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Election Status?
On Wed, May 24, 2023 at 9:50 PM Mattia Verga via devel wrote: > Wait, what?? Someone at RH wakes up in the morning and decides to cut > one of the key roles (or better, THE) of Fedora community and this goes > completely unannounced, unnoticed and without any backup plan? I do understand why RedHat itself will not announce who got laid off, but the Council members should have been informed (I hope!) at the time, and should have worked on an announcement to the community, even if all they could say was "stay tuned, we are working it out". I would like to believe this will be a learning opportunity for the Council to improve their communications for the next time something impacts their group (and the Fedora community). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Election Status?
On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: > What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Heads up! Nforro's awscli2 is working. It's time to retire the awscli
On Sat, May 13, 2023 at 7:02 PM David Duncan wrote: > > Now that awscli2 is out and functional. Excellent! I will finally be able to stop installing a local version. > Gwyn and I are thinking it's time to retire the original > awscli package in favor of this one. We are thinking > that it will be best to keep the awscli (v1) maintained > until the release of F39 later this year and retire it from > the active releases it at that time. If there is anyone > taking a dependency here that thinks that they will need > more time, please let us know. I suspect someone, somewhere, has scripts that use/depend on the old behaviour that are not carried forward, but the changes are well documented, so as long as there is sufficient warning for people to migrate I would hope there would be no reasonable complaints. Thanks for this work! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: BiggerESP (Self-Contained Change proposal)
On Thu, May 11, 2023 at 3:10 PM Lennart Poettering wrote: > > On Mi, 10.05.23 17:54, Chris Murphy (li...@colorremedies.com) wrote: > > > > Read-only drivers, which are the only drivers under discussion here, > > aren't a per se problem because they can't modify the file > > system. So they have no complaints about that. > > No. Not true. There could (in theory) exist a read-only implementation of a journaling file system that applied the journal as part of its processing in memory (or some other transitory copy method). To say that would be extremely fragile is an understatement (it is, in essence, a full implementation of the filesystem code). I can't say I am a great fan of the fat filesystem, but it is ubiquitous, and part of the machine boot standards. Proposing an alternative may be an interesting intellectual exercise, but one needs to work with the various industry consortium's to make it a viable reality and then wait 10+ years before it get implemented everywhere, and 20+ years before someone will not complain you are obsoleting some perfectly usable hardware. Quite honestly, I think that if the end game is likely UKI on the ESP even 500MB might be a little small, as one needs not only space for the kernel images, but firmware updates (and some firmware update images are getting rather large), and any alternative OS files, but it is much better than 200MB. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: BiggerESP (Self-Contained Change proposal)
On Wed, May 10, 2023 at 3:56 PM Neal Gompa wrote: > At least in the upstream kiwi project, we encountered problems making > bigger ESPs because not all UEFI implementations handle FAT32 (despite > it being part of the spec). In particular, there were a few server > boards and especially AWS EC2 that couldn't handle it. As I recall, modern FAT16 implementations (and yes, not all UEFI implementations might support modern FAT16) support a 4GB disk size, which is more than the proposed 1GB size. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, Apr 26, 2023 at 9:04 AM Alexander Bokovoy wrote: > > Hi, > > This morning I woke up to find that packages I maintain were orphaned > out of blue. Nobody contacted the maintainers, nobody raised any tickets > to releng, as far as I can see. Yet, releng ran the orphaning from what > I saw in a few bugs. > > What is happening? Who and how made those decisions? Removing inactive packagers (who have not made any package updates, nor responded to direct emails, for an extended period are removed from the packagers group as part of good security hygiene per: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ It is an artifact of that fact that in Fedora, packages have only one main admin, and when that packager is removed from the packagers group, their packages get orphaned (there is no automated promotion, and nor should there be, to select one of the other maintainers, as that would also imply other responsibilities that one might not want). You (or other interested packager) can go to: https://src.fedoraproject.org and "Take" that packager to become the new main admin/owner. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: SPDX License Phase 2 (System-Wide Change proposal)
On Tue, Mar 28, 2023 at 2:01 PM Zbigniew Jędrzejewski-Szmek wrote: > Hmm, that'd mean thousands of pull requests… I think if we agree to > this, it would make sense to just push a fix directly. Each pull request > ticket is a few mails, and with 8096 expected pull requests, that is > quite a lot of churn. As someone who has migrated all of their packages to SPDX, I don't really have a lot of skin in the process chosen to move forward. I do agree a pull request is a nice thing to do. It gives the packager one last opportunity to do the work on their own schedules and workflows, but any packager who has not yet done the work (after all the reminders, hints, and announcements of tools to make things easier) seems (to me) unlikely to be waiting for that pull request to finally do the work. It is probably time to just announce the push(es) and just do it. Yes, some packagers will complain about a PP using their authorities, but it is not as if they will not have had many many many months to do the work in advance, soI would suggest you just announce and push forward. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: > I see your point. It sometimes also happens when the EPEL package is a > dependency of the important package, the customers aren't actually asking for > the EPEL package. While I am sure that occasionally RH chooses to add a package to RHEL just because they think it is a good idea[0], I would expect that these days adding a package is mostly about customer requirements[1], even if it is an indirect requirement (even as a dependency of a dependency of a dependency). I think your new wording is fine. There will of course still be a few EPEL maintainers who will ask the question of "why now?", but those are likely to be few enough to handle on a case by case basis. Thanks. [0] Although I suspect that is not a common occurrence, as few organizations want to add to their ongoing support burden without something more formal than a whim. [1] Formal requests, or easily anticipated requests based on industry technology directions, and/or from the various industry advisory boards. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] [SONAME BUMP] libcbor will be updated to 0.10.2 in rawhide with a soname bump
On Tue, Mar 7, 2023 at 7:04 PM Richard Hughes wrote: > > On Tue, Mar 7, 2023 at 4:55 PM Gary Buhrmaster > wrote: > > Let me know if you have any issues > > with the build. > > All done, thanks. Thank you. I have submitted the side-tag update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-45ad1ef176 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [HEADS UP] [SONAME BUMP] libcbor will be updated to 0.10.2 in rawhide with a soname bump
On Tue, Mar 7, 2023 at 4:32 PM Richard Hughes wrote: > > On Tue, Mar 7, 2023 at 3:55 PM Gary Buhrmaster > wrote: > > I will rebuild libfido2. For fwupd, I will need the maintainers > > (CC'ed) or a proven packagers assistance. > > No problem at all, thanks for letting me know. Do you need me to do > the build now? The side-tag is ready for your build (libcbor and libfido2 have already been built). Let me know if you have any issues with the build. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS UP] [SONAME BUMP] libcbor will be updated to 0.10.2 in rawhide with a soname bump
libcbor will be updated to 0.10.2 in rawhide in the next week or so, which includes a soname bump. The list of affected packages in rawhide are: libfido2 fwupd I will rebuild libfido2. For fwupd, I will need the maintainers (CC'ed) or a proven packagers assistance. I have used the Mass Prebuild tool (mpb) to verify that all the packages rebuild successfully, so I do not anticipate any surprises. Please use the side tag f39-build-side-64500 Thanks! Gary ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Changes to Bugzilla API key requirements
On Fri, Feb 24, 2023 at 4:56 PM Solomon Peachy via devel wrote: > (I admit I'm surprised that "Free Software for Everything" Red Hat is > chosing to base something so fundamental to their business on a highly > proprietary tool. I suppose O365 is just a matter of time...) They probably also use proprietary ERP systems, as while critical to running the company, they are not fundamental to their services or offerings. It is important to remember that bugzilla is more of an issue tracker, while Jira (and others such as Redmine) are a step up to be project trackers. Once you get beyond a certain size, you find you need to track the entire project's status and progress, and not just at the issue level. It is sometimes possible to use an issue tracker as a poor project tracker by creating a mega issue which "depends on" other specific issues, but it is not quite the same level of integration as a project management tool, which also can deal with resourcing and scheduling, and, as you mention, produce detailed reports so management can show they and their team is producing results (and value). While there are certainly some FLOSS tools out there for project management, they tend not to be in the same class or ability to scale as tools such as Jira, and while some might want to see such solutions be built and available for free, building a viable business providing such a solution is going to be really hard (if not impossible). I expect Jira (and its ilk) to be the tool chosen for larger organizations and projects for quite some time (even as I really dislike its default UI). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Changes to Bugzilla API key requirements
On Thu, Feb 23, 2023 at 6:48 PM Ben Cotton wrote: > I have a survey prepared that will be opened once the F37 > retrospective survey is done. This will give us a basis for evaluating > our requirements as we look for possible replacements. Thanks for planning on the followup. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Changes to Bugzilla API key requirements
On Thu, Feb 23, 2023 at 5:54 PM Matthew Miller wrote: > The "good news" is that Red Hat has announced a move away from Bugzilla for > future products. (They're going to Jira.) RH Bugzilla isn't officially shut > down, but its days are numbered. We need to come up with something else. "Good" is in the eyes of the beholder. I can't say I am enamoured of bugzilla (any variant), but it has been basically an adequate solution. Having a "one pane of glass" view of both RH EL and Fedora bugs/issues (which are sometimes related) is something I am concerned will be lost when RH moves issues to jira (and I really don't look forward to having to look two different places for possible bug reports or resolutions). I seem to recall that some of the Fedora people were talking about creating a document that would show what "we" use bugzilla for so that a future issue/bug tracker solution (whatever that might be) could be evaluated and any prep work needed to potentially unhook Fedora's procedures/processes from bugzilla could be started early (should the eventual chosen solution not be able to provide those features). Did that happen, and if so, where is it located? And does the document capture other wants/desires for new/dropped functionality? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, Feb 21, 2023 at 8:48 PM Matthew Miller wrote: > 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. While occasionally I have seen a small decrease in the size of the files transferred (which certainly can benefit some people some of the time), the total elapsed time of the transaction has always ended up being higher as the recreation of the original rpm exceeds the time that it would have taken me to just download the full new rpm (with an admittedly reasonably high speed network provider in my environment). However, that is an end user experience. What about the mirror providers? Even a small percentage of bandwidth savings might be useful for them (depending on their cost model) at the scale(s) they may be operating. Has anyone asked those providers, or do all (or most) now have a network cost structure such that it does not matter? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski wrote: > It would be really nice if the wording of the bug could contain some > kind of a "thank you" note to the EPEL maintainers of the package in > question. Not everyone will understand this process as "great, I don't > have to maintain package X anymore, Red Hat will be doing that for me > from now on". Some folks may take it as "Oh no! Red Hat is taking away > my toy! Why?!" Ideally, there should still be a way for EPEL > maintainer(s) to continue contributing to the RHEL package. Perhaps add something like (wordsmithed by someone competent in such things): "The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product" ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should python-mysql be retired in Fedora and EPEL?
On Thu, Feb 9, 2023 at 8:40 PM Michel Alexandre Salim wrote: > > Dear fellow Fedorans, > > It seems that python-mysqlclient will now transparently upgrade python- > mysql since 2.1.1-2 (for Fedora): > https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b044f6976e1a07f06226ed3e?branch=rawhide > and 1.4.6-6 (EPEL 8) > https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898ba87e93f9dfefbc9a7fb09e1?branch=epel8 > > (python-mysql was never in EPEL9) However, as I recall, since the python-mysqlclient in EPEL9 does not include the obsoletes/requires on python-mysql, spec files (or applications) that have a BR/R of python-mysql will not get the updated python-mysqlclient auto-upgraded. The EPEL9 python-mysqlclient build should probably be updated with those obsoletes/requires tags to minimize surprises. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Tenacity
On Tue, Feb 7, 2023 at 7:26 PM Philip Rhoades via devel wrote: > > People, > > Has there been any discussion about getting a Tenacity RPM going for > Fedora? - I would prefer that to having to use the AppImage version . . > As I recall, in the beginning, Tenacity (to perform most meaningful operations) required FFmpeg, which was not in Fedora, so that was a clear show stopper. Now that FFmpeg is (or at least with the codecs without IP encumbrances) Tenacity might be able to be packaged as long as it does not include any other libraries that are IP encumbered. Someone will need to perform that IP review, as codecs are a minefield. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: List of long term FTBFS packages to be retired next week
On Tue, Jan 31, 2023 at 12:45 PM Miro Hrončok wrote: > If you see a package that can be rebuilt, please do so. > tpm2-tss-engine mzavalavz No longer FTBFS. It can be removed from the to be retired list. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
On Tue, Jan 31, 2023 at 12:45 PM Miro Hrončok wrote: > If you see a package that can be rebuilt, please do so. > tpm2-tss-engine mzavalavz I can fix this (up-lift to the current release), but I don't see a way to do so before retirement as the current maintainer seems mostly MIA. Am I missing something in the process (as a non-PP). If the package is orphaned, I would just take it, up-lift, and rebuild, but I do not see that as a viable option with the current maintainer is (apparently) non-responsive (yes, I could open the entire non-responsive process, but at this point that would take longer than the date of retirement). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Nonresponsive maintainers ( was Re: Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts )
On Fri, Jan 27, 2023 at 1:10 AM Kevin Fenzi wrote: > jaltman I have sent an email to Jeff, and hopefully he will update his bugzilla email. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: List of long term FTBFS packages to be retired in February
On Thu, Jan 26, 2023 at 10:08 PM Miro Hrončok wrote: > Some packagers do set the bugzillas to ASSIGNED to get rid of the reminders > and > then they forget to actually fix the FTBFS, cannot figure out how to fix it, > are blocked on externalities that never happen, etc. Perhaps ASSIGNED should not get rid of reminders quite that easily? I am all in favor of reminders that can be deferred for a time (other priorities happen), but one should not be able to permanently defer the reminders if the work is not yet completed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 38 mass rebuild is finished
On Tue, Jan 24, 2023 at 7:29 AM Jeff Law wrote:
> On 1/24/23 00:16, Jakub Jelinek wrote:
> > See
> > https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
> > Some libstdc++ headers included in older versions
> > as an implementation detail but no longer do.
> >
> > Including stdint.h will introduce ::uint32_t type among others,
> > but not std::uint32_t, if you use the latter, you need to
> > include .
> I've got a partial list of packages affected by the ongoing header
> cleanups in libstdc++:
I am in favor of header cleanups, and moving forward
with new(er) gcc versions, but I wonder that if in the
future the Fedora gcc change proposal can reference
the porting changes rather than referring only to the
main gcc docs as an additional heads up (in this case,
I skimmed the gcc 13 changes page, but you had to
follow yet another link for porting issues to see the
library header changes (and I did not go looking
there, my bad)).
While it may take me only a minute to recognize
the issue when I see the compile failure for a
missing header ("and there they go again..."),
writing PRs for upstreams and getting those fixes
into their release cycle may take somewhat longer
(and I prefer not to carry local patches in packages
when possible).
Had I seen cstdint I like to think that I would have
tried a rebuild with gcc 13 earlier to see what
(if any) upstream(s) needed some encouragement
for support gcc 13.
Thanks for the consideration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: When to close CVE's
On Fri, Jan 20, 2023 at 4:47 PM Gary Buhrmaster wrote: > such as yourself are contentious about > doing the right thing). Obviously that word should have been conscientious (I hate autocorrect). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: When to close CVE's
On Fri, Jan 20, 2023 at 4:53 PM Kevin P. Fleming wrote: > Small clarification: where you wrote 'component' you meant 'product' :-) > BZ has both Products and Components, forming two levels. RHEL 7/8/9 are > Products, on the same level as Fedora. Thanks. I suppose I should have actually checked the terms before posting. But posting before checking is a time honored tradition which I am too often guilty of :-). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: When to close CVE's
On Fri, Jan 20, 2023 at 3:48 PM Richard Shaw wrote: > I think in practical terms that makes sense but our tools don't really help. I agree, and that seems to be an artifact of the single Fedora component in RHBZ, which treats Fedora as one thing. I supposed (in theory again) that there could be a master bugzilla for the CVE which depends on child bugzillas for each impacted Fedora release, and would get (auto) closed only when all the child bugzillas are resolved (either by updates or the Fedora release aging out). Alternatively, an entirely different bugzilla for each Fedora release (but as Fedora is just a single component, unlike each RHEL which has different components for each version, I don't think that works). > So I guess what I'm asking is if there is a specific policy around this? If > not, should there be? I think there should be at least an agreed upon best practice, which needs to be explicitly documented somewhere (maybe it is, but I don't recall seeing it, so I am not following it). So, as with much of Fedora, we fall back to depending on (usually volunteer) packagers to do the right thing (which works out well most of the time because packagers such as yourself are contentious about doing the right thing). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: When to close CVE's
On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw wrote: > > So is it when a build is complete in Rawhide? Or must *ALL* active releases > get the "fix"? > I am not sure it is official policy/practice, but in theory I would think that the CVE is technically closed when all impacted Fedora releases get the fix, but if you use various "Resolves rhbz#1234567" syntax in the change log (and I generally try to do so in addition to referencing the CVE by it's identifier) I seem to recall that as soon as the package hits rawhide the issue gets closed. It is therefore up to the packager to make sure they have actually done the necessary builds/backports to previous releases as appropriate (not all CVEs may apply to previous Fedora releases as they may have different package versions, of course). I have mostly decided that in practice, as long as I have done any appropriate builds/backports, and one is just waiting for the usual distribution delays, that it is good enough (although high severity CVEs may need special handling). Or are you asking something different? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: FYI... yubioath-desktop is slated to be removed from F38 repository
On Thu, Jan 19, 2023 at 3:53 PM Kevin Kofler via devel wrote: > Why not just ship the legacy version in F38 proper rather than Copr? The new > stuff can be packaged when it is ready, probably as a F39 or F40 Self- > Contained Change. Is someone working on packaging the Dart and Flutter SDK (and all their dependencies, which I had had this vague recollection also required gradle, and, well, gradle is its own issue) for Fedora in that F39/F40 time frame so that they can be used to build apps such as the new yubikey manager? I must have entirely missed that that effort was ongoing as the last discussion about Dart that I recall was years ago, and it was more of a wish rather than a resourced 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
Re: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
On Thu, Jan 19, 2023 at 10:52 AM Michal Schorm wrote: > Would you see a value in e.g. some kind of a robot reminding > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI > check) "Reminding" is another term for nagging. Fedora should not be a nag when there may be reasons for the choices (for example, while one can claim that one should not be running obsolete system versions, sometimes there are "reasons", and that system may even be being supported through an extended support contract). Packager workflow can be complicated, and we need to respect that the many volunteers that contribute to Fedora may have needs outside of the pure Fedora ecosystem. Adding such a check to rpmlint when a packager does their update checks, on the other hand, might be a reasonable approach, as packagers can decide whether to remove the code fragments, to override that check in the rpmlint configuration, or just ignore the suggestion, as they see fit. As for my personal practice, I tend to remove such old code when I decide to review the entire spec file (i.e. review/modernize it for current packaging guidelines typically with a major new version of the software, or I have just adopted an orphaned package that I need), or the spaghetti if/elses become confusing even to myself, and it needs cleaning, or when I am trying to avoid doing something else (sometimes it seems like cleanup should be quick and easy (sometimes it is neither) which I think I can actually accomplish right now). I rarely go looking for new things to add to my infinitely long TODO list just because I could add it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: SPDX Office hours
On Thu, Jan 12, 2023 at 10:19 PM David Woodhouse wrote: > The English word for that is 'fortnightly', FWIW. While that is Old English, and still commonly used in parts of the world and in some formal language usage, most people just use the words "every two weeks" rather than asking people to pull out their OED. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Scripts to rebuild dependencies in copr
On Thu, Dec 22, 2022 at 4:46 AM Kevin Fenzi wrote: > > On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote: > > I've been using an old review_pr.py script produced by the Fedora > > Stewardship SIG to rebuild the depedencies of a package in COPR to test > > changes/updates to packages. It's been incredibly useful. However, it > > seems that the github repo has disappeared. > > > > Is there anything else out there in use that is actively maintained? > > There's the mass pre build project that was recently announced here: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/ > > I've not tried it yet, but it's on my list to look at. I have tried it on a simple package with only a few dependencies, including a recursive one (for which I had already manually done all the usual processes needed to determine dependencies and rebuild so I already knew how things should be expected to go) and after a bit of a learning curve using a new tool, I found it worked rather well, and certainly was less error prone than doing things the way I had been doing them (manually) on the occasion I had needed to do such rebuilds. The project is certainly worth a look. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 for advice - ffmpeg-free and wf-recorder
On Sun, Dec 18, 2022 at 3:29 PM Vitaly Zaitsev via devel wrote: > > On 18/12/2022 15:34, drago01 wrote: > > Why would they? The patents apply to the algorithm, not to any API. > > Help in circumventing patents. Your lawyer may vary in regards to the advice they provide as to an organization's exposure to claims of "contributory infringement" for any specific case(*) but with exceptions(**), one rarely wants to find out what a court in Waco TX(***) might decide. (*) And it is always about the details. Generalities may provide guidance, but the specifics matter (even things explicitly stated as a violation may be allowed if the details support an exception). (**) There are sometimes individuals or organizations who explicitly choose to take an action in order to challenge specific laws or regulations, but such cases can also come with risks (and are often done in a way to attempt to limit the potential losses). (***) The venue shopping that ended up with many patent related cases being brought in Waco TX has been mostly eliminated, but most organizations do not wish to go to any court in the first place (even if you win you lose after spending millions of dollars in legal fees, and if you lose it can be orders of magnitude more). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
On Thu, Dec 8, 2022 at 5:29 PM Adam Williamson wrote: > It shouldn't be too hard to try this out - it's just one setting in > lorax somewhere, but I gave up on this alleyway before figuring out > exactly where to set it. Well, a *very* unscientific (a few random files) showed a mostly small difference between xz and zstd at ultra compression levels (sometimes xz won, sometimes zstd, mostly by small margins), so it is probably mostly a wash (there are probably a few outliers, as there are always outliers). So it seems like zstd was not a good idea. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
