[Test-Announce] [Now Playing] Intel Open CL Test Day

[Sumantro Mukherjee]

Hey All,

We're hosting an Intel OpenCL Test Day[0] and we need your expertise!
Join us on 2024-04-09 to put Intel's OpenCL through its paces. Your
feedback will be invaluable in shaping the future of this technology.
Together, let's push the boundaries of performance and innovation.

Intel's OpenCL (Open Computing Language) is a powerful framework for
parallel computing across CPUs, GPUs, and FPGAs. It enables developers
to harness the full potential of Intel's hardware, optimizing
performance for a wide range of applications from AI and machine
learning to high-performance computing. By participating in our test
day, you'll gain hands-on experience and contribute directly to the
enhancement of Intel's OpenCL platform for Fedora 40.

[0] http://fedoraproject.org/wiki/Test_Day:2024-04-09_Intel_Open_CL



--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

Help Needed for a tricky bug for Fedora Linux 40

[Aoife Moloney]

Hi folks,

There is a bug in the Fedora Blocker Bugs
 app
that has a lot of us stumped on how to resolve it, so I wanted to highlight
it in the hopes that someone might know how to either fix it or maybe even
verify if a few of the ideas that have been suggested would work or not.

The bug in question is #2242759
 and a brief summary
of the problem is this:
Using dnf system-upgrade log --number=-1, an entry like "Signature 10d5
created at Wed Sep 27 16:33:34 2023 invalid: signature is not alive" is
generated for each rpm in the upgrade list.
Raspberry Pi 4 does not have a hardware real time clock so when the Pi is
booting Fedora system time is at some (arbitrary?) date and time. During a
normal boot chronyd is executed and will set the clock: "chronyd[571]:
System clock wrong by 944623.935135 seconds". If the gpg key used by DNF
during the system-upgrade has a valid period more recent than the boot
time, system-upgrade will fail.


A few suggestions* that have been made in the bug to either work around it
or resolve it are:

disable chronyd.service and enable systemd-timesyncd.service.

tell users to 'sudo touch /usr/lib/clock-epoch'

rebuild systemd in F38 (this is probably for F39 now as this bug and
its comments are a few months old)

Stop checking signature time on packages.

Make sure that the time before the upgrade is set properly by using
systemd-timesyncd, or by some other mechanism


*These suggestions are pulled directly from comments in the bug and may
appear out of context in this email as this is meant to raise awareness of
the problem, and hopefully find folks who can help. Please read the
bugzilla for more in-depth detail of solutions offered, testing and log
outputs from other users.


This bug has rolled over since Fedora Linux 39 and it would be great to see
it get resolved before Fedora Linux 40 is released, so if you have some
knowledge in this area and/or have some time to weigh in on one of the
possible workarounds listed above and in the bug, or could even provide a
better workaround or fix, that would be highly appreciated!

And also a big thank you too to all the folks who have been working on this
bug trying to fix it the last few months.


Please comment on the bug or feel free to reach out to me, or better again
to Fedora QA in the #quality:fedoraproject.org chat room on matrix.


Kindest regards and many thanks,
Aoife




-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
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: convert everything to rpmautospec?

[Neal Gompa]

On Mon, Apr 8, 2024 at 5:22 PM Leon Fauster via devel
 wrote:
>
> Am 08.04.24 um 22:22 schrieb Michel Lind:
> > On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:
> >> Am 08.04.24 um 20:12 schrieb Michel Lind:
> >>> (this might require coordination with RH's Leapp developers and
> >>> AlmaLinux's ELevate developers, to make sure those support upgrading
> >>> to lower NEVRAs too)
> >>
> >> Would have a major EL release have a lower package NEVRA?
> >> Mmmh, how many fedora releases are in between? :-)
> >>
> > If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
> > allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
> > Fedora 40 package with epoch reset to 0 (change as suitable - more
> > likely to be EL10 from F40 and EL11 from F46, but in general there are 6
> > Fedora releases in between) -- then even if the version is higher
> > because the epoch is dropped, the EL(N+1) NEVRA will be lower.
>
>
> Fair enough. Such change could be scoped just for fedora and keeping
> the epoch for RHEL (I know it contradicts the plan). Anyway, as far as
> I understand it, epoch support will still be available and its not
> forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4
> downgrades even necessary. Just wondering, why a reset of epoch in
> rawhide is desirable?
>

When the RHEL people notice, they conditionally drop the Epoch for
RHEL already. Epochs are not really necessary at all across
distribution release boundaries.



-- 
真実はいつも一つ！/ 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

[Test-Announce] Fedora Linux 40 Go/No-Go Meeting: 2024-11-04

[Aoife Moloney]

Happy Monday folks!

On Thursday 11th April, the Fedora Linux 40 Final Go/No-Go meeting[1] will
be held at 1700 UTC in #meeting:fedoraproject.org channel on Matrix.

At this time, we will determine the status of the F40 Final release for the
16th April, which is the early target date[2]. For more information about
the Go/No-Go meeting, see the wiki[3].


[1] https://calendar.fedoraproject.org/meeting/10787/
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting


-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 22:22 schrieb Michel Lind:

On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:

Am 08.04.24 um 20:12 schrieb Michel Lind:

(this might require coordination with RH's Leapp developers and
AlmaLinux's ELevate developers, to make sure those support upgrading
to lower NEVRAs too)


Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases are in between? :-)


If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
Fedora 40 package with epoch reset to 0 (change as suitable - more
likely to be EL10 from F40 and EL11 from F46, but in general there are 6
Fedora releases in between) -- then even if the version is higher
because the epoch is dropped, the EL(N+1) NEVRA will be lower.



Fair enough. Such change could be scoped just for fedora and keeping
the epoch for RHEL (I know it contradicts the plan). Anyway, as far as
I understand it, epoch support will still be available and its not
forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4 
downgrades even necessary. Just wondering, why a reset of epoch in 
rawhide is desirable?


--
Leon







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

Summary/Minutes from today's FESCo Meeting (2024-04-08)

[Zbigniew Jędrzejewski-Szmek]

Text Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.html


Meeting summary
---
* TOPIC: Init Process (@nirik:matrix.scrye.com, 19:30:15)
* TOPIC: #3183 Change: PHP No 32-bit (@nirik:matrix.scrye.com, 19:34:05)
* AGREED: Change was approved in ticket (+3, 0, -0) 
(@nirik:matrix.scrye.com, 19:51:47)
* TOPIC: #3191 Change: Switch to DNF5 (@nirik:matrix.scrye.com, 19:52:21)
* AGREED: APPROVED (+5, 2, 0) (@zbyszek:fedora.im, 20:22:48)
* TOPIC: Next week's chair (@zbyszek:fedora.im, 20:26:07)
* ACTION: Tom Stellard will chair the next meeting. (@zbyszek:fedora.im, 
20:27:40)
* TOPIC: Open Floor (@zbyszek:fedora.im, 20:27:54)
* AGREED: The time of the meeting is moved half hour earlier, to 19:00 UTC 
(+6, 0, 0) (@zbyszek:fedora.im, 20:41:28)
  

Meeting ended at 2024-04-08 20:42:15

Action items

* Tom Stellard will chair the next meeting. 
--
___
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: convert everything to rpmautospec?

[Michel Lind]

On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:
> Am 08.04.24 um 20:12 schrieb Michel Lind:
> >(this might require coordination with RH's Leapp developers and
> >AlmaLinux's ELevate developers, to make sure those support upgrading
> >to lower NEVRAs too)
> 
> Would have a major EL release have a lower package NEVRA?
> Mmmh, how many fedora releases are in between? :-)
> 
If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
Fedora 40 package with epoch reset to 0 (change as suitable - more
likely to be EL10 from F40 and EL11 from F46, but in general there are 6
Fedora releases in between) -- then even if the version is higher
because the epoch is dropped, the EL(N+1) NEVRA will be lower.

Cheers,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Three steps we could take to make supply chain attacks a bit harder

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> So… this is what I'm talking about: there is no obvious way to
> figure out what to set. Looking at the logs and trying to figure out
> some variables from that is not very attractive.

The comments at the top of the relevant Find*.cmake module are the best 
source for which variables you are supposed to set directly.

But there is also cmake-gui that can show you all the available options in a 
pretty Qt GUI.

> Nevertheless, for me, CMake and autotools are outdated technologies
> that shouldn't be used in new projects.

And for me, Meson is just a poor Not Invented Here imitation of CMake, with 
fewer features and in a slower programming language. :-)

And the kind of automagic you complain about is something all 3 major build 
systems do (and plenty of obscure ones, too). Maybe not for the specific 
case of the Python executable, but there are plenty of other cases where 
autotools and Meson also do automagic, which is why building outside of a 
chroot is such a bad idea.

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: convert everything to rpmautospec?

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> And sorry, but saying to "process pull requests quickly" is just naive.
> Busy packages often have many different pull requests concurrently, and
> some of them need discussion and fixes and work in other places before
> they can be merged.

