Re: The new version of Fedora Messaging Notifications will arrive this week

[Otto Liljalaakso]

Aurelien Bompard kirjoitti 24.4.2023 klo 16.04:

Hi folks!

The "FMN replacement" team has finished writing the new version of our
notification system, and we are ready to deploy!



You will thus still be able to access the current FMN, and it will
keep running until F39. Due to the difference in features, we can't
import existing rules into the new system, so we encourage you to
create new rules that suit you as soon as the new system is up and
running.



We hope you will enjoy the simpler UI and faster processing speed that
the new FMN brings.


Thank you for working on this. I am not exactly sure how this will 
affect things, but my hopes are high that I can be better notifications now.


My current situation is not ideal. I *think* I currently get the following:

1. Bugzilla's own notifications (probably configurable there, but the 
defaults are ok and I have trouble with the Bugzilla UI, so I have not 
bothered to check)

2. Pagure.io's own notifications (nicely configurable there)
3. src.fedoraproject.org's own notifications (nicely configurable there)
4. Bodhi's notifications (not sure if they are sent by Bodhi or some 
middleman, I wouldn't know how to adjust these even if I wanted to)

5. Fedora Discussion's own notifications (nicely configurable there)
6. Random junk that either duplicates the above or I cannot make any 
sense of (I presume this comes from the old thing that is now being 
replaced, but other than that, I have no idea how I could configure this)
7. Sometimes there is a notification that looks similar to the junk from 
6 but actually has interesting information, like that I received a 
Fedora Badge (the fear of losing these diminishes my willingness to try 
out random things to avoid 6)


First, I would like to keep 1 — 5 and get rid of 6. Retaining 7 would be 
nice but not critical. But I am so confused regarding the notifications 
that I am not sure how to achieve that. Is there some kind of guide 
available on how to set up Fedora notifications in general, so I could 
try to clean up things for myself?

___
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 proposal: BiggerESP (Self-Contained Change proposal)

[Peter Robinson]

On Mon, Apr 24, 2023 at 5:15 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BiggerESP
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
>
> The Fedora installer includes an EFI System Partition of between 200MB
> and 600MB by default, of which the lower size is much too small for
> firmware updates on modern hardware and also for future bootloader
> features like UKI.
> This change will increase the minimum size of the ESP to be 500MB,
> which is also the same value used by Microsoft for Windows 10 and
> newer.

While I believe this to be low impact I do believe it should be a
system wide change as it impacts all aarch64 and basically all the
x86_64 we actively care about.

> == Owner ==
> * Name: [[User:rhughes| Richard Hughes]]
> * Email: rich...@hughsie.com
>
>
> == Detailed Description ==
>
> Modern hardware has UEFI firmware updates that are more than 64MB in
> size. The OEMs recommend a ESP free space of double the flash size
> plus 20MB and fwupd now enforces this requirement to ensure flash
> success. As the ESP is often shared between Windows and Linux, and
> also used for firmware updates, and soon to be used by UKIs it's not
> enough to just allocate a few hundreds of megabytes. Windows 10 and 11
> allocates an ESP of at least 500MiB. Arch also specifies a minimum of
> 512 MiB.
>
> == Feedback ==
>
> There is no alternative -- the ESP has to scale up if we want firmware
> updates to continue to work and to support UKIs for next-generation
> bootloaders.
>
> == Benefit to Fedora ==
>
> Firmware updates will work on future hardware, and we can boot the
> kernel using UKIs using next-generation bootloaders.
>
> == Scope ==
> * Proposal owners:
>
> We need to change a number in Anaconda:
> https://github.com/rhinstaller/anaconda/pull/4711
>
> == Upgrade/compatibility impact ==
>
> We can't grow the ESP in size, and so this change will only affect new
> installs. This is fine, as this will affect new hardware more than old
> hardware.
>
> == How To Test ==
>
> Install Fedora and observe that /boot/efi has at least 276MB free
> space, even when installed alongside Windows.
>
> == Dependencies ==
>
> Anaconda would need to be modified, and Fedora would have a / or /home
> partition that's ~300MB smaller by default than it is now.
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change), No
>
> == Documentation ==
>
> N/A (not a System Wide Change)
>
> == Release Notes ==
>
> Fedora now defaults to a larger EFI System Partition which allows
> firmware updates to work on newer hardware, and allows future
> bootloader and kernel modernizations.
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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
___
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: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Ben Cotton  said:
> Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up
> from `65530` of Fedora; it makes sense to follow their lead and set
> the same value.

It doesn't necessarily make sense for a general-purpose OS to follow
what is effectively an embedded platform.  If this is a good change with
no downsides, then how about going "upstream first" and getting the
change into the Linux kernel?

If this is just for Steam games, then how about seeing if the RPMFusion
Steam package can include this as a sysctl.d drop-in?

-- 
Chris Adams 
___
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 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

[Peter Boy]

The increase step looks very massive. And I wonder why we should make such a 
change to make games of all things work out of the box. Are games the main use 
case of Fedora? 

Wouldn't it make more sense to create a game spin instead? After all, we 
already have a Lab. Or make a corresponding change in this context.


> Am 24.04.2023 um 23:07 schrieb JT :
> 
> How this would affect memory performance on a workstation or server with much 
> more running concurrently, is something I can't really speak to, but I would 
> guess there's a point where increasing it could cause issues depending on 
> total memory available and how many processes are getting memory reservations 
> from the kernel.  
> At first glance it should be relatively easy to get at least a simple 
> baseline check on a busy workstation/server that isn't massively loaded with 
> RAM.  A system that starts to run into memory pressure during heavy use 
> should reveal if this change causes problems under the same workload.

Before introducing this change, we need to check and make sure that this change 
will not affect a server operation under any circumstances.  

And we need to look specifically at the impact on servers in virtualized 
environments, where memory is usually greatly reduced for cost reasons. 


