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

[Kevin Kofler via devel]

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 added to FESCo_meeting_process. (+7,0,0)
> (zbyszek, 17:18:25)

So basically we are stuck with the status quo. Meaning that there is still 
nothing preventing an already rejected feature from being surprisingly 
reconsidered after the change deadline, and no guarantee that the "effort to 
notify people" is actually going to happen (especially in the future, as 
FESCo composition changes). Sad. I had got the impression that there were 
consensus in FESCo to improve the situation. Apparently, that was a false 
impression, unfortunately.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 reconsidered after the change deadline, and no guarantee
>> that the "effort to notify people" is actually going to happen
>> (especially in the future, as FESCo composition changes). Sad. I had got
>> the impression that there were consensus in FESCo to improve the
>> situation. Apparently, that was a false impression, unfortunately.
> 
> Your assumption of bad faith from elected representatives of the community
> is worrying. You manage to imply bad intentions not only from the current
> group, but even from the future ones, yet unknown. Quite an achievement! I
> think that you are under a false impression that repeating your argument
> ad infinitum is useful for something.

Where in the paragraph you quoted have I written anything about bad faith? A 
lack of notification can happen by accident in good faith, as apparently 
happened in the case that triggered the whole debate. (At least, Neal Gompa 
swears it was an accident.) And without any kind of policy enforcing it, a 
pledge to "make an effort to notify people" is not a guarantee. That is all 
I stated.

Another issue that was not addressed by the proposal at all is that the 
change at stake was resubmitted too late, after the change submission 
deadline, and hence should not have been allowed on that ground.

In addition, being elected is not sufficient to guarantee good faith, as can 
be seen in politics. Not to mention that, in Fedora elections, there is 
often not enough competition for voters to vote out candidates they do not 
trust.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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?

> I also stand by what I wrote above. Kevin's words that "there is still
> nothing preventing an already rejected feature from being surprisingly
> reconsidered after the change deadline" can only be true if we assume that
> decision made by FESCo to "make an effort to notify people when proposals
> are resubmitted for voting" has no effect. And for it to have no effect
> the FESCo chair and other members would need to ignore the decision and
> the documented process [1].

Or they could try and fail to follow it. And no consequences will happen, 
because, well, they tried, i.e., "made an effort". There is neither 
accountability for the person who made the mistake, nor a sanction for the 
feature that slipped through. (To clarify the latter part: If affected 
people were not notified in time, the change should automatically be put on 
hold until 1. they had a chance to comment and 2. their comments were 
discussed by FESCo. Even if it means missing the deadline to rush the change 
into Fedora n. Nobody is going to die if the change gets pushed back to 
Fedora n+1.)

> In short, only when bad faith is assumed.

As pointed out in my previous reply, good faith accidents can happen.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
> using SPDX identifiers in software we package and provide so that our
> downstream users are in compliance:
> 
> https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

I do not see anything there requiring RPM packages to contain a License tag. 
I doubt this can ever be encoded in a law.

Software needs to state its license somehow, but that is already the case in 
various forms (depending on the package) within the SRPM and hopefully the 
binary RPM. (If the notice does not make it into the binary package, that is 
an upstream issue and IMHO not our problem.)


Personally, I think it makes sense to state the license in the RPM metadata 
for the people installing the software, but, like Michael Catanzaro, I doubt 
the current approach of requiring to explicitly list every permissive 
license of copied&pasted code is in any way practical. The License tag 
should have only indicative value, the authoritative license(s) are the ones 
on the source code itself.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 encryption keys and
> there are requirements that operating systems no longer ship these as
> enabled for the operating system to be used in universities, health care,
> etc. Where in the past these sorts of things have been 'given' a long time
> for removal (aka the 10+ years for MD5), my understanding is that these
> are being pushed much faster and harder than before.

And that is exactly what we are complaining about. It is not a reasonable 
thing to do to break algorithms that are still in widespread use.

> [Mainly in that continued funding from both public and private
> organizations is tied to audits etc.]

Let the auditors complain all they want, they are not real-world users. The 
default configuration must work out of the box. Security extremists can 
always locally set some absurdly strict rules that will just not work but 
make clueless auditors happy. But they must not be the default.

> The push is going to come in several 'waves' with SHA1 and DSA marked as
> bad now and in 1-2 years, SHA256 and RSA keys below 4096. Like most rapid
> changes, there is always going to be a lot of grit in the gears for
> everyone trying to continue working outside of the change :/

That plan is absolutely unworkable and unacceptable.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 participate (the fallback version is read-only), 
but that JavaScript requires the very latest Chromium or Firefox to work at 
all. Maintained LTS branches such as QtWebEngine 5.15 LTS are NOT supported 
and get only the read-only no-JS fallback view:
https://discuss.kde.org/t/discuss-kde-org-cannot-be-accessed-by-konqueror/548

Discourse also does NOT cover the use cases of mailing lists. E-mail 
notification is just that, notification. Everything still happens on the 
JavaScript site. And Discourse does NOT support NNTP access, which is the 
most practical way to interact with a high-volume mailing list such as this 
one. I am writing this post through the Gmane NNTP gateway using KNode, and 
I am also using that to read the threads.

As a result, I consider your proposal absolutely unacceptable.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 things right),
> but I *like* my existing setup and processes. But that's me, us, the old
> timers.

But that is exactly why it is an absurd idea to move away from mailing 
lists. Fedora will *lose* all the existing contributors like you or me.

> Having said that, my impression is that mailing lists are an already lost
> battle. If you don't have an influx of new contributors, your project is
> going to die eventually. Mailing lists are a big hurdle for newcomers.
> Young people are not used to it (who still uses mailing lists, in
> read-write mode, except for OSS communities?), the lists are difficult to
> set up, the user interfaces are bad, there are many peculiarities to be
> aware of (top-posting, etc). I don't know if moving away from mailing
> lists will make our contributor base grow, but I'm quite certain that
> staying with mailing lists will make our contributor base **not** grow.
> And our project will slowly decline over time.

I strongly doubt that the mailing list is the main barrier to entry to 
Fedora (as opposed to, e.g., packaging guidelines, etc.).

If the issue is that the mailing list is flooding your inbox and you are 
unable to filter it, the remedy is simple: Disable mail delivery and use 
Gmane NNTP or HyperKitty to read and post to the mailing list. That choice 
of preferred technology will go away if we move to a locked-in web platform 
such as Discourse. (I know it is FOSS and the data can be exported somehow. 
It is still a lock-in for the end user.)

> Imagine that you want to contribute to a project and you discover they're
> still using svn, or cvs. There are still some. I personally wouldn't be
> bothered, I'd just invest time elsewhere. I value my time.

I do not see the problem. I just need to bring up another UI (Kdesvn or 
Cervisia instead of Git-Cola), so what? All I care is that I can update from 
upstream and commit/push my changes.

Heck, I still use SVN for *my* personal projects.

And not everything is better with git. SVN basically guarantees a linear 
history whereas with git, I have to follow a specific workflow for that 
(always pull with rebase, never with the default merge strategy, and for 
work branches, always rebase and force-push them rather than merging 
master/main into them, then when done fast-forward them to the master/main), 
and when working with other people, I usually cannot get them to use it, so 
the history becomes a complicated DAG with a mess of merge commits, grrr!

> I already have some experience with Discourse and so far it seemed OK to
> me.

I have some experience with Discourse as well and it is just a pain:
* A silly reliance on JavaScript and AJAX for everything instead of server-
side code. In particular, this means it takes several seconds to render a 
page on mobile devices such as the PinePhone.
* A constant requirement of the latest&greatest bleeding edge browser, no 
support for QtWebEngine LTS branches.
* An absurd assumption that everyone is new to the Internet, leading to lots 
of ridiculous gamified spam "achievements" for basic things such as replying 
to a thread, with which you get bothered on every single Discourse forum you 
(have to) sign up to.
etc.

I do not understand why everybody is moving to this annoying piece of 
software and throwing away not only mailing lists, but also web forums using 
much better software (i.e., pretty much any other forum software), for it.

> But I haven't used it as frequently and in such a volume as mailing
> lists. I also still haven't built my workflow alternative to my email
> workflow in there. But I'd be happy to experiment with it. But in order to
> get real-world experience, it would be great if this was a shared
> experience, where a mass of users really moves and starts using it as a
> primary discussion platform. Then we can collectively figure out the
> benefits and drawbacks and any workarounds for those drawbacks.

