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
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_an
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 packa
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.fedor
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 won
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 b
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)
--
___
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 th
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
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 propos
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.
> Rea
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
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.
>
“Underst
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 Prebui
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 opini
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
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
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.fedo
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
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 t
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)?
>
> Almos
On Mon, Aug 22, 2022 at 4:21 AM Kevin Kofler via devel
wrote:
> PS: I find it incredibly rude to share a paywalled link on a public mailing
> list,
I 100% agree with this (although, to be slightly fair, this does
regularly happen on many of the lists I read, as people just
presume (falsely) that
On Wed, Aug 24, 2022 at 3:14 AM Kevin Kofler via devel
wrote:
...
> This is simply a non-starter.
...
> PCRE 1 needs to remain as a fully supported compatibility library for the
> foreseeable future.
...
> In the end, my suggestion if you are unable to deal with the security
> vulnerabilities is
On Thu, Aug 25, 2022 at 7:57 AM Miro Hrončok wrote:
>
> Hello folks,
>
> during our Nest FESCo session, we've talked about enabling Koschei [1] for all
> packages automatically.
I am not anywhere near the deciders group, but this
(enabling Koschei by default) just makes too much
sense not to do f
On Sat, Sep 3, 2022 at 10:01 PM Adam Williamson
wrote:
> Look, I'm getting old, okay? ;)
I am highly confident that everyone is getting
older (with the possible exception being if
your name is Benjamin Button).
> But yeah, looking at that, one 'loophole' is it doesn't check if
> they're actuall
On Sun, Sep 4, 2022 at 1:06 AM Kevin Fenzi wrote:
> Perhaps it would be better (although more noisy) to just mail all
> provenpackagers every cycle and ask if anyone would like to leave the
> group?
One should ask a PP (I am not so honored), but getting
an email every cycle (and requiring an aff
On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga via devel
wrote:
> If anyone wants to have a look to what packages **may** be orphaned when
> those users are removed from the packager group, I've set up a script
> and uploaded the results here [1].
Thanks for doing this.
The list does not look undu
On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson
wrote:
> Well, not really. 2FA isn't a magic bullet. I would be in favor of
> doing this, but you can't treat any security measure as solving all
> your problems completely.
Nothing is a magic bullet (and most security can be bypassed
with the $10 (
On Sun, Sep 4, 2022 at 3:48 PM Adam Williamson
wrote:
> Personally, once a year wouldn't be anywhere near frequent enough to
> trigger me to Do Something About It - it took me years to turn off
> Bugzilla's "hey look you have needinfo bugs!" thing and I was getting
> that every *day*. :P But I du
On Sun, Sep 4, 2022 at 6:29 PM Alexander Bokovoy wrote:
> You might want to watch our Nest with Fedora 2022 talk. More features
> are coming too, we are working on a direct FIDO2 integration in SSSD and
> FreeIPA .
Thanks for the update. Good news about the progress. I will watch the talk
On Sun, Sep 4, 2022 at 5:30 PM Michael Catanzaro wrote:
> And anybody who isn't willing .
... or able (they are not free, and there may be other
restrictions regarding crypto capable device export/import
that can require a bit of hoop jumping due to sourcing
site shrinkage, all of which does
On Tue, Sep 6, 2022 at 8:40 AM Vitaly Zaitsev via devel
wrote:
>
> On 06/09/2022 10:26, Ondrej Mosnáček wrote:
> > This is just not true. Anyone with an Android or iOS device can set up
> > a software token via FreeOTP [1].
>
> I'm OK with software 2FA authenticators, but they want to force everyo
On Wed, Sep 7, 2022 at 12:27 PM Petr Pisar wrote:
> Do people lose their tokens more often than forget their passwords?
Depends on the person, of course. However, it is
less common that one loses a token and does not
somewhat quickly notice it (especially if it is on their
mobile device, or the
On Fri, Sep 9, 2022 at 10:47 AM Vít Ondruch wrote:
> Nevertheless, this might soon become non issue given:
I think that that may depend on one's definition of "soon",
but I do agree that it would be useful to understand how
CVE tracking bug workflow is being considered to be
handled in the futur
On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi wrote:
>
> On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> >
> > Proven packagers seem to be a fair category to address. Also packagers
> > responsible for security-related bits of the distribution. Compilers?
Perhaps any packager w
On Thu, Sep 15, 2022 at 6:58 PM Adam Williamson
wrote:
> There's a kind of "surprising" property of the critical path list too -
> it contains some things you might not expect.
I was (initially) thinking of the critical-path-base list,
but you are right that the critical path is in the eyes of
t
On Tue, Sep 27, 2022 at 8:06 PM David Airlie wrote:
> Think of it like a jigsaw puzzle, where the person who places the last
> piece in the puzzle pays the license. But then stop thinking of it
> like that and just assume it's a lot vaguer and way more legally
> involved than that.
So, for CPU's
On Thu, Sep 29, 2022 at 12:56 PM Kevin P. Fleming wrote:
>
> On 9/28/22 22:42, Gary Buhrmaster wrote:
> > So, for CPU's with iGPUs sold retail to people
> > like me, does Intel (and now including AMD)
> > include the IP license? If not, how can I get one
> >
On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote:
> Would you be willing to pay for that feature?
A "freemium" COPR service?
I suspect that that would be such a
niche service that the cost per user
(to pay for the overheads to create
and maintain it) would not be
acceptable to anyone.
_
On Thu, Oct 13, 2022 at 3:13 PM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > I'm not going to get into this too much, but suffice to say, it's not
> > universally accessible as a CA.
>
> I would very much be interested in those details though.
As I recall, the current LE root certifica
On Thu, Oct 13, 2022 at 3:56 PM Josh Boyer wrote:
>
> On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster
> wrote:
> >
> > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer
> > wrote:
> >
> > > Would you be willing to pay for that feature?
> >
> >
On Thu, Oct 13, 2022 at 4:57 PM Maxwell G via devel
wrote:
> Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
> any publicly available IPs. Using dns verification is required to obtain a
> Let's Encrypt wildcard certificate.
While I tend to prefer using the dns-01 challen
On Fri, Oct 14, 2022 at 1:39 AM Kevin Kofler via devel
wrote:
> ... but this is absolutely absurd.
To (mis) quote Randy Bush: "their application, their rules".
If you don't like them, find another provider.
I hope that RedHat quickly supports passkeys, where
this all becomes moot.
Unless you sh
On Tue, Oct 18, 2022 at 8:34 PM chedi toueiti wrote:
>
> thanks for the insight, I'll try to see if they could use my help.
>
There was also some discussion on this list which
mentioned the (lack of) qt6-qtwebengine towards the
beginning of the year (the discussion was about
chromium, but qt6-qtw
On Sat, Oct 29, 2022 at 12:44 AM Adam Williamson
wrote:
>
> # F36 Blocker Review meeting
If this was a test to see if anyone noticed the title being
wrong, I am afraid I have failed that test for the entire
cycle.
___
devel mailing list -- devel@lists.f
On Sat, Oct 29, 2022 at 7:05 AM Adam Williamson
wrote:
> I swear I proofread these things. Just apparently not hard enough.
Swearing hard can get you disinvited from the
trendy restaurants (except for Brooklyn, where
every other word has been required to be (by
legislation) the F word).
On Thu, Nov 3, 2022 at 12:10 PM Ian McInerney via devel
wrote:
> But the packaging guidelines already mentioned not globbing the soname part
> of the files, so this change makes no difference to that use case. Extending
> the no-globbing rule to other directories like datadir seems very excessi
On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen wrote:
> Or they will just do what I used to do long ago and just do a temp spec file
> with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` and
> replace the data in the pushed spec with the list. Nothing is caught because
> fe
On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
wrote:
> there, I did it for free. Took one minute.
Clearly it should be submitted as a PR to the kernel package.
And another for the glibc package (that
one likely will take more than a minute).
___
deve
On Thu, Nov 3, 2022 at 4:07 PM Stephen Smoogen wrote:
> At the moment the biggest set of packages that need cleanup will be perl,
> golang and then about a couple hundred library rpms.
I would think that the man api definitions may
be the most interesting for some libraries
(many files, sometim
On Thu, Nov 3, 2022 at 6:34 PM Adam Williamson
wrote:
> Thanks to Aleix Pol, we figured this was due to a missing rebuild of
> layer-shell-qt , which uses private Qt symbols and so needs rebuilding
> for each new Qt version. I did that rebuild and KDE's fine again in
> today's Rawhide, so resume
On Wed, Nov 9, 2022 at 1:52 PM Miroslav Suchý wrote:
> Actually... if you add there the dummy changelog entry, it makes my work
> easier.
Does it make sense for your script in some future
iteration to add in the capability to check if the
license is identical pre/post SPDX if the spec does
not
On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen wrote:
>
>
>
> On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote:
>>
>> I sympathize greatly here. It was a pain to wire up "logout" to the
>> "relogin" property in updateinfo (the field had been in bodhi for a
>> decade and nobody wired it up to the
On Sat, Nov 12, 2022 at 6:16 PM Sandro wrote:
> I appreciate any pointers,
This change to the mpg123 build looks suspicious to me:
* Fri Nov 11 2022 Phil Wyett - 1.31.1-2
- Use --disable-largefile and allow co-installable arch devel packages
__
On Sat, Nov 12, 2022 at 7:19 PM Kevin Kofler via devel
wrote:
> (E.g., many maintainers
> enable automatic pushes because they need to wait so long to be allowed to
> push an update to stable that they would forget to push it manually. But
> automatic pushes are the most common source of bad upda
On Wed, Nov 16, 2022 at 5:38 PM Richard Shaw wrote:
> I recently switched internet providers so I was looking for an ACK that it
> wasn't just me.
I am curious, did you try https://status.fedoraproject.org and did
it show the outage at the time (since it is manually updated, it
would typically
On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý wrote:
> I have to make confession. I am breaking this guidelines too. With releasing
> of new version of Mock and fedora-license-data. The problem for me is that
> the list of these exception is not available and not maintained. I inherited
> Moc
On Mon, Nov 28, 2022 at 11:01 PM Adam Williamson
wrote:
> qemu -> ceph -> openssh -> libfido2 -> libcbor (unmaintained)
I'll pick up libcbor, as I am the packager for libfido2.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
On Thu, Nov 10, 2022 at 8:24 PM Ben Cotton wrote:
> === Items in progress ===
> * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F38
> * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F37
> * Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F36
> * Add `%perl_
On Thu, Dec 1, 2022 at 1:49 PM Richard Shaw wrote:
> No, but it will become more and more difficult to maintain. Right now it
> needs to be ported from pcre to pcre2 which is beyond my capabilities.
I believe it will also be broken with gcc-13 default
compiler options (although there is a (smal
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
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 t
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
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 ar
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
a
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
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/im
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 pote
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") tha
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 occ
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 whe
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 be
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
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 probl
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 w
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 b
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
l
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 makin
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 [.min
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 de
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 n
On Thu, May 2, 2024 at 6:14 PM Matthew Miller wrote:
> I don't believe GNOME Software enforces this. (There was some debate about
> whether doing two updates in a row was really useful, if I remember.) That
> may be a big source of pain.
As I recall, *much* of the time it does not matter, but
if
On Thu, May 2, 2024 at 6:11 PM Matthew Miller wrote:
> Just eyeballing the prediction graph in the Google doc, it looks like the
> linear approximation is distorted by the big drop in "non-trivial" last
> September. And, the slope for "converted" is pretty steep before that, but
> significantly f
On Fri, May 3, 2024 at 9:40 AM Miroslav Suchý wrote:
> The current change
>
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4
>
> is planned to be the last one. At the end of this phase - scheduled to
> 2024-08-06 - we plan to mark this conversion as "done". My estimation is that
On Sun, May 26, 2024 at 8:15 AM Byoungchan Lee via devel
wrote:
>
> While this is okay
> for Google, as they likely have a license agreement with other patent
> holders
>
While I do not think it has ever been officially
confirmed, it has been widely conjectured that
Google just pays the maxi
On Wed, Jun 12, 2024 at 3:50 PM Ben Cotton wrote:
> Neither "Functional" nor "eFficient" are in the Fedora Foundations,
> but in general, I think we should prefer the former over the latter.
> It's better for the project overall to be a little less efficient than
> it could be than to surprise pe
On Wed, Jun 12, 2024 at 6:08 PM Ben Cotton wrote:
> But it
> would at least buy us some time so that we don't end up with the
> "surprise, you can't use this release on your hardware if you want to
> use QEMU!" situation.
Since we don't have complete instrumentation, we
really don't know ho
On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel
wrote:
> But it is the ONLY approach that is compatible with Fedora policies, and as
> such should be required. ESPECIALLY for a package like QEMU that many people
> are using.
Please provide your audited (by a 3rd party) data that shows
tha
On Wed, Jun 19, 2024, 11:33 Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
Another option is to package the nvidia-kmod-open module into Fedora and
> sign it with Fedora key.
>
> Starting with version 555, nvidia-kmod-open will be the default option.
>
As I recall, only the defa
On Thu, Jun 20, 2024 at 3:52 PM Chris Adams wrote:
>
> Once upon a time, Stephen Gallagher said:
> > three) and recommend creation of a Fedora "Hardware Life Extension"
> > Remix that can provide rebuilds of (a subset of) Fedora that they want
> > to run on ancient hardware.
>
> TBH I feel that a
On Wed, Jun 19, 2024 at 8:39 AM Neal Gompa wrote:
> * I suspect more of the hardware that don't support -v2 have failed
> out of use naturally
Due to product line feature differentiation there
are more recent -v1 hardware than the aforementioned
roughly 2008 date, but the one pre-nehalem -v1 sys
On Fri, Jun 21, 2024 at 11:51 AM Dominik 'Rathann' Mierzejewski
wrote:
> If you mean Extended Page Table here
Yes, I used a shorthand term, since I am apparently
too steeped in the architectural details.
> I don't know any way to tell if my Cedar View Atom D2550 CPU from 2012
> supports it or n
On Mon, Jun 24, 2024 at 6:02 PM Alexander Bokovoy wrote:
> BTW, the cheapest and verified to work with Fedora USB token I was able
> to find is T2F2-NFC-Slim from Token2.eu:
> https://www.token2.eu/shop/product/token2-t2f2-nfc-slim-fido2-u2f-and-totp-security-key
When I was looking for "cheap",
On Mon, Jun 24, 2024 at 5:48 PM Matthew Miller wrote:
>
> If we decide that this is a good idea, we might be able to get funding to
> distribute these to all proven packagers (and perhaps more).
>
FD: I am *strongly* in favor of FIDO2 support.
As I recall from a previous query, there are
(aroun
On Tue, Jun 25, 2024 at 2:22 PM Vitaly Zaitsev via devel
wrote:
> I would prefer this one since I can use open source applications to
> generate these codes. I can't find any FIDO2 implementations that are
> completely open source which doesn't require proprietary technologies
> like TPM or SGX.
On Sat, Jul 6, 2024 at 7:03 PM Marc Deop i Argemí
wrote:
> Most users will just click on "Yes" without really comprehending what they
> are doing. And you _know_ this.
With no default provided, the most likely
response may very well depend on the
exact phrasing of the prompt (as few
would be ex
On Wed, May 18, 2022 at 10:08 PM Otto Urpelainen wrote:
> Neal's proposal seems simple and safe.
Except that it conflicts with another of the
proposal authors, who claims one will be
required to use %if-%else logic.
Limitations in tooling to not report violations
of the intention of the require
On Tue, May 24, 2022 at 8:11 PM Miroslav Suchý wrote:
> And the Packaging Guidelines will be altered that in old active branches you
> may use either the old shortname or the new
> SPDX identifiers. What will better work for you.
>
> We see no reason why not to do that. It should not cause any h
On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote:
> Would it make sense to make ALL the new tags be SPDX:, at least for
> an interim period (of years most likely) where both old and new tags are
> allowed?
I don't think that is going to work unless the rpm spec
file support would be backported
On Wed, May 25, 2022 at 12:47 AM Maxwell G wrote:
> I don't follow. What "rpm spec file support" are you referring to?
I interpreted the proposal as adding a
new stanza SPDX: in addition to License:
which requires changing the definition.
The follow up suggested that the license
field be differ
101 - 200 of 399 matches
Mail list logo
