Re: Summary/Minutes from today's FESCo Meeting (2023-03-07)

Zbigniew Jędrzejewski-Szmek wrote: > * #2951 Proposal: policy for resubmitting rejected proposals (zbyszek, > 17:07:47) > * AGREED: FESCo will make an effort to notify people when proposals > are resubmitted for voting without a formal change in the process > rules. A note will be adde

Re: Summary/Minutes from today's FESCo Meeting (2023-03-07)

Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 10, 2023 at 05:49:24AM +0100, Kevin Kofler via devel wrote: >> So basically we are stuck with the status quo. Meaning that there is >> still nothing preventing an already rejected feature from being >> surprisingly reconsid

Re: Summary/Minutes from today's FESCo Meeting (2023-03-07)

Zbigniew Jędrzejewski-Szmek wrote: > Normally, I wouldn't phrase a letter this way. But Kevin will incessantly > repeat the same things after a decision is made that he disagrees with > or when there is some fact that he doesn't like. So you are now accusing me of disagreeing with facts? Seriously

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

David Cantrell wrote: > We can't get rid of the License tag, unfortunately. See: > > https://www.linuxfoundation.org/blog/blog/spdx-its-already-in-use-for-global-software-bill-of-materials-sbom-and-supply-chain-security > > And as part of the US Executive Order on Cybersecurity, we need to start

Re: F38 DNF/RPM install errors due to header signatures

Stephen Smoogen wrote: > Basically the problem is that several checksums and types of keys are > considered highly insecure and will cause problems for large numbers of > users who have systems which need to meet general security rules in > various industries. These include the SHA1 and DSA encrypt

Re: It’s time to transform the Fedora devel list into something new

Matthew Miller wrote: > I propose that we transition devel list, and eventually most of our > mailing lists, to Fedora Discussion (our Discourse-powered forum). You are 19 days late for April Fools! Discourse is an absolute pain in the neck because it not only requires JavaScript to be able to p

Re: It’s time to transform the Fedora devel list into something new

Kamil Paral wrote: > I've spent more than a decade perfecting my email filters and I have a > setup that works for me very well. I dislike certain aspects of mailing > lists (cross-posting, top-posting, reply-to, etc, which just can't work > well when everyone has to be vigilant all the time to do

Re: It’s time to transform the Fedora devel list into something new

On 4/25/23 14:33, Solomon Peachy via devel wrote: >> Honestly, if a "how to configure discourse to mimic the MUA-managed >> mailing list experience (ie not having to log into a web site after the >> initial configuration)" document is produced, that's probaby sufficient >> to overcome most of these

Re: It’s time to transform the Fedora devel list into something new

Josh Boyer wrote: > I want to make sure I understand that statement. You're saying you > will actively walk away from Fedora because you would have to change > the manner in which you discuss things? I am saying I and many other existing contributors may or may not walk away from Fedora entirely

Re: It’s time to transform the Fedora devel list into something new

Matthew Miller wrote: > On Tue, Apr 25, 2023 at 07:00:20PM +0200, Fabio Valentini wrote: >> - Change Proposals could be *announced* on the devel list, but >> discussion could happen in a linked topic on Discourse > > This is basically my proposal, although I suggest devel-announce rather > than d

Re: It’s time to transform the Fedora devel list into something new