The drawbacks are well known (see above) and the platform is basically 
unusable. There is no need to experiment with it to find that out. And 
"get[ting] real-world experience" by forcing everyone to use it "as a 
primary discussion platform" is just unacceptable.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrast

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

[Kevin Kofler via devel]

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 objections, because then the setup cost is
>> one-off, and the ongoing "interact with Fedora-devel" cost won't be any
>> greater than it already is.

As far as I can tell, it is impossible to configure Discourse to work like a 
mailing list. It is not designed for that. It is a web AJAX forum, with the 
possibility to get e-mail notifications, but the e-mail interaction is 
limited and cannot replace the AJAX UI.

And in particular, NNTP is not supported at all, and the way the e-mail 
notifications work does not lend itself to NNTP gatewaying over Gmane.

Ian Pilcher wrote:
> Only if there's a companion document on how to interact with Discourse
> over NNTP.  :-(

Exactly that.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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, and even if not, may reduce our interaction with 
Fedora, due to being forced to use a discussion tool that does not support 
our workflows.

Heck, it does not even work in my browser (Falkon) without ugly workarounds. 
(https://discuss.kde.org/t/discuss-kde-org-cannot-be-accessed-by-konqueror/548)

> That's certainly a choice one could make.  Personally, I would not
> prioritize keeping my bespoke email setup intact over working with a
> community on a project I care about.  If there's even a remote
> possibility moving to Discourse will attract more contributors to
> Fedora then I'd happily learn how to deal with it.  Change is
> difficult, but in the end it's something we're all capable of.

I do not understand this double standard: You and several others are 
expecting new contributors to walk away from Fedora due to the manner in 
which we discuss things, but in the same time act surprised when warned that 
existing contributors are likely to do exactly that. In fact, we have much 
more reason to do so because the new workflow is a regression, and forcing 
it on us over our objections actively tells us we are no longer welcome.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 devel-list, because otherwise the result is two separate discussions.

devel-announce is forwarded to devel, so this does not prevent the two 
separate discussions (mailing list vs. Discourse). Unless you stop this 
forwarding, which would also be a regression because it means we would now 
have to watch yet another mailing list.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 
"achievements" and all the other hand-holding), I think it is safe to assume 
that several important contributors WILL leave, tone down their 
participation, and/or miss some important communication (leading to breakage 
in the distribution, e.g., broken dependencies making it into Rawhide) if 
Fedora makes the switch.

> I don't think it's a double standard.  I think people that already
> know how Fedora development and contribution works are inherently in a
> better position to adapt to something new, whereas net-new
> contributors are unlikely to even start based on an email driven
> practice.

And as I already answered, I think this is completely backwards. If you want 
to newly join a project, you learn their way to do things and adapt to it. 
If, on the other hand, you are already involved in a project and have 
workflows that work for you, any forced change to something perceived as a 
regression will annoy you and make you want to leave.

> It's a barrier to entry problem.  If we, as the experienced and capable
> contributor base, can adapt to something and lower the barrier to entry
> then it benefits us all.

Again, I do not see the communication platform as the main barrier to entry 
for Fedora at all. Where is the evidence for that claim?

As I see it, the main roadblocks for new packagers are:
* accepting the FPCA,
* getting sponsored,
* learning the Packaging Guidelines, and
* getting their package(s) through review,
and that last point can be a roadblock even for existing packagers (because 
we do not trust even experienced provenpackagers and/or packager sponsors to 
review their own packages).

Those points are all there for a reason (the FPCA for legal coverage, the 
sponsorship process so new contributors are mentored and their trustfulness 
verified, the Packaging Guidelines to ensure a certain package quality for 
our end users, and the review process to ensure that the Packaging 
Guidelines are actually followed and as another check that nothing malicious 
sneaks in), but they are the barrier to entry, not the communication 
platform.

> To be clear, I do not like forums.  Discourse is perhaps the best
> forum platform I've used, but that doesn't mean I like it.

I find Discourse to actually be one of the worst forum platforms I have 
used, if not the worst. All the *BB ones out there are much better due to 
using less (to no) AJAX and less annoying hand-holding. 

> What I dislike more than forum software is knowing we're leaving people
> that could do great things and spread more awareness of Fedora simply
> because we've ossified on a communication platform that is hard to
> discover and consume.

Again, this assumes that this is what is holding back new contributors, for 
which I have seen no evidence whatsoever.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 write a 
dedicated bridge.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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. (It is like asking "Everyone 
who does not speak English, please raise your hand!" in English.)

Note that we cannot use the reply by e-mail feature to answer in the thread 
because it is an already existing thread and so we will not get a 
notification to reply to if we turn on e-mail notifications now.

> Keep in mind:
> 
> * It never will be the same as mailman. There are different constraints.

And that is exactly why Discourse will by design never be a replacement for 
a mailing list.

> * Discourse developers and designers see the web interaction as primary,
>   and that isn't going to change.

And that too.

> * Dealing with email has a lot of corner cases, so there will be rough
>   edges.

And that is a logical consequence of having the web forum as the primary 
interface and mail as an afterthought rather than the opposite.

Some features such as editing posts just by design cannot work on a mailing 
list.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 see as cargo culting
> anymore.
> 
> Maybe a bunch of packages will be dropped and Fedora will become 'useless'
> to some of us older contributors. This isn't the first time that has
> happened with the distribution (we saw large drop-offs after we stopped
> Xen and when we changed desktops to GNOME3.) and if the distribution is to
> last as an institution, it won't be the last. We who aren't happy with it
> can either make do with something else, adapt, or finally retire to grow
> potatoes like all the programmers I knew from the 1980s who had gotten
> tired of all the changes over the years.

But what if the major influx of new contributors that you proponents of this 
proposal are hoping for never arrives? (Something I think is quite likely to 
happen, considering that the main barrier to entry is NOT the mailing list.) 
Then you will have driven away existing key contributors without anyone to 
replace them, and Fedora will be dead.

Also keep in mind that experienced contributors are the only ones able to 
work on certain complex tasks and also to mentor new contributors so that 
they will eventually become experienced. Chase them away and all the 
experience will be lost, no matter how many new contributors you attract.

The first priority of a project MUST ALWAYS be to keep the existing 
contributors. Attracting new ones can only come second.


That said, looking at how the "feedback" to this "proposal" is being handled 
(yet again), I guess that all that is really going to change in practice is 
that instead of completely ignoring or trying to explain away all mailing 
list feedback, you folks will be completely ignoring or trying to explain 
away all Discourse feedback. How proposals are supposed to work is that 
somebody suggests something, then feedback is requested, then it is 
discussed, and only then a decision is made. But how it is actually working 
is that a small group of people decides something in a closed-door meeting, 
then calls it a "proposal", asks for "feedback" on the mailing list to give 
an illusion of transparency and democracy, but is not actually willing to 
act on the feedback (because the decision has long been made elsewhere), 
instead only trying to explain why it "does not matter".

The sad thing is that I have even seen several replies trying to explain 
away their OWN objections to the proposal, arguing that it is normal that 
they as experienced contributors are not the target user base of the 
discussion platform. But guess what, it is not (normal). This is a developer 
mailing list, experienced contributors are THE target.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 this whole RFC thread is just a farce. Looks like "I propose" in 
the original post should really read as "I dictate".

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 the NIMBY problem in municipal politics: if you
> give the residents of any area too much say over development in that
> area, they will always tend to oppose it on the grounds that it's bad
> for *them*. They have no inherent motivation to consider the interests
> of other people who might want to live or work in the area, but who
> cannot.

But the local residents are often precious allies in fighting things such as 
new highways, construction projects destroying fertile soil, etc. that make 
things worse for everyone by: accelerating the climate crisis, causing 
pollution, eating up soil needed for agriculture, etc. So guess what, I 
often find myself supporting this kind of local initiatives from the other 
end of the city. Would you be happy if your city builds a huge highway right 
through your previously quiet neighborhood? Would you find that fair?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 confirming that the decision was actually already made
> elsewhere and that this whole RFC thread is just a farce. Looks like "I
> propose" in the original post should really read as "I dictate".

PS: The process that Stephen describes reminds me of those rent sharks that 
deliberately let their beautiful old historical houses rot until they fall 
apart so badly that the rent sharks are allowed to tear them down and build 
some ugly new concrete box with unaffordable apartments in their place.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 moderation,
> etc.
> 
> They are managing it for us. We don't have to do anything except pay
> them. :)

So it is effectively not Free Software for us, given that we use it as SaaS.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 mailman3 from upstream running
> smoothly... it would still be a mailing list and it would really have
> almost all of the same concerns.
> 
> I completely understand where smooge is coming from here.

Well, I see two (almost orthogonal) lines of argumentation here:
* Matthew and others have proposed moving off the mailing list due to
  alleged shortcomings that mailing lists have by design. The issue is that
  this misses that Discourse has much worse shortcomings by design. (And "by
  design" is usually synonymous with "unfixable".)
* Smooge has brought up that the mailing list has in his view been so badly
  neglected over the last few years that it will have to be replaced anyway,
  no matter whether the replacement is actually better or worse.

> Am I frustrated at the current state of our mailing list infrastructre?
> Oh so very much.
> Do I hope we can make it better?
> Oh so very much.

I would hope so too.

> Anyhow, I 100% disagree with you that this is 'a farce'.
> I think it's been useful, I think we have gotten:
> 
> * More information on interacting with discussion via email and if it
> will meet the needs of existing devel folks.
> * A sense of people who will probibly not want to participate at all,
> even via an email interface.
> * Some more use cases mailing lists provide that we should consider a
> way to provide if we move more things to discussion (example, I think
> some kind of better/easier public archive for drive by contributors and
> those that need to look back in history would be good)
> * Some suggestions for improvements we can ask discourse folks to make
> to make more people happy.
> 
> The next steps here would be for Matthew to ask fesco about moving
> changes discussions over to discuss and them to vote/consider that.
> After that, I hope we can fix some of the issues identified here before
> we do anything further to move more discussions over there.

Do you not see my point here? You have gotten a sizable amount of feedback 
pointing out showstoppers that make Discourse anywhere from impractical to 
unusable for several existing contributors, many of which are by design and 
will never be fixed, or at least require a lot of coding that nobody is 
signing up for (e.g., an NNTP gateway, plus, that will also suffer from some 
of the core limitations of the e-mail notification system, e.g., not picking 
up edits (unless maybe if the gateway "cancels" the post and resends the 
edited version? But NNTP post cancellation is not universally supported)). 
Yet, you are still set on pushing this change forward and already discussing 
the next steps (FESCo vote, "fix[ing] some of the issues" (but you will 
never be able to fix all of them because several are by design), 
deployment). That, in my view, makes the RFC thread a farce, because the 
option that ought to be the default (keep the status quo) appears to not 
even be under discussion.

> I'll note that we just released Fedora 38... and the users mailing list
> has had a increase in posts. It had like 60-70 in the last week.
> The askfedora category in discussion had more than that overnight last
> night. It's pretty dramatic. Granted this could be due to us advertising
> that as the way to get help, and users asking questions aren't the same
> as developers, but still... It's a LOT more interaction.

It is certainly both: end users (as opposed to developers) are used to web 
forums, and of course if you link to the forum everywhere and the mailing 
list is hidden behind several clicks and has a more complicated signup 
process, people will choose the forum.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw sysroot paths (and generalizing them)

[Kevin Kofler via devel]

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 sysroot is the
> analogue of /usr in GNU/Linux sysroots.

/mingw is a prefix like /usr. Where this comes from is the native MSYS/MSYS2 
toolchains, where / (and if present, /usr) contains binaries dependent on 
the MSYS DLL ("MSYS binaries"), whereas the subtree /mingw is what contains 
"MinGW binaries", i.e., ones that do NOT require an MSYS DLL. The separation 
helps MSYS because, if it invokes an MSYS binary, no path translation is 
done and the binary receives POSIX paths, whereas a MinGW binary gets its 
command line automatically translated to Windows paths. The rule is that 
everything either outside of the MSYS root or inside the /mingw subdirectory 
is assumed to be a MinGW (or MSVC) binary whereas everything with the MSYS 
root but not under /mingw is assumed to be an MSYS binary.

Cross toolchains are not really affected by this feature, but since MinGW 
build scripts written for MSYS(2) will generally assume native binaries to 
be under /mingw, it is probably best to keep this subdirectory in the 
sysroot.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gimp license corrected

[Kevin Kofler via devel]

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.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gimp license corrected

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build system clocks?

[Kevin Kofler via devel]

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 release
> string including 20230507, but instead got one with 20230506.

Could it be that you built the package over midnight UTC, so the SRPM was 
still built with 20230506, but when the build happened, it was already 
20230507?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Kevin Kofler via devel]

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 point of enabling
> them by default anymore. Does this make sense?

Yes, finally! It is time to shelve the last vestiges of the failed 
"Modularity by default" project.

Users who really want Modularity can just opt in. But I think it usually 
makes more sense to deliver alternative versions in different ways that are 
not subject to the kind of version conflicts modules can cause (i.e., 
libraries as parallel-installable compatibility libraries, leaf packages 
through Copr).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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

So here we go, Discourse is now being forced on us despite all the 
overwhelmingly negative feedback in the thread. I really wonder why feedback 
is being asked for at all. It seems to be just a way to make it LOOK like we 
are in some kind of democracy. In reality, the decisions are already made 
before the thread is even started.

So now you are forcing change feedback to go through an inconvenient 
mechanism in the hope to prevent it from coming up to begin with, so you do 
not have to so blatantly ignore it.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gimp license corrected

[Kevin Kofler via devel]

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 file alone, you must actually look at the headers on top of the 
individual source files.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 the proposals in the FESCo 
meetings, the goal was always to rush to the vote as quickly as possible and 
"+1" it out of the way, discussion was just seen as a waste of time.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 with the feedback on the mailing list, so you 
just made up a poll somewhere else. Basically the same thing you are now 
doing with Discourse. Don't like the community feedback? Let's just make up 
a new community.

Was that poll ever announced on the mailing list? Or did you just expect 
people to magically notice it has popped up in the FESCo ticket?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 FESCo ticket?

Sorry, looking at the FESCo ticket, I see the stats are actually just your 
subjective interpretation of the mailing list replies. Since I do not know 
who you counted in what category, I cannot tell whether your interpretation 
is correct or not.

But:
> Basically the same thing you are now doing with Discourse. Don't like the
> community feedback? Let's just make up a new community.

This part still stands, I see the forced use of Discourse as a way to 
silence community feedback. How about you actually let the community decide 
on which medium to bring up the feedback?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
> now!).