I am currently strongly against introducing this change for Server Edition. At 
the moment I don't see any benefit for a server operation through this proposal.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
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

[Björn Persson]

Kevin Fenzi wrote:
> On Sun, Apr 23, 2023 at 11:21:58PM +0200, Björn Persson wrote:
> > Kevin Fenzi wrote:  
> > > We could probibly come up with some
> > > better way to start new topics/discussions  
> > 
> > Yes I think I can come up with a better way. Give each tag its own
> > email address, like a mailing list. That was very easy to come up with.  
> 
> I think you mean each category?

I don't know Discourse but we're told that something called a tag is
roughly equivalent to a mailing list. I suppose categories could have
addresses too.

> But you may want multiple tags on a post... 

Like Vít said, you can send to multiple addresses. That's how you
cross-post to multiple mailing lists. The Discourse server would then
read all the addresses and apply all of those tags and/or categories
to the post.

When there are multiple recipient addresses in the same domain, a
well-behaved SMTP client is supposed to transmit a single copy of the
message in a single SMTP session with multiple RCPT commands. Thus the
Discourse server will receive only one copy.

It is however possible that some badly written program might mishandle
such a message and send a separate copy to each recipient address. Each
copy would then still contain the whole list of addresses in the To and
CC fields. If the Discourse server would read the header fields and not
just the SMTP envelope, then the copies would appear as duplicate posts,
each with the full set of tags, not as separate posts with one tag each.

If duplicates would turn out to be a great nuisance, then the Discourse
developers might want to add a deduplication feature. The Message-ID
field would be useful for discovering duplicates, but deduplication
should not be done based on the message ID alone. The full contents
should be compared to ensure that the messages really are identical, in
case some defective or malicious email client produces non-unique
message IDs.

As you can see, it doesn't take any great inventions to do this. The
email standards already contain the necessary features. They just need
to be implemented, if the Discourse developers are serious about
supporting interaction by email.

