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
Kilian Hanich via devel wrote:
> About the release cycle: After the initial release of Plasma 6 when dust
> has mostly settled down (approx. 2 point releases), they want to switch
> over to a release cycle which would align (which is likely also the
> reason why F42 was choosen in this proposal).
Gordon Messmer wrote:
> If RPM's ELF dependency generator were better, the importance of
> stability would be debatable, but as it is, I really think Fedora should
> be more stable than it is, especially for whatever it defines as "the
> OS." Today, dnf/rpm will happily allow users to install an a
Gordon Messmer wrote:
> "When you are using the Linux mark pursuant to a sublicense, it should
> never be used as a verb or noun. It should be used only as an adjective
> followed by the generic name/noun. In other words, “Super Dooper Linux
> OS” is okay, but “Super Dooper Linux” isn’t."
>
> http
Aaron Rainbolt wrote:
> Still, one could make some case for this. Plasma is, for one, obviously
> going to be more familiar to newcomers to the Linux world simply by
> virtue of the fact that the paradigms presented by its initial
> configuration are more familiar to those coming from the Windows o
Leon Fauster via devel wrote:
> I already had RHL installed on a Sun IPX with Gnome, so I'm biased.
Interesting that you were not put off by the changes that have happened to
GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
actually pretty good. (It was very configurab
Stephen Smoogen wrote:
> Downloads are very hard to measure because too many things are grabbing
> everything from mirrors for different reasons. [Plus various people seem
> to think manipulating the stats for their particular spin on the number of
> downloads will make it more popular (I am lookin
Steve Cossette wrote:
> Another route would be to go the Ubuntu route, if you really don't want to
> stop having Workstation as the default: Spin (pun intended) the KDE spin
> on it's own branding. Though I do understand that is an undertaking on
> it's own. It would still be Fedora, about as much
Andreas Tunek wrote:
> From Red Hat's POV it is not Fedora Gnome Workstation (
> https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/
> ).
TL;DR: "We do not want 'GNOME' in the name because we want to only support
GNOME in Workstation, whereas 'GNOME Workstat
Kevin Fenzi wrote:
> to you? They are quite relevent to others...
I would really like to see what the proportion of users downloading the
Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the
Spins. I would not expect it to be very high. Most Fedora users are desktop
users.
Luis Correia wrote:
> I'm mostly a user and I can accept a change from GNOME to KDE, IF and only
> if I'm not forced to use Wayland.
>
> For me it isn't usable in my setup and most things are plain broken.
As the maintainer of plasma-workspace-x11 and kwin-x11, I can assure you
that that will no
Peter Boy wrote:
> We would be pretty silly if we did that. This differentiation and the
> associated quality and safeguarding criteria are a model for success and
> one of our differentiation criteria.
I think that is a quite pointless "differentiation criteria". Most users do
not even understan
Joe Orton wrote:
> Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the
> API is optional upstream, and its use has produced compiler warnings
> since it was introduced in Fedora 36, it seems perfectly reasonable to
> disable this API in Fedora 41.
I disagree. Disabling an API t
Steve Cossette wrote:
> Putting aside that i heard from Neal Gompa that anaconda cannot
> accommodate a « multi-flavor » media, can you imagine how big that iso
> would be? Forget 4gb, it’d probably be closer to 20gb!
We used to have multiboot live images that let you pick the live image
flavor t
Eric Blake wrote:
> The upstream autoconf discussion says that 'autoreconf -fi' behavior
> on which 'serial NN' .m4 files to update is determined by automake,
> not autoconf, in part inspired by semantics desired in gnulib. And
> the automake and gnulib developers have argued that the upstream
> b
Kevin Fenzi wrote:
> Why not the opposite:
>
> Download Workstation
>
> [I'm a linux user and know what I want, just show me the full list of
> downloads, click here]?
Because that still leads people to click that "Download Workstation" link
before even seeing the options. "I do not want to hav
Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next
That was for Fedora 21 in 2014! As you stated it, I know you and I have been
around forever and 2014 feels like yesterday, but it was really quite a long
t
Steve Cossette wrote:
> Sorry, that's pretty much how things are right now, is that what you were
> trying to demonstrate?
>
> I'm not really following.
Not really. The current design is better than those old designs that
immediately served you an ISO when you clicked "Download now", but the foc
Kevin Fenzi wrote:
> Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> things, we need some way to describe them to uses who might not know the
> history of things and do it in a quick enough way that they won't decide
> it's all confusing and go do something else.
It is ac
Steve Cossette wrote:
> We essentially just want more visibility on the website, if that makes
> sense.
Back when I was still a KDE SIG member, whenever we brought that up with the
Websites Team, they would just point us to the Board (what is now the
Council), and the Board would point us back t
Adam Williamson wrote:
> Change proposals can be, and frequently are, rejected.
If you look at the statistics, they very rarely are. A lot of bad changes
with lots of criticism on the mailing list were waved through by FESCo. But
if they dare touching a Red Hat holy cow such as the dogma of defa
Richard W.M. Jones wrote:
> Yes, in this case the attacker had set the serial number to 30, but
> the latest upstream serial number was 3. autoreconf won't replace the
> file in this case unless it is deleted. There really should be an
> "always replace if you can" option in autoreconf.
Is that
Gary Buhrmaster wrote:
> And, more importantly, the industry has agreed
> to use the term supply chain. Is the term
> perhaps overloaded, or perhaps too
> ill-defined/imprecise? Sure. But if one wants
> to use a different term one would need to work
> across the industry to change the term, and
Adam Williamson wrote:
> It occurs to me - maybe you don't agree, but this is how it looks to me
> - that, ironically, you and I usually argue the exact *opposite* side
> of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> packages appearing in 'stable', and you argue *against* t
Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.
This proves again that this is a very targeted attack that carefully
analyzed the
Aoife Moloney wrote:
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.
It is funny that the KDE SIG is proposing that now. I have a sense of déjà-
vu:
https://fedoraproject.org/wiki
1 - 100 of 925 matches
Mail list logo