PhpBB, SMF, etc. are all still out there (still maintained).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Kevin Kofler via devel]

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 seen other dumb decisions by RH about Fedora in the past, but I
>> think this is the greatest one, both for Ben's role and for their person.
> 
> I totally agree. I am pretty upset that they chose to let bcotton go.
> His work was top notch and I will miss him and his contributions. Losing
> him as the Fedora Program Manager is going to be very impacting to the
> project in the short to medium term. We are already seeing things fall
> through the cracks. What a short-sighted decision.
> 
> Also finding out about this in a random thread is a bummer. There should
> have been an announcement.
> 
> To the RH powers that be that made this decision. You chuckleheads dun
> goofed.

That is the kind of braindead decisions that was to be expected after the 
sellout to the mega(dis)trust IBM.

The total lack of advance communication (because they want to lay off their 
employees as quietly as possible in order not to scare potential 
shareholders?) just makes it worse.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Kevin Kofler via devel]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deprecation of the aspell package

[Kevin Kofler via devel]

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 library when the rest of 
the world has been moving to Hunspell.

You can find some ancient unmaintained Hunspell dictionaries for Finnish, 
which are based on the same ispell-fi 0.7 from 2000 as the aspell-fi 
dictionaries you are apparently using:
https://github.com/fluks/fi-FI-mozilla-spellchecker
The copyright file says the dictionaries come from the Debian myspell-fi 
package, which is built from the ispell-fi source package:
https://sources.debian.org/src/ispell-fi/
https://launchpad.net/ubuntu/+source/ispell-fi/0.7-18
(That source code should probably be included, given the GPL license of the 
dictionaries.)
This changelog:
https://sources.debian.org/src/ispell-fi/0.7-18/CHANGELOG/
gives the date of the last upstream change as "3rd of September 2000". These 
could be packaged as hunspell-fi, but upstream is completely dead. (Even the 
GitHub repository that just republishes the files has not been touched since 
2017. No changes have been made in that repository at all. The Debian 
package was last touched in 2011, the original upstream in 2000.)

There is also a hyphenation dictionary for Hunspell's "hyphen":
http://hlt.sztaki.hu/resources/hunspell/Finnish/fi_FI.zip
converted 2003-11-03 from a LaTeX rule file apparently last touched in 1995. 
This could be packaged as hyphen-fi, but there too, upstream is dead.