Generally, there should be no room for discussion there. Either the pull 
request is good, then merge it immediately, or it is not, then reject it 
immediately. People who want to contribute to Fedora packaging ought to know 
what they are doing, if not, just reject and let them submit a new pull 
request when they have done their homework.

> I guess we'll just have to agree to disagree. In the other part of the
> thread, a proposal that was floated to allow opt-out. I hope that's
> acceptable.

You have received a lot of all-negative feedback and one single message of 
support. So for me there is a clear consensus to NOT implement your proposal 
at all, not even with an opt-out option.

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 Monday's FESCo Meeting (2024-04-08)

[Kevin Fenzi]

On Mon, Apr 08, 2024 at 06:19:31PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote:
> > = Discussed and Voted in the Ticket =
> > 
> > Change: GNU Toolchain F41
> > https://pagure.io/fesco/issue/3181
> > APPROVED (+6, 3, -0)
> 
> Not that it matters for anything, but it's actually (+6, 0, 0),
> i.e. there were no abstaining votes. (I was surprised by the three,
> so I went to check the ticket.)

Sorry, my brain somehow decided that was 'didn't vote' instead of
'actually abstained'.

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: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 20:12 schrieb Michel Lind:

   (this might require coordination with RH's Leapp developers and
   AlmaLinux's ELevate developers, to make sure those support upgrading
   to lower NEVRAs too)


Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases are in between? :-)

--
Leon
--
___
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 Monday's FESCo Meeting (2024-04-08)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote:
> = Discussed and Voted in the Ticket =
> 
> Change: GNU Toolchain F41
> https://pagure.io/fesco/issue/3181
> APPROVED (+6, 3, -0)

Not that it matters for anything, but it's actually (+6, 0, 0),
i.e. there were no abstaining votes. (I was surprised by the three,
so I went to check the ticket.)

Zbyszek
--
___
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: convert everything to rpmautospec?

[Michel Lind]

On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote:
> On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar  wrote:
> > It's bascially the same problem as Fedora has when users upgrade from 
> > Fredora
> > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade 
> > path
> > between Fedoras is not maintained anymore and users need to do "dnf
> > distro-sync" to ignore the RPM versioning.
> >
> > All that stems from tha fact that a number of commits between parallelly
> > supported braches is not monotonic.
> >
> 
> We did this long before rpmautospec existed. We switched to this
> behavior in Fedora 23 because we have never fully maintained "upgrade
> paths" across releases.
> 

Per private message with Neal this seems to be the Change that brought
it about:

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

I'm ... a bit surprised that we don't seem to have any documentation
stating explicitly that the assumption that NEVRAs in a newer release
are no longer assumed to be monotonically higher.

e.g. packaging guidelines still say "Rawhide is allowed to lag
*temporarily*" (emphasis mine)

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily

I suppose the user facing documentation does say that upgrading using
only DNF is not tested -- but there's no guideline about loosening
monotonicity provided to packagers as far as I can tell.

https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf

So, questions:

- should we update the packaging docs? Does this need to be a new Change
  Proposal or does this just need to go through the Fedora packaging
  committee? (Those involved in the Change like zbyszek can probably
  advise here)

- should we extend this further and say, if we no longer assume NEVRAs
  are monotonically increasing in a new release, we should allow
  packagers to use this opportunity to drop epochs in Rawhide? (likely
  with proper announcement beforehand in devel@)

  (this might require coordination with RH's Leapp developers and
  AlmaLinux's ELevate developers, to make sure those support upgrading
  to lower NEVRAs too)

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: convert everything to rpmautospec?

[Kilian Hanich via devel]

Am 08.04.24 um 14:55 schrieb Emmanuel Seyman:

Well, you and Kevin see "salami tactics" (whatever that may be),

FTR, I have no idea what "salami tactics" is.


Since apperently multiple people don't know the term:

https://en.wikipedia.org/wiki/Salami_slicing_tactics


Regards

Kilian
--
___
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: convert everything to rpmautospec?

[Michael J Gruber]

Zbigniew Jędrzejewski-Szmek venit, vidit, dixit 2024-04-07 17:15:16:
> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

An interesting proposal with unsurprising reactions from the expected
people ;)

Can I add +200 if others add -100, and what does that even mean? Kidding
aside, and putting the obvious "Makes my workflow work", "Destroys my
workflow", "Change? Hell no" aside, too, I think it's worthwhile to
take a step back and widen one's view towards the question:

Do we consider dist-git to be a version control system (vcs) for spec
files?

Historically we have not quite, which is no wonder given the cvs
heritage.  But, assuming for a moment that we do mean version control
seriously and look at the status quo ante rpmautospec ("legacy specs")
and what we do there:

- We put the version ("release" in our terms) of the spec file in the
  version controlled spec file.
- We put the log of the changes in the version controlled files.

How absurd!

Really, from the point of view of version control, anything that takes
this version information out of the versioned spec is better than legacy
specs. rpmautospec is the only such thing which we have right now.

On the practical side, I was sceptical about some shortcomings of
rpmautospec in the beginning, but it's really such a time (and nerve)
saver whenever you need to pick changes - be it from merge requests
against a moved head, from your own feature branches in dist-git forks
where you prepare changes, etc. All information is where it belongs
(change+log), and there are no artificial conflicts (release,
changelog) and no bogus dates.

Also, I find that many packages treat the dist-git log as more or less
worthless nuisance. rpmautospec helps you put both packager and user
info in one place (the commit message) and encourages to care about
both. Since some may not know:
```
Rebase to upstream x.y.z

- shiny new feature S
- various bug fixes

Also, we clean-up the spec file (white space, patch macros).
```
is a commit message which has both user info ("changelog", the first
line/header plus the dashed lines) and the info for other packagers -
how neat is that? You want it, too, admit it :)

We have other "vcs short-comings", of course, such as the fact that we
don't really use merges and feature branches in dist-git. Almost
consequently, rpmautospec does not deal well with merges. It does work
well with cherry-picks, though.

Since it's been mentioned: While (fast forward) merging the ubiquitious
"rebuild for..." commits down to lower releases does not do any "harm",
having a message like "rebuild for bar 24.7" in a release branch where
"bar" is at "23.3" is quite misleading. It's rooted in "cvs think" and
not using feature branches properly. rpmautospec can solves this easily
with cherry-picks now and, possibly, with merges later once it supports
merges better and we accept a true branch model in dist-git ;)

Cheers
Michael
--
___
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

Orphaning some Java packages

[Severin Gehwolf]

Hi,

I'm orphaning a couple of packages of mine which I no longer use or
were used as a dependency of a package I've maintained before and am no
longer using:

Packages without co-maintainers:

jolokia-jvm-agent
prometheus-simpleclient-java
prometheus-jmx-exporter

Packages with co-maintainers:

cglib
snakeyaml

Feel free to take on any of those packages if you're interested.

Thanks,
Severin
--
___
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: convert everything to rpmautospec?

[Carlos Rodriguez-Fernandez]

Thank you Zbigniew and Miro for the link.

On 4/8/24 02:18, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote:

On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote:

Not all commits correspond with a new release downstream, and not all
commit messages are relevant to the end user to be part of the change
log. For example, commits related with increasing gating test coverage
efforts, or setting up gating.yaml itself. Another example is linting
setting and/or configurations. How is that handled with autochangelog?
Can we tell it to skip certain commits? Or should we include it all?


Yes, you can skip %changelog for some commits with '[skip changelog]'
and provide additional content in the commit message which is not part
of the changelog. See
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

Zbyszek




On 4/7/24 23:01, Miro Hrončok wrote:
> On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
>>
>> Not all commits correspond with a new release downstream, and not all
>> commit messages are relevant to the end user to be part of the change
>> log. For example, commits related with increasing gating test coverage
>> efforts, or setting up gating.yaml itself. Another example is linting
>> setting and/or configurations. How is that handled with autochangelog?
>> Can we tell it to skip certain commits? Or should we include it all?
>
> Put [skip changelog] in the commit message.
>
> 
https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries

>



OpenPGP_signature.asc
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

Fedora 40 compose report: 20240408.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240407.n.0
NEW: Fedora-40-20240408.n.0

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

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   124.04 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Sway live x86_64
Path: Spins/x86_64/iso/Fedora-Sway-Live-x86_64-40-20240408.n.0.iso

= DROPPED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-40-20240407.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  khelpcenter-1:24.02.1-2.fc40
Old package:  khelpcenter-1:24.02.1-1.fc40
Summary:  Show documentation for KDE applications
RPMs: khelpcenter
Size: 7.51 MiB
Size change:  131 B
Changelog:
  * Sat Apr 06 2024 Marc Deop i Argem??  - 6.0.3-2
  - Backport fix to open subpages


Package:  qt6-qtdeclarative-6.6.2-3.fc40
Old package:  qt6-qtdeclarative-6.6.2-1.fc40
Summary:  Qt6 - QtDeclarative component
RPMs: qt6-qtdeclarative qt6-qtdeclarative-devel 
qt6-qtdeclarative-examples qt6-qtdeclarative-static
Size: 116.51 MiB
Size change:  12.87 MiB
Changelog:
  * Mon Feb 19 2024 Jan Grulich  - 6.6.2-2
  - Examples: also install source files

  * Tue Apr 02 2024 Jan Grulich  - 6.6.2-3
  - Backport Qt patches for crashes


