Re: Small rant: installer environment size
Adam Williamson wrote: > As of today, with that new dep in webkitgtk, Rawhide's network install > images are 703M in size. Here's a potted history of network install > image sizes: > > Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M) > Fedora 13: 208M > Fedora 17: 162M (last "old UI") > Fedora 18: 294M (first "new UI") > Fedora 23: 415M > Fedora 28: 583M > Fedora 33: 686M > Fedora 37: 665M > Fedora Rawhide: 703M Wow, a factor 7! Thank you for your efforts to track down and try to combat the bloat! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
Terry Barnaby wrote: > Well in this case I have created a suitable compat lib, all I did was > re-introduce the bits to the SPEC file that removed the building of the > compat lib and we are fine. I haven't separated it out from the main > ncurses SPEC through and have only done this locally as I have no > knowledge of the hoops to create a separate package and that seems like > the wrong way to do this in general. I have made this available to > others who will be in the same boat. Typically, compatibility libraries should not be subpackages of the main library. But ncurses is a bit peculiar in that, as I understand it, the latest code can still be built with the old ABI. So in that case, it at least makes sense to build both from the same SRPM. But only if they are going to be maintained by the same maintainer(s), i.e., you should probably sign up as a comaintainer for ncurses in Fedora if you want to do it that way. And of course only as long as upstream continues supporting building for the old ABI. If they drop support, then a separate compatibility package with an old version that supports the old ABI will be needed. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
Neal Gompa wrote:
> While that is true, *I* don't like doing that if I don't have to. I'd
> rather try to get things fixed upstream in tandem. Upstreams tend to
> appreciate that in my experience. :)
Sure, but it tends to be significantly more work. Upstreams need to support
several platforms at once, so they often cannot just move to new libraries
and drop support for the old ones, and some are also quite picky about code
style issues that ultimately do not matter to end users.
> (This is probably why so many people think I'm everywhere, to be honest!
> :P )
:-)
> Further analysis indicates that dvdauthor has a patch in openSUSE[2],
> but the fix breaks support for GraphicsMagick as an alternative. I
> want to rework that patch so it doesn't break GraphicsMagick and old
> ImageMagick support so that it's suitable for upstreaming. I don't
> expect this to be too difficult to do.
Well, that is exactly why it is harder to make a patch that is acceptable to
upstream than one that works in the distribution. A downstream patch can
even be conditionally applied, if you want to support old and new library
versions in the same specfile, so the dual support need not be in the patch.
This is of course not the case for an upstream patch. So then you end up not
only adding "#ifdef"s for every line you changed, but also need to add a
build system ("configure") check for the library version. It can turn a
quick search job into a patch adding dozens of new lines of code.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
Neal Gompa wrote:
> There are actually
> other packages I could fix in Fedora with patches from openSUSE or
> PLD, but they need more work to not break compatibility with building
> with GraphicsMagick (which these packages in question support), so
> using IM6 there for now is fine while that gets worked out.
If there are patches, I do not see why we cannot just apply them downstream
instead of building against a compat package, especially if we make
ImageMagick 7 the default as you propose.
There is no rule in Fedora that any and all patches must be upstreamed.
Especially building against the distribution's version of a library is
exactly what a distribution is for and hence the perfect example of when it
makes sense to patch a package.
IMHO, either we go with Sergio's plan, letting ImageMagick be version 6
forever and introducing ImageMagick7 (and in the future ImageMagick8, etc.)
for all newer versions, then we can slowly switch packages from ImageMagick
to ImageMagick7, or we go with your plan and move ImageMagick to version 7,
but then we should do all we can to make really everything use the new
version.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
Adam Williamson wrote: > On Mon, 2022-12-05 at 22:44 +0100, Kevin Kofler via devel wrote: >> Mattia Verga via devel wrote: >> > Or let's just get rid of Bodhi and trust all packagers to "know exactly >> > what they are doing with their package". >> >> Yes please! > > Exhibits 1 through 2636 for why this is a bad idea: > https://bodhi.fedoraproject.org/updates/?search==unpushed=1 In my ideal world, it would still be possible for a maintainer and for rel- eng to unpush bad updates. IMHO, even from stable updates, since there is not really a technical reason to not allow that. It could be as simple as "koji untag-pkg fnn-updates foo". Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
Vitaly Zaitsev via devel wrote: > On 05/12/2022 12:39, Terry Barnaby wrote: >> I am wondering what Fedora's policy is on depreciated old shared >> libraries and particularly compat RPM's ? > > Fedora is a bleeding edge distribution. If you need old versions, you > should try CentOS or RHEL. Or you can just build the compat package you need in a Copr, see, e.g.: https://copr.fedorainfracloud.org/coprs/kkofler/compat-libgfortran-48/ (which I do not really use anymore, but I have kept the Copr up in case it is useful for other people). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
Mattia Verga via devel wrote: > Or let's just get rid of Bodhi and trust all packagers to "know exactly > what they are doing with their package". Yes please! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Request: ImageMagick7
Neal Gompa wrote:
> You can filter out things that use ImageMagick as a build dependency
> because that's just the command line utilities. That's why I checked
> only the ones that use the libraries, where the API changes and the
> required rebuilds are needed.
How backwards-compatible is the CLI? Can there be things stopping to build
or to work at runtime because ImageMagick 7 convert does not understand some
option intended for ImageMagick 6 convert?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
Neal Gompa wrote:
> I would prefer that *every* build would automatically generate a side
> tag, even if it's a side-tag of one package. Or at least provide an
> option to do that. That would provide opportunities for server-side
> automation for populating side-tags with updated builds against a
> package.
But it is not practical given the performance concerns around side tags.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Stupid question about QT6 and OpenGL support
Mattia Verga via devel wrote:
> ... I wonder why... AFAIK, GLES should be better for low resource
> systems like raspberry, isn't it?
Probably yes. KDE upstream recommends it for Plasma Mobile, and Manjaro ARM
builds a few qt5-es2-* packages (conflicting with the regular qt5-* ones)
for the components where it makes a difference. Fedora could do the same on
aarch64.
And proprietary drivers for ARM often support ONLY OpenGL ES, so if we do
not have Qt builds built for ES, Qt will not support OpenGL with those
drivers at all. (Though it can be argued that that is a feature. ;-) )
As I understand it, Mesa now supports desktop OpenGL everywhere, but missing
functionality is emulated in software, which is obviously slow.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump
Petr Pisar wrote:
> Funilly, kdepimlibs-gpgme already provides a copy of an older
> libqgpgme.so.1.
That is a Qt 4 qgpgme. The Qt 5 port, initially released the same way by
KDE, was eventually upstreamed from KDE into gpgme and is hence no longer
available as a separate package from KDE (and a compatibility package for
that one was not needed because all the affected Qt5/KF5 applications were
able to be built against the qgpgme from upstream gpgme).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: OpenCOLLADA dead upstream
Richard Shaw wrote:
> Before we go ripping it out of Fedora,
Just because a project is dead upstream does not mean it has to be removed
from Fedora.
> is anyone aware of another active upstream we can port to?
Since this is a library, not a leaf package, that would have to happen
before we can even consider removing the package from Fedora.
> It looks like the only direct consumer is Blender (cc'd).
So Blender upstream would have to move to something different. Please take
it up with the upstream Blender project. As long as Blender depends on
OpenCOLLADA, OpenCOLLADA should remain in Fedora.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2022-11-29)
Hi,
Stephen Gallagher wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
> irc.libera.chat.
does anyone have a complete log? It does not show up on
meetbot.fedoraproject.org, and the raw log at
https://meetbot-raw.fedoraproject.org/fedora-meeting/2022-11-29/fesco.2022-11-29-17.00.log.txt
is truncated.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics
Miroslav Suchý wrote:
> abattis-cantarell-fonts warning: not valid as calaway nor as SPDX, please
> check
The name Callaway has 2 'l's in 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 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: moby-engine (also known as Docker) maintenance in Fedora
Dan Čermák wrote:
> I find it a bit odd that the business is asking volunteers to step up to
> help the business out...
Is that not the whole concept of Fedora?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Stephen Smoogen wrote: > On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > >> Kevin Fenzi wrote: >> > I think we are going to just have to agree to disagree here. >> > >> > I think we have had this discussion a number of times now and aren't >> > going to convince the other. >> >> So Bodhi will continue to become more and more unmaintainable due to >> piling >> up more and more complicated rules that it needs to enforce, and obvious >> defects such as the one that started this thread will never get >> addressed. >> >> It is really sad that you are not willing to open your eyes and see the >> amount of damage that this dead-end policy has caused and is still >> causing. >> >> > Could you possibly pick the fight with the right people for once? It > doesn't matter if Kevin Fenzi agreed with you because he isn't the person > who a) writes the guidelines which were asked to be implemented or b) > works on bodhi codebase in any way. He just makes sure it and the other > 240 services runs and that the builds generally flow. That already takes > up about 60 hours of his work week. > > If you have problems with this please bring it up with FESCO and the > Fedora Packaging Committee and probably the Council. Kevin Fenzi is currently a member of FESCo (see https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for years. So pushing the blame off to "someone else" is not going to work. And I have brought this issue to FESCo (which is where most of the update policies came from, not FPC or the Council) more than once. Usually, it was not even brought to a vote. And whenever there was a vote about the issue, it was always in favor of either the status quo or even stricter rules. > They are the ones who over time have listened to packagers, users, and > developers about what was expected from the build system And that is exactly what I am disputing, that they are listening to what packagers expect. Because it can surely not be the packagers' wish to have some piece of software stubbornly dictate that no, that package can not be pushed to stable now because it reached testing only 6 days, 23 hours, 59 minutes and 59.99 seconds ago. (I believe the timestamps in Bodhi have microsecond resolution internally. They used to be displayed that way, at least.) Nor can it be in the interest of the Bodhi developers to have to maintain all that complex logic: you pointed out yourself that "what happens is that you will get into about 1/3rd of the way into it and find you have now to add a bunch of new requirements" – surely that is not what the developers expect. > and they are the ones who have given general guidance over the last 10+ > years of bodhi development. If by "general guidance" you mean skyrocketing requirements, then I agree. Otherwise, I don't, sorry. See above, you admitted yourself that the requirements keep increasing all the time, forcing a major refactoring. These days, even Rawhide (!) gets forced through Bodhi, though with an entirely different workflow (but in turn, that means the Bodhi developers get to maintain 2 completely different workflows with completely different rules). That is something Bodhi was never designed for. And the policy changes that have been made for Rawhide over the years have also changed things for the worse: It used to be that you were able to just do development in Rawhide, without having to bother about broken dependencies (which would just show up in the daily dependency report and get fixed there: I remember provenpackagers, mainly Alex Lancaster and me, mass- rebuilding packages to fix broken dependencies; Rawhide composes did NOT fail due to broken dependencies at the time, the deliverables that failed to compose would just be missing that day), upgrade paths (from Rawhide to Rawhide, really no reason to not just let the users use distro-sync there and allow the version to go backwards; upgrade paths make sense only for releases), test failures (Rawhide was expected to be broken, as is normal), etc. Now we just make life harder for everyone, both package maintainers and Bodhi developers, for no reason. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Kevin Fenzi wrote:
> I think we are going to just have to agree to disagree here.
>
> I think we have had this discussion a number of times now and aren't
> going to convince the other.
So Bodhi will continue to become more and more unmaintainable due to piling
up more and more complicated rules that it needs to enforce, and obvious
defects such as the one that started this thread will never get addressed.
It is really sad that you are not willing to open your eyes and see the
amount of damage that this dead-end policy has caused and is still causing.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Building Python 3.12 with no-omit-frame-pointer
> tl;dr: Python 3.12 should be built with no-omit-frame-pointer if > upstream recommends it. Absolutely not, because… > Apparently there are some benchmarks that make Python look extra slow > when the flags are turned on … considering those benchmarks, Python is one of the programs for which it would be the *least* appropriate to enable frame pointers! > which I don't quite understand. So then please try to figure it out. As long as the performance hit is as big as it is, enabling frame pointers is *not* acceptable. > Meanwhile, on the upstream side, Python 3.12 (due next year, main Python > for Fedora 39 [3]) has support for `perf`. Upstream plans to recommend > compiling with these flags when measuring performance [4], and AFAIK, > the plan is to recommend *always* compiling with them. > [3]: https://fedoraproject.org/wiki/Changes/Python3.12 > [4]: > https://docs.python.org/3.12/howto/perf_profiling.html#how-to-obtain-the-best-results Looking at the details in the link, would it not be sufficient to have the perf trampolines compiled with frame pointers enabled (which will only affect runs with perf support enabled ar runtime)? Or actually, since they are "compiled on the fly", do those trampolines not always have a frame pointer anyway, no matter how Python is compiled? > The idea is that possible speedups from "allowing anyone to > profile/optimize their workflow" are worth the initial slowdown. I and others heavily dispute this claim. There is no evidence that anybody will be doing enough profiling and optimization to compensate for the up to 10% performance hit seen on performance-critical Python code in the benchmarks, nor that such big optimization is even possible to begin with. Also, profiling and optimizing individual Python programs (as opposed to the Python interpreter itself) will not help the vast majority of Python code out there at all. > As far as I can see, performance geeks are enthusiastic for `perf` > support, As you say yourself, this is a niche feature for "performance geeks". > and I'd like to get them to (continue to) use Fedora builds. That is in theory a laudable goal, but not if it degrades the performance for everyone else. > If CPython upstream does recommend these flags (or makes them default), > I'm considering to turn the no-omit options on for Python 3.12 even if > Fedora as a whole doesn't. Then I can only hope that FESCo will explicitly disallow that. > Note that even a 2% slowdown will likely won back by general performance > improvements – the Faster CPython team is targeting a 20% average > speedup for pure-Python code in 3.12, on top of the ~25% for 3.11. And > the people responsible for this speedup have a say in the upstream > recommendations. Those 20% are a stated goal, not a guarantee. Even if attained, they will also not necessarily help all programs the same amount. And most importantly, Fedora will benefit from those upstream optimizations either way, even if it does not ship a build optimized for profiling rather than performance. So I do not see this as an argument for shipping Python with frame pointers. I am also very sceptical of that "grabbing for the stars" approach of accepting a 2-10% performance loss in the hopes of getting a 20% performance win that may or may not be actually achievable. In German, we have a proverb that literally translates to: "Better the sparrow in the hand than the dove on the roof." It means that it is better to take the small thing that you already have than to throw it away for a bigger thing that you have yet to catch. > Technically there are three separate places where the flags can be set, > I think we should turn them on everywhere: > - CPython itself & its standard library > - The debug build (/usr/bin/python3-debug) > - Default for libraries in Fedora (RPM macros) > - Befault for libraries built by users (sysconfig settings) IMHO, the debug build is the only one where it might possibly make sense to do so. Anything else would hurt the performance for real-world users who are not interested in profiling at all. Kevin Kofler ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)
> We currently don't use the initial-setup application in the main KDE > Spin and Kinoite installation ISOs as everything gets configured at > installation time via Anaconda. We thus want to remove this package > from the installation ISOs while keeping it where we currently need it > (pre-installed disk images, etc.). Note that an "initial setup" app is > still needed to enable OEM-style installations > (https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-linux-distributions) > of the KDE Spin/Kinoite (like Fedora Workstation/Silverblue) so we're > planning on introducing a more KDE native application as a replacement > once it is ready, but that may not not happen as part of this change. How about Calamares in a dont-chroot: true configuration? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)
So let me sum up: > Some Python building backends, eg. setuptools, explicitly allow > creating package with version `0.0.0` when the version used by a > project is not known. This was > [https://github.com/pypa/setuptools/issues/2329 discussed upstream] > with conclusion that it's an intended behavior. Upstream says that it is intended that packages are able to set their version to 0 or 0.0.0, but… > Based on discussion on python-devel mailing list there will be no way > to opt out from this change. There will be no possibility to package a > Python package with version `0`. … your proposed Change will fail those packages' build with no opt-out!? You cannot be serious! (Though actually, would %global __provides_exclude_from … together with a manual Provides: python3dist(…) = 0 not work?) A clear -1 to this Change as proposed. > We've never encountered a situation when packaging the version `0` was > the package maintainers intention. What if it is the *upstream* maintainer's intention? Are we now dictating versioning schemes on upstream projects, disallowing version numbers that upstream setuptools explicitly considers valid? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
cally divert the push to testing instead, but keep the update queued for stable so it goes out as a 0-day update as soon as the freeze lifts). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX - How to handle MIT and BSD
Miroslav Suchý wrote: > There are two common ways to find out what SPDX identifier you should use > in such cases. > > > 1) You can use https://github.com/spdx/spdx-license-diff and use it to > identify your license. This is a Chrome and Firefox plugin and allows you > to select the text; and in the context menu, you can choose to identify > the license. It will print, e.g., that it matches 60% of the MIT-feh > license and highlight the difference. Or... > > > 2) you can navigate to > > https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ > > in the search box above the first table, you enter your license and filter > the content. If you enter "MIT", it will find you 26 licenses. Out of > them, 15 have "MIT" in the "Fedora abbreviation" column (Hmm, this should > be changed to "legacy name"). Now you have to open the link in the "URL" > column and find your package's license. This may look painful, but you > usually find the correct license within a few clicks. That is a lot of pointless work for details that almost certainly is going to care about, 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 version, GPL instead of LGPL or vice-versa, etc., sometimes even entirely wrong licenses). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
SCIP MI(L)P and MINLP solver (and SoPlex LP solver) now Free Software
Hi, I have good news for everyone interested in optimization software: SCIP (https://www.scipopt.org/) has changed its license from the previously used semi-free academic non-commercial license to the Apache 2.0 License, i.e., a Free Software license and an OSI Approved Open Source license. The license change also applies not only to SCIP itself, a solver for mixed- integer linear (MIP/MILP) and non-linear (MINLP) problems, but also to the underlying default continuous LP solver SoPlex. The change has already been made in git. New tarballs will be released with the next bugfix 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@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: Direct to stable updates
Gary Buhrmaster wrote:
> Interesting. I have never seen such analysis results
> shared (either the part about why maintainers do it,
> or the pushes being the common causes of bad
> updates), and of course, anecdotal experience does
> not lead to a supportable conclusion. 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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Stephen Smoogen wrote: > Pretty much every one of those bodhi requirements is because either > > * a developer did not use that wonderful organ for some reason, and people > said 'that should never happen again.' > * what the developer decided was not liked by other developers enough that > it was decided 'that should never happen again.' > > Look back on the 15-20 years of fedora devel emails and see how many times > someone has said that something should never happen. Guess what? Enough > other developers agreed at times, and decided it needed to be automated > because the other big old complaint was about how long it took for people > to review things and how prone to failure was also true. Whenever something "bad" happens, people are always quick to jump to the conclusion that we need a law or rule banning the "bad" thing, no matter whether a rule is actually a workable way to prevent it. So we end up with overreaching laws banning even common activities, or with law texts so complex that everyone agrees they need to be simplified. In Fedora, we have had a handful bad updates making it to stable due to questionable decisions by some maintainers, and instead of simply telling those people to be more careful, we instead turned pushing Fedora updates into a bureaucracy that just keeps getting worse and worse when invariably bad updates keep slipping through because the complexity actually discourages good practice instead of encouraging it. (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 updates making it through, and also for issues such as broken upgrade paths between releases (because one release happened to get karma sooner than the other).) So of course the answer is that we need even stricter rules, because the alternative would mean to admit a mistake and step back, which nobody seems to be willing to do. 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 ___ 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: webkit2gtk5.0 -> webkitgtk6.0
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 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: Direct to stable updates
Stephen Smoogen wrote:
> You can only refactor it when you have a steady set of requirements. The
> code has been 'refactored' at least 4 times but what happens is that you
> will get into about 1/3rd of the way into it and find you have now to add
> a bunch of new requirements.
Sounds like pretty much what I had guessed. ;-)
So I think it would really help if Bodhi were to become more of an enabling
tool and less of an enforcing tool again. Package maintainers have this
wonderful organ between their ears that allows them to know better what is
best for their packages than 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.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: Direct to stable updates
Neal Gompa wrote: > Bodhi is an unusually difficult codebase for what it does. IMHO, the main reason the Bodhi code is so complex is because of all the policy that it enforces: karma (counting), update policies (minimum karma/time), critical path, autopushes, gating (automatic QA), … If we would just let Bodhi do what the maintainer asks in the common case (i.e., no karma, no autopushes, no gating, just two buttons "push to testing" and "push to stable" that the maintainer can click at any time, as Bodhi was initially designed), it would be a lot easier to implement 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://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: Direct to stable updates
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 move forward? If > rel- eng just hits a different button / 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. PS: The "worst mistake" that can happen then is that if we push only testing to a non-frozen release for whatever reason, the update will be included in that testing push, and then move forward to stable in the next stable push. I do not see this as a real issue. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
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 move forward? If rel- eng just hits a different button / 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 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: Direct to stable updates
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 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: PSA: Rawhide KDE users, do not update
Iñaki Ucar wrote:
> Packages using Qt private headers usually raise a FTI bug report.
> Wasn't this the case with this update?
It used to be, but the patch that made it so was dropped 4 months ago:
https://src.fedoraproject.org/rpms/qt5-qtbase/c/5ada0f5c5e88dcca0a367c8c82a2c89e99c70dbb?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 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: Deprecating intents in Modularity
Matthew Miller wrote:
> Or, for example, if we had a "personal productivity apps" module, and you
> had KDE Plasma installed, you'd get a KDE-flavored set of these apps,
> while if you had GNOME Shell you'd get gtk ones. :)
Indeed, intents sounds like something we would 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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Silent changes in Packaging Guidelines
Stephen Smoogen wrote:
> I came to the conclusion that even `%{bindir}/ansible*` would be against
> this as you would still miss
> a) if ansible-foobaz had been added to the package when it had not been
> there before
> b) if ansible-foobaz was in a different package 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
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: Silent changes in Packaging Guidelines
Vitaly Zaitsev via devel wrote: > On 03/11/2022 17:01, Gary Buhrmaster wrote: >> As I recall(*), there are spec files that just >> find the various installed files (categorized >> as needed), and then use the -f option >> on the %files section. > > IMO, such behavior should be strictly prohibited. Congratulations, you have just banned %find_lang… There are cases where automatically generating a file list is clearly the most reasonable solution, and we even have macros for that (e.g., %find_lang and some KDE-specific variants of the concept). (Hint: A 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 come and go.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Silent changes in Packaging Guidelines
Petr Pisar wrote:
> However, this is not true anomore. E.g. In February a ban for wildcard
> %files was augmented from dynamic libraries to all top-level files
> <https://pagure.io/packaging-committee/c/2bc90a6463ae591ed134955485da0596c2fe958b>:
When will this silliness ever stop? It just does not make sense to
explicitly list every single file in the RPM. Wildcards are often the only
reasonable way.
It is already enough of a PITA that we are now forced to explicitly maintain
the soname for libraries in our specfiles. (I have always been opposed to
that. Soversions are 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.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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
it is not Free Software. > I really hope we can look at these and learn how to do it better, instead > of deciding that better isn't possible. And — while I'm not really up on > node — I have pretty good hindsight on what went wrong with modularity. > (Not enough to try modularity _again_ just yet... but that's a different > thing. A whole talk for next year's Nest/Flock, maybe) Why would trying modularity ever again even be up for discussion? Can we not finally stop beating that dead horse? Modularity failed exactly because of the fundamental design issue I had warned about from day one: Modules can contain non-leaf packages, other modules can depend on a those and typically depend on a specific version, and those specific versions cannot coexist on the same system. That necessarily leads to conflicts. And in the non-modular world, we already have ways to solve exactly those conflicts (e.g., compat packages). >> alternatives, all attempts at trying 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, plain RPM packages. > > I'll take "for now". :) I do not expect that to change, ever. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
h. No, the answer to upstream shipping an unpackageable mess cannot possibly be to make it easier to smuggle unpackageable messes into Fedora! > It's not because it's statically-linked binaries [2] can't or shouldn't > exist in Fedora — that's not one of our core principles! It is actually one of our Packaging Guidelines that static linking is discouraged: https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries as is bundling libraries: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling (So they can indeed exist, but they definitely SHOULD NOT, the Guidelines undisputably say so.) > In fact and quite to the contrary, we need to adapt to handle this amazing > open source success story better. I fail to see a success story here. I see a failure story. Dependency hell is not a success. > And, I led with: I appreciate all the work you've all done to make this > work. That's definitely true — I think it was super-valuable to pilot this > approach. But I think that the Rust ecosystem would be a great place to > pilot a different way. Something lightweight where we cache crates and use > them _directly_ in the build process for _application_ RPMs. Fabio has already explained very well why that is a horrible 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 missing. And, no matter what > we think, we're clearly not going to stop them. Rust needs to adapt to become relevant in GNU/Linux distributions. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?
Marius Schwarz wrote:
> On what criteria does the algorithm decide which package to install, if
> the system it should judge on, has more than one DE installed?
It installs the packages for all the installed desktop environments, even if
their functionality overlaps. If you choose to install both KDE Plasma and
GNOME, you should get both KDE applications and GNOME applications by
default. If you have 4 DEs installed, you should get applications for all 4
of them by default (where they differ to begin with, so, e.g., you would
probably get 4 file managers, but only 2 partitioners).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?
Josh Boyer wrote: > I think it would be interesting to replace it with Colin's OS > Container ideas. Want KDE? Install the KDE OS container layer. > Creation of that is in a container file. That does not even come close to fulfilling all the use cases comps is for. A comps group can both be used to create images (including container images) and be installed at any time on an existing system. This is much more flexible than just having to install a whole new container for every desktop environment you want to use. > That's a departure from traditional installations, but it's still > interesting. Not for me, sorry. > The rub here is that comps isn't well loved, but it's not very complicated > either. It's a list of packages associated with a thing, and our tools > know how to interpret it. A modern replacement for "a list of things" by > itself isn't going to be very ground breaking. But it ultimately still needs to be "a list of things", you cannot replace apples with oranges as you seem to suggest. (And at that point, I see no point in redoing comps from scratch, we just need to improve what is already there, adding the missing features, and then actually making use of them.) > Changing how we think about and deploy the OS gives us more interesting > options. But "changing how we think about and deploy the OS" is not what this thread is about! I am fed up of containers being constantly sold 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 used to compose containers, but not the opposite.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ridiculous new Red Hat Bugzilla password security requirements
Sérgio Basto wrote:
> please try `pwgen -s 20 1 -cny`
Good idea, though it actually accepted the 20-character alphanumeric
password without symbols just fine. I believe there used to be a requirement
for a symbol, but this does not seem to be a hard requirement anymore, there
is a more complex 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-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: Ridiculous new Red Hat Bugzilla password security requirements
Marcin Juszkiewicz wrote: > 9 characters password in 2022 is considered 'easy breakable' thanks to > power of GPUs. To "break" the password offline with a GPU, you need a hashed password to begin with. If I log in securely over HTTPS and if the server is not compromised (and neither is my computer), you do not get my password, neither hashed nor unhashed. So then you need to actually brute-force the password by logging in to the server, the GPU will not help you a bit, and you will likely get blacklisted pretty quickly. So I see this as an absolute non-issue. > Maybe 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. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Ridiculous new Red Hat Bugzilla password security requirements
Hi,
today, Red Hat Bugzilla forced me to change my password because apparently a
password of 9 random alphanumeric+symbol characters (1 symbol, 8 mixed-case
alphanumeric) is suddenly no longer considered secure enough. This is
absolutely ridiculous for a bug tracker. It is not like that password is for
a bank account or for a build system (I believe FAS and thus Koji actually
has less stringent password security requirements than that!), so how secure
does the password really have to be?
I have generated a new 20-character random password with "pwgen -s 20 1",
and that 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 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: Non-responsive maintainer check for volter
Scott Talbert wrote:
> This is a non-responsive maintainer check for volter (Volker Fröhlich).
> Does anyone know how to contact this user?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2134665
Volker basically left Fedora packaging almost a year ago:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3QANCB2C5PLVBJD4SNQPBZQ7Q5MU2L45/#T4NT6DFNGYXB3WI6GBQOVSPC5NKQZVN6
Does the e-mail address in FAS and Bugzilla (the gmx.at one) no longer work?
I am going to ping him on IRC (volter at Libera Chat) pointing him to this
thread, but considering 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 Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Fabio Valentini wrote: > Do you have suggestions for improving this situation? I think we're > pretty close to doing the best we can with packaging Rust projects, > given the current limitations of the language (i.e. the support for > building "true shared Rust libraries" is still very limited and > unstable; but that might improve in the future). Building true shared libraries is pretty much a prerequisite for any sane form of packaging. > Additionally, the way the Sequoia GPG backend for RPM is implemented, > it's actually shipped as a standard shared library with a C ABI and > accompanying C headers (which are binary compatible with the existing > in-house GPG backend code in RPM). No Rust code will be statically > linked into /usr/bin/rpm. That at least makes sense. (Though I assume that that C-style .so still internally depends on a whole bunch of Rust crates that are statically compiled and linked into the .so, does it not?) > I'm sorry to disappoint you, but Rust is here to stay, whether you > like it or not. > For example, it's been voted the "most loved" and "most wanted" > language for a few years in a row in Stack Overflow's surveys: > https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted And according to the same statistics, the majority of developers runs Windows, yet hopefully you do not propose that Fedora ship Windows… We need to ship what we can reasonably 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 email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
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. I do not see anybody being excluded from Let's Encrypt, not even countries under US embargo (e.g., over 30 sites in Iran are apparently using it successfully). > And using Let's Encrypt for private mirrors is sufficiently painful that I > wouldn't recommend it. Set up a subdomain like vpn.example.com, point it to the public IP, then configure the VPN's internal DNS to resolve vpn.example.com to the VPN- internal address instead, the /etc/hosts on the VPN server itself to resolve it to 127.0.0.1, and the mirror server on port 443 (whereas port 80 is reserved for certbot's builtin temporary (and world-readable) webserver with the http-01 challenge) to accept connections only from the VPN and from localhost and to use the Let's Encrypt certificate. Been there, done that (not for a repository mirror though, my employer is small enough for that not to be worthwhile). I assume that this approach should also work for a physical LAN in lieu of the VPN. > There have been attempts to fix things, but Panu doesn't feel > qualified to review the changes. That doesn't mean someone else who > would be willing to do so couldn't. But because of... reasons, as long > as it's in the RPM codebase, it's unlikely someone else will be > trusted enough to do those reviews. 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.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Josh Boyer wrote:
> Would you be willing to pay for that feature?
Probably not, because at that point, it would probably be cheaper to just
set up a mirror or even a full-fledged build system on a VPS somewhere. Or
even to use OBS, though I do not know what their retention policies for old
repositories are (i.e., whether they are any better or even worse).
What makes Copr so interesting is that it is offered at no cost to all
Fedora contributors. But it has always been treated as an unloved stepchild
by Red Hat and has never received the kind of resources, e.g., OBS has.
Though 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.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Neal Gompa wrote: > No, because when you do things like mirror repositories (especially > for private mirrors), that signature is the only way to verify the > integrity. HTTPS is only transport encryption from a particular > connection. HTTPS protects against a MITM on the connection introducing invalid repository contents, which I would assume to be the biggest threat here. But sure, it by design does not guarantee that the data on the remote end is valid to begin with. > Also, a ton of Fedora mirrors still don't use HTTPS for various reasons. I would say that those mirrors ought to be kicked out of the mirror list immediately. With Let's Encrypt having been available for years, there is really no excuse for not offering HTTPS. Assuming you own a domain name (which I assume to already be the case for all mirrors), setting up HTTPS with Let's Encrypt does not cost you a dime. Even if you are a commercial entity. > Well, it might still be worthwhile to split out RPM's OpenPGP > implementation into its own project and allow people to contribute to > it. The worst that can happen is that nothing changes. If that implementation is really as 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 Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Neal Gompa wrote: > This is also the underlying reason why Red Hat has resisted > implementing signed repository metadata and enforcing it by default. > Of course this is a bit of a catch-22 as well, as there's no > motivation to find a solution because neither Fedora nor RHEL offer > signed repository metadata despite repeated calls for it over the past > decade. Is signed repository metadata not basically moot now that pretty much all the world has moved on from unencrypted HTTP to secure HTTPS? > Now, don't get me wrong: I'm personally extremely unhappy about having > to depend on the Sequoia stack for RPM PGP. I have a strong distaste > for the Rust community ecosystem these days, and I don't love the idea > of having to have LLVM in the core bootstrap chain (hopefully gcc-rs > will be in place soon enough!). The dependency on LLVM is not even the worst issue in my eyes. LLVM is also used by other core projects, e.g., mesa, these days. The worst issue I see with Rust is the way libraries are "packaged", which just implies installing source code and recompiling that source code for every single application. (And as a result, the output obviously gets statically linked into the application, with all the drawbacks of static linking.) I consider a language with no usable shared library support to be entirely unpackageable and hence entirely useless. And then of course there is the issue that it is yet another language with yet another syntax (and an only partially C-like one, so the learning curve is unnecessarily high), yet another library ecosystem, etc. C has been the de facto lingua franca all this time, now we are back into a tower-of-babel scenario with tons of programming languages, which will necessarily 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.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
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 eaten in a spam filter somewhere), so >> once again a lot of data was deleted forever with no way to recover it. > What is your proposal then? The resources are not infinite. At least allow the opt-out per maintainer. I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and then evaluate how many maintainers actually check that checkbox and how much resource usage is actually caused by it. Then after a year or two, decide whether to keep the checkbox or revert to the current status quo. Or drop it sooner if you really run out of disk space as quickly as you seem to expect. >> (By the way, I have since entirely deleted 3 deprecated Coprs that do not >> have builds for newer releases and hence stopped being useful entirely as >> a result.) > ??? If you have enabled "Follow Fedora branching" (per-project setting) > then all your packages are automatically rebuild for new Fedora version > when it is added to Copr. And your project will be always up2date. Patched mesa builds based on an ancient Fedora mesa package are not going to be of any use on current Fedora releases, which is why I had not enabled those autorebuilds for that Copr. I no longer build the nouveau-locking- patched mesa, and in fact, I believe the issue has finally been fixed upstream since, years later. The other 2 repositories were about providing a stable Wesnoth on a Fedora release that shipped with an unstable version, but that stable version is now really outdated (there has been at least one new stable release since), so I deliberately did not support that Copr on current Fedora. But now it is also no longer available for those Fedora releases that I did intend to support. > BTW email is not the only one notification we have. If some of yours > chroot are flagged as EOL you will be shown this banner in WebUI: > > Some of the chroots you maintain are *newly marked EOL*, and will be > removed in the future. Please review > https://copr.fedorainfracloud.org/user/repositories/ to hide this warning. That assumes I actually log into Copr, otherwise I will never see the message. Maybe only start the timer if the maintainer actually logs into Copr and sees the banner? >> PS: At the very least, you could add a checkbox to allow a maintainer to >> opt out permanently of automatic expiration (it would still be possible >> to > > This is not a solution as it does not comes with solution where we get the > storage. I am not convinced that the storage requirements will actually skyrocket as quickly as you expect. As I wrote, I would suggest trying it out and evaluating what happens. >> manually click on "Expire now"), as opposed to having to click dozens of >> buttons (an everincreasing number, since there is not even an "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. > > We did not put there "Extend all" intentionally. With the intent that you > have to consider each project separately and think about if you still > really needed. That is exactly the definition of a dark pattern. > BTW: I am curious what is your use-case to keep **dozens** EOL > repositories (which means F34-) alive? A handful Coprs * several EOL releases * several architectures = dozens of buttons to click. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
> For the last 20 years or so, RPM has used a home-grown OpenPGP parser > for dealing with keys and signatures. That parser is rather infamous > for its limitations and flaws, and especially in recent years has > proven a significant burden to RPM development. In order to improve > security and free developer resources for dealing with RPM's "core > business" instead, RPM upstream is in the process of deprecating the > internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP] > based solution written in Rust. Why are you using a new library written in Rust? Can you not use one of the existing mature C implementations of OpenPGP? gpgme maybe? > At this point the change is mostly invisible in normal daily use. Not really, because it makes some packages uninstallable. > - Some old, insecure (MD5/SHA1 based) signatures are rejected (this 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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
PS: At the very least, you could add a checkbox to allow a maintainer to opt out permanently of automatic expiration (it would still be possible to manually click on "Expire now"), as opposed to having to click dozens of buttons (an everincreasing number, since there is not even an "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 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
Copr delete-by-default expiration policy still unacceptable
Hi, 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 eaten in a spam filter somewhere), so once again a lot of data was deleted forever with no way to recover it. (By the way, I have since entirely deleted 3 deprecated Coprs that do not have builds for newer releases and hence stopped being useful entirely as a result.) The assumption that users will receive notifications mails and act on them is still entirely invalid (because e-mail is not a certified 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 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: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?
Ben Cotton wrote: > In going through the bugs against comps, I came across > https://bugzilla.redhat.com/show_bug.cgi?id=1971338 > > The "admin-tools" group in comps includes GNOME Disks, which is a > surprise for KDE Plasma users. That is just a symptom of a core issue with comps, that the applications in non-desktop-environment groups are not conditional on the user's desktop environment in any way. This affects much more than just GNOME Disks and the admin-tools group. Pretty much all comps groups except the KDE ones are filled with GNOME apps as mandatory or default, and the KDE equivalents as optional if even listed at all. > We can swap it out for blivet-gui (note that other groups for GTK-based > desktops would still include GNOME Disks) easily enough, but I didn't want > to do that without seeking comment. That is still a GTK application 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 everywhere. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
wxQt
Hi, with the wxWidgets 3.2.0 release, there is now finally a wxQt backend available. Are there any plans yet to package that? Currently, the Fedora wxWidgets package (even the specfile and SRPM) is called wxGTK, even though it is actually built from the generic wxWidgets tarball. Can we not build the different backends from the same SRPM? Then we should rename the source package to wxWidgets and build both wxGTK and wxQt from it. And as I understand it, wxWidgets backends cannot be swapped at runtime, but applications need to be recompiled to use wxQt instead of wxGTK, 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...@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: Mesa in F37- vaapi support disabled for h264/h265/vc1
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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Carla-2.5.0 compilation fails with: error: static assertion failed: 64-bit large file support is not enabled
Martin Gansser wrote:
> different errors occur on the ppc64le and s390x platform:
> Carla-2.5.0/source/bridges-
plugin/../modules/ysfx/thirdparty/WDL/source/WDL/eel2/nseel-compiler.c:5214:
> undefined reference to `eel_callcode64_fast'
>
> ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=92400914
> s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=92400913
>
> if no solution can be found here, then I will build with "ExcludeArch:
> %{ix86} ppc64le s390x" .
The problem is these lines in nseel-compiler.c:
> #elif defined(_WIN64) || defined(__LP64__)
>
> #include "glue_x86_64_sse.h"
>
> #else
>
> #include "glue_x86.h"
>
> #endif
so for any unknown 64-bit platform (__LP64__ defined), it includes the
x86_64-specific header, for any unknown 32-bit platform, the x86-specific
header.
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 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: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)
Clemens Lang wrote:
> Note that we’re discussing moving openssl to a src-git approach, so it
> should eventually become much easier to see the relation between upstream
> code and our downstream copy.
At that point, you have the patent-encumbered files in your (src-)git
history. I do 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.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
Ben Cotton wrote:
> I'll close ones that already exist in Pagure as DUPLICATE
Bugzilla does not allow you to use the DUPLICATE status without giving a
concrete Bugzilla bug ID of which the bug is allegedly a duplicate, so you
cannot use it for bugs that are duplicated on external bug trackers.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: disable comps component in Bugzilla
Ben Cotton wrote: > On Tue, Sep 20, 2022 at 10:03 AM Neal Gompa wrote: >> >> The main reason would be blocker review, but I'm not sure how often it >> comes up in the past few cycles. > > Rarely, which is why I think using distribution as a proxy is fine. > For the curious, a total of 16 comps bugs have ever been a part of the > blocker or freeze exception process. Here's a list of release with > non-zero comps bugs in the blocker/FE processes: > > F18: 4 > F19: 1 > F21: 2 > F22: 1 > F23: 1 > F24: 1 > F28: 2 > F30: 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.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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
Brian C. Lane wrote:
> We have reached a point where boot security is important enough
LOL!
> that Windows is now only allowing their bootloader to be used.
It is blatantly obvious that that is actually the goal, not the means.
This is clearly a vendor lock-in "feature", with "security" used as the
excuse (just like other similar vendor lock-in "features", e.g., the iOS App
Store monopoly).
Incidentally, the "feature" not only prevents chainloading (which can be
worked around by using BootNext), but also disabling Restricted Boot
("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 these absolutely
unacceptable monopolistic restrictions.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: WebKitGTK package naming
Michael Catanzaro wrote:
> Being different than other distros is most confusing of all!
I have to disagree with that blanket assertion.
E.g., I believe it would have been much more confusing for our users if we
had shipped kdelibs 3.5.x as kdelibs4 (or "kdelibs4c2a" as Debian actually
called it, because they also handled a libstdc++ soname bump in a totally
weird way) rather than kdelibs3 as we did.
I believe version numbers should be human-readable, not reflect the internal
soname when they differ, even if that means we use a different package name
than distributions 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.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: Replace DNF with DNF5 (System-Wide Change proposal)
Tommy Nguyen wrote:
> DNF5 is ridiculously fast.
It is faster, but "ridiculously"? In the metric that matters (elapsed
wallclock time), your benchmark shows the update taking 30% less time.
That said, there are other features of DNF5 (no more Python, shared cache
between PackageKit 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 Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2022-09-20)
Miro Hrončok wrote:
>* https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> was submitted as an Fedora 37 update after it was deferred to Fedora
> 38. We need to decide what to do. (mhroncok, 17:02:38)
[snip]
>* AGREED: The update may be shipped after Fedora 37 Beta release,
> before the Fedora 37 Final Freeze. (+7,0,-0) (mhroncok, 17:12:48)
This makes a farce of the whole Change process. I do not see why a Change
that was deferred to the next release can now be rushed in post Beta during
a feature freeze period where only release-critical bugs should be fixed.
(And in the particular case of this Change, I also do not see why it was
approved at all, be it for Fedora 37, 38, or some future version, for the
reasons that were already stated by me and others when the Change was pre-
announced for discussion. The feedback 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 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: OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs
Zdenek Dohnal wrote:
> IMHO it is much better to find out earlier that your printer does not
> work/is missing some options when printing via printer application and
> report it, than later just cry in beer that there wasn't enough time to
> test.
There will be complaints either way, even with infinite testing time. The
user experience with printer applications is just much worse by design than
with the good old CUPS 2 drivers. (E.g., one should not be required to point
a web browser to an arbitrary port on localhost to configure a printer.)
CUPS attempting to force printer 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 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: [Rawhide] Blender 3.3.0 with initial enabled Wayland support
Luya Tshimbalanga wrote:
> Starting from 3.3.0 and only for Rawhide, initial Wayland support is
> enabled for testing purpose using libdecor for window decoration
> (currently generic) [2] and running on EGL.
>
> [https://developer.blender.org/rB29755e1df82e34061a0b0586234a5aaac5177d35
Looking at the code, the choice between client-side (libdecor) and server-
side, i.e., compositor-side (xdg-decoration) window decorations is a
compile-time choice only. That is unfortunate, because server-side
decorations are preferred under KDE Plasma Wayland, whereas GNOME flat out
refuses 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).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Alexander Sosedkin wrote: > That's a reason why my initial thread [1] has been named > "Landing a larger-than-release change (distrusting SHA-1 signatures)": > flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is 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.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: WebKitGTK package naming
Michael Catanzaro wrote: > And the Debian names are: > > libwebkit2gtk-4.0-37 > libwebkit2gtk-4.1-0 > > (Debian hasn't packaged -5.0 yet, and requires the soversion appended > to the package name.) Debian is also notorious for having shipped kdelibs 3 as kdelibs4 and kdelibs 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. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
WebKitGTK package naming
Hi,
the latest webkitgtk package now uses the following subpackage names:
* webkit2gtk4.0 and webkit2gtk4.1 are for GTK 3,
* webkit2gtk5.0 are for GTK 4.
As you can see, the WebKitGTK soversion ends up appended to "gtk", making it
look like the package targets a different (higher) GTK 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
___
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: Thunderbird 102 pushed to F36 stable
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 commit
applied (cherry-picked) to two branches, but they are different (and looking
closer at the commit message would have made that clear).
> applies (and compiles), and if it does, apply it.
But this still stands: If I am not sure whether the branch is affected, I
would attempt to just backport the two patches and see whether they apply.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
Maxwell G via devel wrote:
> I don't think Fedora packagers should be CCed on these global trackers.
The problem is that, as it stands, those global trackers are the only place
that actually explains (usually in one paragraph) what the security issue
actually is. The [fedora-all] trackers are pretty useless considering that
they contain no information whatsoever beyond the subject line. (Their only
relevant content is the state, mainly whether they are open or closed.)
If we want independent Fedora-specific tracker bugs, they will need a copy
of the introductory paragraph(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: 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: Thunderbird 102 pushed to F36 stable
Sandro wrote:
> Mozilla's blog entry doesn't substantiate the claim and the linked bug
> report[1] is not publicly accessible.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1784838
The best way then would be to check whether the one-line fix:
https://hg.mozilla.org/comm-central/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
___
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: Thunderbird 102 pushed to F36 stable
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 some minor bugs, than to be sorry. > > Debian claims on 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. And if that claim is wrong, you can simply backport the fixes: The MFSA lists the bug IDs, so just search for those in the hg history: https://hg.mozilla.org/comm-central/log?rev=1784838 https://hg.mozilla.org/comm-central/log?rev=1783831 https://hg.mozilla.org/comm-central/log?rev=1745751 https://hg.mozilla.org/comm-central/log?rev=1787741 In particular, the fix for the high-impact CVE-2022-3033 is a one-line addition. It does not make sense to upgrade to an incompatible version for that fix. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Thunderbird 102 pushed to F36 stable
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 some minor bugs, than to be sorry.
Debian claims on 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.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: Thunderbird 102 pushed to F36 stable
Mattia Verga via devel wrote:
> Moreover, thunderbird in on the critical path update list; Bodhi
> requires 14 days of testing for those packages, but it is set to require
> only +2 karma, so packagers easily bypass the testing phase, like it is
> clearly happened here (pushed to stable just after 5 hours). I think
> critpath updates should spend more time in testing, maybe we should
> increase the critpath min karma to, at least, +5.
There are a lot of critpath packages that never reach +5 karma. Especially
for Fedora n-1 (right now, 35), for which we also need to push 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 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: GTK 2 removal from RHEL 10+
Tomáš Popela wrote:
> This is an early heads-up about GTK 2 removal from RHEL 10+ (the gtk2
> package was marked as unwanted in ELN with
> https://github.com/minimization/content-resolver-input/commit/b6d44e496f46bd2444e8e24dd3e9113b326817ac).
I suppose it could be carried in EPEL 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-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: abipkgdiff - indirect sub-type changes
Orion Poplawski wrote:
> Does this break ABI?
Yes. They changed functions to take 64-bit integers instead of 32-bit ones.
When called by code compiled against a previous version, the upper half will
be garbage. On some architectures (depending on how exactly arguments are
passed, but they will usually be big-endian ones), even the whole thing.
(There, the lower half will be complete garbage, and the upper half will be
what should be the lower half. Or in the worst case, some architectures
might even decide to switch from register to stack passing, making the whole
number or even also 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/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: GNOME's Icon Development Kit icons potentially causing implicit conflicts
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 unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)
Lukas Javorsky wrote:
> Anyway, the main idea behind this change is to prevent any new packages
> coming to Fedora 38 to require the old pcre package and forward them to
> use the newer version of it *pcre2*.
As I have stated several times, I do not see this process as a productive or
useful thing to do. It can prevent useful software from going into Fedora
just because it has been written by upstream some time ago and not
immediately packaged. It will not magically port any software to newer
libraries, just prevent it from entering Fedora for no good reason.
To put it bluntly, 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 Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)
Daniel P. Berrangé wrote:
> pcre will also have a drop in found CVEs simply because far fewer people
> will be bothering to look at the old code. If no one is looking for bugs
> then none are going to be reported :-)
That was exactly my point though. If nobody finds CVEs, then nobody has 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
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)
Ben Cotton wrote: > == Summary == > Upstream stopped the support for the old 'pcre' package. It only > supports the new 'pcre2' version, so Fedora should deprecate it so it > could later be retired and removed from Fedora entirely. > > == Owner == > * Name: [[User:ljavorsk| Lukas Javorsky]] > * Email: ljavo...@redhat.com This is simply a non-starter. You yourself list dozens of packages using this compatibility library. Some of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and will never be fixed by upstream. It is entirely impractical to port them to a completely different API. But even current leaf packages such as rkward are in the list. PCRE 1 needs to remain as a fully supported compatibility library for the foreseeable future. > == Detailed Description == > Upstream stopped supporting the old 'pcre' package. The 8.45 is marked > as a final release and nothing else will be added/fixed in it. This > may lead to some unresolved CVEs, which would have to be resolved by > the maintainers. Unfortunately, due to our limited capacity, we > wouldn't have the time and experience to solve this by ourselves, so > we need to deprecate this package. After the deprecation is done, the > very next step would be starting the [[PcreRetirement|retirement > change]], so the package is removed from Fedora entirely. How different is the code from the pcre2 code? If it is completely different, then CVEs found in pcre2 will typically not affect the legacy code, and you can expect a steep drop in found CVEs with the upstream drop of support. If, on the other hand, it is sufficiently similar for the CVEs to apply, then the fixes can also be backported. In the end, my suggestion if you are 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.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: glibc 2.36 and DT_HASH (preserving it for F37+)
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 "SubscriberLink", both between quotes, into a > search engine does wonders.) PS: I find it incredibly rude to share a paywalled link on a public mailing list, all the more in cases like this where there is a legal way to share the content without excluding large parts of the community. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: glibc 2.36 and DT_HASH (preserving it for F37+)
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 "SubscriberLink", both between quotes, into a search engine 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 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 system upgrade automatic or not?
Stephen Smoogen wrote: > I should have been clearer. I was talking about the changes between > XP->7->8->8.1->10->11 versus 10. -> 10.. I was thinking of > it more since for the most part they used pretty much the same compiler > for all of 10 versus new compiler and major library changes every six > months That is a very developer-centric view though. End users will usually not care about what compiler the operating system was compiled with, all the more on Windows, which does not even ship with a compiler (so those who do actually need to compile code can select their compiler version more or less independently of the operating system version). What they will notice though is when the Windows desktop shell (the Windows equivalent of KDE Plasma or GNOME Shell) gets a major update which makes it look different, and I know from Windows users' complaints that that has happened repeatedly in Windows 10 point releases. Start Menu, Control Panel, etc. have all had significant look changes at least once. And as you point out yourself, those updates are also not always without issues. E.g., another frequent complaint is that device configuration is reset during upgrades, e.g., that it simply forgets printers that are not plugged in while upgrading (and always plugging in all hardware is not possible on a notebook that travels between different locations). So I would really compare those Windows point releases with Fedora releases. The schedule is basically the same and the risk is also about the same. (Though one difference is that Windows ships a lot less software, so you can have fewer issues with software getting upgraded as part of the operating system upgrade there. Though that can also result in the application stopping to work after the operating system upgrade, at least until you manually upgrade the application as well.) I wonder whether we should simply switch Fedora releases to a different numbering scheme more like RHEL or Windows. (Keep in mind that my suggestion would be only a pure renumbering, there would be no changes whatsoever to the schedule (including EOL dates) or the nature of the releases.) So we would by default just release the next Fedora as 37.1, then 37.2, etc. Only if some comittee (probably FESCo) decides that a release has enough major changes to warrant a new major version (e.g., Fedora 9 with KDE/Plasma 4, GCC 4, etc., or Fedora 15 with GNOME 3), then it moves to 38.0. This can be decided shortly before the release, after having the final list of accepted and not reverted changes. After all, Linus also decided on a fairly short notice to renumber the kernel 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 ___ 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: Intent to retire: novacom-client, novacom-server
Jonathan Dieter wrote:
> Unfortunately, this state of affairs has ended. Libusb, one of
> novacom's dependencies has been retired, and it's not clear to me that
> it's worthwhile (or even possible) to keep novacom alive.
Does this not build against libusb-compat-0.1-devel? (That has been the
replacement for the old libusb-devel 0.1 for ages, and it is still in
Fedora.)
Unless this actually wants libusb 1 (some versions also known as libusbx),
then it should BuildRequire libusb1-devel instead.
That said, I am NOT interested in picking up this package, just pointing out
how 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-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 system upgrade automatic or not?
Stephen Smoogen wrote: > I don't know of an Operating System which isn't a rolling operating system > which works this way. MacOS, Windows, Debian, Ubuntu, Fedora all require a > manual clickthru to get to the 'next' version which is available. For Windows, it really depends on what you mean by the "next version". If you are thinking in RHEL-like time frames, then the "next version" is Windows n+1 (e.g., 10 to 11), to which upgrades are not automatic. But Windows does release major upgrades to every Windows version every 6 months (which pretty much corresponds to Fedora n+1) and upgrades users to those more or less automatically. Even fully automatically without the user's consent at the latest around when the next upgrade comes out (which would correspond to fully automatic upgrades to Fedora n+1 around when n+2 is released, which conveniently 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 ___ 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: hardened memory allocate port to linux-fedora system for secutiry
martin luther wrote:
> should we implement https://github.com/GrapheneOS/hardened_malloc/
> it is hardened memory allocate it will increase the security of fedora
> according to the graphene os team it can be ported to linux as well need
> to look at it
There are several questions that come up:
* Against what exact threats does this protect? Use-after-free? Heap buffer
overflow? Others?
* How does it relate to _FORTIFY_SOURCE? Can they be used together? (If not,
it might actually reduce rather than increase the security of Fedora.)
* How does it perform, both in terms of speed and memory consumption
(overhead)? Better or worse than the glibc malloc? (If it is much worse than
the glibc malloc, it is not going to be a suitable default for Fedora.)
* How does it compare to the glibc malloc in terms of quality of
implementation issues, such as that realloc should avoid copying the whole
block whenever an in-place resize is possible?
* Can hardening be added to the existing glibc malloc implementation or is a
complete rewrite as the suggested one really needed?
* How do you suggest it getting used distro-wide instead of the glibc
implementation? Upstream'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.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive asio maintainers (uwog, fale, dcavalca, raineforest)
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
___
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: CC0 reclassified as "not allowed" for code (reposted from legal list)
Richard Fontana wrote:
> We plan to classify CC0 as allowed-content only, so that CC0 would no
> longer be allowed for code.
One more concern I see is that, since CC0 by design does not require
attribution, there is actually no way to know that the package does not
contain unattributed CC0 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.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: CC0 reclassified as "not allowed" for code (reposted from legal list)
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 Fedora ships a stripped FFmpeg, there is really no
good reason to not do the stripping of encumbered parts of the AAC spec on
the LGPL-licensed built-in FFmpeg AAC codec instead. That would also make it
easier to switch to the unstripped FFmpeg AAC codec from RPM Fusion. (Right
now, things like GStreamer use fdk-aac-free directly, not through FFmpeg, so
switching to FFmpeg AAC is not a simple drop-in replacement.)
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: CC0 reclassified as "not allowed" for code (reposted from legal list)
Neal Gompa wrote:
> That is correct. The clause is considered a no-op and the license
> isn't approved for use outside of this case.
I do not see how FDK-AAC minus known patented code (i.e., fdk-aac-free) is
any different there than some random CC0-covered software. In both cases,
there is a blanket disclaimer of patent grants, without any evidence that
there are actually any patents affected by the disclaimer.
Even if Fraunhofer gave you a specific list of patents, you can take their
word for it, but then by the same standard you should also trust a statement
like:
https://github.com/nemequ/hedley/issues/52#issuecomment-1035648021
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).
(There are also 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
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: CC0 reclassified as "not allowed" for code (reposted from legal list)
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 > | limitation the patents of Fraunhofer, ARE GRANTED BY THIS SOFTWARE > | LICENSE. Fraunhofer provides no warranty of patent non-infringement with > | respect to this software. > | > | You may use this FDK AAC Codec software or modifications thereto only > | for purposes that are authorized by appropriate patent licenses. > > (That is not the only clause whose freeness was disputed, but if that > clause is unacceptable for CC0, I do not see why it would be acceptable > for FDK- AAC.) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/52 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CC0 reclassified as "not allowed" for code (reposted from legal list)
Richard Fontana wrote: > We plan to classify CC0 as allowed-content only, so that CC0 would no > longer be allowed for code. This is a fairly unusual change and may > have an impact on a nontrivial number of Fedora packages (that is not > clear to me right now), and we may grant a carveout for existing > packages that include CC0-covered code. Sorry, but I have a hard time taking this seriously. Considering the history (see below), it sounds absolutely ridiculous to me. To give some historical context: There was and is still a lot of software out there sloppily declaring itself as "public domain", which, in many jurisdictions, is not even legally allowed. So Fedora has over the years tried to approach those upstreams convincing them to adopt an all-permissive license instead. And, there comes the point: Fedora has EXPLICITLY SUGGESTED CC0 to those upstreams as a legally sound alternative to use! So now, Fedora wants to ban software for using a license that Fedora itself has been EXPLICITLY RECOMMENDING to use for years. This is going to hurt the reputation of the Fedora Project big time, in addition to making us potentially lose hundreds of packages (whose authors might not be willing to relicense their code AGAIN, after Fedora tells them that the license they recommended is suddenly no longer acceptable; after all, authors who put their code under "public domain" or CC0 are authors who do not want to spend time on licenses or even on their software at all, they just want to drop it out there and let people do what they want with it). This is going to be a huge fiasco. And what do you suggest the software use instead? Hopefully not the vague WTFPL? (I wonder whether the claim that the WTFPL implies a patent license would stand in court.) MIT-0 sounds like the most reasonable to me: https://spdx.org/licenses/MIT-0.html > The reason for the change: Over a long period of time a consensus has > been building in FOSS that licenses that preclude any form of patent > licensing or patent forbearance cannot be considered FOSS. CC0 has a > clause that says: "No trademark or patent rights held by Affirmer are > waived, abandoned, surrendered, licensed or otherwise affected by this > document." (The trademark side of that clause is nonproblematic from a > FOSS licensing norms standpoint.) It is unfortunate that this is only coming up now, after years of Fedora itself recommending CC0. 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 | limitation the patents of Fraunhofer, ARE GRANTED BY THIS SOFTWARE | LICENSE. Fraunhofer provides no warranty of patent non-infringement with | respect to this software. | | You may use this FDK AAC Codec software or modifications thereto only for | purposes that are authorized by appropriate patent licenses. (That is not the only clause whose freeness was disputed, but if that clause is unacceptable for CC0, I do not see why it would be acceptable for FDK- AAC.) > The regular Creative Commons licenses have similar clauses. So, e.g., CC-BY-SA is also 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 ___ 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: Help needed: build failure trying to upgrade healpix
Jeff Law wrote:
> That would eliminate the need for those crazy macros. The problem is
> many packages have configury bits that are ancient and can't be rebuilt
> with modern autotools.
I have a hard time believing that.
Even the gigantic KDE 3 autotools mess last updated by upstream 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 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: Help needed: build failure trying to upgrade healpix
Richard W.M. Jones wrote:
> At some point we should just require autoreconf.
I have been arguing for that for years. IMHO, it is a logical consequence of
the general rule that everything in Fedora must be built from source.
Generated files are NOT source code. Patching anything in the configure
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
___
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: poppler soname bump in Rawhide
Marek Kasik wrote: > I plan to rebase poppler to 22.08.0 once it is available. The release > usually happens at the beginning of month so I'm waiting for it now. > Once it is ready, I'll build it in a side tag and will post it here. I > plan to merge the side tag with buildroot next week before branching. > > Packages which will need rebuild: > > calligra > gambas3 > gdal > gdcm > inkscape > kf5-kitinerary > libreoffice > pdf2djvu > scribus > texlive-base I take it that packages that use only, e.g., the Qt 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-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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Important changes to software license information in Fedora packages (SPDX and more!)
Daniel P. Berrangé wrote: > I do expect Fedora reviewers to do more than just look at a handful of > source files though. For any package review, the header of every source > file should checked. Random sampling is not sufficient to identify the > exceptions which do occur often, and are not usually mentioned in the > top level LICENSE file. If there's no header present, then it is > implicitly under the global license, and it is fine to trust that for > the purposes of Fedora license tag. I wish you good luck opening every single of the 167383 files in QtWebEngine (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 in each.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
Zammis Clark wrote: > > It doesn't help that Microsoft does not embed the name of the party > who submitted an UEFI driver for signing in the signature itself. > > Microsoft does do this; it's in an authenticated attribute with OID > 1.3.6.1.4.1.311.2.1.12, aka "SPC_SP_OPUS_INFO_OBJID", it's documented as > part of Office document file formats (VBA signing): > https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-oshared/91755632-4b0d-44ca-89a9-9699afbbd268 With a name like this (a cryptic abbreviation "SPC_SP_OPUS_INFO_OBJID" that does not make it obvious that this is the submitter) and documentation in such a weird place (only one of the many items that can be signed by Microsoft), is it any wonder that, as you write: > The same thing is done for Windows drivers that they sign; Windows > understands this attribute (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 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
