Richard W.M. Jones wrote:
> The problem is you're confusing general gains and gains in
> specific scenarios.
But the thing is that a gain in some specific scenario is a lot less useful
than a general gain. And the latter is usually not had through profiling,
but through improvements in toolchain
Neal Gompa wrote:
> GCC is not the official compiler on Windows or macOS. Both platforms
> require frame pointers on all supported architectures with their
> official compilers (MSVC for Windows, Clang for macOS).
Frame pointers are not required by the operating system if you can compile
working
Kevin Kofler via devel wrote:
> Also, for MSVC, /Oy- is documented to be supported on everything except
/Oy actually. /Oy- is the default (= -fno-omit-frame-pointer), /Oy is the
equivalent of -fomit-frame-pointer. But both are documented as unsupported
only for "x64 compilers".
Kevin Kofler via devel wrote:
> Still, it gives an extremely bad impression of rushing this through
> without giving anybody the chance to object.
>
> I also do not see why this needed to be approved for F38 on such a short
> notice and could not wait for F39.
PS: The impressio
Kevin Kofler via devel wrote:
> 7. Only 4 days had elapsed between the (unannounced) opening of the ticket
> and the vote. This is clearly insufficient. The one week in the Change
Sorry, there were actually 6 days. Still, less than a week, and there was no
mailing list announcemen
Vitaly Zaitsev via devel wrote:
> The original proposal received a lot of negative feedback. Only a few
> big corporations will get benefit and end users will get a 3-10%
> performance penalty which is absolutely unacceptable.
Not to mention the size impact. My request in the original discussion t
Also, the pull request implementing the change was merged 6 days BEFORE the
change was approved by FESCo! It is unacceptable to sneak unapproved changes
into Rawhide this way in order to "create facts".
Kevin Kofler
___
devel mailing list -- de
Kevin Kofler via devel wrote:
> PS: The impression I get is that everything was deliberately rigged so
> that the vote would end up the way it did:
>
> 1. A new ticket was filed, in order to exclude the participants of the
> previous discussion.
> 2. The people watching the o
Am Montag, 9. Jänner 2023 17:47:54 CET schrieb Matthew Miller:
And, from a practical point of view, since this passed with six +1 votes,
I'm not sure what benefit canceling and re-voting would really add.
Canceling the vote and requiring that the Change Policy be followed would
mean that the c
Am Montag, 9. Jänner 2023 20:10:53 CET schrieb Daniel P. Berrangé:
Holding a FESCo meeting and vote on the very first working day after
the long xmas / new year holiday is not exactly good timing if you
want contributors to be broadly aware it is happening[1]. I might
humbly suggest that next yea
Am Montag, 9. Jänner 2023 21:02:48 CET schrieb Tom Stellard:
I think a good solution would be to move the proposal submission deadlines
a month earlier in the schedule. There's only 3 weeks between the
"Changes Requiring Mass Rebuild" deadline and the mass rebuild.
I don't think 3 weeks is rea
Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately
rigged so that
the vote would end up the way it did
Miro Hrončok wrote:
> Considering the mass rebuild is happening really soon, I feel like
> repeating the vote later is not helpful, but if people want to, we can
> surely run the vote again. However, I am confident the result will be the
> same.
With all this talk about the mass rebuild being immi
Demi Marie Obenour wrote:
> On 1/6/23 20:35, Frank Ch. Eigler wrote:
>> (There are exist other profiling tools and techniques that do not
>> require frame pointer recompilation, but whatever.)
>
> Which ones? I would love for them to exist, and I believe there is
> work being done in that direct
Am Dienstag, 10. Jänner 2023 08:25:27 CET schrieb Zbigniew
Jędrzejewski-Szmek:
On Mon, Jan 09, 2023 at 11:53:17PM +0100, Kevin Kofler via devel wrote:
No, the result is NOT why I got the impression that the vote
was rigged. The way that result was obtained is.
Exactly, you're just confi
Miro Hrončok wrote:
> * ACTION: bcotton to make a proposal on the mailing list to explicitly
> require full resubmission of rejected proposals (and then bring it
> to a FESCo ticket once discussion has happened) (mhroncok,
> 18:36:36)
So FESCo is willing to prevent this from happening again in th
Hans de Goede wrote:
> lua-5.4.4-4.fc37 in F37 release provides both:
>
> liblua-5.3.so()(64bit)
> liblua-5.4.so()(64bit)
>
> aka both of:
>
> /usr/lib64/liblua-5.3.so
> /usr/lib64/liblua-5.4.so
This was a compatibility hack that was accidentally left enabled:
https://src.fedoraproject.org/rpms
Simo Sorce wrote:
> Soname breakage should not happen in stable releases...
There are exceptions, including but not limited to security updates, which
is relevant for Lua.
> liblua should be rebuilt to provide the older so name and if not
> possible with the new code, reverted back via epoch cha
Michael Catanzaro wrote:
> You've previously indicated that developers should just 'dnf
> distro-sync' to an alternative Fedora that has frame pointers, as if
> building two alternate versions of Fedora, one for developers and one
> for users, is a reasonable thing to do. The cost of this is just t
Michael Catanzaro wrote:
> (In particular, I doubt the _FORTIFY_SOURCE=3 change was really a major
> consideration here.)
What was, then? That was literally the only thing that has changed between
the two diametrically different votes.
Kevin Kofler
___
Zbigniew Jędrzejewski-Szmek wrote:
> That description assumes that FESCo members are preschoolers who are
> easy to trick and also need to be reminded who said what every day.
> That's certainly not the case. The objections against the proposal
> were made very clearly and they certainly weren't fo
Siddhesh Poyarekar wrote:
> That came up in yesterday's FESCO meeting, so hopefully at least that
> workflow hole will be plugged:
Still does not help the current case though, unfortunately.
Kevin Kofler
___
devel mailing list -- devel@lists.fed
Hi,
to those who are pushing the -fno-omit-frame-pointer change: Are you aware
that neither that flag nor even -mno-omit-leaf-frame-pointer actually
guarantee that every leaf function is going to carry a frame pointer, as
required for your backtraces?
See for yourself:
https://godbolt.org/z/Tj
Daniel Alley wrote:
> It is unlikely that the critical bottleneck of any applications will be on
> such a function.
But it can be in the function CALLING such a function, and said function
will be completely missing from the backtrace.
Quoting your link
[https://developer.arm.com/documentation/
Olivier Fourdan wrote:
> Actually… I suspect fixing that build failure would require a fix in
> the xserver from ajax [1]
Actually, this is the fix that is needed:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/commit/4e1963a812f2c1777ba5d56ea9e939a3e40a0496
(This is the xf86-video-q
Daniel Alley wrote:
> The quotation says the opposite of what you are saying. "leaves the frame
> pointer pointing to the caller's frame" => the caller set the frame
> pointer, the leaf did not, therefore the leaf function will not show up
> but the caller still will.
No, that is not what it say
Lukas Zaoral wrote:
> there is no need to wait for klee. Unfortunately, the package cannot be
> build in Rawhide at the moment since the project cannot be built with LLVM
> 15 and the llvm14 compatibility package cannot be used with clang 15 (and
> clang14 is a library only package).
Looks like we
> * As of today the module does nothing because one of the configuration
> files use to define the permissions (50-default.perms) is not
> installed in the distribution. Other packages may install their own
> configuration files to specify the permissions, but I haven't found
> any.
So basically,
Fabio Valentini wrote:
> In that case, I think it would make sense to have C / C++ compiler
> flags for user-installed Python packages to fall back to GCC defaults
> (same as for user-compiled C / C++ code)
The GCC defaults are completely useless. -O0, almost no warnings, etc.
Kevin Kofle
Daan De Meyer via devel wrote:
>> What about the new SFrame unwind info?
>
> We're closely following up on this new format and will compare it against
> frame pointers if a patch introducing a kernel unwinder for sframe is
> proposed and likely to be merged. It's still very early days for SFrame
>
Gerald B. Cox wrote:
> yubioath-desktop and potentially yubikey-manager-qt will not be included
> in the F38 repository due to packaging issues. For additional information
> and suggested mitigations, please review:
> https://discussion.fedoraproject.org/t/f38-yubioath-desktop-yubikey-manager-qt-w
Gary Buhrmaster wrote:
> Is someone working on packaging the Dart and Flutter SDK
> (and all their dependencies, which I had had this vague
> recollection also required gradle, and, well, gradle is its
> own issue) for Fedora in that F39/F40 time frame so that they
> can be used to build apps such
Adam Williamson wrote:
> OTOH, it's not reasonable to dictate to the person maintaining a Fedora
> package whether they should think that's a reasonable use of their time
> or not. The current maintainers of Bottles decided they trust the
> upstream developers to distribute their software 'properly
Michael Catanzaro wrote:
> A PackageKit backend for dnf5 would also work and I have no doubt it
> will happen regardless. Surely that'd be the best option for Fedora if
> dnfdaemon does not have the same D-Bus API that PackageKit does,
> because pushing dnf-specific code into upstream projects when
Fabio Valentini wrote:
> You don't even need to file paperwork for excluding i686 anymore since
> this happened:
> https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
But openmpi is not a leaf package, so this fast-track process does not
apply.
Kevin Kofler
__
Luya Tshimbalanga wrote:
> Sharing the same point of view, I failed to understand why as open
> source the community failed to properly produce a better documentation
> for a plugin and better documentation for a cross platform front
> package manager like PackageKit while continuing to yet anothe
Lokesh Mandvekar wrote:
> We (podman upstream and fedora maintainers) are hoping to disable i686
> and 32-bit arm builds for Podman and some related tools under
> https://github.com/containers org. We would like to do this also for
> released Fedora versions, and not just the upcoming ones.
In gen
Daniel P. Berrangé wrote:
> Looking at Flatpaks with both my upstream author hat and distro maintainer
> hat, the main advantages I see is not the isolation. It is that they have
> the potential to eliminate the massive amount of duplicated work between
> every distro re-packaging the same app, and
Lokesh Mandvekar wrote:
> Checked with the team and I'm told 32-bit containers on 64-bit arch
> should not be impacted.
Good to know. Then I think nobody will miss the i686 build or even notice
its absence (considering that it is not a shared library and that pure i686
installations of Fedora ha
Ben Cotton wrote:
> 1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
> exceeds maximum size — ASSIGNED
Let me guess, this is from the -fno-omit-frame-pointers Change? I have been
asking for data on the size impact and I have been completely ignored both
by the Change owners
Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 09, 2023 at 06:44:03PM +0100, Tomas Hrcka wrote:
>> Hi All,
>>
>> Fedora Linux 38 has now been branched, please be sure to do a git pull
>> --rebase to pick up the new branch
>
> I know this has been discussed seemingly on every branching since the
Chris Adams wrote:
> Can you stop grinding your axe against a decision you don't agree with?
> You're just "guessing" with zero evidence.
I have also seen zero evidence of the contrary (i.e., that the size change
is *not* significant), which should have been a prerequisite for accepting
the chan
Maxwell G via devel wrote:
> ```
> $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent
> $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent
> ```
Since your mail does not document what the -X flag does:
Quoting:
https://git.sr.ht/~gotmax23/fedrq/tree/e75
Kevin Kofler via devel wrote:
> We need to be much stricter on size increases! In Fedora 9 (when the xz
> compression for live images was introduced, which made it smaller than
> Fedora 7 or 8), the x86_64 KDE Spin was 729272320 bytes.
I have to correct myself: Fedora 9 was not whe
Stephen Smoogen wrote:
> I did a check on some.. I only downloaded 3 isos so this isn't a complete
> set.
I think trying to track down 11 to 16 years of creeping bloat now is pretty
much a lost cause, but one thing I notice:
> The 20 largest packages on 33 is:
[snip]
> 47955205 qt5-qtwebkit
> 60
Stephen Smoogen wrote:
> The following is from the F38 image from last week?
>
> dnf remove qt5-qtwebengine
> Error:
> Problem: The operation would result in removing the following protected
> packages: plasma-desktop
QtWebEngine is the native web engine of the KDE desktop and the one that
shou
Neal Gompa wrote:
> FYI, if the GTK-based Anaconda UI goes away, the KDE variants probably
> ship a thin QtWebEngine wrapper or use Firefox instead for the
> web-based UI. No reason to depend on WebKitGTK for this.
Well, the way the Anaconda web UI is currently packaged, it hardcodes a
requiremen
Neal Gompa wrote:
> We're not getting rid of Firefox.
At least that is an answer, unlike the complete radio silence on:
https://bugzilla.redhat.com/show_bug.cgi?id=1920298
Still does not explain why Firefox has to be the default though.
But the thing is, this inevitably leads to:
* unnecessarily
Demi Marie Obenour wrote:
> And is kept up to date, unlike QtWebEngine. QtWebEngine is invariably
> behind on security patches. I blame Google for not making embedded
> Chromium a first-class citizen.
Qt backports security fixes to its stable branches, a service Google is not
offering by themse
Peter Robinson wrote:
> It was decided years ago that all desktops would have some Fedora
> similarities, backgrounds, browser etc.
If and when that was decided, that was without involving the maintainers of
the Spins. I know because I was directly involved with maintaining the KDE
Spin at the t
Michael Catanzaro wrote:
> As a browser maintainer itself, I'm very supportive of the Falkon
> project. I consider it to be KDE's equivalent of Epiphany, sort of a
> sister project, more or less.
Agreed. I also think that the "Workstation Edition" should be shipping
Epiphany instead of Firefox (a
Adam Williamson wrote:
> On Tue, 2023-02-14 at 16:44 +0100, Kevin Kofler via devel wrote:
>> Peter Robinson wrote:
>> > It was decided years ago that all desktops would have some Fedora
>> > similarities, backgrounds, browser etc.
>>
>> If and when that
Gordon Messmer wrote:
> As there is some discussion of whether the ELF dependency generator
> should use the full version string presented by the library file name's
> suffix, or should assume a SemVer-style major.minor and truncate the
> requirement to the first two dot-separated numbers, question
Julian Sikorski wrote:
> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> build [2] has already been deleted. This is not ideal from maintainer
> perspective as it effectively is a bug with no info provided whatsoever.
> Not to mention being quite wasteful from the resources
Kevin Fenzi wrote:
> I fear the only way to fix it is to get pungi to merge entire repos, and
> I don't think thats anything that pungi wants to be on the hook for
> doing.
But there are more things than just DeltaRPMs it could be useful for. E.g.,
I remember that in ancient times (pre Core-Extra
Gordon Messmer wrote:
> I'm not sure if that means that you are opposed to the proposal, or to
> the idea of truncating the version numbers, or something else entirely.
> :)
I see the value of the proposal, but I am worried that it may run into
issues with upstream packages using very weird libr
Ben Cotton wrote:
> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
> must replace your API keys at least once a year. Additionally, any API
> key that is not used for 30 days will be suspended but can be
> re-enabled on the account's preferences tab.
So Red Hat Bugzilla API
Matthew Miller wrote:
> The "good news" is that Red Hat has announced a move away from Bugzilla
> for future products. (They're going to Jira.)
Ah right, I had forgotten about that issue. I do not think I will ever
understand the fascination some projects have for JIRA. It is proprietary,
and IM
Michael Catanzaro wrote:
> On Fri, Feb 24 2023 at 12:00:40 AM +0100, Björn Persson
> wrote:
>> There are also other dangers with installing only security fixes. If a
>> bugfix is released and packaged, and later it's discovered that the
>> bug
>> had security implications, then no security update
Kevin Fenzi wrote:
> I'm not sure what a solution could be. Keep every update in updateinfo
> so dnf could tell you that there's 2 updates and 1 is security and the
> other bugfix? but then we would need to also keep those updates around
> to update to.
Add a repodata field "last security update E
Kevin Kofler via devel wrote:
> I would personally not miss --security, but what is really useful is the
> --advisory=… flag that used to be implemented by the same plugin. (They
> are now both built in in DNF.) That is invaluable to test individual
> updates from updates-testing. I wo
Felix Wang wrote:
> /usr/bin/ld: /tmp/ccW09Umc.ltrans0.ltrans.o: relocation R_X86_64_PC32
> against symbol
`_ZTIZN8logstore4SinkC4EbRSoEUlSt17basic_string_viewIcSt11char_traitsIcEEE_'
> can not be used when making a shared object; recompile with -fPIC
Pass -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=O
Dan Horák wrote:
> another option is to build the internal libs as static, then they won't
> have to be installed. Try appending
> -DBUILD_SHARED_LIBS:BOOL=OFF
> to the cmake flags
I guess this is also why the OP ran into the error with the non-PIC code in
the static library in the RPM build and
Zbigniew Jędrzejewski-Szmek wrote:
> Parallel runtime installation is obviously required.
> But is it necessary to have parallel installation of devel headers?
> It might be less work to have conflicting -devel packages and just
> BuildRequire one or the other.
Conflicting -devel packages are an a
Petr Pisar wrote:
> Would that affect all clients? No. updateinfo.xml can only be downloaded
> by clients requesting that data. People doing "dnf upgrade" can safely
> skip it.
Keep in mind that updateinfo.xml is also used by GUI updaters such as
dnfdragora or plasma-pk-updates to display details
Kevin P. Fleming wrote:
> Not O365, but Google Workspace... that ship sailed some time ago (I'm
> sending this using Thunderbird going through Google Workspace, so at
> least I don't have to *see* GMail...)
#facepalm# 🤦
Kevin Kofler
___
devel ma
Daniel P. Berrangé wrote:
> The main reason for i686 continuing to exist at all in Fedora is to
> facilitate running of externally distributed 32-bit apps (for example
> wine/steam related). Those apps are all going to be built with 32-bit
> time_t.
WINE is packaged in Fedora. If Fedora rebuilds e
Zbigniew Jędrzejewski-Szmek wrote:
> True. But is this annoyance bigger than updating dependent packages
> to load headers from a different location? Apparently many (most?)
> packages will need to use the compat headers at least for now, so that
> cost would be pretty high.
This depends mainly on
Florian Weimer wrote:
> And I thought Wine can run 32-bit Windows applications against 64-bit
> system libraries these days? Or at least it's getting there. Then Wine
> wouldn't be a reason to keep 32-bit builds around.
>
> | *** WoW64
> |
> | - The 64-bit Windows-on-Windows (WoW64) architectur
David Michael wrote:
> - Firecracker can be built with Fedora's libc (glibc), but it is
> officially unsupported upstream[3]. Functionality would be harmed by
> not using musl, e.g. seccomp filters are not used.
Upstream's refusal to write seccomp filters that work with glibc should be a
red fla
Richard W.M. Jones wrote:
> And since we're talking hypervisors, qemu also manages to use glibc &
> implement a seccomp filter.
Good to know. I was not aware that qemu has a seccomp filter, that is nice.
Kevin Kofler
___
devel mailing list -- dev
Mattia Verga via devel wrote:
> BTW, it's not really different on how the kde-sig managed to drop x11
> support - they wanted to do so and they have not stopped until they got
> what they want, addressing most of the concerns raised by the community.
But the main concern was that the community doe
Michael Catanzaro wrote:
> We don't have proposed wording yet. We should of course be reasonable
> and not write something misleading, but I think the question should be
> something along the lines of "help improve Fedora" (e.g. "Help improve
> Fedora by sending anonymous usage data" plus maybe "Fe
mkol...@redhat.com wrote:
> To only change that could impact spins is that we would ideally like to
> drop the X11-only libXklavier library we have used for keaboard
> handling so far and replace it with the universal localed keyboard
> handling API. IIRC Jiri Konecny already notified all spin owne
Ohms, Jannis wrote:
> I Inherited a legacy Project using this tool to count pages. I use this
> tool as part of a tea4cups hook . are you aware of any substitutes for
> pkpgcounter
There is this fork: https://github.com/berghetti/pkpgcounter-1 that at least
claims to support Python 3. (It is a f
Kevin Kofler via devel wrote:
> That said, it is not sufficient to reject adding Fedora downstream
> spyware. Fedora also needs a policy that upstream "telemetry" spyware is
> not allowed and needs to be disabled at compile time or patched out. We
> have several packaged a
Frank R Dana Jr. wrote:
> I do not envy you this work. The documentation fallout alone...
So WHY again are we doing this then? All this is achieving is causing
breakage, for zero user-visible benefit.
IMHO, the sbin merge should NOT be merged/pushed from the side tag into
Rawhide. Instead, the
Zbigniew Jędrzejewski-Szmek wrote:
> So… the question now: should I pull the plug on the change for F41,
> dump the side tag,
Yes please!
> and try again for F42?
No thanks! Please just dump this broken idea into the trashcan it belongs
in.
Kevin Kofler
--
___
Kevin Fenzi wrote:
> I guess you are talking about live images here?
>
> If so, they shouldn't need rpm as they don't install using it...
The live images MUST contain the rpm executable because their contents are
installed to disk (HDD/SSD/whatever) when installing the live image, and at
that p
Pavel Raiskup wrote:
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds. Currently, Rawhide build results are kept indefinitely, but
> this is going to change in the future.
>
> For the full story,
Pavel Raiskup wrote:
> Have you considered to submit an RFE for this "Extend All" feature?
> I think this convenience button (or even with API, if reasonably easy to
> implement) sounds like an acceptable compromise to me.
I remember having once suggested that on this mailing list and having
rece
Pavel Raiskup wrote:
> Yes, I believe there are high chances to accept this (much harder will
> to prioritize the feature). If you know what you are doing, the point
> should not be to make the prolonging process click-expensive - which it
> admittedly is now, if you maintain dozens of long-term p
Marián Konček wrote:
> You will do the others a great service if you use the English
> language in GitHub commits and READMEs.
I doubt this will be used outside of Italy, except perhaps by Italian
citizens abroad (like me), who should also understand the Italian language.
It looks like every sin
Germano Massullo wrote:
> It worths also mentioning that both the Windows and Mac OS versions do
> not contain any Java source.
> Moreover, the Windows version contains some C# sources
> https://github.com/italia/cie-middleware
> and the Mac OS version contains some Objective C sources
> https://gi
Germano Massullo wrote:
> 1. please switch to CMake build system completely: some parts of the
> software need to be built through Eclipse, I.E. cie-pkcs11. CMake should
> be the only build system in the project. CMake will also enable CIE
> Middleware being built for all Linux distributions, Mac O
Marián Konček wrote:
> I had the same question and I don't exactly remember the most important
> reason, but it was something like there were large differences between
> versions which made the builds more difficult. Now I see it also uses
> Kotlin, maybe that is also a reason. Upstream projects te
Julian Sikorski wrote:
> Germany uses their own implementation too:
> https://src.fedoraproject.org/rpms/AusweisApp2
> To add insult to injury, it requires the use of custom EC curves, which
> are bound to stop working at any moment:
> https://bugzilla.redhat.com/show_bug.cgi?id=2259403
At which p
Zbigniew Jędrzejewski-Szmek wrote:
> #3244 Change: Retire Python 2.7
> https://pagure.io/fesco/issue/3244
> APPROVED (+8, 0, 0)
This is going to break the build of a whole bunch of compatibility packages,
which will in turn break a lot of software in Fedora.
Do you expect packages to do what Qt5
Zbigniew Jędrzejewski-Szmek wrote:
> #3242 Change: Opt-In Metrics for Fedora Workstation
> https://pagure.io/fesco/issue/3242
> APPROVED (+6, 0, 0)
And this one is yet another case of FESCo rubberstamping a change without
even any dissenting vote despite loads of negative mailing list feedback. I
Am Mittwoch, 24. Juli 2024 02:41:12 CEST schrieb Gary Buhrmaster:
And, FWIW, it appears that qtwebkit has been
FTBFS since F39, so qtwebkit could end up
being a moot point.
It built fine in the F39 mass rebuild, only started failing in the F40 one.
So it is NOT in the list of packages to be re
Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster:
On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel
wrote:
And this one is yet another case of FESCo rubberstamping a change without
even any dissenting vote despite loads of negative mailing list feedback.
How can one
Kevin Fenzi wrote:
> The approved/second/reworked version of this _did_ take lots of people's
> concerns into account. There were/are still some few people who still
> didn't like it for whatever reasons, but I think it's pretty clear that
> concerns were defintely heard. The change owners were ver
Przemek Klosowski via devel wrote:
> I just can't agree with this statement---both in some deep philosophical
> sense and in practical terms. F is for First! Yes, the changes are
> sometimes annoying---I miss my FreeCAD :(---but, overall, I think Fedora
> has a track record of consistently advancin
Björn Persson wrote:
> I wish I were allowed to use FIDO2. The dominant ID protocol in Sweden
> is called BankID. It's a proprietary and secretive protocol that
> requires a proprietary app that requires an operating system from
> either Apple or Google – or sometimes Microsoft, but in many cases n
Kevin Fenzi wrote:
> I am not making any such assumputions. Let me be clear (and speaking
> only for myself):
>
> Changes are not always good
> Not every unacceptable/rejected change can be reworked to be acceptable.
>
> Where did I say otherwise?
The "Not every unacceptable/rejected change can
Jan Grulich wrote:
> The reason for this is that qt5-qtwebengine copies over re2 header files,
> but that doesn't mean it links against the system version, it still uses
> the bundled one anyway.
The way it was SUPPOSED to work was that the header hack was supposed to be
applied together with an
Josh Boyer wrote:
> Yes, but people could just use HTML mail as well. I'm far too lazy to
> deal with multiple syncs across devices and phones, and other online
> clients suffer from the same problems.
Huh? Is it not the point of IMAP that everything happens on the server,
there is nothing to sy
l...@fedoraproject.org wrote:
> In this case, OpenCOLLADA can be retired on Rawhide as Blender no longer
> explicitely requires it for building.
That by itself is not a reason for fast-track retiring the library.
Kevin Kofler
___
devel mailing l
Peter Robinson wrote:
> Assuming those "binary compatible distributions" choose to add
> LibreOffice back in and support it, given what they actually do in
> terms of actual development it's actually pretty unlikely they're
> going to do all the extra work to add back an office suite and all the
>
Peter Robinson wrote:
> Someone doing work in EPEL is quite a bit different to my point of a
> corporate organisation downstream of RHEL adding value and
> differentiation that Red Hat doesn't provide as part of RHEL.
The discussion was about people being able or unable to obtain the
LibreOffice
101 - 200 of 969 matches
Mail list logo
