es", it turned out that said "new features" mainly consisted of a
dangerous backdoor (xz CVE-2024-3094)…
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.
t upgrades from Fedora n to n+2, there SHOULD be Obsoletes in
place until at least the F40 EOL. I would recommend just keeping the
Obsoletes forever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
plain there too. I guess that is what
we have CLOSED NOTABUG for.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fe
rce0: resp. Patch0:.
But it should not be used. Use Source0/Patch0 instead.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fe
Planet Fedora, the new one currently has 30
(should be at least 31 soon when it picks up my RSS URL that I have just
added to accounts.fedoraproject.org). That is less than 4%. More than 96% of
the blogs will be gone.
This is not helpful.
Kevin
Pisar
pointed out), the intended resolution:
> a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and
> remove add-determinism-nopython
could also not possibly work because:
> remove add-determinism-nopython
Kevin Kofler
--
__
st banned from Fedora by
a git hook rejecting such specfiles.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fe
ora} version), cannot specify
a -b backup file extension for each patch. So it is not a fair comparison.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fed
y the
choice between a backwards-incompatible syntax (added only in RPM 4.18) and
an ugly and redundantly verbose syntax (the -P syntax). And even the modern
syntax is 1 character (space) longer for every patch. The shortest syntax
was the one being dropped.
Kevin Kofler
--
EPEL8/9 builds)?
>>
>
> Yes. It's been supported for a very long time.
%patch -P is already documented in the 1997 First Edition of Maximum RPM.
Here is the link in the 2000 online edition:
https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-WHICH-PATCH-TAG
Kevi
e oldest possible Java as I suggest, it will have
to get fixed anyway.) As is, you may need to explicitly:
BuildConflicts: java-1.8.0-devel
BuildConflicts: java-11-devel
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
T
cause subtle misbehavior that is a pain to debug is just too high,
especially if we have the actual older JDK available and could just
BuildRequire the correct version.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To
a version (the oldest JDK branch that we still ship
if the library supports that, otherwise the oldest the library supports).
And IMHO, if the library is built against a higher version than the lowest
we ship, it needs a versioned Requires on the JRE.
Miro Hrončok wrote:
> If you wish to help, I guess you can send a pull request to the release
> notes...
Or Mattia could simply unretire and adopt the package.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproje
d users to break?
All this just so that lazy packagers do not have to increment a number (in
most cases a single-character change, in some cases (such as a minor bump or
every 10 major bumps) a two-character change, rarely more) when doing a new
build.
Kevin Kofler
--
__
the upgrade path.
> But as others have pointed out, in the light of distrosync and
> macro-determined differences etc. we may just as well give up the
> illusion that "-5" means the same in different branches, and
> consequently lift the sorting policy between different bran
t replace %autorelease with a correctly manually bumped Release
in the specfile as part of doing the rebuild.
Just letting %autorelease do its thing and ending up with a full bump would
be incorrect, so it should not even be considered as an option.
Kev
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .
Sigh… Time for a UsrUnmerge? :-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproje
ast-forwarded again. But a clean linear history is no longer possible
after someone did an unwanted cherry pick instead of a fast-forward merge.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send a
nk having /usr/lib64/lp64d be a symlink to /usr/lib64 is in
violation of any standard.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduc
with the compat package, to
> complete the transition away from Redis).
I do not see why we need a separate compat subpackage at all. Valkey should
just Obsolete/Provide redis and include all the compat symlinks in the main
package.
Kevin Kofler
--
__
security", LOL…
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-condu
view, the fact that, in those implementations, there is no
Treacherous Computing hardware preventing me from doing what I want with my
own private key (e.g., just copying the same key to all my devices, as I can
also do with TOTP) is actually a feature, even if it goes against the
"security&qu
lso some hardcoded if (optimize_size) peppered
throughout various GCC optimizations and even target files (to choose
between faster or smaller instructions).
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
arger is Python at -O3 compared to -O2? And other packages?
I would like to see -Os as the default.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
ith, you can just SFTP your
~/.config/org.kde.keysmith/Keysmith.conf from/to all your GNU/Linux
computers including the PinePhone or equivalent, and they will all be able
to generate the same TOTP keys with the same master key.
Kevin Kofler
--
_
thon executable, but there are plenty of other cases where
autotools and Meson also do automagic, which is why building outside of a
chroot is such a bad idea.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
ort. So for me there is a clear consensus to NOT implement your proposal
at all, not even with an opt-out option.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapro
t just makes my life
harder for no benefit whatsoever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org
.
> Perhaps it's time to discuss imposing financial and/or legal penalties
> when the opt-in nature of the change goes away.
Who would impose those? And from whom to whom would the money flow? I do not
think this can work.
Kevin Kofler
--
___
o always build
in a mock chroot with only the expected BuildRequires installed, as I have
written.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code o
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream
the Plasma Edition be a Scientific Edition) from non-scientific KDE
users who understandably did not want to have to install a Scientific
Edition and then uninstall lots of niche apps they will never use from it.
But that discussion became moot because the Edition application was rejec
p as described above is probably a
better fit for traditional desktop/notebook computers.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of C
Tomasz Torcz wrote:
> GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.
And I believe that that, too, was a refinement added in later releases.
IIRC, GNOME 3.0 just maximized everything.
Kevin
kstation might be declining because people are installing
other desktop Spins, or a custom selection from Everything, instead. :-)
None of those will have fedora-release-workstation installed.
Kevin Kofler
--
___
devel mailing list -- devel@lists.
pretty good post summarizing the issues with autotools, both
generally and in the context of the xz vulnerability:
https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/
Kevin Kofler
--
___
devel mailing l
ad
>> key, etc.)" this is also not the case for ages, or at least not in its
>> completeness.
>
> Yes, this did change a few GNOME releases ago.
Of course, having only tried GNOME 3 once, I could not know this.
Kevin Kofler
--
__
h less open than RHL, and Caldera eventually became the infamous SCO)
with the at the time brand new KDE 1 (version 1.1.1). Having used DOS, the
bash CLI was not that bad to work with, but the distros at the time already
came with GUI environments (FVWM95,
his proposal).
Interesting point. And there I thought it was only because the answer is
always 42. ;-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
equires on the
dependencies where it matters.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/e
oper Linux” isn’t."
>
> https://www.linuxfoundation.org/legal/the-linux-mark
Kinda the same recommendation that also applies to the Fedora trademark, by
the way. But everyone only cares about their own trademark.
Kevin Kofler
--
___
lly good options"
as Adam Williamson wrote (in the post to which you were replying).
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
rience felt pretty much unusable to me personally.
KDE Plasma not only has more familiar defaults (actually looking and feeling
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily
change those defaults that you do not like.
Kevin Kofler
--
__
is pointless to feature that particular Edition prominently on
fedoraproject.org. That is why I was asking for download statistics
specifically.
And is there a statistical evaluation of that data somewhere? Downloading
350 MiB (!) of raw CSV data does not sound to me like a convenient way to
work with
bout as much as Kubuntu is Ubuntu.
> (Though, I don't know about 'Kedora' as it has absolutely no meaning XD)
> Though I feel like we should really only go this route if the other ideas
> get completely exhausted...
That is what I tried with Kannolo. Success was… limited, to say the
to a desktop widget or
similar) developed for one of the Fedora desktop deliverables (Workstation
Edition, desktop Spins) is also going to work on any of the others.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubs
ktop variants
(Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche.
So why do you expect those Editions to be more relevant to users downloading
Fedora from fedoraproject.org than the Spins?
Kevin Kofler
--
___
deve
11 rather than Wayland, if
even SDDM does not work properly under Wayland for you.)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
ot;Edition") and
second-class ("Spin" or "Lab") spins, for no benefit whatsoever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject
entionally limited and there are strict rules on
what packages are allowed to depend on it.) It should NEVER be considered
reasonable to break other people's work.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
obably be needed, and a lot of
testing on different hardware will definitely be needed, to make the
multiboot generator work (reliably) again.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
not include that warning.
And this also makes "--force" pretty much useless as it stands.
We and Debian both need to patch aclocal downstream immediately to make
--force actually work. And then of course Fedora needs to actually always
run autoreconf -i -f as Debian already does,
ot see the full list of options anywhere, but just a
list of lists. You actually have to click on "Learn More" after "Fedora
Spins" to even see what desktop environments are available.
Kevin Kofler
--
___
devel mailing list
xpect that we will
get lots of media coverage and another bump in downloads from that.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
htt
t least visibly state somewhere what desktop environment
they are based on, an information which some Labs now put in their
description, requiring an extra click to see it, and some not even there.)
Kevin Kofler
--
___
devel mailing list -
ly the users you think will be confused by the
options and will give them a desktop environment designed exactly for them.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
ted that "'Download' means 'Download'" and that a button with a verb
must trigger an immediate action.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
gma of defaulting to
GNOME everywhere, they are likely to be rejected. (Been there, done that.)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
; option in autoreconf.
Is that not what -f is supposed to do? At least, the documentation claims
so, but the implementation does not actually do what is documented.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
led "Free Software"
and not "Open Source". :-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproj
sition here in any way.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
analyzed the individual targeted distributions, the distributions whose
packaging tools the build script attempts to detect were not just picked
because they are known to link OpenSSH to liblzma, but also individually
tested and targeted.
Kev
ity). Now they are refloating it as their own, without even
citing my original proposal.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduc
nsense.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
y uses it.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guid
that can also write to regular files, without checking that
"$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU
vulnerability), introducing an arbitrary file overwrite vulnerability.
Kevin Kofler
--
__
regenerate
all files that can be regenerated, which is not happening. But if you
explicitly delete the files before running autoreconf, then it has to
regenerate them no matter what.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedor
stricter vetting of Fedora contributions. The attack was performed
upstream, NOT in Fedora.
* More distrust of new Fedora contributors. The offending upgrade was
imported by a TRUSTED Fedora contributor. The untrusted new person operated
upstream, NOT in Fedora.
s just going to introduce more
different library versions (in the worst case, one per container) with a
higher probability that one of them is compromised.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe s
n we are all this time talking about lowering, not rising, the barrier to
entry.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Con
Neal Gompa wrote:
> Well, an easy solution is to make it so "dnf update" is coerced to
> "dnf distro-sync" for development releases.
That would not have helped containing this vulnerability. Keeping updates-
testing disabled by default would h
dependencies, or causes a file
conflict with some other package. Being retired is by itself NOT a reason to
forcefully remove a package that users may depend on from their systems. So
that is what should be documented, not your personal wishes.
those people to cause the package
> they have complete control over to be automatically pulled in as a
> dependency on virtually every single one of those systems.
This would get noticed pretty quickly, when that package comes up in update
transactions for
sabled, but people still have packages from
updates-testing (such as the backdoored xz, but also tons of untested
packages or ones that explicitly failed testing) installed.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsub
. They should NEVER be run
in a distribution build.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org
on.
> But if we dropped those, we'd lose very valuable testing of the codebase.
On the other hand, "test files" are exactly how the payload of this backdoor
was disguised! So a policy that deletes all binary test files or even all
test files altogether woul
.
This is just fundamentally not how Free Software works.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproje
ivated new maintainer" as for an individual hobbyist project like
xz.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduc
interface to developers.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-cond
d_library call.
> And of course nobody has time to look into those scripts, making it
> easy to smuggle something through there.
You are right that bundled Find*.cmake scripts are a problem.
Kevin Kofler
--
___
devel mailing list -- devel@
re is potential for abuse,
too.
That said, I do not believe completely banning custom functions and macros
as Meson does is a workable solution.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
defining both macros and actual functions, and
macros are what you want to use in most cases. The main reason functions
were introduced is to allow recursion (which is a two-edged sword because it
makes the language Turing-complete with all its implications).
s it even harder to tell whether
liblzma will end up being loaded or not.
> Long ago (I think like ~10 years ago), libsystemd was actually several
> separate smaller libraries. Perhaps we could consider asking upstream
> to switch back to that model?
+1
rent: How do we know whether some
random sd_foobarify() function or some random foobard linked against
libsystemd will (always or ever (and when?)) end up dlopening liblzma or
not?
Distribution packagers tend to dislike dlopen due to the hidden dependencies
it introduces.
Kevin Kofler
--
e is that I actually want to see LESS stuff in
critpath, not more. It cannot be scrutinized well enough because there is
just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath
because Akonadi required it. (Nowadays, Akonadi actually recommends using
SQLite instea
ins only sd_notify, or
we should just stop using sd_notify at all. It increases the attack surface
of daemons a lot just to allow the service to be "Type=notify" rather than
one of the other available approaches. Arch Linux is also systemd-based
nowadays, but still does not link OpenSSH ag
ckages, an intentionally small
> subset associated with very secure services which are enabled by
> default.
I think the issue is that there is just too much stuff in critpath these
days. Whole desktop environments and all their transitive dependencies
probably ought to not be in there. If
Mikel Olasagasti wrote:
> And they wayback WayBackMachine[3] doesn't have previous versions.
We have the previous versions in the dist-git lookaside cache and in the old
SRPMs.
Kevin Kofler
--
___
devel mailing list -- de
Hi,
wow: https://www.openwall.com/lists/oss-security/2024/
I think at this point we clearly cannot trust xz upstream anymore and should
probably fork the project.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
n the benchmark results on one of the actually affected files, I now
think zstd -19 is what we want to use, not xz -9.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ill of course still be nowhere near zstd in decompression
speed. That is not what I intended to claim (and I thought it is obvious
that that is not the correct interpretation), though my message was somewhat
ambiguous, and I apologize for that.
Kevin Kofler
--
___
and the review request got
approved!
I hope this helps,
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedorapr
will take longer to compress, but should actually be
FASTER (!) to decompress, which is what really matters.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Co
cally built software that depends on the dropped compatibility
libraries. Forcefully obsoleting those will break the locally installed
software.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to de
at compression happens once on the server and downloading and
decompression happens many times on many computers, I think we should use
the highest possible compression level.
By the way, xz also supports stronger parameters than -9 in principle, there
is just no preset fo
;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).
Kevin Kofler
--
___
Kevin Kofler via devel wrote:
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2
> that allowed that was unfortunately dropped in the LGPLv3, now you have to
> put the "or later"
Kevin Kofler via devel wrote:
> Neal Gompa wrote:
>> I think the immediate fix is pulling in redict once it makes its first
>> release: https://codeberg.org/redict/redict
>
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatib
Scott Williams wrote:
> Yeah, I was going to say it depends on the dotnet8 runtime. There are
> containers for it, but that's a lot of extra dependency load.
It is actually already packaged in Fedora:
https://src.fedoraproject.org/rpms/dotnet8.0
But yes, it is bloat.
Kevin
1 - 100 of 4314 matches
Mail list logo