Package:  sdubby-1.0-8.fc40
Old package:  sdubby-1.0-7.fc40
Summary:  Set of systemd-boot shims that don't fit anywhere else in the 
distro
RPMs: sdubby
Size: 18.39 KiB
Size change:  455 B
Changelog:
  * Tue Mar 26 2024 Jeremy Linton  - 1.0-8
  - Add default kernel compatibility flag and install.conf file to force 
kernel-install to do the right thing, work around BZ 2271674



= DOWNGRADED PACKAGES =--
___
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: convert everything to rpmautospec?

[Gary Buhrmaster]

On Mon, Apr 8, 2024 at 2:26 PM Tom Hughes via devel
 wrote:
>
> On 08/04/2024 14:47, Fabio Valentini wrote:
>
> > It is already supposed to be default / preferred since this Fedora 38 
> > Change:
> > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
>
> I find that quite interesting because while I may have read it at
> the time I had certainly long since forgotten that.

I read it at the time, and it was promised (at the time)
that rpmautospec would be a recommendation, and
not a requirement.  I would have strongly objected to
a MUST.

That rpmautospec works fine for some is great
(for them).  And it can be a good default for many
(if someone asked me how to package something
new, I would suggest they consider rpmautospec).
However, as long as it does not work 100% of the
time in 100% of the use cases (and by it's nature,
it can't) means that it should never (can never)
move forward to a MUST.
--
___
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: convert everything to rpmautospec?

[Tom Hughes via devel]

On 08/04/2024 14:47, Fabio Valentini wrote:


It is already supposed to be default / preferred since this Fedora 38 Change:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default


I find that quite interesting because while I may have read it at
the time I had certainly long since forgotten that.

The problem I think what that change is that it's essentially about
changing policy and getting all packagers to move to a new way of
doing things but at a practical level all it did was update some
documentation - nothing it in actual provides for outreach or bringing
the change to the attention of packagers in any way so it's perhaps
not surprising that it seemingly didn't really achieve it's objective
leading us to this attempt to try again.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: convert everything to rpmautospec?

[Miroslav Suchý]

Dne 08. 04. 24 v 2:55 odp. Emmanuel Seyman napsal(a):

FTR, I have no idea what "salami tactics" is.


https://en.wikipedia.org/wiki/Salami_slicing_tactics

Something that would be unacceptable to be done in one step is possible when 
you do that in tiny steps.
You cannot eat whole salami, but you can eat one slice of salami. And repeat 
until whole salami is gone.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
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: convert everything to rpmautospec?

[Tom Hughes via devel]

On 08/04/2024 10:28, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote:

On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:

-1 for existing packages certainly - none of my git commit logs
are written with the expectation that they will double as package
changelogs so doing so may break the changelog.


Yes, I think rpm changelog is for users of the package and git log
is for the maintainers. Most of the time the entries apply to both,
but sometimes they don't.


This was already answered to some extent, but since it seems to a
common misconception, I'll reply here again:

%autochangelog is designed to keep the separation between git log and
%changelog. Generally, only some git log entries end up with a
matching entry in the autogenerated %changelog, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries.


Yes I read the documentation last night after some of the clarifications
and I'm much less opposed now and considering trying it out next time
there is a new release for one of my packages.

I think things might have gone better if things had been phrased
as reminding people of how it all worked, and that it is in fact now
policy to use it (which had passed me by) rather than coming straight
out with threats to use proven packagers which I suspect got people's
backs up and led to some of the swift negative responses.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> OK, so you mean that the approach with '.' at the end of Release
> doesn't work. Yes, that case is not supported very well.
> 
> There is no great solution here, but there are a few options. Which
> one makes the most sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
> 
> Looking at the docs again, the docs are not great, and we should
> support this case better. This certainly needs looking into.
> 
Now I recalled yet another downstream issue: Importing without a git history
will reset release numbers. That hashes RPM-dependencies which refer to
a specific release (like "Conflicts: foo < 1-20" after a package split). One
should of course carefully check them on import, but forking whole
distribution like that into a new downstream distribution warrants there will
remain gems like this.

I don't say it's Fedora's problem. I only try to show why some people are not
keen to adopt rpmautospec.

-- Petr


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: convert everything to rpmautospec?

[Iñaki Ucar]

On Mon, 8 Apr 2024 at 15:47, Fabio Valentini  wrote:

> On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar  wrote:
> >
> > So someone wanted to use rpmautospec and was willing to do the work,
> putting things together as an opt-in feature. Perfect.
> >
> > Now, I don't see any problem if some time later someone revisits the
> topic and proposes to go further. I don't see anything unfriendly here.
> Everything was set or decided at some point, and nothing could ever be
> changed if we don't allow ourselves to change our minds and be free to make
> new proposals.
> >
> > That said, we are also free to reject those proposals, and I'm -1 here.
> As of today, I think it's fine as an opt-in feature, and I'm even using it
> for some small uncomplicated packages. But I don't think it should be the
> default with an opt-out.
>
> It is already supposed to be default / preferred since this Fedora 38
> Change:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default


Described as preferred in the docs != default. Also versioning and
changelog are described separately, so some could use autochangelog but not
autorelease, or the other way around, or not at all. In the same way that
one could use autosetup or not. But here it has been proposed that
autochangelog + autorelease are not options anymore, and that you would
need to add a file to the repo to opt-out. -1 to this. The current status
is fine for me.

-- 
Iñaki Úcar
--
___
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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> > RHEL do updates into older minor distribution versions. E.g. you might want 
> > to
> > build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> > build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> > from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated 
> > to
> > the 9.2 build before or not.
> 
> OK, so you mean that the approach with '.' at the end of Release
> doesn't work. Yes, that case is not supported very well.
> 
> There is no great solution here, but there are a few options. Which
> one makes the most sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
>
That's what people probably do, but it's not ideal because people need not to
forget to do it and it means a larger churn in dist-git than would be otherwise
necessary.

> > > > - I sometimes need a different commit message from an RPM changelog 
> > > > entry.
> > > 
> > > That's not a problem, the %changelog entry is customziable, see
> > > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> > >
> > If I understand it correctly
> 
> You understand incorrectly ;) Please see the docs linked above.
> 
I see. A multi-line commit message without ellipsis reproduces only the first
line into the RPM changlog. That would do. Thanks for insisting on the
documentation.

> > With preserving the release numbers. Last time it subsituted the release
> > number with a dummy value. Part of the development is comparing old and new
> > builds and testing an upgrade path. A dummy release number is not 
> > sufficient.
> 
> No. I don't know what "last time" means, but it hasn't been like that
> since it was officially introduced in Fedora.

Indeed. I probably mistaken it with building from a source package in mock.

-- Petr


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: convert everything to rpmautospec?

[Fabio Valentini]

On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar  wrote:
>
> So someone wanted to use rpmautospec and was willing to do the work, putting 
> things together as an opt-in feature. Perfect.
>
> Now, I don't see any problem if some time later someone revisits the topic 
> and proposes to go further. I don't see anything unfriendly here. Everything 
> was set or decided at some point, and nothing could ever be changed if we 
> don't allow ourselves to change our minds and be free to make new proposals.
>
> That said, we are also free to reject those proposals, and I'm -1 here. As of 
> today, I think it's fine as an opt-in feature, and I'm even using it for some 
> small uncomplicated packages. But I don't think it should be the default with 
> an opt-out.

It is already supposed to be default / preferred since this Fedora 38 Change:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default

Fabio
--
___
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: convert everything to rpmautospec?

[Jonathan Wright via devel]

-1 as well, for all the reasons already mentioned.

On Mon, Apr 8, 2024 at 8:28 AM Iñaki Ucar  wrote:

> So someone wanted to use rpmautospec and was willing to do the work,
> putting things together as an opt-in feature. Perfect.
>
> Now, I don't see any problem if some time later someone revisits the topic
> and proposes to go further. I don't see anything unfriendly here.
> Everything was set or decided at some point, and nothing could ever be
> changed if we don't allow ourselves to change our minds and be free to make
> new proposals.
>
> That said, we are also free to reject those proposals, and I'm -1 here. As
> of today, I think it's fine as an opt-in feature, and I'm even using it for
> some small uncomplicated packages. But I don't think it should be the
> default with an opt-out.
>
> Iñaki
>
> On Mon, 8 Apr 2024 at 14:56, Emmanuel Seyman  wrote:
>
>> * Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
>> >
>> > Well, you and Kevin see "salami tactics" (whatever that may be),
>>
>> FTR, I have no idea what "salami tactics" is.
>>
>> > while I see normal engineering practice: some new idea is hatched,
>> > it's implemented and used narrowly, them it's applied by default
>> > and more widely, and possibly at the end previous methods are
>> > deprecated.
>>
>> This sounds acceptable but is not at all how these changes are proposed.
>>
>> An proposal is made, stating explicity that it will be opt-in or target
>> a subset of the target audience and never even suggesting that the scope
>> might one day be expanded.
>>
>> It is accepted based on that premise and, after a while, changes are
>> made to make the change default or opt-out, leaving the people who would
>> not have accepted it had they known they would be forced to use it with
>> no recourse.
>>
>> This is unfriendly (thus violating one of Fedora's core principles) at
>> best and deceitful at worst.
>>
>> > The alternative would be to have "grand plans" where we decide that
>> > some technology will be used by default and mandatory before we deploy
>> > it widely and get feedback.
>>
>> Another alternative would be not lie to the target audience by
>> initially claiming that the change is opt-in. Yet another alternative
>> would be to not go back on this claim.
>>
>> > I think that if you think this through, you'll realize that the
>> > "salami tactic" is quite reasonable.
>>
>> I don't but wish to thank you for the condescending tone nonetheless.
>>
>> Emmanuel
>> --
>> ___
>> 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
>>
>
>
> --
> Iñaki Úcar
> --
> ___
> 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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: convert everything to rpmautospec?

[Iñaki Ucar]

So someone wanted to use rpmautospec and was willing to do the work,
putting things together as an opt-in feature. Perfect.

Now, I don't see any problem if some time later someone revisits the topic
and proposes to go further. I don't see anything unfriendly here.
Everything was set or decided at some point, and nothing could ever be
changed if we don't allow ourselves to change our minds and be free to make
new proposals.

That said, we are also free to reject those proposals, and I'm -1 here. As
of today, I think it's fine as an opt-in feature, and I'm even using it for
some small uncomplicated packages. But I don't think it should be the
default with an opt-out.

Iñaki

On Mon, 8 Apr 2024 at 14:56, Emmanuel Seyman  wrote:

> * Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
> >
> > Well, you and Kevin see "salami tactics" (whatever that may be),
>
> FTR, I have no idea what "salami tactics" is.
>
> > while I see normal engineering practice: some new idea is hatched,
> > it's implemented and used narrowly, them it's applied by default
> > and more widely, and possibly at the end previous methods are
> > deprecated.
>
> This sounds acceptable but is not at all how these changes are proposed.
>
> An proposal is made, stating explicity that it will be opt-in or target
> a subset of the target audience and never even suggesting that the scope
> might one day be expanded.
>
> It is accepted based on that premise and, after a while, changes are
> made to make the change default or opt-out, leaving the people who would
> not have accepted it had they known they would be forced to use it with
> no recourse.
>
> This is unfriendly (thus violating one of Fedora's core principles) at
> best and deceitful at worst.
>
> > The alternative would be to have "grand plans" where we decide that
> > some technology will be used by default and mandatory before we deploy
> > it widely and get feedback.
>
> Another alternative would be not lie to the target audience by
> initially claiming that the change is opt-in. Yet another alternative
> would be to not go back on this claim.
>
> > I think that if you think this through, you'll realize that the
> > "salami tactic" is quite reasonable.
>
> I don't but wish to thank you for the condescending tone nonetheless.
>
> Emmanuel
> --
> ___
> 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
>


-- 
Iñaki Úcar
--
___
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: F41 Change Proposal: Pytest 8 (self-contained)

[Tomas Hrnciar]

I got a list of all packages BuildRequiring pytest using this command:

$ repoquery --repo=rawhide{,-source} --whatrequires python3-pytest
--recursive | grep src$ | pkgname | sort | uniq > packages.txt

FreeIPA is not there because pytest build time dependency is disabled via
bcond.

On Mon, Apr 8, 2024 at 8:16 AM Alexander Bokovoy 
wrote:

> On Суб, 06 кра 2024, Sandro wrote:
> >On 05-04-2024 23:45, Aoife Moloney wrote:
> >>== Summary ==
> >>
> >>Update to a new upstream release of pytest that is not completely
> >>compatible with previous releases. Pytest 8 is a major upstream
> >>release removing a lot of deprecated functions and introducing
> >>breaking changes.
> >
> >I was wondering how this will pan out with the introduction of Python
> >3.13, which is also planned for F41 and comes with its own set of
> >breaking changes. Some of those affecting tests.
> >
> >The current test builds are run against Python 3.12. Will all Python
> >packages also be tested against Python 3.13 with pytest 8 later on?
> >Does that even make sense?
> >
> >Anyway, it's two major updates affecting the Python ecosystem, which
> >are both aiming at F41. Maybe letting the dust settle on Python 3.13
> >first and then updating pytest to the next major release will let
> >package maintainers (and upstream) focus more. Just some food for
> >thought.
>
> On top of that, I wonder how the packages were chosen. FreeIPA is
> missing in the test COPR at all (but freeipa-healthcheck is present).
> FreeIPA is also missing in the list of affected packages. We do use
> pytest and some of more complex pytest plugins (multihost, sourceorder),
> also add our own extensions.
>
> I filed an upstream issue to track Pytest 8:
> https://pagure.io/freeipa/issue/9571
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> --
> ___
> 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

Fedora rawhide compose report: 20240408.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240407.n.0
NEW: Fedora-Rawhide-20240408.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  6
Dropped packages:8
Upgraded packages:   132
Downgraded packages: 0

Size of added packages:  477.63 KiB
Size of dropped packages:829.48 KiB
Size of upgraded packages:   895.47 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240408.n.0.iso

= DROPPED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20240407.n.0.s390x.qcow2

= ADDED PACKAGES =
Package: rpm-spec-language-server-0.0.1-1.fc41
Summary: Language Server for RPM spec files
RPMs:rpm-spec-language-server
Size:50.87 KiB

Package: rust-gix-dir-0.3.0-1.fc41
Summary: Handle git-style directory walk
RPMs:rust-gix-dir+default-devel rust-gix-dir-devel
Size:55.90 KiB

Package: rust-pcg-mwc-0.2.1-1.fc41
Summary: Fast non-cryptographic psudo random number generator
RPMs:rust-pcg-mwc+default-devel rust-pcg-mwc+serde-devel 
rust-pcg-mwc+serde1-devel rust-pcg-mwc-devel
Size:38.20 KiB

Package: rust-pulldown-cmark-escape-0.10.0-1.fc41
Summary: Escape library for HTML created in the pulldown-cmark project
RPMs:rust-pulldown-cmark-escape+default-devel 
rust-pulldown-cmark-escape-devel
Size:23.71 KiB

Package: rust-pulldown-cmark0.9-0.9.6-2.fc41
Summary: Pull parser for CommonMark
RPMs:rust-pulldown-cmark0.9+default-devel 
rust-pulldown-cmark0.9+gen-tests-devel rust-pulldown-cmark0.9+getopts-devel 
rust-pulldown-cmark0.9+serde-devel rust-pulldown-cmark0.9+simd-devel 
rust-pulldown-cmark0.9-devel
Size:148.18 KiB

Package: rust-regex-cursor-0.1.4-1.fc41
Summary: Regex fork that can search discontiguous haystacks
RPMs:rust-regex-cursor+default-devel rust-regex-cursor+perf-inline-devel 
rust-regex-cursor+ropey-devel rust-regex-cursor-devel
Size:160.77 KiB


= DROPPED PACKAGES =
Package: rust-ashpd0.6-0.6.7-1.fc41
Summary: XDG portals wrapper in Rust using zbus
RPMs:rust-ashpd0.6+async-std-devel rust-ashpd0.6+default-devel 
rust-ashpd0.6+gdk4wayland-devel rust-ashpd0.6+gdk4x11-devel 
rust-ashpd0.6+gtk4-devel rust-ashpd0.6+gtk4_wayland-devel 
rust-ashpd0.6+gtk4_x11-devel rust-ashpd0.6+libc-devel 
rust-ashpd0.6+pipewire-devel rust-ashpd0.6+pw-devel rust-ashpd0.6+tokio-devel 
rust-ashpd0.6+tracing-devel rust-ashpd0.6-devel
Size:167.16 KiB

Package: rust-gstreamer-editing-services0.21-0.21.3-1.fc41
Summary: Rust bindings for GStreamer Editing Services
RPMs:rust-gstreamer-editing-services0.21+default-devel 
rust-gstreamer-editing-services0.21+serde-devel 
rust-gstreamer-editing-services0.21+v1_16-devel 
rust-gstreamer-editing-services0.21+v1_18-devel 
rust-gstreamer-editing-services0.21+v1_20-devel 
rust-gstreamer-editing-services0.21+v1_22-devel 
rust-gstreamer-editing-services0.21+v1_24-devel 
rust-gstreamer-editing-services0.21-devel
Size:147.62 KiB

Package: rust-gstreamer-gl-egl0.21-0.21.2-1.fc41
Summary: Rust bindings for GStreamer GL library (EGL support)
RPMs:rust-gstreamer-gl-egl0.21+default-devel 
rust-gstreamer-gl-egl0.21+v1_16-devel rust-gstreamer-gl-egl0.21+v1_18-devel 
rust-gstreamer-gl-egl0.21+v1_20-devel rust-gstreamer-gl-egl0.21+v1_22-devel 
rust-gstreamer-gl-egl0.21+v1_24-devel rust-gstreamer-gl-egl0.21-devel
Size:86.94 KiB

Package: rust-gstreamer-gl-wayland0.21-0.21.1-1.fc41
Summary: Rust bindings for GStreamer GL library (Wayland support)
RPMs:rust-gstreamer-gl-wayland0.21+default-devel 
rust-gstreamer-gl-wayland0.21+v1_16-devel 
rust-gstreamer-gl-wayland0.21+v1_18-devel 
rust-gstreamer-gl-wayland0.21+v1_20-devel 
rust-gstreamer-gl-wayland0.21+v1_22-devel 
rust-gstreamer-gl-wayland0.21+v1_24-devel rust-gstreamer-gl-wayland0.21-devel
Size:86.95 KiB

Package: rust-gstreamer-gl-x11_0.21-0.21.1-1.fc41
Summary: Rust bindings for GStreamer GL library (X11 support)
RPMs:rust-gstreamer-gl-x11_0.21+default-devel 
rust-gstreamer-gl-x11_0.21+v1_16-devel rust-gstreamer-gl-x11_0.21+v1_18-devel 
rust-gstreamer-gl-x11_0.21+v1_20-devel rust-gstreamer-gl-x11_0.21+v1_22-devel 
rust-gstreamer-gl-x11_0.21+v1_24-devel rust-gstreamer-gl-x11_0.21-devel
Size:86.55 KiB

Package: rust-gstreamer-player0.21-0.21.2-1.fc41
Summary: Rust bindings for GStreamer Player library
RPMs:rust-gstreamer-player0.21+default-devel 
rust-gstreamer-player0.21+v1_16-devel rust-gstreamer-player0.21+v1_18-devel 
rust-gstreamer-player0.21+v1_20-devel rust-gstreamer-player0.21+v1_22-devel 
rust-gstreamer-player0.21+v1_24-devel rust-gstreamer-player0.21-devel
Size:103.73 KiB

Package: rust-pbkdf2_0.10-0.10.1-3.fc40
Summary: Generic implementation of PBKDF2
RPMs:rust-pbkdf2_0.10+default-devel rust-pbkdf2_0.10+hmac-devel 
rust-pbkdf2_0.10+parallel-devel rust-pbkdf2_0.10+password-hash-devel 
rust

Re: F41 Change Proposal: Pytest 8 (self-contained)

[Tomas Hrnciar]

On Sat, Apr 6, 2024 at 12:46 PM Sandro  wrote:

> On 05-04-2024 23:45, Aoife Moloney wrote:
> > == Summary ==
> >
> > Update to a new upstream release of pytest that is not completely
> > compatible with previous releases. Pytest 8 is a major upstream
> > release removing a lot of deprecated functions and introducing
> > breaking changes.
>
> I was wondering how this will pan out with the introduction of Python
> 3.13, which is also planned for F41 and comes with its own set of
> breaking changes. Some of those affecting tests.
>
> The current test builds are run against Python 3.12. Will all Python
> packages also be tested against Python 3.13 with pytest 8 later on? Does
> that even make sense?
>

I dug up some numbers.

1769 packages depends on pytest
- 138 fails with pytest 8 and python 3.12
- 1631 builds with pytest 8 and python 3.12
- 1294 were attempted to build with python 3.13 (either succesfully or
unsuccesfully)
- 61 packages failed with either (python 3.13) or (python 3.12 and
pytest 8)
- 337 weren't attempted yet to build with python 3.13 (probably missing
dependencies)

I am aware it's not ideal to test against 3.12, but right now it's our best
option since a lot of packages are still missing dependencies in python
3.13 copr.


> Anyway, it's two major updates affecting the Python ecosystem, which are
> both aiming at F41. Maybe letting the dust settle on Python 3.13 first
> and then updating pytest to the next major release will let package
> maintainers (and upstream) focus more. Just some food for thought.
>

The priority is to deliver python 3.13. I want to ship pytest after python
3.13 mass rebuild to avoid disruptions on that front. Until then I want to
open bugzillas to notify maintainers and backport patches if available.
There is also an option to introduce pytest 7 compat package in case of a
high number of broken packages before Beta Freeze. We should have roughly 2
months between the end of python 3.13 mass rebuild and Beta Freeze to
decide on how to proceed.


>
> -- Sandro
> --
> ___
> 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: convert everything to rpmautospec?

[Emmanuel Seyman]

* Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
>
> Well, you and Kevin see "salami tactics" (whatever that may be),

FTR, I have no idea what "salami tactics" is.

> while I see normal engineering practice: some new idea is hatched,
> it's implemented and used narrowly, them it's applied by default
> and more widely, and possibly at the end previous methods are
> deprecated.

This sounds acceptable but is not at all how these changes are proposed.

An proposal is made, stating explicity that it will be opt-in or target
a subset of the target audience and never even suggesting that the scope
might one day be expanded.

It is accepted based on that premise and, after a while, changes are
made to make the change default or opt-out, leaving the people who would
not have accepted it had they known they would be forced to use it with
no recourse.

This is unfriendly (thus violating one of Fedora's core principles) at
best and deceitful at worst.

> The alternative would be to have "grand plans" where we decide that
> some technology will be used by default and mandatory before we deploy
> it widely and get feedback.

Another alternative would be not lie to the target audience by
initially claiming that the change is opt-in. Yet another alternative
would be to not go back on this claim.

> I think that if you think this through, you'll realize that the
> "salami tactic" is quite reasonable.

I don't but wish to thank you for the condescending tone nonetheless.

Emmanuel
--
___
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: convert everything to rpmautospec?

[Pavel Raiskup]

On neděle 7. dubna 2024 17:15:16 CEST Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

I'm -1 here.

I'm also -1 for baking the "actual build source data" into a git-log
history, instead of just plain checkout.  One of the reasons:
https://pagure.io/fedora-infra/rpmautospec/issue/227

Then retro: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2G6OSOSM76O2V6K4COIE2QHNXIBSXPFR/

1. git-log is not a %changelog, "generated like we do it" it has close
   to zero value.  Can we finally state that %changelog is not needed?
   Or just point at forge's git-log?

2. Release could be made build-system specific, and IMO _should_ be.

Pavel

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



signature.asc
Description: This is a digitally signed message part.
--
___
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: convert everything to rpmautospec?

[Christopher Klooz]

On 08/04/2024 11.31, Richard W.M. Jones wrote:

On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote:

Emmanuel Seyman wrote:

I've noticed a trend in proposed changes in the way Fedora works.

I am fed up of this salami tactic as well. When we complain about the new
stuff, we invariably get told "don't worry, you don't have to use it, it's
all optional", but the plan is always to make it mandatory later. See also
2FA that they are now trying to force on us, taking as an excuse an incident
that was demonstrably NOT stopped by 2FA.


They start off as as things packagers will not have to use if they do
not want to and, over time, become default/forced (Matrix vs IRC,

To be fair, part of the blame there is to be put on Libera.Chat that
unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some
time to address the demands they had, but when Matrix told them it was not
feasible in such a short time frame, they just first suspended, then
permanently blocked the Matrix bridge.) But, and here is where I blame
Fedora, instead of just letting the chans on Libera.Chat die and moving
everything to Matrix, they should have moved the IRC chans to a network with
a working Matrix bridge, such as OFTC (or pretty much anything other than
Libera.Chat – I guess even Freenode under its new owners might be an
option), then we could still be happily using both technologies
interoperably. Instead, we get told to just use Matrix and shut up, which I
do not consider acceptable.


Discourse, ...).

There too, I do not see why some discussions are now being directed to
Discourse instead of the mailing list. And it is not even working. Most of
the pertinent feedback for new Changes still comes on this list, not on
Discourse. The developers use this list, Discourse is only for users who do
not know how to use a mailing list.

The massive & central problem with discourse (and it's amazing that it
still has not been fixed) is that there's no way to reliably get it to
send me an email when there's a new topic, or even when there's a new
message on an existing topic.  As a result it's completely useless and
invisible to me.

Rich.


I am also not a fan to merge everything into one piece of centralized infra 
because discourse may develop into a big single point of failure.

But the email issue has **partly** been solved: I work with email for about a year with 
**limited** problems **when** it comes to keep informed about topics I am already 
involved in and also for topics that contain a tag that I am watching (major problem 2 
below makes the "limited" in this case).

But once a new topic that is interesting for me is created, I need to set it to 
watched in discourse before I can rely on getting informed (which means I need 
to know about the topic), because of major problem 1:

Major problem 1: you cannot rely that people who open new topics always set the 
right tags. I guess it would take months if not longer before people get used 
to that and it would cause a lot of devastating confusion till then, if people 
get used to it at all (especially those who work mostly in other communities 
that do not centralize at discourse).

Major problem 2: people can change their posts, and nearly everyone gets used 
to that quickly, and you will NOT be informed by email if a post is changed.

Major problem 3: many people will have a hard time to get into setting the right properties in their discourse 
configuration so that it behaves in the "email"-like way. (e.g., you need to subscribe to related 
tags/topics as "watched", not only "tracked" or so -> **maybe this is related to your 
problem** ). I am not sure if that is comprehensible if people are not used to it.

(Major?) problem 4: afaik, it is still not possible to add openpgp signatures 
to emails (I am not sure if that was fixed in the meantime). We don't use that 
yet but at least the possibility to use that possibility on short notice if we 
want or need to is not possible. We trust in any case 100% on discourse's 
centralized crypto, integrity and availability.

Major problem 5: I still don't know a comprehensible way to add myself to a 
topic without becoming active on web discourse if the topic does not contain 
one of my subscribed tags. The same for creating new topics. If there is a way, 
I am quite sure it is not an intuitive one. In any case, if people can open a 
topic in a way I get not informed about, I can miss it.

Major problem 6: in urgent / intensive discussions, 5 minutes can contain 
several messages, and thus it will be not possible to discuss among email and 
web posts because email posts will be always 5 minutes late (and miss changed 
posts at all).

(Major?) problem 7: cross-community topics. I am not sure if that is used at 
the moment in devel. But if so, I think this is next to the centralized 
trust/crypto issue the one that cannot be solved effectively.

But since we are now an Enterprise customer of discourse, I could i

Re: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek 
> napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL 
> > > minor
> > >   releases).
> > 
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> > 
> RHEL do updates into older minor distribution versions. E.g. you might want to
> build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.