If you want these rules to be maintained, somebody who speaks the Finnish 
language will have to do it. (There was a suggestion to look for inspiration 
at the rules for Estonian, which, as you probably know, is closely related.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deprecation of the aspell package

[Kevin Kofler via devel]

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 again in the future
> if we hypothetically decided that, say, Nuspell should replace Hunspell as
> our default spellchecker.

It shall be noted that KDE upstream actually dropped Enchant support in 
Sonnet in KF5 and switched to using Hunspell directly. (They also support 
aspell, hspell, and voikko. All 4 are optional at compile-time, and plugins 
at runtime.) Though to be fair, Sonnet is already an abstraction similar to 
Enchant, and having an abstraction built on top of an abstraction apparently 
did not work out that well.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deprecation of the aspell package

[Kevin Kofler via devel]

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 does not have a C++ API that offers a convenient way for applications
> to run a spell check against the system's default dictionary.

Enchant and Sonnet both handle that for you (they use the Hunspell C++ API 
and do their own file lookup in system paths), see:
https://github.com/AbiWord/enchant/blob/e224b4cbc9856d86335afb43dd1a6651f99fc58e/providers/enchant_hunspell.cpp#L196
https://invent.kde.org/frameworks/sonnet/-/blob/88ba0b8c53d4bc6fbb45ab5350bdf5aa4fde23d7/src/plugins/hunspell/hunspellclient.cpp#L23

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Kevin Kofler via devel]

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* indicate priorities (which is a completely different discussion,
> and which you might, legitimately, ask if IBM and RH is committed, and at
> what level, to Fedora in the long term(*)).

It was pretty clear in IBM's acquisition announcement that they are only 
interested in RH as a cloud services company and do not care at all about 
RHEL, let alone Fedora. The word "Linux" did not show up a single time in 
the whole announcement!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 maintenance and still
> keep fedora java friendly.

And these changes have made the Fedora Java packages basically useless, 
because there is really no advantage anymore to be had over just using, 
e.g., Adoptium builds. Your changes have removed the choice from users to 
choose between a Java built the upstream way (Adoptium and others) and a 
Java built according to the Fedora Packaging Guidelines as all Fedora 
packages are supposed to be (but yours no longer are).

> * In first system wide change, we had changed JDKs to build properly
> as standalone, portable jdk - the wey JDK is supposed to be built. I
> repeat, we spent ten years by patching JDK to become properly dynamic
> against system libs, and all patches went usptream, but it become
> fight which can not be win

This is already against the best practices recommended by the Fedora 
Packaging Guidelines, and arguably even against a mandatory rule (because 
you say all the patches allowing unbundling went upstream):

https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/

"All packages whose upstreams allow them to be built against system 
libraries must be built against system libraries."

> * as a second step we introduced portable rpms, which do not have any
> system integration, only builds JDK and pack final tarball in RPM for
> free use.
> * In third step - without any noise, just verified with fesco -
> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> integrated rpms. Instead of this, normal RPMS BUildRequire portable
> rpms and just unpack it, and repack it.

In short, you build an RPM containing a tarball instead of unpacked files, 
and then have the final RPM BR that intermediate RPM, untar the tarball, and 
repackage it. A really ugly hack that goes against any packaging best 
practices and maybe even subtly violates the letter of the Fedora Packaging 
Guidelines (it is definitely against the spirit).

I do not understand why FESCo approved this hackery. It brings no advantages 
whatsoever to the user, it just makes the builds take longer overall for no 
good reason.

> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> contains latest STS jdk - currently 20, soon briefly 21 and a bit
> alter 22... Should be built in latest live EPEL - epel8 now. We have
> verified, that such repacked JDKs work fine.

And that part is completely against Fedora Packaging Guidelines. Fedora does 
not allow repackaging binary blobs built on another distribution (and RHEL 
*is* another distribution). Such binary blobs can be used only for 
bootstrapping, which implies that they MUST be replaced with something built 
on the targeted Fedora release before reaching end users.

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 source on 
Fedora anymore, but on a commercial operating system (RHEL). That is 
unacceptable for a distribution that intends to be self-hosting.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 interfaces, so there is really 
no way they can prevent us from shipping executables, or at least symlinks, 
named that way.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 long as I do not notice any incompatibility in my actual 
work.

What I *do* care about is that the build is built and packaged the Fedora 
way, which is less and less the case for the OpenJDK packages.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 to run on every build, and that sometimes system libraries 
cause failures in some obscure test that are hard to debug), to which the 
obvious answer is to just stop running it and call the package something 
other than the current java-*-openjdk. (My understanding as a non-lawyer is 
that it should be enough to change the package Name and the Summary and 
%description. The java-*-openjdk name could still be Obsoleted/Provided, and 
the binaries do not have to be renamed either.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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, there might not even be a trademark issue at all, at least for 
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing 
to:
https://openjdk.org/legal/openjdk-trademark-notice.html

> As you wrote about the liberty of choice between temurins and fdeoara ona
> - can you be a bit more specific? Afaik if the builds are similar, we have
> mcuh less possibility of some fedora-specific bug.

But it also means that I no longer have the option to use a Java that does 
not bundle several libraries, possibly including security vulnerabilities, 
bloating its size, and likely reducing system integration (there have been 
concerns about, e.g., worse fontconfig integration in the discussion of your 
previous Change proposal). There is now just the "choice" between a Fedora 
package with everything bundled and third-party packages with also 
everything bundled.

> I once wrote,m that wworked 10years to enable dynamic linking, and yes,
> all is upstream, but there are limitations which can not be overtaken -
> major is ahead of tie comilation. If you can do it right, you cnanot have
> dyanmic linking.

Wait, Java does real AOT compilation now? Or are we talking about that 
strange "feature" you already brought up in the old discussion, where you 
basically just prepend a JRE to a JAR and ship that as a "compiled" 
executable? That "feature", to be honest, I had never heard of before you 
folks brought it up.

As far as I can tell, nobody in the Java world uses it. It breaks the "write 
once, run anywhere" promise and brings us no real advantage over having the 
JRE and the JAR separate.

It is definitely not useful for me because our customers all run Windows, 
not Fedora or any other GNU/Linux. So really it makes no difference for me 
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking) 
or on all GNU/Linux (static linking), they will not run on our customers' 
computers anyway, making that "feature" entirely useless either way.

We have a few ways to deploy our JARs to our customers, but none of them 
involves turning them into native executables through (either real or fake 
as described above) AOT compilation.

> The goal should still be to have fedora rpms properly integrated in
> fedora, and usable, as any other java onthe world, without hacks.

Sorry, but I believe that the old packaging was exactly that, "properly 
integrated" and "without hacks", whereas I have to politely disagree about 
the new packaging having those properties.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 compilation where the result is really 
independent of a JRE (e.g., what GCJ, which is no longer maintained, used to 
produce by default), but if the AOT compilation requires you to bundle the 
whole JRE (and that is the only case where having a statically vs. 
dynamically linked JRE matters), the total deliverable size is going to be 
much larger.

> 2. It is the _only_ way to have decent performance on
>platforms where JIT compilation is forbidden.