Josh Boyer wrote: > Ah. May or may not. That gives me hope at least. Well, considering that we have hundreds of existing contributors, who all may or may not be willing to adapt to a platform that is clearly not designed for them (Discourse is very strongly newbie-centric, see the "achievemen

Re: It’s time to transform the Fedora devel list into something new

Matthew Miller wrote: > I actually love the idea of a Discourse-to-NNTP bridge. But is it ever going to happen? What is sure is that Discourse's e-mail notification system cannot be used for this, or at least it is not suitable for the existing e-mail to NNTP bridges. So somebody would need to w

Re: It’s time to transform the Fedora devel list into something new

Matthew Miller wrote: > I've written this: > > https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 > > and I'd love feedback on it. Asking feedback from users who are not using Discourse… on Discourse (!) is absurd and the best way to not get any answers. (

Re: It’s time to transform the Fedora devel list into something new

Stephen Smoogen wrote: > I may be in that list of toning down, but that is OK. Look it's really > time for new people to come in and break things. It is the only way they > really learn if something is something that should be really avoided or > was a taboo we had from the 1990's which we can't se

Re: It’s time to transform the Fedora devel list into something new

Stephen Smoogen wrote: > So let us say it is voted on and the answer is keep the mailing lists. > What are the next steps to fixing the mail system which is held together > by duct-tape and bailing wire? [etc.] Thanks for confirming that the decision was actually already made elsewhere and that t

Re: It’s time to transform the Fedora devel list into something new

Adam Williamson wrote: > A poll like this would have an inherent problem: it's ineffective to > have *only* the people who are already in a place vote on whether a > measure to get new people into the place is a good idea. Yet this approach is working fine for, e.g., Debian. > This is the same as

Re: It’s time to transform the Fedora devel list into something new

Kevin Kofler via devel wrote: > Stephen Smoogen wrote: >> So let us say it is voted on and the answer is keep the mailing lists. >> What are the next steps to fixing the mail system which is held together >> by duct-tape and bailing wire? > [etc.] > > Thanks for co

Re: It’s time to transform the Fedora devel list into something new

Kevin Fenzi wrote: > I think you are conflating contributors with "packagers". We are talking about moving things off the devel list, which is mainly a packaging mailing list. > Our discourse instance is hosted for us by discourse. > We shouldn't have to do maint on it, but we will have to do mo

Re: It’s time to transform the Fedora devel list into something new

Kevin Fenzi wrote: > I... don't understand how you reached that conclusion. > > My current understanding is: > * Matthew posted about a number of issues / concerns with mailing lists. > These concerns are completely 100% unrelated to our current list > infrastructure. If we had the very latest mai

Re: mingw sysroot paths (and generalizing them)

Florian Weimer wrote: > Is the /mingw/ part of the sysroot path, or is it within the sysroot? > Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or > --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the > sysroot? > > I assumed the latter, but now I wonder if /mingw in the s

Re: gimp license corrected

Josef Řídký wrote: > AND GPL-2.0-only AND GPL-3.0-only Oops? 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.fedorapro

Re: gimp license corrected

Josef Řídký wrote: > Based on the SPDX requirements, that should be correct. Some parts of the > package are available under GPL-2.0-only and some under GPL-3.0-only > license. And they are not linked together? Because if they are, we have a problem! Kevin Kofler _

Re: Build system clocks?

Chris Adams wrote: > I updated the source of a package of mine last night. The upstream is > on Github, and I use the %forgemeta macro for an easy spec file. When I > tried to run "fedpkg build" though, it failed - the build system > rejected the build because it was expecting an SRPM with a rele

Re: disabling yum modular repos by default?

Jens-Ulrik Petersen wrote: > I have been thinking about proposing a Change to Fedora 39, > which would disable yum modular repos by default in installs. > I thought I would float the idea here first. > > I suspect the vast majority of Fedora users don't use > the modular repos, so I don't see the

Re: disabling yum modular repos by default?

Jens-Ulrik Petersen wrote: > ps I think it would be a good idea to disable the cisco-h264 repo too by > default in the fedora container image, and maybe also for headless Fedora > editions. PS: IMHO, the restricted Cisco H.264 should not be enabled by default for anybody. Kevin Kofler __

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

Zbigniew Jędrzejewski-Szmek wrote: > * #2989 Proposal to adjust Changes Policy to use Fedora Discussion > instead of the devel list (zbyszek, 17:03:21) > * AGREED: APPROVED (+6, 0, 0): > Subsequent Fedora Changes for F40 and later will be discussed on > discussions.fedoraproject.org

Re: gimp license corrected

Josef Řídký wrote: > The file-dds plugin directory has available COPYING file which is > GPL-2.0-only original text (with accuracy 0.983). It is normal for GPL-2.0-or-later code to come with a copy of the GPLv2 COPYING. You cannot distinguish GPL-2.0-only from GPL-2.0-or-later from the COPYING f

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

Fabio Valentini wrote: > This might be a potentially useful URL: > > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations#Candidate_Nominations So that I get outvoted (n-1, 0, 1) on everything? Been there, done that, a long time ago… Nobody was even interested in discussing t

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

Zbigniew Jędrzejewski-Szmek wrote: > Nope, that is actually not true. Matthew posted some stats in the > fesco ticket [1], and the stats were fairly evenly split > (supportive or open, neutral, opposed or concerned). In fact, > "opposed" is the least popular option. So you folks were not happy wit

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

Kevin Kofler via devel wrote: > So you folks were not happy with the feedback on the mailing list, so you > just made up a poll somewhere else. [snip] > Was that poll ever announced on the mailing list? Or did you just expect > people to magically notice it has popped up in the

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

Neal Gompa wrote: > I deeply dislike the way Discourse works as a forum, but what else is > there now? I guess Vanilla, but that's a solution where there's a > mismatch in the "cloud" version and the self-hosted open source > version (at first glance, they might be completely different codebases >

Re: Election Status?

Joe Doss wrote: > On 5/24/23 4:49 PM, Mattia Verga via devel wrote: >> Wait, what?? Someone at RH wakes up in the morning and decides to cut >> one of the key roles (or better, THE) of Fedora community and this goes >> completely unannounced, unnoticed and without any backup plan? >> >> I have see

Re: Election Status?

Gary Buhrmaster wrote: > RH's staff redundancies The position was clearly NOT redundant. This is just RH unilaterally killing jobs including a central Fedora position in order to increase IBM's profits. Kevin Kofler ___ devel mailing list -- de

Re: Deprecation of the aspell package

ijaaskelai...@outlook.com wrote: > What are Finnish users supposed to do once aspell-fi retires? As I understand it, the only spellchecker the Finnish spellchecking community supports is Voikko. Unfortunately, upstreams have been reluctant to add support for a single-language spellchecking libra

Re: Deprecation of the aspell package

Peter Oliver wrote: > If we’re going to recommend migration to anything, shouldn’t it be > enchant2? Users would be able to configure their preferred spellchecking > engine per language (which I imagine is more important for some languages > than others), and we wouldn’t have to go through this ag

Re: Deprecation of the aspell package

Sam Varshavchik wrote: > I have one package in Fedora. It uses aspell's C++ API. > > Hunspell does not have a functionally-equivalent C++ API. Then use Enchant2, as already suggested. It has a C (enchant.h) and a C++ (enchant++.h) API. Or if it is a Qt/KDE application, just use Sonnet. > it do

Re: Election Status?

Gary Buhrmaster wrote: > Any particular position (in a large enough company like IBM, or RH) has > about zero impact on any organization's profits. Which is why they have laid off a whole bunch of people. They just happen to not be as visible as the (now former) Fedora Program Manager. > It *may

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Aoife Moloney wrote: > As described in > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > during last year, packaging of JDKs had changed dramatically. As > described in same wiki page, and individual sub changes and devel > threads, with primary reason this - to lower maintena

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Gerd Hoffmann wrote: > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't > see how that violates the 'build from source' requirement. The plan is now to build the prebuilt RPMs on RHEL+EPEL instead of the current Fedora release, which means they would not be built from sourc

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Jiri Vanek wrote: > Long story short yes, if yo wish to distribute jdk *binary* it have to > pass java compliance suite. Only if you ship it as "Java" and/or "OpenJDK". If you ship it as, e.g., icedtea-11, nobody can force you to run the JCK. (And the binary names "java" and "javac" are interfa

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Peter Boy wrote: > If you're serious about developing Java applications, you're not going to > use an uncertified JDK to do it. Huh? I develop Java applications for a living, and I could not care less about whether the build of OpenJDK I am running is JCK-certified and/or named "OpenJDK", as lon

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Neal Gompa wrote: > Because the alternative is no Java runtime at all, and that's even > less acceptable. I do not see why the way the packaging used to work all these years could not be kept unchanged. The only issues that were pointed out were related to the Java TCK (that it takes too long t

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Jiri Vanek wrote: > At elast providing ofjava/openjdk is definitley out of scope. I do not think a Provides would be a trademark violation. It is a part of the standard procedure for renaming a package. But you would have to ask Red Hat Legal for a definite answer. I am not a lawyer. That said,

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Demi Marie Obenour wrote: > I haven’t written Java in years, but my understanding is > that AOT compilation has three major advantages: > > 1. It reduces the size of total deliverables because the >final executable only includes the libraries it needs. This may be true for real AOT compilatio

Re: LibreOffice packages

Gwyn Ciesla via devel wrote: > I've taken ownership of libreoffice for the time being, at least to keep > the lights on. Also of the many dependencies? As far as I can tell, from the list in the orphaned package report, all these are part of the LibreOffice stack: > flute

Re: Fedora Copr builders updated to Fedora 38

Pavel Raiskup wrote: > I'm not strongly against anything; but rather than weaker policy for > everything I slightly prefer keeping the _stricter default policy_ with > _disabled gpgcheck for EL6_ (we should phase epel-6 out entirely anyway > since it's long time EOL, but we still keep it for the di

Re: Fedora Copr builders updated to Fedora 38

Gary Buhrmaster wrote: > Well, EL6 ELS support is still available for (around) > another year, so it is a nice to have to support those > limping along with EL6, but I would generally agree > with the principal that if supporting a product past > official EOL becomes overly onerous that support > s

Re: Fedora Copr builders updated to Fedora 38

Kevin Kofler via devel wrote: > Gary Buhrmaster wrote: >> Well, EL6 ELS support is still available for (around) >> another year, so it is a nice to have to support those >> limping along with EL6, but I would generally agree >> with the principal that if supporting a p

Re: SecureBoot certificates

Chris Murphy wrote: > OK I tried this again and discover shim is signed twice. > > Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, > CN=Microsoft Corporation UEFI CA 2011 > Not Before: Sep 9 19:40:20 2021 GMT > Not After : Sep 1 19:40:20 2

Re: Modules without modularity

Petr Pisar wrote: > I spent some time thinking how to approximate the nice features with > current state of RPM, Koji, and DNF and come up with this approach > . The linked approach > achieves it at the expense of dedicated build targets and an inabilit

Re: Modules without modularity

Petr Pisar wrote: > I understand the horror that you can have two packages which cannot be > installed at the same time. The same as you cannot start httpd and nginx > services at the same time. But now the conflict is visible on RPM level. You can actually, if you set them to different ports. Bu

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

Josh Boyer wrote: > Agree with Matthew fully here. We've been working rather hard > internally to adjust the development process for RHEL to be more > collaborative and open than it ever has before. The *development process* is more open, but the production releases, which is the only thing end

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

Neal Gompa wrote: > On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel wrote: >> >> Josh Boyer wrote: >> > Agree with Matthew fully here. We've been working rather hard >> > internally to adjust the development process for RHEL to be more >> >

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

Neal Gompa wrote: > I will also point out that CentOS Stream is perfectly suitable for > production use, and I would argue it provides a differentiated > experience in its own right: because CentOS Stream does not go through > certification work that locks on specific package versions, any and > al

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

> Image Builder is a set of modern tools for building operating system > images. Its goal is to make the builds reliable and reproducible. > Moreover, it's designed to give the end users a simple workflow to > build their own custom images. The aim of this change is to switch the > build tool for F

Re: Is there a chance to phase out `/lib64` directory?

Kalev Lember wrote: > I would like to have a layout similar to what Debian is doing, so that > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64 > would be a legacy symlink pointing to it. That layout is NOT compliant with the FHS. Which is particularly hilarious as Debian

Re: Is there a chance to phase out `/lib64` directory?

Carlos O'Donell wrote: > And assembling those sysroots is not straight forward. The easiest way is to unpack a live image. If you are targeting an Arch- based or similar distro, you will probably get away with just unpacking the image, because it installs development files by default. But if you

Re: Intent to retire OpenCOLLADA

Richard Shaw wrote: > If anyone wants to take it over let me know otherwise I plan to retire > early next week. The right thing to do here is to orphan it, not retire it directly. It will be retired if nobody picks it up, but if somebody wants to pick it up, it saves them the unnecessary bureauc

Re: Orphaning packages (was LibreOffice packages)

Bastien Nocera wrote: > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of

Re: Package deprecation policy

Ben Beasley wrote: > There are other valid reasons to deprecate packages. Upstream > deprecation is one of them. IMHO, it is not. Packages that are not actively maintained upstream tend to be very little maintenance effort in Fedora, because there are no new upstream releases to pick up. You jus

Re: Orphaning packages (was LibreOffice packages)

Peter Robinson wrote: > I would hardly say Libreoffice, bluetooth on the desktop and certain > iDevice pieces is "killing all work on the desktop" it's more focusing > on things that are important to their customers in those contexts. What corporate desktop customers do not use LibreOffice? If RH

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

Leslie Satenstein via devel wrote: > What should I do, if the person I gave the software to, removes my > copyright, rebrands the software and sells my software as their own? Is it > right? And when I release a bug fix, they take it, insert the fix into the > rebranded copy they are selling, and th

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 comp

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 >

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?

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 se

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 y

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". >>

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

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

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 h

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") > Fedo

Re: Small rant: installer environment size

Tomáš Popela wrote: > firefox, because that's what the web based installer should/will use in > the end 🤦 A full-blown, 71 MB compressed (!) web browser just to show the UI for the installer! IMHO, the web-based UI is a major mistake and should never be shipped in Fedora. It is good as a protot

Re: Small rant: installer environment size

Adam Williamson wrote: > On Thu, 2022-12-08 at 07:57 +0100, Florian Weimer wrote: >> It has all the targets in it. As it's for JIT, we'd only need one >> target. > > That sounds interesting, though of course the details of how to > implement it could be a bit tricky, I guess... Build /usr/lib64/

Re: Small rant: installer environment size

Kevin Kofler via devel wrote: > 🤦 A full-blown, 71 MB compressed (!) web browser just to show the UI for > the installer! PS: And I guess we will then also need to ship the langpacks, which are another 42 MB compressed! (And in one monolithic package for all languages.) Kevin

Re: Small rant: installer environment size

Gary Buhrmaster wrote: > As I am sure you are aware, it seems a number of distros > are experimenting with their next gen installer. OpenSUSE > has their new web based D-installer, and Canonical is > writing an installer in flutter. And most of the others have stopped reinventing the wheel and ar

Re: Starting Flatpak SIG

Timothée Ravier wrote: > If possible, as this is a new channel, I'd recommend going Matrix only. > This makes things simpler. But it locks out IRC users. So this is a bad recommendation. Kevin Kofler ___ devel mailing list -- devel@lists.fedorap

Re: Small rant: installer environment size

David Cantrell wrote: > Broadly speaking, a lot of the growth came from converging the runtime > environment for the installer with the installed system. In Fedora Core 8 > and previous releases, the "installer environment" was a unique and > stripped down install. This was frustrating because it

Re: Small rant: installer environment size

Adam Williamson wrote: > On Thu, 2022-12-08 at 12:50 -0500, David Cantrell wrote: >> If mesa-dri-drivers is not required for installation, it could be removed >> from the installer environment. > > It is required - we don't get any graphics without it. Is that because of the use of GNOME Shell? A

Re: Small rant: installer environment size

Chris Murphy wrote: > Net costs: Fedora releng takes one compression hit per image created, but > consumers of those images which also includes a ton of Fedora QA bot time > as well as human users are in the dozens to thousands of hits per image > created. But for those human users, a smaller imag

Re: Small rant: installer environment size

Adam Williamson wrote: > Looking at sizes, iwlwifi firmware alone is 75M(!) ath10k is 6.8M, > ath11k is 12M, ath6k is 812K, so that's nearly another 20M. brcm/ is > another 6.4M and I *think* that's all wifi. There's a few other minor > ones, but that's a little over 100M of just wifi, with Intel b

Re: colorful license change

Artur Frenszek-Iwicki wrote: > colorful had a new major release, v2.0, which brought in a licensing > change. I took this as an opportunity to also migrate the License: tags to > SPDX. > > Old v1.3 license: zlib with acknowledgement > > New v2.0 licenses: > - colorful: GPL-3.0-only AND (MPL-2.0 O

Re: Polymake soname bump

Maxwell G via devel wrote: > ABI incompatible updates are against the Updates Policy for stable > releases: > >> ABI changes in general are very strongly discouraged, they force >> larger update sets on users and they make life difficult for >> third-party packagers. > > -- > https://docs.fedorap

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Neal Gompa wrote: > I think Fedora is the only major distro that doesn't do this, > actually. Mageia and openSUSE do this too. They also use graphical > GRUB by default instead of plain text GRUB. IIRC, the reason that Fedora does not use graphical GRUB by default is that it at least used to brea

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Daniel P. Berrangé wrote: > That is not correct. There are a number of benefits of UKIs. > > The most critical is that the initrd content and cmdline is > covered by the SecureBoot signature. From an end user point of view, having more stuff covered by Restricted Boot is not a benefit.

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

PS (adding to my previous reply): Daniel P. Berrangé wrote: > The immediate need for UKIs is indeed related to SecureBoot and > TPMs. These are a core technology foundation of the confidential > virtual machine stack. On Azure today, if you request an Ubuntu > confidential VM, Azure will pre-encry

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

> Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as > the default approach. > Packaging Guidelines and other documentation are adjusted to describe > this approach first. > Various tools that provide spec file templates are adjusted. -1 to this proposal. As I had already written

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Neal Gompa wrote: > Can we please have gcc-rs also built (even though it's experimental)? Will gcc-rs be able to generate usable shared libraries for Rust crates? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscrib

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Zbigniew Jędrzejewski-Szmek wrote: > tl;dr: you want to fix changelog entries. That's supported by saving the > generated changelog to 'changelog' file and doing whatever edits you want > there. > > With that approach, you can do arbitrary formatting and fixups. The > advantage compared to status

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Fabio Valentini wrote: > - incompatible compile-time options (i.e. resulting in conditional > compilation): different packages depend on crates with different sets > of features enabled, sometimes with conflicting options. Even with a > stable ABI, you'd need to build crates for all necessary combi

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Fabio Valentini wrote: > Speaking for myself: Using rpmautospec has massively reduced the > maintenance burden for the Rust stack, and also for other packages > that I maintain. > > Due to the way optional dependencies / features are mapped to RPM > subpackages (this works like with "extra" depend

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Matthew Miller wrote: > Okay. no. This is not how we do things here. Apologies for my snide remark that visibly came out rude, sorry. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le..

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dominik 'Rathann' Mierzejewski wrote: > Personally, I use the kernel's recommended commit to the oldest > supported branch and merge upwards workflow and I've learned not to be > afraid of merge commits. If any branch needs some specific fixes, > I just apply them there and only there, without usin

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Fabio Valentini wrote: > - incompatible compile-time options (i.e. resulting in conditional > compilation): different packages depend on crates with different sets > of features enabled, sometimes with conflicting options. Even with a > stable ABI, you'd need to build crates for all necessary combi

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Neal Gompa wrote: > On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel > wrote: >> >> On 03/01/2023 18:42, Miro Hrončok wrote: >> >* AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora >> > Linux 38 and we evaluate whether to retain it by Fedora Linux 40. >> > This

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Neal Gompa wrote: > For what it's worth, frame pointers are required on other operating > systems for precisely this reason What operating systems REQUIRE frame pointers? GCC supports -fomit-frame-pointer basically everywhere. Kevin Kofler ___

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Michael Catanzaro wrote: > Benchmarks probably won't improve. And that alone is enough to make Fedora look bad and lose users to other distributions that cater to the Phoronix crowd. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproj

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Andrii Nakryiko wrote: > >> This is why I think the change is implicitly just for x86_64. > > Definitely not intentionally, might be just a bias of what we had most > hands-on experience with. Well, that is why it is so bad that you forced through this change behind the toolchain team's back. Th

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

PS: Kevin Kofler via devel wrote: > The way this was done is so wrong: > * There was a vote. You were not happy with the outcome. > * So you first tried to complain in the original ticket about this. It was > clear that the consensus in that ticket was to not reconsider at this &g

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Miro Hrončok wrote: > On 04. 01. 23 17:29, Jonathan Wakely wrote: >> On Tue, 3 Jan 2023 at 09:39, Miro Hrončok wrote: >>> >>> = New business = >>> >>> #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to >>> #default >>> compilation flags >>> https://pagure.io/fesco/issue/2923 >> >>

  1   2   3   4   5   6   7   8   9   10   >