OK, so you mean that the approach with '.' at the end of Release
doesn't work. Yes, that case is not supported very well.

There is no great solution here, but there are a few options. Which
one makes the most sense depends a lot on the package. But in particular:
- just switch to non-autorelease numbering when introducing the
  minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.

Looking at the docs again, the docs are not great, and we should
support this case better. This certainly needs looking into.

> It's bascially the same problem as Fedora has when users upgrade from Fredora
> 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
> between Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
> 
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
> 
> > > - I sometimes need a different commit message from an RPM changelog entry.
> > 
> > That's not a problem, the %changelog entry is customziable, see
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> >
> If I understand it correctly

You understand incorrectly ;) Please see the docs linked above.

> the customization is actually dumping a changelog
> into a static file. So instead of a few-line commit one would need to review
> the complete changelog. No, thanks.
> 
> > > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> > 
> > That also just works.
> > 
> With preserving the release numbers. Last time it subsituted the release
> number with a dummy value. Part of the development is comparing old and new
> builds and testing an upgrade path. A dummy release number is not sufficient.

No. I don't know what "last time" means, but it hasn't been like that
since it was officially introduced in Fedora.

Zbyszek
--
___
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: convert everything to rpmautospec?

[Neal Gompa]

On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar  wrote:
>
> V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek 
> napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL 
> > > minor
> > >   releases).
> >
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> >
> RHEL do updates into older minor distribution versions. E.g. you might want to
> build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.
>
> It's bascially the same problem as Fedora has when users upgrade from Fredora
> 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
> between Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
>
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
>