That is also irrelevant in this thread: If it matters how the JRE is linked, 
the AOT-compiled output includes a bundled copy of the GNU/Linux JRE 
(otherwise why would it matter?), so it will only run on GNU/Linux, which is 
NOT a "platform where JIT compilation is forbidden". (There is only really 
one such platform, iOS with Apple's totalitarian app store rules.)

> 3. AOT-compiled apps start up faster and use less memory.

That part may be true, but there too, if we are talking about a solution 
that includes bundling the JRE, I doubt it.

> In short, an AOT-compiled application behaves much more
> like one that is written in a native language like C++,

And it turns out a lot of Java applications do not actually work that way. 
Which is why GCJ had a second mode, where, instead of building a binary with 
gcj just like with g++, you would instead AOT-compile every Java class 
individually to a .so in a special directory, then run the Java application 
"the Java way" with gij, and gij would behind the scenes look up the AOT-
compiled classes to speed up the interpreted run. IMHO a very ugly hack, but 
necessary because Java applications are NOT designed to be built like native 
applications (e.g., pure AOT compilation without a JIT and/or interpreter 
fallback cannot handle classes loaded at runtime, such as dynamically 
generated or downloaded class files). Many applications worked with GCJ only 
in that mixed mode.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Kevin Kofler via devel]

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 orphan   0 weeks 
> ago 
> hunspell  alexl, gnome-sig, mbarnes,   0 weeks ago
>   orphan, rhughes, rstrode 
> hunspell-af   orphan   0 weeks 
> ago 
> hunspell-ak   orphan   0 weeks 
> ago 
> hunspell-am   orphan   0 weeks 
> ago 
> hunspell-ast  orphan   0 weeks 
> ago 
> hunspell-az   orphan   0 weeks 
> ago 
> hunspell-be   orphan   0 weeks 
> ago 
> hunspell-ber  orphan   0 weeks 
> ago 
> hunspell-bg   orphan   0 weeks 
> ago 
> hunspell-br   orphan   0 weeks 
> ago 
> hunspell-ca   orphan   0 weeks 
> ago 
> hunspell-cop  orphan   0 weeks 
> ago 
> hunspell-csb  orphan   0 weeks 
> ago 
> hunspell-cv   orphan   0 weeks 
> ago 
> hunspell-cy   orphan   0 weeks 
> ago 
> hunspell-da   orphan   0 weeks 
> ago 
> hunspell-dsb  orphan   0 weeks 
> ago 
> hunspell-el   orphan   0 weeks 
> ago 
> hunspell-en   alexl, gnome-sig, mbarnes,   0 weeks 
> ago 
>   orphan, rhughes, rstrode 
> hunspell-eo   orphan   0 weeks 
> ago 
> hunspell-es   olea, orphan 0 weeks 
> ago 
> hunspell-et   orphan   0 weeks 
> ago 
> hunspell-fa   orphan   0 weeks 
> ago 
> hunspell-fj   orphan   0 weeks 
> ago 
> hunspell-fo   orphan   0 weeks 
> ago 
> hunspell-fr   orphan, remi 0 weeks 
> ago 
> hunspell-fur  orphan   0 weeks 
> ago 
> hunspell-fy   orphan   0 weeks 
> ago 
> hunspell-ga   orphan   0 weeks 
> ago 
> hunspell-gd   orphan   0 weeks 
> ago 
> hunspell-gl   orphan   0 weeks 
> ago 
> hunspell-grc  orphan   0 weeks 
> ago 
> hunspell-gv   orphan   0 weeks 
> ago 
> hunspell-haw  orphan   0 weeks 
> ago 
> hunspell-hil  orphan   0 weeks 
> ago 
> hunspell-hr   orphan   0 weeks 
> ago 
> hunspell-hsb  orphan   0 weeks 
> ago 
> hunspell-ht   orphan   0 weeks 
> ago 
> hunspell-hu   orphan   0 weeks 
> ago 
> hunspell-hy   orphan   0 weeks 
> ago 
> hunspell-ia   orphan   0 weeks 
> ago 
> hunspell-id   orphan   0 weeks 
> ago 
> hunspell-is   orphan   0 weeks 
> ago 
> hunspell-it   orphan   0 weeks 
> ago 
> hunspell-kk   orphan   0 weeks 
> ago 
> hunspell-km   orphan   0 weeks 
> ago 
> hunspell-ko   orphan   0 weeks 
> ago 
> hunspell-ku   orphan   0 weeks 
> ago 
> hunspell-ky   orphan   0 weeks 
> ago 
> hunspell-la   orphan   0 weeks 
> ago 
> hunspell-lb   orphan   0 weeks 
> ago 
> hunspell-ln   orphan   0 weeks 
> ago 
> hunspell-lt   orphan   0 weeks 
> ago 
> hunspell-mg

Re: Fedora Copr builders updated to Fedora 38

[Kevin Kofler via devel]

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 distro upgrade
> team(s)).  This is up to the community to decide, let us know in our
> issue tracker if you are concerned.

Considering that Fedora buildroots always get killed off within days of the 
EOL, I do not see why you are keeping epel-6 buildroots active 2½ years (!) 
after its EOL.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Kevin Kofler via devel]

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
> should end, or be explicitly funded out of the ELS
> fees if the ELS community needs that support.

EPEL is not covered by ELS, hence EPEL is already EOL.

If we are going to support distros that had their EOL 2½ years ago, I want 
my Fedora 31 to 36 buildroots back! (Fedora 31 had its EOL only 6 days 
before EPEL 6, Fedora 32 to 36 had theirs more recently.)

> I do not consider setting gpgcheck=0 overly
> onerous for EPEL6

I consider it a security risk and a no go.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Kevin Kofler via devel]

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 product past
>> official EOL becomes overly onerous that support
>> should end, or be explicitly funded out of the ELS
>> fees if the ELS community needs that support.
> 
> EPEL is not covered by ELS, hence EPEL is already EOL.

PS: I also do not see why Fedora should be supporting the users of a 
commercial subscription scheme with free services such as Copr.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SecureBoot certificates

[Kevin Kofler via devel]

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 2022 GMT
> 
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
> CN=Microsoft Corporation Third Party Marketplace Root
> Not Before: Jun 27 21:22:45 2011 GMT
> Not After : Jun 27 21:32:45 2026 GMT

Are you sure those are 2 independent signatures and not a signature chain?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modules without modularity

[Kevin Kofler via devel]

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 inability to
> introduce completely new modules (as opposite to new streams of existing
> modules) after releasing an installation media.

So the linked approach emulates Modularity with its main issues (in 
particular, the risk of dependency version conflicts ("RPM hell") between 
packages, due to the mutual exclusiveness of the different versions of a 
"stack") by massive abuse of the Conflicts RPM tag (which is frowned upon 
for exactly the aforementioned reason) and without an opt-out (because you 
want to drop these packages into the main repository rather than the 
optional modular one that is now going to be disabled by default for a good 
reason). I fail to see the improvement from that proposal.

If you want to build packages with this (selectable mutually exclusive 
versions) approach, please keep using the normal Modularity and accept that 
users now have to explicitly opt in to those modules. And in particular, 
please accept that non-modular packages are not allowed to require one of 
those modules (or in particular, a specific version thereof). Attempting to 
work around those requirements (designed to protect users from version 
conflicts they cannot resolve) is a very bad idea.

If you really need a package to depend on a specific version of a library, 
that library version should be packaged as a parallel-installable 
compatibility library as per the packaging guidelines.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modules without modularity

[Kevin Kofler via devel]

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.

But the issue here is that you can have 2 completely unrelated packages 
clashing over the version of some transitive dependency. Imagine not being 
able to install a KDE application on GNOME or vice-versa because of the KDE 
and GNOME stacks requiring a conflicting version of some "plumbing-layer" 
library. That is exactly the kind of scenario I and others want to avoid.

> Of course. My proposal does not forbids it. If users of the
> parallel-installable packages are fine with rewriting all their RPM
> dependcies and file locations in their applications, then
> parallel-installable packages are a perfect solution. It's simply a
> different problem with a different solution.

