or even notice to begin with.
I would suggest just picking the most common option (MIT→MIT and BSD→BSD-3-
Clause) and letting people file a bug if it turns out to be wrong. We have
had packages with more inaccurate License tags than that (wrong GPL v
release (8.0.3), though I do not know when exactly that will
be.
So it should now be possible to package this in Fedora. In my experience,
SCIP performs much better than COIN-OR Cbc on MIPs (MILPs).
Kevin Kofler
___
devel mailing list -- devel
clusion. Where was
> that analysis published so I can read it?
It is empirical evidence only. (When something bad was pushed to stable, I
looked at how it happened, and more often than not, it was autokarma.) There
is not much of an analysis that can be done because Bodhi does not retain
historical data.
The original trigger for the update policy enforcement was actually an
update that broke the bind DNS server, a package that ~99% of Fedora users
do not even have installed. The response has always been a complete
overreaction.
Kevin Kofler
___
Vitaly Zaitsev via devel wrote:
> What about packages that use dlopen() like Telegram Desktop?
Why the heck does a Qt application like Telegram Desktop dlopen WebKitGTK?
They are supposed to use QtWebEngine.
Kevin Kofler
___
devel mailing l
n some piece of software, no matter how much
complexity we force that software's maintainers to add to the latter. :-)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedor
ment those
few special cases that are actually needed, such as freezes.
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://do
Kevin Kofler via devel wrote:
> Mattia Verga via devel wrote:
>> with the current workflow, Bodhi doesn't know when a release is freezed.
>> There is support for a "Freeze" state, but it was never used.
>
> How do we prevent then that pushes to stable actually m
runs a different script to push testing
only instead of both testing and stable, that is the "can we push to
stable?" property Bodhi needs to check.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Adam Williamson wrote:
> Yeah, this is a good point, though I'm not sure how easy it is to fix.
if (state == pending && request == stable && !can_push(stable))
push(testing);
else
push(request);
Kevin Kofler
___
devel ma
branch=rawhide
I do not understand why. That patch was there exactly to prevent this exact
issue. Dropping that patch is what caused this blocker bug.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
want in more places, not
fewer ones. (I am thinking of comps in particular.) But of course, if, as
seems to be the status quo, it only theoretically works for modules, does
not really work even for modules in practice, and is not actually used by
modules, then it does not make sense.
ge and you have an
> unintentional conflict.
I think the concern is not about Ansible suddenly adding, e.g.,
%{bindir}/ansible-cp, but about them suddenly adding, e.g., %{bindir}/cp.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
T
wildcard would
actually be wrong to use there because it misses the %lang(…) tags that the
macro automatically adds. And you really do not want to have to list every
single language manually, and update the list for every single new upstream
release, since translations co
the main thing for which I used to *always* use a
wildcard.)
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
ing different approaches (maven
>> artifacts in koji, vendoring NodeJS dependencies, Java Modules, etc.)
>> have *failed* and ultimately made things worse instead of improving
>> the situation - the only thing that has proven to be sustainable (for
>> now) is ... maybe surprisingly
rible idea.
> Fedora _needs_ to adapt to stay relevant in the world where every language
> stack has developed a packaging ecosystem which effectively ignores us.
> Some of them are missing lessons they could have learned, ah well — but
> they also have a lot of nice new ideas we're miss
Peter Robinson wrote:
> Why are they insecure? This is public open data, not banking data,
> where the data being downloaded is verifiable by the rpm signatures
> and signing keys.
The metadata is not, at least not currently.
Kev
ioners).
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:
as the one-size-fits-it-all
solution to all our problems, even where it is completely off topic.
(And ultimately, replacing a system of package groups with one of "take it
or leave it" containers would give the end user *fewer* options, not more.
The package groups can easily be
lex strength check now.
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
be start using some password manager to generate and store long
> enough passwords?
Well, yes, I store the password in KWallet, so it was not a major
inconvenience to have to generate and store a new one. It was just an
entirely unnecessary inconvenience.
at is good enough for Bugzilla (but who knows for how long?), but this
is absolutely absurd.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Condu
g the thread linked above, I think we can probably
fast-track the orphaning.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Con
asonably ship, not what the (relative)
majority of developers in the world (most of whom do not even run Fedora)
happens to prefer.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
I see. So splitting might be worthwhile then. Assuming someone will care
enough to actually maintain the code.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject
ugh it is still better than what smaller distributions like Arch are able
to offer, where, e.g., the AUR only allows publishing the source PKGBUILD
files and no binaries at all.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.
s awfully broken as Panu is saying, I do
not think that that would be of much use, unfortunately.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
ily bloat
the core system over time.
> So here we are, in a subpar situation created by bad tools because
> nobody cares enough about security anyway.
Sounds like a mess indeed.
Kevin Kofler
___
devel mailing list -- devel@lists.fedorapro
Miroslav Suchý wrote:
> Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):
>> I am really angry at Copr's expiration policy once again. It looks like I
>> missed the deadline to renew the expired chroots (I still do not get any
>> notification mails, they end up e
is is
> in line with the stronger crypto settings proposed elsewhere for F38)
Such a hardcoded restriction, without a way for the local administrator to
allow the legacy signatures, is not acceptable.
Kevin Kofler
___
devel mailing list -- d
quot;Extend all"
button) at least every 180 days (in practice, more often, or you end up
missing the deadline). That is a very unfriendly dark pattern.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
delivery
method, mails can get lost at any time), and deleting data is not and will
never be a safe default. The default must be to retain, not to delete.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
plication though. KDE Plasma users will want KDE
Partition Manager instead.
IMHO, we need a proper solution for the general comps issue rather than that
half-baked compromise that does not really improve the situation. KDE Plasma
users should get KDE applications by default
, is that
correct? So should we ship all wxWidgets applications in the form of
multiple subpackages compiled against the different wxWidgets backends?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Michael Catanzaro wrote:
> In Fedora 38, we'll have a new service,
> fedora-autofirstboot, that installs OpenH264 for you with no user
> interaction
Installing restrictively licensed stuff (see the patent license) with no
user interaction is not really helpful.
Kev
eader.
It looks like EEL only supports the following hardcoded set of architectures
(with platform-specific assembly code): ppc, aarch64, arm, x86_64, x86.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
not think the src-git approach is legally possible at all for
these packages, at least not based on upstream git. (You could of course
make your own git history with just code drops of the hobbled tarballs'
contents, but that makes the use of git much less useful.)
Kev
Neal Gompa wrote:
> Unfortunately, we have to be very careful to not provide a complete
> codepath to these codecs to avoid legal risks.
Considering that we have been shipping these hardware codec interfaces for
years without any legal trouble, I find this absolutely ridiculous.
ers.
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: ht
1
> F32: 1
> F34: 2
That was almost every release, and in fact an average of around one such bug
per release cycle.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproj
uot;Secure" Boot) altogether (which is a much worse restriction), because
that, too, changes the TPM PCR measurements.
But the marketing as a "security" "feature" clearly works, because there
does not seem to be any noticeable public outrage about the
s like Debian stubbornly sticking to soname-based
versioning.
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
geKit and CLI) that are IMHO even more interesting than the raw
speed gain.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Co
on the mailing list was entirely
negative, the only people in favor were the submitters.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
applications on us by deprecating drivers
is not going to make users happy no matter what you do. In the end, if CUPS
upstream is not willing to keep classic drivers working, I see no other
option than forking CUPS.
Kevin Kofler
___
devel
es to implement them for Wayland (see
https://gitlab.gnome.org/GNOME/mutter/-/issues/217). So a compile-time
choice cannot make everyone happy. It should be decided at runtime (i.e.,
the code should try using xdg-decoration first, and only if that fails, fall
back to libdecor).
just insane, and will just lead to
applications bundling their own SHA-1 implementation and possibly even their
own PGP signature implementation to work around your deliberate breakage.
Kevin Kofler
___
devel mailing list -- devel@lists.fedor
ibs 4 as kdelibs5 due to the same soversion-based versioning policy.
That confused the heck out of users. (Fedora, on the other hand, used human-
readable versioning, so kdelibs 3 was and still is called kdelibs3, not
kdelibs4.) So I do not think Debian is a good example to follow.
TK version than it
actually does.
I can see why you want the soversion in there, especially to distinguish 4.0
from 4.1, but would it not make more sense to use:
webkit2gtk3_4.0
webkit2gtk3_4.1
webkit2gtk4_5.0
as the names?
Kevin Kofler
___
dev
Kevin Kofler via devel wrote:
> The best way then would be to check whether the one-line fix:
> https://hg.mozilla.org/comm-central/log?rev=1784838
Actually, there are two parts, and the main one is more than one line.
It had looked to me at a first glance that those are just the same
h(s).
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: ht
tral/log?rev=1784838
applies (and compiles), and if it does, apply it.
Though it is moot anyway because Fedora has already been upgraded to
Thunderbird 102.2.1. But backporting security fixes should have been
considered as an option. I get the impression that it was not even
considered.
Kevin Kofler via devel wrote:
> Marius Schwarz wrote:
>> I know it was a security update for
>> https://www.mozilla.org/en-US/security/advisories/mfsa2022-38/
>> <https://www.mozilla.org/en-US/security/advisories/mfsa2022-38/>,
>> so better safe and live with
n https://security-tracker.debian.org/tracker/CVE-2022-3033
that Thunderbird 91 is not even vulnerable to the CVEs fixed by that
advisory, only Thunderbird 102 releases (prior to the fix) were.
Kevin Kofler
___
devel mailing list -- devel@lists
security
updates.
The real issue is not the low karma threshold, but the automatic push with
no double-check from the maintainer.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
if needed. Or is somebody attempting
to veto that too?
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-U
lso the other arguments complete garbage.)
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/proj
Elliott Sales de Andrade wrote:
> Icons are not code.
Even if they are compiled into a code binary as a resource file (as seem to
be often done in this case)?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscr
luntly, I believe package deprecation should not exist or be
allowed at all.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduc
s to
fix them. We can only fix what we know about, and blackhats can only attack
what they know about.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fe
e unable to deal with the security
vulnerabilities is to simply orphan the library and let someone else pick it
up. (If nobody else does, I will, because at least 3 of my packages depend
on it.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedorap
Kevin Kofler via devel wrote:
> Neal Gompa wrote:
>> There's a pretty decent write-up about this on LWN:
>> https://lwn.net/Articles/904892/
>
> Here's a link that actually works:
> https://lwn.net/SubscriberLink/904892/dba951441b61cbdc/
> (Putting the title and &qu
ine does wonders.)
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 G
rnel from Linux 5.20 to Linux 6.0, without even any
reason for the bump other than "the second number is getting too large", so
my proposal would work similarly, but less arbitrarily and more in the
spirit of semantic versioning.
Kevin Kofler
w whoever wants to maintain it can probably fix 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-U
tly is when Fedora n is about to reach its EOL).
Now, I think there would be a huge outcry if Fedora did this the Microsoft
way with no way to opt out (I would be one of the first to complain), but
claiming that Windows does not do this is just wrong.
Kevin Kofler
s suggestion is to link it as an additional dynamic
shared object, so then the order of linking is important, and you also have
to take care to link it into all applications (and there are lots of build
systems out there). The alternative, I suppose, would be to modify glibc.
Leigh Scott wrote:
> Shouldn't asio package be retired as it's provided by boost-devel?
>
> /usr/include/boost/asio/
It is unfortunately not a drop-in replacement:
https://think-async.com/Asio/AsioAndBoostAsio.html
Kevin Kofler
0 code that was unilaterally relicensed by a third
party.
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
Kevin Kofler via devel wrote:
> I do not see why we need to give FDK-AAC a blanket pass just because a
> team at Red Hat decided to work on it first and send the licence for legal
> review afterwards (which is entirely the wrong order in which to do
> things).
PS: Especially now that
other clauses of dubious freeness in that license, the
exclusion of patent grants is not even the worst IMHO.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Kevin Kofler via devel wrote:
> But then fdk-aac-free is also not allowed in Fedora and should be removed:
> https://fedoraproject.org/wiki/Licensing/FDK-AAC
>
> | 3. NO PATENT LICENSE
> |
> | NO EXPRESS OR IMPLIED LICENSES TO ANY PATENT CLAIMS, including without
> | l
not acceptable for software? (I have seen that
used for code by some people who, I assume, liked the idea of copyleft, but
not the GNU project. I do not know whether any of that code has ever made it
into Fedora though.)
Kevin Kofler
___
de
m in 2008 can
be regenerated with current autotools with only 6 patches (2 of which only
fix hardcoded maximum version numbers).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
ure
stuff without running autoreconf is always a pain. (By the way, autoreconf
with no arguments is not all that helpful, you need at least
"autoreconf -i -f". That is just one of the many annoyances with the
autotools.)
Kevin Kofler
binding, do not have to
be rebuilt? (E.g., okular.)
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
(checked with 5.15.8, but that is the order of magnitude for all versions)
to check the license header, if there is any to begin with. (Some of the
bundled libraries are of the "let's just drop in one license file that
applies to everything" kind, and it is named differently
e (binaries from specific parties can be
> blocked by the CiPolicy/SiPolicy which is Microsoft's current
> Windows-specific revocation list du jour), but UEFI firmware does not
> (yet).
only Windows understands this attribute?
Kevin Kofler
other LInux distributions and in
> upstream projects generally.
With at least one notable exception:
https://fedoraproject.org/wiki/Forbidden_items#cdrtools
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
o trust the global license file to tell the truth.
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/p
Jerry James wrote:
> On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel
> wrote:
>> What I see is that the hacks that you apply to configure are apparently
>> not working:
>>
>> checking command to parse /usr/bin/nm -B output from gcc object...
>&g
();/g' ./configure
+ /usr/bin/sed -r --in-place=.backup 's/^char \$2 \(\);/__attribute__
((used)) char \$2 ();/g' ./configure
that is not accepted by the C++ compiler?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
Boot will also do it.)
It makes me particularly sad when I see GNU/Linux developers touting the
purported security merits of Restricted Boot and TPM Treacherous Computing
in their blogs.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject
eme.
(By the way, the name "Bitlocker" even SOUNDS like a ransomware.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
h
ect.org/rpms/qt5-qtwebengine/blob/b22f6246a6afa4b7e212be3eedabc366938df78b/f/qt5-qtwebengine.spec#_70
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.o
locker behind the user's back, i.e., also without prompting
for a passphrase, provides absolutely no security in the event of a stolen
notebook because somebody else hitting the power button will NOT change the
TPM measurements, the power button is not a
anyone still believe
that all this is about security?
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/
Chris Murphy wrote:
> It's a Rube Goldberg machine way of doing this.
Isn't that the Unix Way?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
Chris Murphy wrote:
> On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
>> As I already mentioned the last time this has come up: Why can we not,
>> instead of chainloading Windows directly, chainload a systemd-boot
>> configured to always bootnext to Windows?
l think it boots
Windows directly. (I do not see why it would notice any difference, all that
would change is the name of the image that gets chainloaded.) And systemd-
boot does not need to know that it is being chainloaded from GRUB. So I do
not see why that would not work, without any changes to the
gt; centric.
>
> The bigger problem is the version was reset from something 2.x
2.1.8.20140319 is what is now in Rawhide.
> back to 1.0.0, the current version being 1.10.
How about Name: libphidget, Version: 2.2.1.10?
Kevin Kofler
__
n pcre as a compatibility
library for the foreseeable future.
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
rs can be
effectively blocked by policy from importing upstream software that is not
yet packaged in Fedora.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedor
Please just orphan it instead. Then either
somebody else will take care of the package, or it will eventually
automatically get retired. In this case, it is quite likely that it will be
taken up. (In fact, if nobody else does, I will probably have to take it
ould consider a drop of supported hardware to be a major
change and hence inherently system-wide, and also something that should not
be dropped upon users late in the release cycle without prior warning,
catching them off-guard. (That said, I do not know how many, if any, users
of pre-z13 s390x exist in th
to render. I have had to fix a couple of these. So
seccomp is definitely used.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
Vitaly Zaitsev via devel wrote:
> On 20/07/2022 16:50, Kevin Kofler via devel wrote:
>> There is a lag, but it is less than the average lag we add in Fedora.
>>
>> E.g., the security fixes from Chromium 100 were backported to
>> qtwebengine- chromium git after 1 month,
PS:
Kevin Kofler via devel wrote:
> (*) These features require the KDE KF5/Plasma integration plugin, i.e.,
> the optional falkon-kde subpackage. Everything else is built-in into
> Falkon and/or Qt.
The gopher:// example also requires the kio_gopher package, which is not
installed b
cause QtWebEngine is 99+% compatible with Chrome.) And my
smartphone is a PinePhone running Plasma Mobile, on which I use Angelfish as
my one and only browser, a mobile browser also using QtWebEngine.
Kevin Kofler
___
devel mailing list -- devel@
401 - 500 of 4318 matches
Mail list logo