We did this long before rpmautospec existed. We switched to this
behavior in Fedora 23 because we have never fully maintained "upgrade
paths" across releases.

RHEL is *even worse* in this regard because there is no active testing
or handling of distribution upgrades within the distribution itself
(hence why no equivalent to fedora-obsolete-packages in CentOS/RHEL),
which is why distribution upgrades are the bane of every RHEL admin's
existence. The Leapp tooling more or less externally does the same
thing now, but that's generally not available to CentOS users.

The distro-sync behavior is the right way to handle distribution
upgrades, the "upgrade path" is the right way *within* a distribution
release.




--
真実はいつも一つ！/ 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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL 
> > minor
> >   releases).
> 
> Hmm, can you provide describe the workflow that is broken in more
> detail?
> 
RHEL do updates into older minor distribution versions. E.g. you might want to
build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
the 9.2 build before or not.

It's bascially the same problem as Fedora has when users upgrade from Fredora
40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
between Fedoras is not maintained anymore and users need to do "dnf
distro-sync" to ignore the RPM versioning.

All that stems from tha fact that a number of commits between parallelly
supported braches is not monotonic.

> > - I sometimes need a different commit message from an RPM changelog entry.
> 
> That's not a problem, the %changelog entry is customziable, see
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
>
If I understand it correctly the customization is actually dumping a changelog
into a static file. So instead of a few-line commit one would need to review
the complete changelog. No, thanks.

> > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> 
> That also just works.
> 
With preserving the release numbers. Last time it subsituted the release
number with a dummy value. Part of the development is comparing old and new
builds and testing an upgrade path. A dummy release number is not sufficient.

-- Petr


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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek 
> napsal(a):
> > I think it's time to switch to rpmautospec completely.
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert their packages
> > - provenpackagers MAY convert existing packages
> >   (e.g. when they want to push some fix or separately from other
> >work)
> > - people submitting pull requests against src.fp.o MAY also
> >   include a conversion in the pull request and packagers SHOULD
> >   merge it.
> > 
> I don't like it because:
> 
> - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
>   releases).

Hmm, can you provide describe the workflow that is broken in more
detail?

> - I sometimes need a different commit message from an RPM changelog entry.

That's not a problem, the %changelog entry is customziable, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

> - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).

That also just works.

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

No Open NeuroFedora Meeting: Monday, 08 April 2024 (today) at 13:00 UTC

[Ankur Sinha]

Hi folks,

We won't have the NeuroFedora meeting today. We'll continue in 2 weeks
as per our schedule.

-- 
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: "fedpkg local" builds fail for rust packages

[Neal Gompa]

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones  wrote:
>
> On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> > wrote:
> > >
> > > So you're saying that those packages are in the repos for everyone but
> > > not meant to be installed by anyone (besides mock chroots), and that is
> > > how and why they are packaged.
> >
> > Yes. That is the best we can do given how cargo + Rust work.
> >
> > > `This package contains library source intended for building other 
> > > packages which
> > > use the "xyz" crate.`
> >
> > So the description matches what I said?
> >
> > > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> > > mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
> > >
> > > Wow!
> >
> > Sorry to burst your bubble, but "fedpkg local" is an ugly hack
> > (independent of Rust peculiarities).
>
> fedpkg local works fine for almost all cases.
>
> > And I am not interested in adding workarounds to the Rust packaging
> > toolchain to support it.
> >
> > "fedpkg mockbuild" and "fedpkg srpm" all work as expected ...
> >
> > > Is there any other set of packages which we package like that?
> >
> > Probably golang ... maybe Haskell, OCaml?
>
> OCaml is definitely _not_ packaged like this.  ocaml-* and
> ocaml-*-devel packages are normal packages that can be installed by
> end users if they want, although usually only if they're developing
> OCaml software.
>

Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883

Without this feature, it becomes difficult to do development using
packaged crates.


-- 
真実はいつも一つ！/ 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: convert everything to rpmautospec?

[Petr Pisar]

V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
I don't like it because:

- It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
  releases).

- I sometimes need a different commit message from an RPM changelog entry.

- I prefer "fedpkg local" over mock (faster, smaller, easier to debug).