> But that also doesn't solve the spam problem... anyone could send to
> those addresses, and indeed spammers will. ;( 

We're told that only sender addresses associated with a Fedora account
are allowed to send to the single global new-topic address. Obviously
that would apply to the tag (and category) addresses too. That's
analogous to reducing spam to mailing lists by accepting posts only
from subscribers.

In what scenario do tag-specific new-topic addresses result in a worse
spam problem than a single global new-topic address?

> But perhaps this could be useful with some other way to autenticate
> posts.

I haven't seen spammers impersonate subscribers in the mailing lists.
The occasional spam that gets into the mailing lists seems to be done
by subscribing a disposable address and sending from that address.

If spammers would start putting in a legitimate user's address as sender
to get the spam into mailing lists or Discourse, then there's DKIM. I
have found DKIM by itself ineffective, as most of the spam is DKIM-
signed now, but DKIM combined with a requirement for a known sender
address should be sufficient authentication to stop spam. The spammer
would at least have to actually send from the same domain as the user
they impersonate.

For registered users whose email provider doesn't sign their messages
with DKIM, a verification message could be sent that they have to reply
to, like when signing up for a mailing list but repeated for every post
that isn't a reply. There's also OpenPGP/MIME. But I rather doubt that
such measures will be needed just to fight spam. Strong authentication
is for preventing more targeted attacks than spam.

Björn Persson


pgpHIaugWIhhr.pgp
Description: OpenPGP digital signatur
___
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 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

[JT]

Interesting that this came up.  I was just talking to someone else about
this the other day.  From what I understand, that sysctl affects the max
number of memory map areas a process can have, i.e. contiguous reserved
memory.  For a game that's great because it can pack more into memory and
decrease disk IO.
My guess is that this is really not an issue for the Steam Deck because
realistically it will only be doing a few things at once... Basic system,
Steam Client, and the Game running.
How this would affect memory performance on a workstation or server with
much more running concurrently, is something I can't really speak to, but I
would guess there's a point where increasing it could cause issues
depending on total memory available and how many processes are getting
memory reservations from the kernel.
At first glance it should be relatively easy to get at least a simple
baseline check on a busy workstation/server that isn't massively loaded
with RAM.  A system that starts to run into memory pressure during heavy
use should reveal if this change causes problems under the same workload.



On Mon, Apr 24, 2023 at 1:13 PM Kevin Fenzi  wrote:

> A few questions:
>
> * Could we perhaps try and get upstream to adjust this higher?
>
> * Is there any description/docs on what happens when this value is too
> low? do games error in a particular way?
>
> * Is there any adverse impact increasing this? More memory used?
>
> Thanks for putting this together.
>
> kevin
> ___
> 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
>
___
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

Hdr Hackathon: 24-26 April

[Reon Beon via devel]

https://wiki.gnome.org/Hackfests/ShellDisplayNext2023
___
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: Firecracker microVM manager

[Neal Gompa]

On Mon, Apr 24, 2023 at 4:10 PM Demi Marie Obenour
 wrote:
>
> On 4/24/23 08:33, Neal Gompa wrote:
> > On Mon, Apr 24, 2023 at 4:19 AM Peter Robinson  wrote:
> >>
>  There is no problem technically; the Copr repo[2] is building
>  Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
>  to be against it in Fedora.  From this thread:
> >>> Why does Fedora not want to ship Firecracker statically linked to musl?
> >>> That is the supported and tested configuration upstream.  Using glibc
> >>> or dynamic linking is not supported for production use.
> >>
> >> Because glibc is Fedora's supported libc implementation and supporting
> >> two different implementations at the same time is complex
> >
> > And importantly, as the musl maintainer, I recommended against it. We
> > should take the opportunity to engage with upstream to fully support
> > glibc instead.
>
> Can they support glibc without either taking on a huge maintenance burden
> or weakening the sandbox?

Whatever the community wants to support will be supported. That's how
open source projects work.

Previously it seemed like nobody was interested in Firecracker, so
nothing happened. If there's interest now, things will change.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Firecracker microVM manager

[Demi Marie Obenour]

On 4/24/23 08:33, Neal Gompa wrote:
> On Mon, Apr 24, 2023 at 4:19 AM Peter Robinson  wrote:
>>
 There is no problem technically; the Copr repo[2] is building
 Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
 to be against it in Fedora.  From this thread:
>>> Why does Fedora not want to ship Firecracker statically linked to musl?
>>> That is the supported and tested configuration upstream.  Using glibc
>>> or dynamic linking is not supported for production use.
>>
>> Because glibc is Fedora's supported libc implementation and supporting
>> two different implementations at the same time is complex
> 
> And importantly, as the musl maintainer, I recommended against it. We
> should take the opportunity to engage with upstream to fully support
> glibc instead.

Can they support glibc without either taking on a huge maintenance burden
or weakening the sandbox?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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

[Gabriel Ramirez via devel]

On 4/23/23 18:32, Kevin Fenzi wrote:

You can write the tag after the plus sign if that makes it easier to
implement. Instead of"fedoraproject+newto...@discoursemail.com"  the
address could be"fedoraproject+de...@discoursemail.com"  or maybe
"fedoraproject+devel/newto...@discoursemail.com". Or some other format.
The local-part can be structured any way the Discourse developers like,
as long as it's at most 64 bytes and adheres to the dot-atom-text syntax
in RFC 5322.

But that also doesn't solve the spam problem... anyone could send to
those addresses, and indeed spammers will. ;(


I have not used the forum mailing lists so I don't know if they already 
include the following: Perhaps in each email include the url 
corresponding to the forum post, so that if you want to answer it, you 
have to do it from the forum, so the mailing lists can be read-only 
Gabrielo

___
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: The new version of Fedora Messaging Notifications will arrive this week

[Justin W. Flory (he/him)]

Congratulations on the new release, and thanks team for the hard work on
modernizing FMN over the past several months.

On Mon, Apr 24, 2023 at 9:31 AM Aurelien Bompard 
wrote:

> Hi folks!
>
> The "FMN replacement" team has finished writing the new version of our
> notification system, and we are ready to deploy!
>
> We plan on:
> - deploying the new version on https://notifications.fedoraproject.org
> this week,
> - keep the old one around but move it to
> https://apps.fp.o/notifications-old
> - redirect from https://apps.fp.o/notifications to the new place.
> (fp.o being an abbreviation for fedoraproject.org)
>
> You will thus still be able to access the current FMN, and it will
> keep running until F39. Due to the difference in features, we can't
> import existing rules into the new system, so we encourage you to
> create new rules that suit you as soon as the new system is up and
> running.
>
> The change of URLs will happen with the planned outage set for
> 2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
>  for details.
>
> If you have issues with the new FMN, please open infra tickets at:
> https://pagure.io/fedora-infrastructure/new_issue
>
> We hope you will enjoy the simpler UI and faster processing speed that
> the new FMN brings.
>
> Cheers!
> Aurélien
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-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-annou...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
*jwf* (*he/him*) || 📧 j...@redhat.com
TZ=America/New_York (UTC-4) 🕗

While I may be sending this email outside my normal office hours, I have no
expectation to receive a reply outside yours.
___
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

Tuesday's FESCo Meeting *canceled* (2023-04-25)

[Major Hayden via devel]

There wasn't much in the FESCo queue this week, so April 25th's meeting is 
canceled.

However, issue 2981 could use more feedback for the FESCo election interview 
questions. If FESCo members could take a moment to look over the questions and 
reply on the ticket[0], that would be helpful!

I'll volunteer to chair the following week's meeting (May 2). 🪑

Just as a reminder if you need to put something on the agenda:

*
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
*

Best wishes to all of you this week.

[0] https://pagure.io/fesco/issue/2981

--
Major Hayden
___
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

[Kamil Paral]

On Thu, Apr 20, 2023 at 11:21 PM Matthew Miller 
wrote:

> I propose that we transition devel list, and eventually most of our
> mailing lists, to Fedora Discussion (our Discourse-powered forum).
>

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.

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.

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 imagine this
feeling might be similar to what younger people feel when they're asked to
use a mailing list. It would require too much investment from them, and so
they'll go somewhere else with a more comfortable barrier to entry.

With some things, there's a simple transition path, because new things are
both technically superior and more comfortable at the same time, and still
extremely similar. Svn -> git. Plain git -> git with pull requests. Irc ->
Matrix. But we don't really have the same equivalent with mailing lists. I
guess mailman3+hyperkitty was supposed to be that replacement, but as we
can see, it didn't work out. A discussion forum is very different, but it's
a workflow that people are familiar with and has much easier onboarding.
Mailing lists are a lost cause. They are being abandoned, nobody migrates
*to* mailing lists. If we want to keep new blood flowing in, we can't be
afraid to change stuff. We have to adapt, instead of requiring everyone
else to adapt to us.

I already have some experience with Discourse and so far it seemed OK to
me. 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.

Cheers,
Kamil
___
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: A new FMN will arrive this week

[Mattia Verga via devel]

Il 24/04/23 11:47, Aurelien Bompard ha scritto:
> Hi folks!
>
> The FMN replacement team has finished writing the new version of our
> notification system, and we are ready to deploy! We plan on deploying
> the new version on https://notifications.fedoraproject.org this week,
> we'll keep the old one around but move it to
> https://apps.fedoraproject.org/notifications-old, and redirect from
> https://apps.fedoraproject.org/notifications to the new place,
> notifications.fedoraproject.org.
>
> You will thus still be able to access the current FMN, and it will
> keep running until F39. Due to the difference in features, we can't
> import existing rules into the new system, so we encourage you to
> create new rules that suit you as soon as the new system is up and
> running.
>
> The change of URLs will happen with the planned outage set for
> 2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
>  for details.
>
> If you have issues with the new FMN, please open infra tickets at:
> https://pagure.io/fedora-infrastructure/new_issue
>
> We hope you will enjoy the simpler UI and faster processing speed that
> the new FMN brings.
>
> Cheers!
> Aurélien

Thank you, the new FMN is much cleaner and easier to use than the
previous version.

One thing it's not clear to me: are the rules processed sequentially
(first to match stop processing) or in parallel? I'd like to create two
rules, one for my packages and one for packages of a sig. Some of my
packages are also in that sig packages list. Will I receive double
notifications?

Mattia

___
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 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Mon, Apr 24, 2023 at 12:15:12PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> 
> The Fedora installer includes an EFI System Partition of between 200MB
> and 600MB by default, of which the lower size is much too small for
> firmware updates on modern hardware and also for future bootloader
> features like UKI.
> This change will increase the minimum size of the ESP to be 500MB,
> which is also the same value used by Microsoft for Windows 10 and
> newer.

This refers to the minimum size being changed, but later it mentions
the default size being changed. Are the default & minimum sizes
effectively the same in this case ?

nitpick - the github change linked is 512 MiB rather than 500 MB.

> == Owner ==
> * Name: [[User:rhughes| Richard Hughes]]
> * Email: rich...@hughsie.com
> 
> 
> == Detailed Description ==
> 
> Modern hardware has UEFI firmware updates that are more than 64MB in
> size. The OEMs recommend a ESP free space of double the flash size
> plus 20MB and fwupd now enforces this requirement to ensure flash
> success. As the ESP is often shared between Windows and Linux, and
> also used for firmware updates, and soon to be used by UKIs it's not
> enough to just allocate a few hundreds of megabytes. Windows 10 and 11
> allocates an ESP of at least 500MiB. Arch also specifies a minimum of
> 512 MiB.

My only thought is whether 512 MiB is sufficiently future proofed if we
start to make more use of UKIs, given that /boot by comparison is already
at 1 GiB by default IIUC ?

> == Feedback ==
> 
> There is no alternative -- the ESP has to scale up if we want firmware
> updates to continue to work and to support UKIs for next-generation
> bootloaders.
> 
> == Benefit to Fedora ==
> 
> Firmware updates will work on future hardware, and we can boot the
> kernel using UKIs using next-generation bootloaders.
> 
> == Scope ==
> * Proposal owners:
> 
> We need to change a number in Anaconda:
> https://github.com/rhinstaller/anaconda/pull/4711
> 
> == Upgrade/compatibility impact ==
> 
> We can't grow the ESP in size, and so this change will only affect new
> installs. This is fine, as this will affect new hardware more than old
> hardware.
> 
> == How To Test ==
> 
> Install Fedora and observe that /boot/efi has at least 276MB free
> space, even when installed alongside Windows.
> 
> == Dependencies ==
> 
> Anaconda would need to be modified, and Fedora would have a / or /home
> partition that's ~300MB smaller by default than it is now.

For any install which does end up using UKIs on the ESP, the /boot would
no longer need to be as large as it is today as it would not have kernel
images. In fact /boot could potentially not need to exist at all in any
EFI installs using UKIs.

IOW, the increased size for the ESP could potentially be won back by
permitting /boot to be smaller, or eliminating /boot. I'm not suggesting
this needs to be a pre-requisite of this change proposal though, just a
thought for the future. Could be something that is optimized in any cloud
image kickstarts that end up using UKIs.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

[Kevin Fenzi]

A few questions:

* Could we perhaps try and get upstream to adjust this higher?

* Is there any description/docs on what happens when this value is too
low? do games error in a particular way?

* Is there any adverse impact increasing this? More memory used?

Thanks for putting this together. 

kevin


signature.asc
Description: PGP signature
___
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: RFC: No koji builds during mass branching and updates-testing enablement

[Kevin Fenzi]

On Sun, Apr 23, 2023 at 07:28:08AM +, Mattia Verga via devel wrote:
> Isn't simpler to schedule:
> 
> 1. lock down Koji in  (stop accepting new builds,
> possibly only for Rawhide)
> 2. let Koji finish running builds (assuming there are none which
> requires more than 24h)
> 3. at  check any stuck Rawhide update in Bodhi
> 4. branch
> 5. unlock Koji
> 
> I think a 24h Koji outage is much clearer to users other than cancelling
> their builds and unpushing their updates. Unless releng wants to take
> note of those builds and updates and resubmit them after the mass
> branching...

well, 24hours is both too long and too short.

On one hand we have some things that take longer than 24h sometimes.
On the other we have a bunch of builds that only take a few minutes.

I'd hate for a important update that only takes a few minutes to build
to be delayed for 24hours. ;( 

I think we could perhaps look at resubmitting things.
That could be a bit complex with targets and such, but it might be
doable.

kevin


signature.asc
Description: PGP signature
___
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

F39 proposal: BiggerESP (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/BiggerESP

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

The Fedora installer includes an EFI System Partition of between 200MB
and 600MB by default, of which the lower size is much too small for
firmware updates on modern hardware and also for future bootloader
features like UKI.
This change will increase the minimum size of the ESP to be 500MB,
which is also the same value used by Microsoft for Windows 10 and
newer.

== Owner ==
* Name: [[User:rhughes| Richard Hughes]]
* Email: rich...@hughsie.com


== Detailed Description ==

Modern hardware has UEFI firmware updates that are more than 64MB in
size. The OEMs recommend a ESP free space of double the flash size
plus 20MB and fwupd now enforces this requirement to ensure flash
success. As the ESP is often shared between Windows and Linux, and
also used for firmware updates, and soon to be used by UKIs it's not
enough to just allocate a few hundreds of megabytes. Windows 10 and 11
allocates an ESP of at least 500MiB. Arch also specifies a minimum of
512 MiB.

== Feedback ==

There is no alternative -- the ESP has to scale up if we want firmware
updates to continue to work and to support UKIs for next-generation
bootloaders.

== Benefit to Fedora ==

Firmware updates will work on future hardware, and we can boot the
kernel using UKIs using next-generation bootloaders.

== Scope ==
* Proposal owners:

We need to change a number in Anaconda:
https://github.com/rhinstaller/anaconda/pull/4711

== Upgrade/compatibility impact ==

We can't grow the ESP in size, and so this change will only affect new
installs. This is fine, as this will affect new hardware more than old
hardware.

== How To Test ==

Install Fedora and observe that /boot/efi has at least 276MB free
space, even when installed alongside Windows.

== Dependencies ==

Anaconda would need to be modified, and Fedora would have a / or /home
partition that's ~300MB smaller by default than it is now.

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No

== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==

Fedora now defaults to a larger EFI System Partition which allows
firmware updates to work on newer hardware, and allows future
bootloader and kernel modernizations.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
This change aims at increasing the default value of the
`vm.max_map_count` sysctl

== Owner ==
* Name: [[User:aleasto| Alessandro Astone]]
* Email: ales.ast...@gmail.com


== Detailed Description ==
Increase the vm.max_map_count sysctl default value.

The goal is to improve compatibility with Windows games through wine
or steam. Read on "Benefit to Fedora" for examples.

Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up
from `65530` of Fedora; it makes sense to follow their lead and set
the same value.

== Feedback ==

This was briefly discussed in #fedora-devel and received positively.
Concerns over possible downsides were raised. I am not aware of any,
but more input here is desired.

== Benefit to Fedora ==
The following Windows games will work out of the box (through wine or steam):
* DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/
* Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510
* Counter Strike 2 (Beta Windows build):
https://www.youtube.com/watch?v=i02n_Ak98TA
* Any other software that might be invoking a lot of mmaps

== Scope ==
* Proposal owners: Add the new default to `/usr/lib/sysctl.d/`

* Other developers: No work will be necessary unless the new default
is found breaking some software

* Release engineering: N/A (not needed for this Change)

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==
Upgrading to the new Fedora release will seamlessly update the
default. No manual intervention is necessary.

== How To Test ==
Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642`

Run any of the software listed above to verify that it now works.

Or run any other software to verify the change causes no regression.


== User Experience ==
More Windows games will work out-of-the-box (through wine or steam)

== Dependencies ==
None


== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: Final Freeze
* Blocks release? No


== Documentation ==
The default value is currently hard-coded in the kernel, at
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203
.
It cannot be changed through the kernel defconfig, instead it must be
set through sysctl.

== Release Notes ==
The default value of the vm.max_map_count sysctl is increased


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora 38 Review in LUP #507

[Luna Jernberg]

https://linuxunplugged.com/507 Fedora 38 review of LUP from yesterday
uploaded now
___
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

[Stephen Smoogen]

On Mon, 24 Apr 2023 at 09:38, Simo Sorce  wrote:

> On Sat, 2023-04-22 at 12:16 -0700, Adam Williamson wrote:
> > On Sat, 2023-04-22 at 10:37 -0700, Kevin Fenzi wrote:
> > > On Fri, Apr 21, 2023 at 02:30:45PM -0700, Adam Williamson wrote:
> > > > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote:
> > > > >
> > > > > > For lists that are active, the split is confusing — when should
> > > > > > something be on the packaging list rather than devel? What
> happens when
> > > > > > something is related to both Cloud and Server, or Workstation
> and KDE?
> > > > > > One can post to both lists, but if someone replies and isn’t
> subscribed
> > > > > > to both, the conversation gets split.
> > > > >
> > > > > Do Fedora mailing lists reject mail from non-members, and redirect
> > > > > follow-ups?
> > > >
> > > > Many lists *hold* mail from non-members, because mailing lists get
> tons
> > > > of spam. So the mail won't get through until an admin approves it.
> That
> > > > might happen right away...or it might happen in two days, when the
> mail
> > > > is no longer relevant. We can't really just let all mails from non-
> > > > members through because...spam.
> > >
> > > Right. I don't think we have many (or possibly any) lists that still
> > > hold email from non-members. The flood of spam is just too high for
> that
> > > for the last N years. So, almost all our lists are set to reject non
> > > member posts. :(
> >
> > ah, I hadn't noticed that change :/ I could've sworn I still sometimes
> > get hold notices when I send meeting announcements to lists I'm not
> > subscribed to...
>
> In theory we could make it simpler by sending back a message that
> requires just a click to subscribe/authorize the email by a real user,
> if they intend to do so, on their first email to a mailing list.
> We could also allow posting to other mailing lists if the email address
> is subscribed to any other list.
>
>
We had this running for a bit where we would send back emails saying this
is held. 99% of the emails would then go sit in queue on bastion slowing
down regular deliveries. We are talking hundreds of emails a day on 'good'
days and tens of thousands on 'bad' days. Trying to deal with this is a
full time job that no one is paid (and my volunteer time is limited) to do.
Trying to fix in better ways is usually a massive project because you need
to think out the total email flow plan and needs. Email is no longer the
old 'set up a mail server and let it live'. It is 'why do we have 10,000
queued emails today?' 'why aren't redhat.com emails getting delivered
today?' 'oh look 2 new DNS features to 'deal' with SPAM', 'oh spamassassin
needs new setup and fixes', 'why is email stuck here?' 'why is X sending
email to google.com but we are getting errors from gandhi.net or
protonmail.com'.

The software which runs mailing lists is also much more complicated than it
was 20 years ago. You need to deal with backend databases, caching web
servers, internal search engines, message tooling, spam deletion, account
acceptance, etc. That takes constant learning and dedicated 'brain' space
for admins to keep it working.

In order to keep email working, it takes dedicated and hard work and
decisions to make it happen.

I realize this would require working on mailman and that is probably
> something we do not want to spend time on ...
>
> After all you have to subscribe to discourse as well to be able to post
> ... so there is no huge difference here.
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Ben Cotton]

On Sat, Apr 22, 2023 at 1:24 AM Benson Muite  wrote:
>
> Thanks, this is helpful. Can you make the scripts/programs you used for
> these available to allow for a more detailed analysis?

No, because I literally went to each page of the archives and copied
the numbers into a spreadsheet. If you want to do a more in-depth
analysis, you can download the mbox archive file.

On Sat, Apr 22, 2023 at 12:28 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Could we have the same graph for discourse (and Fedora telegram and Fedora
> matrix)? It'd be interesting to see what percentage of active communicating
> users are active on the mailing list.

I can't provide that, but someone could do that analysis. The hard
part would be mapping the email addresses to Fedora accounts,
especially as those may have changed over the years (and there are
theoretically people on this list who don't have a Fedora account at
all).

That speaks to some of the questions that come from the quick graphs I
did: how many mailing list threads are of the zero-engagement
announcement variety, versus active discussion? And what's the
distribution of threads for users? Do most people reply to one or two
threads and a handful reply to dozens?

--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

[Simo Sorce]

On Sat, 2023-04-22 at 12:16 -0700, Adam Williamson wrote:
> On Sat, 2023-04-22 at 10:37 -0700, Kevin Fenzi wrote:
> > On Fri, Apr 21, 2023 at 02:30:45PM -0700, Adam Williamson wrote:
> > > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote:
> > > > 
> > > > > For lists that are active, the split is confusing — when should
> > > > > something be on the packaging list rather than devel? What happens 
> > > > > when
> > > > > something is related to both Cloud and Server, or Workstation and KDE?
> > > > > One can post to both lists, but if someone replies and isn’t 
> > > > > subscribed
> > > > > to both, the conversation gets split.
> > > > 
> > > > Do Fedora mailing lists reject mail from non-members, and redirect
> > > > follow-ups?
> > > 
> > > Many lists *hold* mail from non-members, because mailing lists get tons
> > > of spam. So the mail won't get through until an admin approves it. That
> > > might happen right away...or it might happen in two days, when the mail
> > > is no longer relevant. We can't really just let all mails from non-
> > > members through because...spam.
> > 
> > Right. I don't think we have many (or possibly any) lists that still
> > hold email from non-members. The flood of spam is just too high for that
> > for the last N years. So, almost all our lists are set to reject non
> > member posts. :(
> 
> ah, I hadn't noticed that change :/ I could've sworn I still sometimes
> get hold notices when I send meeting announcements to lists I'm not
> subscribed to...

In theory we could make it simpler by sending back a message that
requires just a click to subscribe/authorize the email by a real user,
if they intend to do so, on their first email to a mailing list.
We could also allow posting to other mailing lists if the email address
is subscribed to any other list.

I realize this would require working on mailman and that is probably
something we do not want to spend time on ...

After all you have to subscribe to discourse as well to be able to post
... so there is no huge difference here.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
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

The new version of Fedora Messaging Notifications will arrive this week

[Aurelien Bompard]

Hi folks!

The "FMN replacement" team has finished writing the new version of our
notification system, and we are ready to deploy!

We plan on:
- deploying the new version on https://notifications.fedoraproject.org
this week,
- keep the old one around but move it to https://apps.fp.o/notifications-old
- redirect from https://apps.fp.o/notifications to the new place.
(fp.o being an abbreviation for fedoraproject.org)

You will thus still be able to access the current FMN, and it will
keep running until F39. Due to the difference in features, we can't
import existing rules into the new system, so we encourage you to
create new rules that suit you as soon as the new system is up and
running.

The change of URLs will happen with the planned outage set for
2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
 for details.

If you have issues with the new FMN, please open infra tickets at:
https://pagure.io/fedora-infrastructure/new_issue

We hope you will enjoy the simpler UI and faster processing speed that
the new FMN brings.

Cheers!
Aurélien
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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

[Simo Sorce]

On Fri, 2023-04-21 at 15:39 -0500, Carl George wrote:
> As Matthew stated, Ben has measured it and fewer people are
> participating on the mailing list over time.  We are already leaving
> out many contributors.

This is an interpretation, but are we sure we are missing them because
the mailing list is uninviting, and not just because the pool of
interested people is shrinking?


>   Those conversations are largely moving to
> issue trackers, which are also not perfect but are clearly more
> appealing than email for many people.

Issue trackers are a pretty good way to deal with issues, we should
have a better issue tracker that makes those conversations better, not
discourage them to make everything flow in non-descript mailing lists
or forums...

>   Discourse has the potential to
> be a more attractive alternative than both email and issue trackers.

And less attractive to people that work better with mailing lists and
issue trackers...

> To me this seems like a solid strategy for reversing the trend and
> getting more people participating in development discussions.

I really dislike this fixation on numbers. We need higher quality and
we need to discuss what is really needed. Numbers shouldn't be priority
number one, unless there are other underlying issues.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
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: Firecracker microVM manager

[Neal Gompa]

On Mon, Apr 24, 2023 at 4:19 AM Peter Robinson  wrote:
>
> > > There is no problem technically; the Copr repo[2] is building
> > > Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
> > > to be against it in Fedora.  From this thread:
> > Why does Fedora not want to ship Firecracker statically linked to musl?
> > That is the supported and tested configuration upstream.  Using glibc
> > or dynamic linking is not supported for production use.
>
> Because glibc is Fedora's supported libc implementation and supporting
> two different implementations at the same time is complex

And importantly, as the musl maintainer, I recommended against it. We
should take the opportunity to engage with upstream to fully support
glibc instead.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Fedora rawhide compose report: 20230424.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230423.n.0
NEW: Fedora-Rawhide-20230424.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  3
Dropped packages:0
Upgraded packages:   32
Downgraded packages: 0

Size of added packages:  183.38 KiB
Size of dropped packages:0 B
Size of upgraded packages:   387.77 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   17.15 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server_KVM qcow2 aarch64
Path: Server/aarch64/images/Fedora-Server-KVM-Rawhide-20230424.n.0.aarch64.qcow2

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-robfig-cron-3.0.1-3.fc37
Summary: A cron library for go
RPMs:golang-github-robfig-cron-devel
Size:37.43 KiB

Package: rust-pep440_rs-0.3.5-1.fc39
Summary: Library for python version numbers and specifiers, implementing PEP 440
RPMs:rust-pep440_rs+default-devel rust-pep440_rs+pyo3-devel 
rust-pep440_rs+serde-devel rust-pep440_rs-devel
Size:52.34 KiB

Package: rust-pep508_rs-0.1.5-1.fc39
Summary: Library for python dependency specifiers, better known as PEP 508
RPMs:rust-pep508_rs+anyhow-devel rust-pep508_rs+default-devel 
rust-pep508_rs+modern-devel rust-pep508_rs+pyo3-devel 
rust-pep508_rs+pyo3-log-devel rust-pep508_rs+serde-devel 
rust-pep508_rs+serde_json-devel rust-pep508_rs+toml-devel rust-pep508_rs-devel
Size:93.60 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  accel-config-4.0-1.fc39
Old package:  accel-config-3.5.3-1.fc39
Summary:  Configure accelerator subsystem devices
RPMs: accel-config accel-config-devel accel-config-libs
Size: 294.93 KiB
Size change:  -6.69 KiB
Changelog:
  * Sun Apr 23 2023 Jun Miao  - 4.0-1
  - Update to v4.0 release


Package:  bird-2.13-1.fc39
Old package:  bird-2.0.12-1.fc38
Summary:  BIRD Internet Routing Daemon
RPMs: bird bird-doc
Size: 2.92 MiB
Size change:  6.43 KiB
Changelog:
  * Sun Apr 23 2023 Robert Scheck  - 2.13-1
  - Upgrade to 2.13 (#2188938)


Package:  blender-1:3.5.0-3.fc39
Old package:  blender-1:3.5.0-2.fc39
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 199.33 MiB
Size change:  14.60 MiB
Changelog:
  * Sun Apr 23 2023 Luya Tshimbalanga  - 1:3.5.0-3
  - Include missing addon unbundled by upsteam


Package:  budgie-desktop-10.7.1-3.fc39
Old package:  budgie-desktop-10.7.1-2.fc39
Summary:  A feature-rich, modern desktop designed to keep out the way of 
the user
RPMs: budgie-desktop budgie-desktop-devel budgie-desktop-docs
Size: 12.90 MiB
Size change:  -984 B
Changelog:
  * Sun Apr 23 2023 Joshua Strobl  - 10.7.1-3
  - Backport fixes for mutter and zenity


Package:  dunst-1.9.2-1.fc39
Old package:  dunst-1.9.1-1.fc39
Summary:  Lightweight and customizable notification-daemon
RPMs: dunst
Size: 526.14 KiB
Size change:  1.62 KiB
Changelog:
  * Sun Apr 23 2023 Aleksei Bavshin  - 1.9.2-1
  - Update to 1.9.2


Package:  fcitx-libpinyin-0.5.4-7.fc39
Old package:  fcitx-libpinyin-0.5.4-6.fc38
Summary:  Libpinyin Wrapper for Fcitx
RPMs: fcitx-libpinyin
Size: 23.28 MiB
Size change:  -64.12 KiB
Changelog:
  * Mon Apr 24 2023 Peng Wu  - 0.5.4-7
  - Migrate to SPDX license


Package:  g3kb-switch-1.2-1.fc39
Old package:  g3kb-switch-1.1-1.fc39
Summary:  CLI keyboard layout switcher for GNOME Shell
RPMs: g3kb-switch g3kb-switch-bash-completion g3kb-switch-devel 
g3kb-switch-zsh-completion
Added RPMs:   g3kb-switch-devel
Size: 200.64 KiB
Size change:  73.21 KiB
Changelog:
  * Sun Apr 23 2023 Pavel Solovev  - 1.2-1
  - version 1.2 (rhbz#2188905)


Package:  glslang-11.9.0-14.fc39
Old package:  glslang-11.9.0-12.fc38
Summary:  OpenGL and OpenGL ES shader front end and validator
RPMs: glslang glslang-devel
Size: 13.23 MiB
Size change:  61.82 KiB
Changelog:
  * Sun Apr 23 2023 Dave Airlie  - 11.9.0-13
  - update to 1.3.243.0 sdk

  * Mon Apr 24 2023 Dave Airlie  - 11.9.0-14
  - update to 1.3.243.0 sdk


Package:  gnome-shell-extension-ibus-font-0.20210510-6.fc39
Old package:  gnome-shell-extension-ibus-font-0.20210510-5.fc38
Summary:  A GNOME Shell extension for ibus-setup custom font settings
RPMs: gnome-shell-extension-ibus-font
Size: 16.22 KiB
Size change:  -104 B
Changelog:
  * Mon Apr 24 2023 Peng Wu  - 0.20210510-6
  - Migrate to SPDX license


Package:  mstflint-4.23.0-4.fc39
Old package:  mstflint-4.23.0-3.fc38
Summary:  Mellanox firmware burning tool
RPMs: mstflint
Size: 8.89 MiB
Size change:  -6.43 KiB
Changelog:
  * Sun Apr 23 2023 Florian Weimer  - 4.23.0-4
  - Port to C99


Package:  nginx-mod-modsecurity-1.0.3-3.fc39
Old package:  nginx-mod-modsecurity-1.0.3-2.fc39
Summary:  ModSecurity v3 nginx connector
RPMs: nginx-mod-modsecurity
Size

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

[Jun Aruga (he / him)]

In my opinion, in this kind of big change, it's important for us to
make things reversible, and to consider a possibility for us to go
back.

I think it's better for us to keep the infra of the mailing list for a
while. When we migrate the devel@ to the discourse, we should still
keep to manage other mailing lists without migrating to the discourse.
It's risky to migrate every mailing list at the same time or in a
short period.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

[Vít Ondruch]

Dne 24. 04. 23 v 2:32 Kevin Fenzi napsal(a):

On Sun, Apr 23, 2023 at 11:21:58PM +0200, Björn Persson wrote:

Kevin Fenzi wrote:

We could probibly come up with some
better way to start new topics/discussions

Yes I think I can come up with a better way. Give each tag its own
email address, like a mailing list. That was very easy to come up with.

I think you mean each category? But you may want multiple tags on a
post...



You could send it to multiple email addresses, right?

Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
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: SPDX Statistics - ZX Spectrum edition

[Miroslav Suchý]

Dne 24. 04. 23 v 12:10 Felix Schwarz napsal(a):

I have updated some of my packages, but they're still listed there. I've
used "Update license tag to SPDX" in the changelog.


similar for me.

For example take python-pydyf:
https://src.fedoraproject.org/rpms/python-pydyf/commits/rawhide


After git-push it is gone now in the updated stats. Sorry.

Miroslav
___
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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 24 April (today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 24th April
at 1300UTC in #fedora-neuro on Matrix or IRC
(Libera.chat).  The meeting is a public meeting, and open for everyone
to attend. You can join us over:

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

You can use this link to see the local time for the meeting:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20230424T13&p1=%3A&ah=1

or you can use this command in a terminal:
$ date --date='TZ="UTC" 1300 Monday'

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Package health check: 
https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F38: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:
https://neuroblog.fedoraproject.org/2023/04/24/next-open-neurofedora-meeting-24-April-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
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: SPDX Statistics - ZX Spectrum edition

[Miroslav Suchý]

Dne 23. 04. 23 v 11:59 Mattia Verga via devel napsal(a):

I have updated some of my packages, but they're still listed there. I've
used "Update license tag to SPDX" in the changelog.


Ag! I forgot to git-push. Fixed.  Sorry.

Miroslav
___
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: SPDX Statistics - ZX Spectrum edition

[Felix Schwarz]

Am 23.04.23 um 11:59 schrieb Mattia Verga via devel:

I have updated some of my packages, but they're still listed there. I've
used "Update license tag to SPDX" in the changelog.


similar for me.

For example take python-pydyf:
https://src.fedoraproject.org/rpms/python-pydyf/commits/rawhide

Should I use a different license tag?

Felix
___
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

A new FMN will arrive this week

[Aurelien Bompard]

Hi folks!

The FMN replacement team has finished writing the new version of our
notification system, and we are ready to deploy! We plan on deploying
the new version on https://notifications.fedoraproject.org this week,
we'll keep the old one around but move it to
https://apps.fedoraproject.org/notifications-old, and redirect from
https://apps.fedoraproject.org/notifications to the new place,
notifications.fedoraproject.org.

You will thus still be able to access the current FMN, and it will
keep running until F39. Due to the difference in features, we can't
import existing rules into the new system, so we encourage you to
create new rules that suit you as soon as the new system is up and
running.

The change of URLs will happen with the planned outage set for
2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
 for details.

If you have issues with the new FMN, please open infra tickets at:
https://pagure.io/fedora-infrastructure/new_issue

We hope you will enjoy the simpler UI and faster processing speed that
the new FMN brings.

Cheers!
Aurélien
___
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: SPDX Statistics - ZX Spectrum edition

[Miroslav Suchý]

Dne 23. 04. 23 v 13:29 Richard Shaw napsal(a):



NEW: the package fedora-license-data now contains BNF grammar which you can 
use. It is available in
`/usr/share/fedora-license-data/grammar.lark`


You'll have to explain to me the significance of this.


This is good starting point:

https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

The BNF is one of the basic grammar used in formal automata. It is the data part of any formal validation or compiler. 
The validation is most relevant in this case.


There is lot of libraries that load the grammar and validate or tranform the 
input.

I wrote this grammar for Lark library. The validation is then just two-liner

You can see it used e.g., here

https://pagure.io/copr/license-validate/blob/main/f/license-validate.py#_31

Miroslav

___
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: Self Introduction: Herald Yu

[Benson Muite]

On 4/24/23 09:42, Herald Yu wrote:
> Hello everyone, I am Herald come from Shanghai, China. It's nice to meet you 
> in Fedora Devel Community.
> 
> I am a Tech Writer who is passionate about open-source technology. I have 
> contributed to JuiceFS and I am willing to package and maintain this software 
> package. I hope to join the Fedora developer community, learn from everyone, 
> and contribute to the development of the Fedora ecosystem.
> 
> If you would like to know more information about me, I am willing to further 
> introduce myself to everyone.

Welcome to Fedora and thanks for contributing to packaging. We hope you
like it here and look forward to also learning from you.
___
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: Firecracker microVM manager

[Peter Robinson]

> > There is no problem technically; the Copr repo[2] is building
> > Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
> > to be against it in Fedora.  From this thread:
> Why does Fedora not want to ship Firecracker statically linked to musl?
> That is the supported and tested configuration upstream.  Using glibc
> or dynamic linking is not supported for production use.

Because glibc is Fedora's supported libc implementation and supporting
two different implementations at the same time is complex
___
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