Kevin Fenzi wrote:
> On Wed, Apr 09, 2025 at 03:35:06PM -0400, Eduard Lucena wrote:
>> Can we go ahead in time and let kevin to create the gdm-x11 package? We
>
> Sure, if he wants to?
I do not currently have plans to introduce that package, though I would
encourage people who care enough about
Nishant Mishra wrote:
> It's all good but then in Plasma also you can install X11 session
Yes, but only because *I* packaged kwin-x11 and plasma-workspace-x11
separately and went through a long argument in the FESCo issue tracker with
the KDE SIG trying to block me from introducing those 2 packa
Neal Gompa wrote:
> You need to switch to another display manager, as GDM no longer
> supports X11 sessions.
Time to fork GDM.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@
Nishant Mishra wrote:
> Do you know you still can use X11 sessions on Gnome on Fedora by
> installing the X Packages? This does not mean that X11 support has
> completely been dropped !
Only by using an alternate display manager, and GNOME is known for not
supporting some functionality if GDM is
Jared K. Smith wrote:
> On Wed, Apr 9, 2025 at 12:59 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> This crusade against X11 in Fedora needs to stop NOW!
>>
>
> I'm not involved in this change -- but I take exception to your l
Dominik 'Rathann' Mierzejewski via devel wrote:
> It has been mentioned in various places [1][2] that GDM has dropped
> support for running X11 session in F42. However, I cannot find the
> corresponding Change in the F42 Change list [3]. Has this been done
> without raising a Change? If yes, I'd ar
Sérgio Basto via devel wrote:
> "It is being explicitly dropped from GDM as the code to X11 greeter
> mode is also tied to supporting X11 sessions. If you want to
> use X11 sessions, you need to use something else. "
>
https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/thread/7RLN
Benson Muite wrote:
> enchant still uses it:
> https://src.fedoraproject.org/rpms/enchant2/blob/rawhide/f/enchant2.spec
But Enchant is an abstraction layer that can be built without the aspell
backend, which…
> Other dependencies on f41 are limited:
> enchant-aspell
… as you can see, is a speci
Cristian Le via devel wrote:
> It would be unfair to require upstream to support that pattern when
> CMake does not provide the tools to do so (I know about approaches with
> $ and configure_package_config_file(PATH_VARS), but
> these are not easy to adapt and support for older versions).
if(IS_AB
Kevin Fenzi wrote:
> Ideally things would just be more resistant to being able to make the
> mistakes in the first place, but sometimes thats not easy to do.
As far as I can see, things are quite resistant already considering that the
gating has blocked this from going into Rawhide. :-)
If this
Cristian Le via devel wrote:
> Coming back to `LIB_SUFFIX` and `*_INSTALL_DIR`, those should have never
> been added globally [2]
Why not?
LIB_SUFFIX might not be standard, but is used across many projects and has
clear semantics. If the project does not use it, it will just ignore it. So
why r
Samuel Sieb wrote:
> On 2/22/25 6:50 PM, Benson Muite wrote:
>>
>> Fedora has a policy to support only one kernel. Projects such as
>> OpenHarmony support multiple kernels to enable reuse of components on
>> devices with a wide range of compute capabilities - in particular mobile
>> and edge devi
Leigh Scott wrote:
>> == Benefit to Fedora ==
>> * The size of the default wallpaper is drastically reduced when using
>> JXL format compared to PNG. An example is on this [Fedora 42 Default
>> Wallpaper
>> ticket](https://gitlab.com/fedora/design/team/release-artwork/default-wallpaper/-/is...)
>>
Mario Torre wrote:
> On Tue, Feb 11, 2025 at 2:11 AM Kevin Kofler via devel
> wrote:
>>
>> Mario Torre wrote:
>> > OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
>> > been updated in January for example.
>>
>> This is
Mario Torre wrote:
> OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
> been updated in January for example.
This is entirely unacceptable. The package shipped with Fedora 41, so it
MUST get security backports until the Fedora 41 EOL. If the maintainers do
not want to take
Mikel Olasagasti wrote:
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
I am opposed to this. Bundli
Vitaly Zaitsev via devel wrote:
> On 16/12/2024 21:43, Aoife Moloney via devel-announce wrote:
>> removed support for GPU Generations prior to the
>> 12th Gen GPUs. This effectively means that any hardware released
>> before 2020 is no longer supported for OpenCL and oneAPI workloads.
>
> If it re
Michael Catanzaro wrote:
> * We do expect smartcards to work on immutable systems where
> installing extra packages is either inconvenient (Silverblue and
> Kinoite require overlays) or not possible (future Fedoras, hopefully)
Quite a distopian future you paint there!
My vision of the future does
Dominik 'Rathann' Mierzejewski wrote:
> Dirac codec support is optional in the above.
It still means that the claim that nothing is using this library anymore is
false.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
T
Kevin Kofler via devel wrote:
> PS: I suspect the documentation was actually just an attempt to document
> the previous broken Bodhi policy implementation. (See
> https://github.com/fedora-infra/bodhi/issues/772 and
> https://github.com/fedora-infra/bodhi/issues/1033 – both got close
Björn Persson wrote:
>> == Release Notes ==
>> The /etc/pki/tls/cert.pem file has been deprecated
>
> Removed, not deprecated, according to the rest of the proposal.
> Sysadmins who read "deprecated" in the release notes will think they
> can upgrade Fedora and look into migrating off /etc/pki/tls
Adam Williamson wrote:
> The situation in the old code was actually rather more complicated, and
> weird, than "the non-settable threshold was fixed to the wrong value" -
> there were multiple check functions that applied different logic to
> different operations, which is why you could sometimes p
Kevin Kofler via devel wrote:
> When was this decided? I only remember FESCo ever having decided to
> require +2 for critpath updates, not for non-critpath ones.
>
> At some point, those values were written down in the documentation, but
> under what authority? Where was the FES
Adam Williamson wrote:
> specifically, for releases past the Beta freeze point, *all* updates
> require +2 karma to be pushed stable before the minimum wait. That is,
> if you want your non-critpath update to go stable sooner than 7 days
> after it reached testing, it needs +2 karma. For critpath,
Zbigniew Jędrzejewski-Szmek wrote:
> Heh, that's a cool idea. But that's not how standards work.
> You cannot just insert things at random points in low-level config
> files or protols. How do you think this would work?
> You insert "$tuned_params", I insert "{tuned_params}", and GNU people
> inser
Neal Gompa wrote:
> I know the idea of moving to -O3 has been briefly mentioned before in
> other contexts when we've discussed uplifting the flags, but it looks
> like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason
> why we shouldn't consider doing the same for Fedora Linux 42?
Ye
Zbigniew Jędrzejewski-Szmek wrote:
> With python3-pyqt6-6.8.0-0.1.fc42.x86_64, we get a difference in how the
> icons are rendered:
>
> calibre-7.20.0-1.fc42.x86_64
> modified-S.5
> /usr/share/icons/hicolor/16x16/apps/calibre-gui.png
> modified-S.5
>
Hi,
the recent EPEL 10 branch request for ufw reminded me of this:
I would like to hand out UFW, the Uncomplicated FireWall, (Fedora package
"ufw") to one or more packagers who are more interested in it than me.
I packaged UFW a few years ago as part of the Kannolo effort, because
ufw-kde wa
Adam Williamson wrote:
> Yeah, I was more worried about vesa.
>
> I've now tested and basic graphics mode works OK on UEFI and BIOS on
> both GNOME and KDE with a recent F41 image, so that's good. It uses
> Wayland in all cases so no X drivers involved. The other case I'm
> concerned about is doin
Sérgio Basto wrote:
> That is the point for me, if we have an replacement there is no point
> on keeping old code.
That is the same argument they used to justify desupporting plasma-
workspace-x11 and kwin-x11 in favor of their Wayland counterparts.
I do not see a valid reason for removing workin
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> 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,
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
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
--
___
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
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
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
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
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
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
Am Mittwoch, 3. Juli 2024 06:15:04 CEST schrieb Aleksei Bavshin:
All the prep work has been finished and the side-tag is ready.
Please, rebuild your packages with 'fedpkg build
--target=f41-build-side-91835'.
I have rebuilt kwin and kwin-x11 in the above side tag.
Kevin Kofler
--
_
Aoife Moloney wrote:
> This change is for Fedora Linux 41, and not 411 as the typo in the heading
> suggests :)
Glad that we do not have to wait 185 years ((411-41)/2=185) for this
feature. ;-)
Kevin Kofler
--
___
devel mailing list -- devel@li
Gary Buhrmaster wrote:
> Please provide your audited (by a 3rd party) data that shows
> that MANY (i.e. significant percentage of) people on x86_64-v1
> users have a need for qemu.
"Many people" was just an estimate considering that QEMU is a popular
package, so it is more likely to be used in ge
> This change proposal aims at removing NetworkManager support for ifcfg
> files in Fedora.
[snip]
> * Proposal owners: drop the following packages:
> ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin
Huh? This contradicts the following paragraph in the simultaneously filed
htt
Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in hot-paths makes a perf difference.
>
> So w
Fabio Valentini wrote:
> We requested an exception to the Updates Policy, which was granted by
> FESCo: https://pagure.io/fesco/issue/3204
Quoting from there:
> Now the Multimedia SIG has been approached by GStreamer upstream
> developers - why Fedora 40 is shipping without the latest version of
>
Sandro wrote:
> I was probably overthinking this. In practice it will turn out to be a
> new package submission indeed. Moreover, the last remaining active
> branch of the retired package (F38) is now EOL.
>
> I've submitted the review [1] without any Obsoletes.
Since we support upgrades from Fed
Julian Sikorski wrote:
> are there guidelines advising how to handle upstream desktop filename
> change in a stable fedora release? For gnumeric I just followed upstream
> [1], which led to a bug report [2]. Now I am facing similar situation
> with pavucontrol [3]. Should I rename the desktop file
Michael J Gruber wrote:
>> %patchlist and %auto* should just go away, or at least banned from Fedora
>> by a git hook rejecting such specfiles.
>
> We also have unnumbered patch source definition lines, don't we?
IIRC, unnumbered Source: or Patch: just defaults to Source0: resp. Patch0:.
But it
Pedro Moura wrote:
> To add blog posts in Fedora Planet you basically need to update RSS URL
> field at https://accounts.fedoraproject.org/
Which means that basically all blogs are going to vanish from Fedora Planet
unless people re-add them manually.
There are 809 blogs on the old Planet Fedora
Neal Gompa wrote:
> I have the question of why is dnf5 running as if "--allow-erasing" is
> always passed to it? Older versions of DNF explicitly didn't do that
> because we get weird behaviors like this.
Without --allow-erasing (which was actually passed explicitly, as Petr Pisar
pointed out), t
Panu Matilainen wrote:
> Patch and source numbers start from zero, that goes for automatically
> numbered patches too. So there's an off by one in the application, and
> the latter %autopatch which is supposed to apply patches >= 2 simply has
> nothing to do, and falls through silently. That's a bu
Adam Williamson wrote:
> The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly
applies all patches in numeric order. Cannot reorder patches, cannot apply
them conditionally (e.g., based on the 0%{?fedora} ver
Florian Festi wrote:
> We have an even easier solution for you: You can just run the script at
> [3] with -n on your own spec files to get them changed to the %patch N
> variant. If you do that right now they will not break nor will they be
> touched during the mass change.
>
> As I said the %patc
Neal Gompa wrote:
> On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel
> wrote:
>>
>> Am 06.05.24 um 13:56 schrieb Florian Festi:
>> > Hi everyone,
>> >
>> > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
>> > the patch number for a year now. See the RPM documentation
Carlos Rodriguez-Fernandez wrote:
> How could that be expressed so that those are caught quickly at build
> time? Someone wants to depend on a java lib that has been tested only in
> JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa,
> for example. Perhaps, the only feasible w
Christopher wrote:
> So, I actually think that building with the *latest* JDK that we ship,
> and using the `--release` flag during compilation is actually safer
> than building against the lowest that we support, because it is most
> likely to strictly enforce correct byte code generation for the
Carlos Rodriguez-Fernandez wrote:
> Regarding the proposal as a whole, I think the proposal idea makes a lot
> of sense, but for apps depending on system jar libraries, there should
> be a way to specify that the app depends on a specific java bytecode
> version range. System libraries packages cou
Miro Hrončok wrote:
> If you wish to help, I guess you can send a pull request to the release
> notes...
Or Mattia could simply unretire and adopt the package.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
Fabio Valentini wrote:
> No, that's just wrong.
> The "upgrade path" (wrt/ NVRs) is no longer enforced across release
> boundaries. AFAIK, all supported release-upgrade methods now use
> distro-sync or something equivalent, so NVR-based "upgrade path" is just
> not important any more.
That just do
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
> dist
Julian Sikorski wrote:
> I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> mame-0.265-1.fc41 is already built against it so I only need to build
> mame-0.265-1.fc40.1. Can it be done using %autorelease?
No, which is why you should not be using %autorelease.
I would just replace %autore
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .
Sigh… Time for a UsrUnmerge? :-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the branches
David Abdurachmanov wrote:
> We currently use a symlink (as Richard) mentioned, but it's not ideal
> and causes problems (e.g. meson generates wrong paths breaking some
> packages [one example: libplacebo]).
Which I would say is a bug in Meson and should be fixed there.
I do not think having /usr
Nathan Scott wrote:
> - it could be advantageous if the new compat sub-package contained
> the redis binary symlinks & not the primary valkey package (this could
> allow valkey and redict packages to coexist, for example). Long-term
> we may want to drop those entirely (along with the compat packa
Kilian Hanich via devel wrote:
> The fact that you can share the keys is actually part of the design and
> wanted. Apple for exmaple has (or wants to) implement easy sharing of
> passkeys via AirDrop.
So the Apple Cloud can see your private key, but you cannot? Sounds like
GREAT "security", LOL…
Gary Buhrmaster wrote:
> [2] As I understand it, the issue is the
> lack of the required trusted environment
> in generic Linux. There are software
> implementations that do not have the
> hardware enclave protections,
And to be honest, I do not see the problem there. I will use whatever will
le
Richard W.M. Jones wrote:
> As gcc -Os was mentioned too, that is -O2 with the following
> optimizations disabled:
>
> -falign-functions -falign-jumps
> -falign-labels -falign-loops
> -fprefetch-loop-arrays -freorder-blocks-algorithm=stc
Last I checked, there were also some hardcoded if (opti
Neal Gompa wrote:
> I would like for us to consider evaluating a global change to -O3. I
> am not convinced that there's a good reason anymore to remain at -O2.
>
> If we get this kind of benefit from Python, I would be interested in
> seeing what we'd get elsewhere.
How much larger is Python at
Adam Williamson wrote:
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
If you use Keysmith, you can ju
Zbigniew Jędrzejewski-Szmek wrote:
> So… this is what I'm talking about: there is no obvious way to
> figure out what to set. Looking at the logs and trying to figure out
> some variables from that is not very attractive.
The comments at the top of the relevant Find*.cmake module are the best
sou
Zbigniew Jędrzejewski-Szmek wrote:
> And sorry, but saying to "process pull requests quickly" is just naive.
> Busy packages often have many different pull requests concurrently, and
> some of them need discussion and fixes and work in other places before
> they can be merged.
Generally, there sho
Zbigniew Jędrzejewski-Szmek wrote:
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
The fix for that inconsistency would be to ban rpmautospec. It just makes
everything mo
Emmanuel Seyman wrote:
> I've noticed a trend in proposed changes in the way Fedora works.
I am fed up of this salami tactic as well. When we complain about the new
stuff, we invariably get told "don't worry, you don't have to use it, it's
all optional", but the plan is always to make it mandato
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream ma
Peter Boy wrote:
> Well, a switch from Gnome to KDE would require a lot of changes in
> everyday applications, e.g. Mail. That is not required when you update
> from Gnome 2 to Gnome 3.
Well, in principle, GNOME applications will usually work under Plasma and
the other way round. But in practice
Leslie Satenstein via devel wrote:
> The Cellphone user is very comfortable with Gnome. So much so, that I
> believe that if he was given KDE as the interface, two things would
> happen. a) The user will switch to Gnome, or b) The user will find a way
> to add his favourite applications to the desk
Tomasz Torcz wrote:
> GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.
And I believe that that, too, was a refinement added in later releases.
IIRC, GNOME 3.0 just maximized everything.
Kevin Kofler
--
___
d
Peter Boy wrote:
> I'm probably not the right person to comment on this, because I completely
> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That
> destroyed my daily workflow and work routines and made it unusable (for
> me), or at least barely usable for serious professional work
I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.
PS: Here is a pretty good post
Neal Gompa wrote:
> By default, GNOME only presents the close window button. The other
> buttons are missing, and there isn't really an intuitive way to
> discover the other window management actions.
In the version I tried, and judging from end user reports, for several
years, it did not even pr
Leon Fauster via devel wrote:
> 10 minutes is not enough to do a remodeling of the "familiar"
> experience, so that you reaches the so called realm of intuition.
> The latter is something that we learn over time and the desktop
> environment does not offer this on its own. It provides only a
> fram
1 - 100 of 950 matches
Mail list logo