-- Petr



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: Three steps we could take to make supply chain attacks a bit harder

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 05:52:07AM -0400, Neal Gompa wrote:
> On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > > I wrote:
> > > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > >  wrote:
> > > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> > > >> detection of python, and it found /usr/bin/python3.13t that I have
> > > >> installed, and subsequently it got all the paths wrong.
> > > >
> > > > That's why you should never build packages outside of mock.
> >
> > That's another way of saying "it's broken" ;]
> > Mock is great, but I'm doing local development and a local build
> > against my envirnoment is what I need.
> >
> > > PS: Autotools also loves to autodetect random libraries that happen to be
> > > installed on the system. It is in no way specific to CMake.
> > >
> > > >> How do I override this?
> > > >> ('cmake -LAH' doesn't yield anything useful.)
> > >
> > > Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake 
> > > for
> > > the variables it uses. (First, try to figure out whether RPM is using a
> > > system-installed FindPython or its own custom version, so you look at the
> > > correct version.)
> >
> > Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
> > want to integrate with the Linux userspace in the normal way.
> >
> 
> You know that pkgconfig *also* uses variables too, right? It's
> perfectly "normal" to do it this way. Arguably, the fact that every
> variable is known and saved in the CMakeLists and CMakeCache data for
> you to read is a boon, because if you need to know a variable to
> override, you can find it easily in the logs.

So… this is what I'm talking about: there is no obvious way to
figure out what to set. Looking at the logs and trying to figure out
some variables from that is not very attractive.

Of course I know pgkconfig uses variables, I don't know what you
are trying to say.

I think CMake hits the "sour spot" here in a few different ways:

- because of the historical mindset, instead of using standard
  mechanisms that everybody else uses, it implements custom detection,
- this autodetection very often does things wrong,
- because of the approach with Find* scripts, each package is different
  and each detection script has a custom interface, so overriding things
  is a lot of work,
- the complicated language that is partially variable-based, partially
  macro-based is not easy to follow.

autotools has './configure --help',
meson has all options in `meson_options.txt' and also 'meson configure'
will print all options,
but with CMake the options are buried in Find* and not easy to figure out.

> And this your statement on normalcy is silly since we don't *have* a
> normal way. The GNU Build System (Autotools), Meson, and CMake all do
> things differently, and all three have significant share in our
> packages. Projects that use plain Makefiles are even *more*
> non-standard, as they do whatever they want too.

Yeah, I know we have a bazillion build systems. And all have
to work and the packagers need to use and understand all of them.
Nevertheless, for me, CMake and autotools are outdated technologies
that shouldn't be used in new projects.

Zbyszek
--
___
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: "fedpkg local" builds fail for rust packages

[Richard W.M. Jones]

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> wrote:
> >
> > So you're saying that those packages are in the repos for everyone but
> > not meant to be installed by anyone (besides mock chroots), and that is
> > how and why they are packaged.
> 
> Yes. That is the best we can do given how cargo + Rust work.
> 
> > `This package contains library source intended for building other packages 
> > which
> > use the "xyz" crate.`
> 
> So the description matches what I said?
> 
> > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> > mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
> >
> > Wow!
> 
> Sorry to burst your bubble, but "fedpkg local" is an ugly hack
> (independent of Rust peculiarities).

fedpkg local works fine for almost all cases.

> And I am not interested in adding workarounds to the Rust packaging
> toolchain to support it.
> 
> "fedpkg mockbuild" and "fedpkg srpm" all work as expected ...
> 
> > Is there any other set of packages which we package like that?
> 
> Probably golang ... maybe Haskell, OCaml?

OCaml is definitely _not_ packaged like this.  ocaml-* and
ocaml-*-devel packages are normal packages that can be installed by
end users if they want, although usually only if they're developing
OCaml software.

Rich.

> > If that is how you do things for the rust eco-system, those "devel"
> > packages should be clearly distinguished from real development packages,
> > come with a huge boiler plate "do not install" - or, really, be in a
> > separate repo if installing them is both worthless and misleading for
> > any "real" user. CRB for Fedora material.
> 
> You just pasted the package description above. What more do you want?
> It clearly states that the purpose of the packages is to build other packages.
> 
> Also, Fedora won't do split repos (been there, done that), and stuff
> like it doesn't even work that well in RHEL (and causes all sorts of
> issues).
> 
> While I agree that the situation is not ideal, I still think this is
> the best that we can do:
> 
> 1. We don't want Rust applications to vendor their dependencies
> 2. Rust can only do static linking (for now)
> -> Dependencies can only be shipped as source code, not as compiled artifacts.
> 
> And while you *can* use packaged Rust crates for local development if
> you really want, it's not really a supported use case.
> 
> Fabio
> --
> ___
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Neal Gompa]

On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > I wrote:
> > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> > >> detection of python, and it found /usr/bin/python3.13t that I have
> > >> installed, and subsequently it got all the paths wrong.
> > >
> > > That's why you should never build packages outside of mock.
>
> That's another way of saying "it's broken" ;]
> Mock is great, but I'm doing local development and a local build
> against my envirnoment is what I need.
>
> > PS: Autotools also loves to autodetect random libraries that happen to be
> > installed on the system. It is in no way specific to CMake.
> >
> > >> How do I override this?
> > >> ('cmake -LAH' doesn't yield anything useful.)
> >
> > Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
> > the variables it uses. (First, try to figure out whether RPM is using a
> > system-installed FindPython or its own custom version, so you look at the
> > correct version.)
>
> Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
> want to integrate with the Linux userspace in the normal way.
>

You know that pkgconfig *also* uses variables too, right? It's
perfectly "normal" to do it this way. Arguably, the fact that every
variable is known and saved in the CMakeLists and CMakeCache data for
you to read is a boon, because if you need to know a variable to
override, you can find it easily in the logs.

And this your statement on normalcy is silly since we don't *have* a
normal way. The GNU Build System (Autotools), Meson, and CMake all do
things differently, and all three have significant share in our
packages. Projects that use plain Makefiles are even *more*
non-standard, as they do whatever they want too.



-- 
真実はいつも一つ！/ 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: Three steps we could take to make supply chain attacks a bit harder

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> I wrote:
> > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> >> detection of python, and it found /usr/bin/python3.13t that I have
> >> installed, and subsequently it got all the paths wrong.
> >
> > That's why you should never build packages outside of mock.

That's another way of saying "it's broken" ;]
Mock is great, but I'm doing local development and a local build
against my envirnoment is what I need.

> PS: Autotools also loves to autodetect random libraries that happen to be 
> installed on the system. It is in no way specific to CMake.
>
> >> How do I override this?
> >> ('cmake -LAH' doesn't yield anything useful.)
> 
> Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for 
> the variables it uses. (First, try to figure out whether RPM is using a 
> system-installed FindPython or its own custom version, so you look at the 
> correct version.)

Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
want to integrate with the Linux userspace in the normal way.

Zbyszek
--
___
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: convert everything to rpmautospec?

[Richard W.M. Jones]

On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote:
> Emmanuel Seyman wrote:
> > I've noticed a trend in proposed changes in the way Fedora works.
> 
> I am fed up of this salami tactic as well. When we complain about the new 
> stuff, we invariably get told "don't worry, you don't have to use it, it's 
> all optional", but the plan is always to make it mandatory later. See also 
> 2FA that they are now trying to force on us, taking as an excuse an incident 
> that was demonstrably NOT stopped by 2FA.
> 
> > They start off as as things packagers will not have to use if they do
> > not want to and, over time, become default/forced (Matrix vs IRC,
> 
> To be fair, part of the blame there is to be put on Libera.Chat that 
> unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some 
> time to address the demands they had, but when Matrix told them it was not 
> feasible in such a short time frame, they just first suspended, then 
> permanently blocked the Matrix bridge.) But, and here is where I blame 
> Fedora, instead of just letting the chans on Libera.Chat die and moving 
> everything to Matrix, they should have moved the IRC chans to a network with 
> a working Matrix bridge, such as OFTC (or pretty much anything other than 
> Libera.Chat – I guess even Freenode under its new owners might be an 
> option), then we could still be happily using both technologies 
> interoperably. Instead, we get told to just use Matrix and shut up, which I 
> do not consider acceptable.
> 
> > Discourse, ...).
> 
> There too, I do not see why some discussions are now being directed to 
> Discourse instead of the mailing list. And it is not even working. Most of 
> the pertinent feedback for new Changes still comes on this list, not on 
> Discourse. The developers use this list, Discourse is only for users who do 
> not know how to use a mailing list.

The massive & central problem with discourse (and it's amazing that it
still has not been fixed) is that there's no way to reliably get it to
send me an email when there's a new topic, or even when there's a new
message on an existing topic.  As a result it's completely useless and
invisible to me.

Rich.

> > Perhaps it's time to discuss imposing financial and/or legal penalties
> > when the opt-in nature of the change goes away.
> 
> Who would impose those? And from whom to whom would the money flow? I do not 
> think this can work.
> 
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote:
> On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
> > -1 for existing packages certainly - none of my git commit logs
> > are written with the expectation that they will double as package
> > changelogs so doing so may break the changelog.
> 
> Yes, I think rpm changelog is for users of the package and git log
> is for the maintainers. Most of the time the entries apply to both,
> but sometimes they don't.

This was already answered to some extent, but since it seems to a
common misconception, I'll reply here again:

%autochangelog is designed to keep the separation between git log and
%changelog. Generally, only some git log entries end up with a
matching entry in the autogenerated %changelog, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries.

> I use a script to generate rpm changelog
> entries from git log as a separate commit with the release bump, but
> occasionally I need to edit the text.

That still works. Just put the whatever text in 'changelog' file, and
%autochangelog will use that. (The way it works is that it processes
git log from the top, generating %changelog entries, until it hits a
commit which touches 'changelog' file, at which points it uses the
contensts of that file as the rest of the %changelog. This mechanism
is also used when one needs to "edit" the autogenerated changelog.)

Zbyszek
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote:
> On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote:
> > Not all commits correspond with a new release downstream, and not all
> > commit messages are relevant to the end user to be part of the change
> > log. For example, commits related with increasing gating test coverage
> > efforts, or setting up gating.yaml itself. Another example is linting
> > setting and/or configurations. How is that handled with autochangelog?
> > Can we tell it to skip certain commits? Or should we include it all?

Yes, you can skip %changelog for some commits with '[skip changelog]'
and provide additional content in the commit message which is not part
of the changelog. See
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

Zbyszek
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2024 at 12:38:47AM +0200, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > I'm revisting the topic of rpmautospec because I was doing some work
> > on various packages, and it's annoying that some packages are using
> > rpmautospec and others are not.
> 
> The fix for that inconsistency would be to ban rpmautospec. It just makes 
> everything more complicated.
> 
> > All my packages have been converted, so in day-to-day work, I don't
> > even think about %changelog. When working with other packages, I'll
> > forget to update the Relase and/or %changelog. Today I was rebasing
> > some pull requests in pagure, and the _only_ conflicts that I had were
> > about Release and %changelog.
> 
> Generally, it helps to keep all your branches in sync [...] if you are 
> building the same 
> versions for all releases (which is typically the one case where you bother 
> backporting specfile updates across releases at all), and to process pull 
> requests quickly, before you or rel-eng or another pull request bump the 
> specfile in Rawhide. Then you rarely have conflicts in %changelog to begin 
> with.

Hmm, so KDE has an explicit exception for the updates policy, so that
old releases can be updated and it's indeed possible to keep branches
in sync. I _like_ keeping my branches in sync, but for most packages,
this is not what is supposed to happen.

And sorry, but saying to "process pull requests quickly" is just naive.
Busy packages often have many different pull requests concurrently, and
some of them need discussion and fixes and work in other places before
they can be merged.

> I mean, fast-forwarded to the exact same commit hash – no, it is not
> a problem if the changelog for a Fedora release includes an entry
> for a Rawhide mass rebuild made after that Fedora release branched,
> it explains why the Release number has increased and is otherwise
> harmless

I find that distateful and annoying ;]
It's also unnecessary, with rpmautospec and cherry-picking, you get
a clean changelog.

> > I think it's time to switch to rpmautospec completely.
> > Thus, the proposal:
> > - new packages MUST use rpmautospec
> > - packagers SHOULD convert their packages
> > - provenpackagers MAY convert existing packages
> >   (e.g. when they want to push some fix or separately from other
> >work)
> > - people submitting pull requests against src.fp.o MAY also
> >   include a conversion in the pull request and packagers SHOULD
> >   merge it.
> 
> I am opposed to every part of this proposal. Allowing provenpackagers to 
> convert existing packages (that they do not explicitly comaintain) would be 
> particularly rude. I do NOT want any of this automagic (also the various 
> %auto* macros such as %autosetup) in my specfiles, it just makes my life 
> harder for no benefit whatsoever.

I guess we'll just have to agree to disagree. In the other part of the
thread, a proposal that was floated to allow opt-out. I hope that's
acceptable.

Zbyszek
--
___
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: convert everything to rpmautospec?

[Cristian Le via devel]

Zbyszek

While I am in favor of autospec, I agree with the comment that it 
doesn't work well outside of koji.



- builds in copr work.


The builds themselves work, but in my experience they do not increase 
the `release`, nor do they handle `autochangelog`. Are there ways around 
it if we want `copr` to be a pre-release/testing environment?


Cristian

On 2024/04/08 10:43, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, Apr 07, 2024 at 12:58:04PM -0400, Neal Gompa wrote:

No. I do not want to use rpmautospec as it currently exists. It does
not help me. It does not achieve anything for me. It breaks my
packages for building outside of Fedora Koji. It doesn't even make
things better for supporting automation.

I do not want to use it unless I absolutely have to (e.g. Rust
packages since rust2rpm sets it up that way).

-100.

No. I do not want to use this unless it is finally fixed to enable
rebuild automation. And since that will not happen anytime soon, I
have no compelling reason to use it and tremendous disadvantages
otherwise. It makes building things in COPR terrible, it makes
building things locally annoying, and I can't use it at all reasonably
in non-VCS oriented build systems.

Neal,

I appreciate the work you with other distributions, but in this case,
you're essentially saying that you'll hold Fedora hostage in order
to force some unrelated changes that have no consensus.

In particular:
- local builds work, I do them all the time, with 'fedpkg local' or
   through an srpm.
- builds in copr work.
- "non-VCS oriented build systems" — building from srpm works, so they
   probably actually work, but anyway, it's 2024, we want more version
   control, not less.
- if you want automated rebuilds, please make a proposal and open a
   new dicussion. Don't beat up on rpmautospec.

And we already have a significant fraction of packages using rpmautospec,
so you must have _some_ solution in place that works for those packages.
Even if rpmautospec doesn't fit those external workflows nicely, maybe
even you would benefit if it is used consistently, because then you
can apply the same (adjusted) workflow everywhere?

Zbyszek
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 07, 2024 at 06:44:57PM +0200, Emmanuel Seyman wrote:
> * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:56] :
> >
> > On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote:
> > > 
> > > This doesn't solve the problem you have so that's a no-go as well.
> > 
> > In what way doesn't it solve the problem?
> 
> In your original post, you stated "When working with other packages,
> I'll forget to update the Relase and/or %changelog." This will not go
> away if packages are allowed to opt-out.

The issue will be greatly reduced. Every package that is convered
means a little less busy work ;)

> > The opt-out with 'norpmautospec' would solve 1 and 2.
> 
> I've noticed a trend in proposed changes in the way Fedora works.
> 
> They start off as as things packagers will not have to use if they do
> not want to and, over time, become default/forced (Matrix vs IRC,
> Discourse, ...).

Well, you and Kevin see "salami tactics" (whatever that may be),
while I see normal engineering practice: some new idea is hatched,
it's implemented and used narrowly, them it's applied by default
and more widely, and possibly at the end previous methods are
deprecated.

And yes, the purpose of introducing it narrowly at first is so that
we can change course or even revert completely if it turns out to
be a bad idea. And also, so we can apply corrections. In another
part of the thread, Miro raised some concrete issues, which is useful,
because we know that there's something to fix before moving forward.

The alternative would be to have "grand plans" where we decide that
some technology will be used by default and mandatory before we deploy
it widely and get feedback. Maybe this works in a company where
management sets the course, but not such much in community project.
I think that if you think this through, you'll realize that the
"salami tactic" is quite reasonable.

Zbyszek
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 07, 2024 at 12:58:04PM -0400, Neal Gompa wrote:
> No. I do not want to use rpmautospec as it currently exists. It does
> not help me. It does not achieve anything for me. It breaks my
> packages for building outside of Fedora Koji. It doesn't even make
> things better for supporting automation.
> 
> I do not want to use it unless I absolutely have to (e.g. Rust
> packages since rust2rpm sets it up that way).
> 
> -100.
> 
> No. I do not want to use this unless it is finally fixed to enable
> rebuild automation. And since that will not happen anytime soon, I
> have no compelling reason to use it and tremendous disadvantages
> otherwise. It makes building things in COPR terrible, it makes
> building things locally annoying, and I can't use it at all reasonably
> in non-VCS oriented build systems.

Neal,

I appreciate the work you with other distributions, but in this case,
you're essentially saying that you'll hold Fedora hostage in order
to force some unrelated changes that have no consensus.

In particular:
- local builds work, I do them all the time, with 'fedpkg local' or
  through an srpm.
- builds in copr work.
- "non-VCS oriented build systems" — building from srpm works, so they
  probably actually work, but anyway, it's 2024, we want more version
  control, not less.
- if you want automated rebuilds, please make a proposal and open a
  new dicussion. Don't beat up on rpmautospec.

And we already have a significant fraction of packages using rpmautospec,
so you must have _some_ solution in place that works for those packages.
Even if rpmautospec doesn't fit those external workflows nicely, maybe
even you would benefit if it is used consistently, because then you
can apply the same (adjusted) workflow everywhere?

Zbyszek
--
___
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: convert everything to rpmautospec?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 07, 2024 at 05:55:08PM +0100, Sérgio Basto wrote:
> I also still see some issues in %autorelease , why fix a typo is a new
> release ? 

Either the fix is important and you rebuild and then you _must_ have a
new release, because koji requires a unique NEVRA. Or the fix can wait,
so you commit the fix, probably with '[skip changelog]'.

> in  %{forgesource} , as I mention in 
> https://src.fedoraproject.org/rpms/rawstudio/pull-request/2#comment-167038
> "forge date should be the date of the last commit upstream of upstream
> git (i.e. git log -1 --format=%cd --date=short | tr -d -)" 

There is no problem with that. The forge date is part of the upstream
version information, so it goes into Version.

> and the most important, I don't see "great" benefits and give me more
> work . 

Frankly, I think you are not using it properly. I think you must be trying
to adapt some obsolete workflow onto rpmautospec, because otherwise I don't
see how it can increase work. What step is taking more work for you?

Zbyszek
--
___
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: convert everything to rpmautospec?

[Leigh Scott]

> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.

-1 to all of this!
I have zero interest in learning or using rpmautospec.
If anyone touches my packages I will revert them back and refuse all merge 
requests for rpmautospec.
--
___
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: convert everything to rpmautospec?

[Miroslav Lichvar]

On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
> -1 for existing packages certainly - none of my git commit logs
> are written with the expectation that they will double as package
> changelogs so doing so may break the changelog.

Yes, I think rpm changelog is for users of the package and git log
is for the maintainers. Most of the time the entries apply to both,
but sometimes they don't. I use a script to generate rpm changelog
entries from git log as a separate commit with the release bump, but
occasionally I need to edit the text.

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