It is a different solution indeed, but I disagree about it solving a 
different problem. It solves the *same* problem in a different, better (from 
the end user's perspective – I know it is more work for the packager) way.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 users are interested in, are less open!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
>> > collaborative and open than it ever has before.
>>
>> The *development process* is more open, but the production releases,
>> which is the only thing end users are interested in, are less open!
>>
> 
> Actually, this is not true either. Since December 2020, Red Hat
> Enterprise Linux has added a number of avenues in which you can freely
> get it:
> 
> 1. Individuals (16 entitlements, prod use permitted):
> https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
> 
> 2. Teams (mucho entitlements for companies, no prod):
> https://developers.redhat.com/articles/2022/05/10/access-rhel-developer-teams-subscription
> 
> 3. OSS projects running their own infra (mucho entitlements, prod use
> permitted):
> https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations

That is not "open", it is just free as in beer, for a restricted subset of 
people. If you are not (explicitly! Not just "try and hope we do not 
terminate your subscription at our whim") entitled to share the SRPMs, it is 
NOT open.

> I will also point out that CentOS Stream is perfectly suitable for
> production use

If it were, Red Hat would offer it as a supported alternative to their 
commercial subscription users. They do not, obviously for a reason. A beta 
branch is not a production release.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
> all fixes done by Red Hat or community members are released
> immediately after running through the gates and passing the tests at
> the gates. That shortens the average TTL for non-critical/non-security
> improvements from 6 months to a couple of weeks.

Well, another aspect that I think was not mentioned so far in this 
discussion is that CentOS Stream has only half the support time of RHEL, 
which makes it much less useful for production servers (and less 
advantageous over competitors' offerings such as Ubuntu LTS, which offer a 
similar support period as CentOS Stream).

This also means that if RH is telling rebuilds to do their own backports 
from CentOS Stream, that is only going to help them in the first half of the 
lifecycle. In the second half, there are no point releases, hence also no 
CentOS Stream that would prepare those. So, as I understand it, the security 
fixes are then only going to be published through the subscription channels.

> Offhand, I know CentOS Stream 9 is available as an option in the
> following VPS providers:
> 
> * DigitalOcean
> * Linode
> * Vultr
> * Hetzner
> * Afterburst

At least Hetzner also offers Rocky Linux and (recently added due to customer 
demand) AlmaLinux. If their customers were happy with CentOS Stream, they 
would not do that. (For the record, I happen to be one of those customers, 
for a small VPS (currently still running CentOS 7) and 2 domain names. That 
is the only involvement I have with Hetzner.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

> 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 Fedora Workstation live ISO from livemedia-creator to
> Image Builder.

Yet another image building tool? I remember not too long ago when livemedia-
creator was the shiny new thing instead of livecd-creator. (Yet, I found 
livecd-creator to work much better for me to create my Kannolo images than 
livemedia-creator.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 has long refused to use 
/usr/libexec (despite GNU having had it for ages, and Debian's refusal has 
in turn lead several upstreams to not or poorly support it and abuse 
/usr/lib or other directories for its purpose instead) because it was 
purportedly against the FHS (it seems they have never noticed that the 
clause that allows lib64 and lib32 does not actually require the suffix to 
be a number, "exec" is a perfectly fine suffix, so libexec is just another 
lib64/lib32-type directory), but was very fast to add an exception for this 
new entirely non-standard layout. (The FHS requires the arch-specific libdir 
variants to be suffixed sibling directories of lib, NOT subdirectories.)

> That kind of layout would make it much easier to do cross compilation
> because you could just take the whole /usr/lib/another-host-triplet/
> directory from another architecture without it interfering with the host
> libraries and use it for cross compilation purposes.

Practical cross-compilation to a completely different architecture needs 
sysroots anyway. That way, one can also easily target a different 
distribution on a different (or even the same) architecture, not just Fedora 
on a different architecture.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 are 
targeting Fedora or a similar distro, you will probably want to compose a 
custom live image with a bunch of -devel packages. (You can also try to 
install packages within the sysroot, but if you are cross-compiling to a 
different architecture, that is not straightforward, you either need to use 
host tools and point them to the sysroot, or to use CPU emulation to run the 
tools within the sysroot, or as a last resort to unpack package contents 
manually.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intent to retire OpenCOLLADA

[Kevin Kofler via devel]

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 bureaucracy of unretiring the package.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

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 my upstream and
> downstream work will be reassigned depending on Red Hat's own priorities,
> as I am transferred to another team.

So Red Hat is essentially killing all work on desktop packages, not just on 
LibreOffice? Also considering that several of those packages are libraries 
that cannot just be put on Flathub as LibreOffice can (which was their 
excuse for terminating all work on LibreOffice packaging).

With the layoff and the destruction of the position of the Fedora Program 
Manager, the termination of public RHEL source releases, and this move, Red 
Hat is really turning into an unfriendly company, and I really have to 
wonder whether Fedora is going to be of any use to me in the long run.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package deprecation policy

[Kevin Kofler via devel]

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 just need to keep the package compiling 
and address security issues. Sure, there are packages where either or both 
of these is impractical, in which case the package should just get orphaned 
and eventually retired. But planning for the package removal before this is 
even an issue, just because upstream deprecated the package, does not make 
sense. It can prevent useful software from entering Fedora just due to the 
upstream maintenance state of a single (possibly even transitive) 
dependency, whose impending removal from Fedora is entirely unnecessary.

And I am speaking from experience there, as one of the people keeping the 
Qt/kdelibs 3 and 4 stacks working for legacy applications to use. Those are 
a lot less work to maintain than the current KDE Frameworks that need to be 
updated to a new upstream release every month or so.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

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 considers 
LibreOffice unimportant to their customers, it is obvious that they only 
care about server customers.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 they quietly say, "Screw You,
> Leslie".

Removing the copyright is not allowed under the GPL, and in many 
jurisdictions your license cannot even allow that to begin with, but that is 
not what is being done by the rebuilds, so that point is a strawman.

The rest is just how Free Software works and should work.

> Suppose I was the government, and I did that same offer to end-users.
> Would the redistribution be legit, and even honest, if from the
> government, and it was for remuneration?

Same answer as above.

> What right does a company have the right to clone and rebrand my product
> and resell it?

That is an essential part of Free Software, of Open Source, and of the GPL 
in particular.

> Under the gpl3, they have an unenforceable obligation to
> provide me with bug reports.

They actually have no such obligation, enforceable or not.

> They do not have a moral right to redistribute my software as their own,
> and for remuneration.

That is your very personal interpretation and does not match the Free 
Software definition nor the Open Source definition.

> In two cases, at least two companies offer Linux as known Red Hat, clones.
> We understand that they copy the sources, the bug fixes, and rebrand the
> software as their own. In most cases, vanilla in -- vanilla out. But it is
> not revenue in, revenue shared.

Guess what, Free Software means this is perfectly acceptable behavior, 
whether you find it fair or not. Life is not fair.

> What should Red Hat do to recover the costs for development of new
> features, documentation, distribution, bug-fixes, 24/7 support as well,
> the infrastructure that allowed an individual to freely download the
> entire package. The clones have none of those obligations or costs? Red
> Hat is financing Centos and Fedora. Moreover, visit
> https://kojipkgs.fedoraproject.org/compose/
> to get a small idea of the investment, operating costs, and end-user
> benefits. Recall, Red Hat shareholders are not a government body.

The clones also have infrastructure costs.

They indeed do not share the development costs, but there is no requirement 
that they do.

> Perhaps it is time to provide a gpl4 rule that encompasses or replaces
> gpl3.

A "GPL4" with the kind of rules you imply would no longer be Free Software, 
hence I hope the FSF will never put this kind of terms into any version of 
the GPL.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Stupid question about QT6 and OpenGL support

[Kevin Kofler via devel]

Mattia Verga via devel wrote:
> ... I wonder why... AFAIK, GLES should be better for low resource
> systems like raspberry, isn't it?

Probably yes. KDE upstream recommends it for Plasma Mobile, and Manjaro ARM 
builds a few qt5-es2-* packages (conflicting with the regular qt5-* ones) 
for the components where it makes a difference. Fedora could do the same on 
aarch64.

And proprietary drivers for ARM often support ONLY OpenGL ES, so if we do 
not have Qt builds built for ES, Qt will not support OpenGL with those 
drivers at all. (Though it can be argued that that is a feature. ;-) )

As I understand it, Mesa now supports desktop OpenGL everywhere, but missing 
functionality is emulated in software, which is obviously slow.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kevin Kofler via devel]

Neal Gompa wrote:
> I would prefer that *every* build would automatically generate a side
> tag, even if it's a side-tag of one package. Or at least provide an
> option to do that. That would provide opportunities for server-side
> automation for populating side-tags with updated builds against a
> package.

But it is not practical given the performance concerns around side tags.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Kevin Kofler via devel]

Neal Gompa wrote:
> You can filter out things that use ImageMagick as a build dependency
> because that's just the command line utilities. That's why I checked
> only the ones that use the libraries, where the API changes and the
> required rebuilds are needed.

How backwards-compatible is the CLI? Can there be things stopping to build 
or to work at runtime because ImageMagick 7 convert does not understand some 
option intended for ImageMagick 6 convert?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kevin Kofler via devel]

Mattia Verga via devel wrote:
> Or let's just get rid of Bodhi and trust all packagers to "know exactly
> what they are doing with their package".

Yes please!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:

> On 05/12/2022 12:39, Terry Barnaby wrote:
>> I am wondering what Fedora's policy is on depreciated old shared
>> libraries and particularly compat RPM's ?
> 
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Or you can just build the compat package you need in a Copr, see, e.g.:
https://copr.fedorainfracloud.org/coprs/kkofler/compat-libgfortran-48/
(which I do not really use anymore, but I have kept the Copr up in case it 
is useful for other people).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kevin Kofler via devel]

Adam Williamson wrote:

> On Mon, 2022-12-05 at 22:44 +0100, Kevin Kofler via devel wrote:
>> Mattia Verga via devel wrote:
>> > Or let's just get rid of Bodhi and trust all packagers to "know exactly
>> > what they are doing with their package".
>> 
>> Yes please!
> 
> Exhibits 1 through 2636 for why this is a bad idea:
> https://bodhi.fedoraproject.org/updates/?search=&status=unpushed&page=1

In my ideal world, it would still be possible for a maintainer and for rel-
eng to unpush bad updates. IMHO, even from stable updates, since there is 
not really a technical reason to not allow that. It could be as simple as 
"koji untag-pkg fnn-updates foo".

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Kevin Kofler via devel]

Neal Gompa wrote:
> There are actually
> other packages I could fix in Fedora with patches from openSUSE or
> PLD, but they need more work to not break compatibility with building
> with GraphicsMagick (which these packages in question support), so
> using IM6 there for now is fine while that gets worked out.

If there are patches, I do not see why we cannot just apply them downstream 
instead of building against a compat package, especially if we make 
ImageMagick 7 the default as you propose.

There is no rule in Fedora that any and all patches must be upstreamed. 
Especially building against the distribution's version of a library is 
exactly what a distribution is for and hence the perfect example of when it 
makes sense to patch a package.

IMHO, either we go with Sergio's plan, letting ImageMagick be version 6 
forever and introducing ImageMagick7 (and in the future ImageMagick8, etc.) 
for all newer versions, then we can slowly switch packages from ImageMagick 
to ImageMagick7, or we go with your plan and move ImageMagick to version 7, 
but then we should do all we can to make really everything use the new 
version.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Kevin Kofler via devel]

Neal Gompa wrote:
> While that is true, *I* don't like doing that if I don't have to. I'd
> rather try to get things fixed upstream in tandem. Upstreams tend to
> appreciate that in my experience. :)

Sure, but it tends to be significantly more work. Upstreams need to support 
several platforms at once, so they often cannot just move to new libraries 
and drop support for the old ones, and some are also quite picky about code 
style issues that ultimately do not matter to end users.

> (This is probably why so many people think I'm everywhere, to be honest!
> :P )

:-)
 
> Further analysis indicates that dvdauthor has a patch in openSUSE[2],
> but the fix breaks support for GraphicsMagick as an alternative. I
> want to rework that patch so it doesn't break GraphicsMagick and old
> ImageMagick support so that it's suitable for upstreaming. I don't
> expect this to be too difficult to do.

Well, that is exactly why it is harder to make a patch that is acceptable to 
upstream than one that works in the distribution. A downstream patch can 
even be conditionally applied, if you want to support old and new library 
versions in the same specfile, so the dual support need not be in the patch. 
This is of course not the case for an upstream patch. So then you end up not 
only adding "#ifdef"s for every line you changed, but also need to add a 
build system ("configure") check for the library version. It can turn a 
quick search&replace job into a patch adding dozens of new lines of code.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Kevin Kofler via devel]

Terry Barnaby wrote:
> Well in this case I have created a suitable compat lib, all I did was
> re-introduce the bits to the SPEC file that removed the building of the
> compat lib and we are fine. I haven't separated it out from the main
> ncurses SPEC through and have only done this locally as I have no
> knowledge of the hoops to create a separate package and that seems like
> the wrong way to do this in general. I have made this available to
> others who will be in the same boat.

Typically, compatibility libraries should not be subpackages of the main 
library. But ncurses is a bit peculiar in that, as I understand it, the 
latest code can still be built with the old ABI. So in that case, it at 
least makes sense to build both from the same SRPM. But only if they are 
going to be maintained by the same maintainer(s), i.e., you should probably 
sign up as a comaintainer for ncurses in Fedora if you want to do it that 
way. And of course only as long as upstream continues supporting building 
for the old ABI. If they drop support, then a separate compatibility package 
with an old version that supports the old ABI will be needed.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

Adam Williamson wrote:
> As of today, with that new dep in webkitgtk, Rawhide's network install
> images are 703M in size. Here's a potted history of network install
> image sizes:
> 
> Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M)
> Fedora 13: 208M
> Fedora 17: 162M (last "old UI")
> Fedora 18: 294M (first "new UI")
> Fedora 23: 415M
> Fedora 28: 583M
> Fedora 33: 686M
> Fedora 37: 665M
> Fedora Rawhide: 703M

Wow, a factor 7!

Thank you for your efforts to track down and try to combat the bloat!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 prototype, but way too resource-heavy to be shipped 
in production. We need a rewrite of the UI design in a desktop toolkit. (If 
GTK is not suitable, how about Qt? ☺)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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/libLLVM-15.so with only the host as the target, and a 
renamed /usr/lib64/libLLVM-cross-15.so with all the targets. Link the 
compilers against the latter.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 are all 
shipping Calamares instead. Which is written in a toolkit actually designed 
for desktop applications (Qt).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Starting Flatpak SIG

[Kevin Kofler via devel]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 was effectively
> maintaining a small mini distro for the purposes of running the distro
> installer.

But this "converging" unfortunately means the installer image now runs 
things like GDM which are definitely not needed to just bring up an 
installer.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 non-compositing X11 window 
manager or a plain fbdev framebuffer would probably work fine without it, 
would they not?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 image (thanks to stronger compression) 
means less time and energy, and for users on metered connections also less 
money, spent downloading the image.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Kevin Kofler via devel]

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 by a huge
> margin the worst offender.
>  
> Does anyone know anyone we can talk to at Intel about this? It's pretty
> obnoxious.

It's the same situation as for some of the GPU firmwares: They have 
submitted as vendor driver to upstream, which does very little, together 
with a huge proprietary firmware, which does most of the real work. Hardware 
manufacturers love playing that trick.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: colorful license change

[Kevin Kofler via devel]

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 OR Zlib)
> - colorful-data: zlib-acknowledgement

In case people wonder (as I did): This is a leaf package:
https://svgames.pl/en/down
https://github.com/suve/LD25/
> Colorful is a simple 2D side-shooter game
so the license change to a more restrictive license should not be an issue.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Polymake soname bump

[Kevin Kofler via devel]

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.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Bumping the soname of a library with only a handful, or even, as in this 
case, only one single, dependent package(s), as a grouped update together 
with those dependent package(s), is not what I would call an "ABI 
incompatible update".

Of course, the more packages depend on the library, the more you want to 
avoid bumping their ABI in an update.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 break the NVidia proprietary driver.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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-encrypt the root filesystem and

So basically this change proposal is about supporting a feature of the 
Microsoft cloud platform (Azure) in Fedora and will be pretty useless to any 
user not using Microsoft's platform.

> seal the LUKS key against predicted TPM PCR values. It guarantees
> that the root disk can only be decrypted by the specific VM
> instance that is requested, when it is running in SecureBoot
> mode with the expected measurments on AMD SEV-SNP confidential
> hardware.

Does it really guarantee that, and not just that it can only be decrypted by 
any VM using the same UKI?

How reliably does it ensure that the user can only get root in the decrypted 
image with the root password (or SSH key or similar) stored inside the image 
and not through some other means?

In the end, if you store data on a "cloud", you are storing it on other 
people's computers. You are also relying on their confidentiality 
guarantees. How can you trust the "cloud" provider to actually perform the 
encryption steps they claim to perform when you check that checkbox, and 
also to not have a backdoor (such as a fixed master key in an extra LUKS key 
slot, or a custom, possibly software-emulated, TPM that does not actually 
keep the key sealed) that allows them to decrypt anything anyway?

You are handing off your data to a third party and then trying to rely on 
Treacherous Computing technologies preventing that third party from doing 
some things (such as copying the encryption key) on their own computers. I 
do not think that this is in either party's interest.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

> 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 when this was first introduced, autogenerating the 
changelog from git history is a bad idea, especially in Fedora dist-git 
where published git history cannot ever be rewritten, so it is impossible to 
fix typos in the changelog, hide fixup commits if they did not use the 
proper fixup markup (or even avoid them altogether by amending the 
previously pushed commit), etc., which all requires to at least be able to 
edit commit messages, which unfortunately in git means you need to be able 
to amend the commit altogether and force-push. As long as such force-pushes 
are by design not allowed in Fedora dist-git, its (effectively immutable) 
metadata is not a suitable place to maintain the changelog in.

In addition, it assumes that the commits in git use the correct format for 
%autochangelog. In my current commits, I paste the full changelog entry with 
date and all into the commit details field and add a one-line summary as the 
commit summary. (Git-Cola automatically turns this into a commit message  in 
the conventional git format summary + blank line (i.e., 2 newlines) + 
details.) Obviously, I do not want the date line to be pasted back into the 
changelog below an automatically generated one. (My older commits from pre-
git times even had only the full changelog entry pasted with no summary 
line.) In addition, sometimes, I add details to the git commit message that 
are too long for the RPM changelog and hence are deliberately only in the 
git commit message. (More precisely, I append to the pasted changelog entry 
a blank line and one or more freeform paragraphs with the extra details.) I 
do not want those to ever be automatically added to the RPM changelog 
either.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 quo (non-autochangelog) is that you only need
> to do it if the autogenerated changelog is deficient for whatever reasons.
> In the default case you can use autochangelog, and fall back to the manual
> version when necessary.
[snip]
> Rpmautospec allows you to have a part or parts of a commit message that
> end up in the changelog, and parts that do not, see
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages

All in all a very complicated and error-prone process just to save some 
extremely lazy packagers a 5-second copy&paste. I really do not see why that 
should be the default and recommended process.

The rules how to format the commit message are error-prone, and if you get 
them wrong, you usually only notice when it is too late to fix it (because 
force-pushes are not allowed). Yes, you can manually run "rpmautospec 
generate-changelog", but that is actually no less effort than just taking 
care of the changelog manually to begin with.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 combinations
> of configurations, and that matrix quickly explodes (i.e. usually
> exponentially - 2^n builds for for n independent flags). This is a
> deal-breaker for shared libraries in most cases, and also can't be
> solved by using a different compiler. (Unless you want to figure out
> *which* combinations to build, and *only* build these.)

The application can pick the options with which each library is compiled? 
What a stupid idea! Now I understand why the language is called "Rust".

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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" dependencies in Python
> packages, so this is not unique to Rust), you really should regenerate
> the entire spec file with rust2rpm for every new version (and every
> time when touching a patch that modifies features / optional
> dependencies in Rust crate metadata).
> 
> Previously, this meant arduously copying the old changelog contents
> somewhere, regenerating the spec file with rust2rpm, copying the old
> changelog back, set the Release count to "0", run "rpmdev-bumpspec"
> for the latest change, and commit the changes (usually with a useless
> duplicate of the changelog entry as commit message).
> 
> With rpmautospec, all steps except "regenerate the spec file with
> rust2rpm" and "git commit -c 'changelog contents'" are eliminated,
> which makes updating packages *much* easier, faster, and less
> error-prone.

So it looks like in this case, it helps. That does not mean it needs to be 
the default for packages which are not autogenerated though.

> Additionally, not having Release counter and changelog in the .spec
> file means that you can usually freely cherry-pick or merge bug-fix
> commits across different dist-git branches. This wasn't possible
> without rpmautospec due to merge conflicts caused by different Release
> counter or changelog contents.

If I have a package that I upgrade in stable releases, I keep Release in 
sync, and the changelog only really reflects Rawhide. I just fast-forward 
Rawhide to the release branch, and the Release tag and the changelog go 
along with it. If that includes some "Rebuild for Fnn mass rebuild" entries 
that do not really apply to the release branch, so be it. At least it 
explains why the Release number is as high as it is.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 using spec conditionals.
> This keeps the specfiles clean and readable, even if they differ
> between branches. Obviously, this can't be (easily) automated and
> doesn't scale to hundreds or thousands of packages, but it works well
> for leaf packages.
> 
> rpmautospec doesn't work with the above workflow as it breaks on those
> merge commits, produces bogus changelog messages and artificially
> inflates Release counters.

This (the failure to handle merge commits) is a serious limitation because 
this is one of the workflows where an autochangelog would be most useful, in 
order to avoid the merge conflicts on the changelog.

If you work the way I do, avoiding merge commits in favor of fast forwards 
and specfile conditionals, then rpmautospec can in principle generate the 
autochangelog, but in that case, I do not really need it because my manual 
changelog fast-forwards just fine along with the rest of the commit.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 combinations
> of configurations, and that matrix quickly explodes (i.e. usually
> exponentially - 2^n builds for for n independent flags). This is a
> deal-breaker for shared libraries in most cases, and also can't be
> solved by using a different compiler. (Unless you want to figure out
> *which* combinations to build, and *only* build these.)

Let me try formulating my criticism more constructively (since my previous 
reply failed both at being polite and at getting my point through, sorry 
again for that):

I am really surprised to read above that Rust apparently allows applications 
to pick the flag with which the libraries they depend on are compiled. I 
really have to wonder why anyone would think that allowing that would be a 
good idea, but then again I guess I know the answer: Whoever added this 
feature was so set in a mindset where everything is compiled on demand and 
statically linked that they figured: why not?

And if you are in that mindset, that actually sounds like a reasonable call 
to make. Source-based software distributions do have the advantage of 
offering this kind of flexibility on demand, see also the USE flags in 
Gentoo. Those are in fact one of the main reasons some people decide to 
compile an entire GNU/Linux distribution from source (and hence pick a 
distribution such as Gentoo) to begin with. Likewise, the Rust way of 
compiling dependencies on demand allows applications to make this kind of 
settings for them.

Still, I can see several issues with that approach, e.g., what if an 
application depends on two libraries A and B that both depend on library C, 
but with conflicting flags? But the main issue is that, as you point out, it 
makes binary distribution of shared libraries highly impractical. That is 
why I think this was a short-sighted design decision.

But we will have to work around this one way or another, because I doubt 
anyone will be willing to remove that questionable feature now that 
developers have come to rely on it. (And no, I do not think the current 
Fedora approach of packaging crates in source form only is the optimal 
approach, for reasons I have already pointed out in other threads on this 
list.)

I hope that the above now brings my point across constructively.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 Change must be implemented in a manner which packages are
>> >  able to trivially opt-out of retaining frame pointers during
>> >  compilation so that packages that take larger performance hits can
>> >  easily
>> >  revert.  (mhroncok, 17:20:38)
>>
>> Already rejected proposal was submitted because big corporations weren't
>> happy with the results. This is a VERY BAD precedent for Fedora.
>>
> Actually, the Change owners were prepared to give up. I was the one
> that pushed for it to be reconsidered because of how much benefit it
> gives to desktop Linux developers.

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 time.
* So instead, you filed up a *new* ticket, with *no* public discussion 
(e.g., on this mailing list), and also with *no* link in the original 
ticket, thereby excluding participants of the existing discussion that you 
lost (who did not get any notification that the decision was being 
reconsidered before it was too late and hence no chance to chime in).
* And then you expedited the issue to the next meeting, only 4 days after it 
was opened, again precluding any kind of discussion or feedback.
* I also do not see anything that has changed since this was last discussed.
* And as in the last discussion, I still believe that 2 releases, i.e., a 
whole year, is way too long an evaluation period. If anything, this needs to 
be evaluated in Rawhide only with the option to revert it with a mass 
rebuild before feature freeze. It does not make sense to ship pessimized 
code to end users for a whole year.

> When the Change proposal came in for FORTIFY_SOURCE=3 (which introduces
> similar pressure), the resulting discussion prompted the re-vote.

I do not see how this is a fair comparison because FORTIFY_SOURCE is a 
security feature whereas this one is not. Of course, stricter FORTIFY_SOURCE 
comes at a performance penalty, but it improves security for end users. 
Frame pointers, on the other hand, bring no value whatsoever to end users, 
only to developers.

In addition, if you believe the penalty is too high, then the outcome should 
have been to reconsider the FORTIFY_SOURCE=3 change instead.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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. They are the experts.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
> time.
> * So instead, you filed up a *new* ticket, with *no* public discussion
> (e.g., on this mailing list), and also with *no* link in the original
> ticket, thereby excluding participants of the existing discussion that you
> lost (who did not get any notification that the decision was being
> reconsidered before it was too late and hence no chance to chime in).
> * And then you expedited the issue to the next meeting, only 4 days after
> it was opened, again precluding any kind of discussion or feedback.

* You apparently also did not even invite the toolchain team, the experts on 
this issue, since judging from Florian Weimer's reply here and from Siddhesh 
Poyarekar's reply in the ticket, they were caught by surprise by this sudden 
complete reversal just as completely as I was.

> * I also do not see anything that has changed since this was last
> discussed.
> * And as in the last discussion, I still believe that 2 releases, i.e., a
> whole year, is way too long an evaluation period. If anything, this needs
> to be evaluated in Rawhide only with the option to revert it with a mass
> rebuild before feature freeze. It does not make sense to ship pessimized

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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
>> 
>> Given the controversial nature of this one, why was it re-litigated at
>> short notice when a large number of the stakeholders were still on
>> vacation?
> 
> Presumably because it now had majority support in FESCo and waiting extra
> week would collie with the mass rebuild.

Still, it gives an extremely bad impression of rushing this through without 
giving anybody the chance to object.

I also do not see why this needed to be approved for F38 on such a short 
notice and could not wait for F39.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue