Re: Switching XZ for ZSTD?

[Christoph Karl via devel]

Hi!

+1

The sequence must be: measure -> think -> act.
Not:
act (in panic) ->
think (oh, that ist not the correct way, or even worse: oh, this is the
way the attacker wants us to go.)
measure (we have a weakness)

Best regards
Christoph


Am 04.04.24 um 20:11 schrieb Leon Fauster via devel:

One approach that would be at least bring some light into "weak"
(non technical layer) components (albeit not sure how feasible it is),
could be:

  - Checking the resources of a packaged project.
    Resources in terms of man or firm power that backup the project

  - Contribution activity of people

  - General activity of the project

  - Transparency of the workflow / tools

and that for all projects that the distribution includes.

Why? This would allow to plan internal review activities
(or processes) more effectively. They would be directed
to the "weak" components with higher priority (recurrent, actions).


Like the current process for checking the license (SPDX) of a project,
it could also collect such metrics right away.



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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-acb47e6aea   
libopenmpt-0.7.6-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-d0d107787c   
assimp-5.0.1-7.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-8791118dee   
mbedtls-2.28.8-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-7a1c939a17   
editorconfig-0.12.7-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-88820507e6   
upx-4.2.3-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-57848161af   
trafficserver-9.2.4-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

nagios-plugins-2.4.9-1.el8
python-markdown2-2.4.13-1.el8
waf-2.0.27-1.el8

Details about builds:



 nagios-plugins-2.4.9-1.el8 (FEDORA-EPEL-2024-fc78e0348a)
 Host/service/network monitoring program plugins for Nagios

Update Information:

Update to 2.4.9

ChangeLog:

* Fri Mar 29 2024 Guido Aulisi  - 2.4.9-1
- Update to 2.4.9

References:

  [ 1 ] Bug #2270901 - nagios-plugins-2.4.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270901




 python-markdown2-2.4.13-1.el8 (FEDORA-EPEL-2024-d52a2bb01e)
 A fast and complete Python implementation of Markdown

Update Information:

python-markdown2 2.4.13
[pull #559] Allow cuddled tables (#557)
[pull #560] Fix markdown-in-html not always splitting HTML tags into separate
lines (#558)
[pull #564] Fix incomplete comments in safe mode not being escaped (#563)
[pull #566] Fix crash in markdown-in-html extra (#565)

ChangeLog:

* Thu Apr  4 2024 Thomas Moschny  - 2.4.13-1
- Update to 2.4.13.




 waf-2.0.27-1.el8 (FEDORA-EPEL-2024-1bcf0f8e37)
 A Python-based build system

Update Information:

WAF 2.0.27
Improve Qt6 detection on msvc #2423
Fix a regression in the detection of QtX3D libraries #2367
Avoid coloring all MSVC logs #2366
Switch to nonstopmode for latex prompts #2421
Restrict executable detection to files having the executable bits #2349

ChangeLog:

* Thu Apr  4 2024 Thomas Moschny  - 2.0.27-1
- Update to 2.0.27.
* Sat Jan 27 2024 Fedora Release Engineering  - 
2.0.26-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild


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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-07e8f5f1f0   
libopenmpt-0.7.6-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-d9102d9191   
clojure-1.8.0-3.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-1f6e851537   
trafficserver-9.2.4-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

nghttp2-1.33.0-1.3.el7

Details about builds:



 nghttp2-1.33.0-1.3.el7 (FEDORA-EPEL-2024-866ac60917)
 Experimental HTTP/2 client, server and proxy

Update Information:

fix CONTINUATION frames DoS (CVE-2024-28182)

ChangeLog:

* Thu Apr  4 2024 Jan Macku  - 1.33.0-1.3
- fix CONTINUATION frames DoS (CVE-2024-28182)

References:

  [ 1 ] Bug #2268639 - CVE-2024-28182 nghttp2: CONTINUATION frames DoS
https://bugzilla.redhat.com/show_bug.cgi?id=2268639


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

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Adam Williamson]

On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote:
> On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> > 
> > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> > > So here are three brainstorming proposals:
> > > 
> > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be
> > > careful about how we do it. I would still promote Fedora Workstation as 
> > > the
> > > main/recommended "leading" desktop, would call Plasma an "alternative
> > > desktop option," and would strongly caution against use of the word
> > > "Workstation" anywhere in the branding for the Plasma version. That is,
> > > let's continue to steer undecided users towards Fedora Workstation, while
> > > making Plasma easier to find and presenting it more prominently than it is
> > > today.
> > 
> > I like this proposal. It would give the KDE spin more prominence and
> > would be a good reply to the huge work that has been put into the spin
> > in recent times. It also wouldn't disrupt our story about Fedora 
> > Workstation.
> > 
> > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
> > confused with Fedora Workstation.
> > 
> 
> So, effectively no change other than it moves from the Spins section
> to the Editions section? That would also mean it should be on the
> front page too, like the other Editions.

Being an Edition is a very significant thing, though, as we conceive of
Fedora more widely than just the download page. We put a bunch of hoops
in the way of IoT and CoreOS becoming editions, and there are hoops in
the way of Silverblue becoming one (or, you know, wherever we go with
that path in the end).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Neal Gompa]

On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> > So here are three brainstorming proposals:
> >
> > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be
> > careful about how we do it. I would still promote Fedora Workstation as the
> > main/recommended "leading" desktop, would call Plasma an "alternative
> > desktop option," and would strongly caution against use of the word
> > "Workstation" anywhere in the branding for the Plasma version. That is,
> > let's continue to steer undecided users towards Fedora Workstation, while
> > making Plasma easier to find and presenting it more prominently than it is
> > today.
>
> I like this proposal. It would give the KDE spin more prominence and
> would be a good reply to the huge work that has been put into the spin
> in recent times. It also wouldn't disrupt our story about Fedora Workstation.
>
> If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
> confused with Fedora Workstation.
>

So, effectively no change other than it moves from the Spins section
to the Editions section? That would also mean it should be on the
front page too, like the other Editions.

> > (b) Alternatively, elevate the positioning of all spins on the
> > fedoraproject.org homepage. Place the link to the spins right next to the
> > link to Fedora Workstation, above the atomic desktops (which are sadly still
> > experimental), above the Fedora labs and ALT downloads, and honestly
> > probably above the non-desktop Fedora editions. Nobody is going to be
> > confused as to which one is the primary product.
>
> I'm not sure. I think the getfedora.o page could use some work, but
> just moving one or two things might not be enough. For me, when using
> the website is the huge list semi-orthogonal categories:
> the top-level split is:
>   - editions, as individual items
>   - atomic desktops
>   - spins
>   - labs
>   - alt downloads
> Alt downloads is split into:
>   - Fedora 40 beta
>   - network installer
>   - torrent downloads
>   - alternate architectures (even though download pages also have 
> architectures?)
>   - cloud base images
>   - testing images
>   - rawhide
> The Fedora Spins looks great, IMO.
> The Fedora Labs page looks nice too.
>
> There's also a visual split
> I also always struggle to find Beta releases when I need them.
> In some places there's a banner with a link, in other places there's a toogle.
>
> And there are at least three domains:
> getfedora.org, fedoraproject.org, alt.fedoraproject.org.
>
> This is hard to navigate. It seems that each subpage uses a different
> categorization and way to split things. And the different subpages
> use different visual styles.
>
> I think we should have:
>   a) one domain
>
>   b) a flat categorization where you first select the type
>   (one of the editions or the desktops or spins or labs or network
>   installer or cloud image).
>
>   The editions should be listed prominently, and the other things can
>   lower in the page or require a click to show.
>
>   c) at all subpages there should be a toggle button to show
>   pre-release
>
>   d) once you know what to download, you can see
>   the architecture and format options and torrent vs. iso.
>
> In such a structure the same "procedure" would be used to navigate
> different choices, making it easier to figure out what all the options
> are.
>

There are only two artifacts left on alt.fedoraproject.org that really
need to be moved to the main site:

- the Everything netinstall ISO
- the Fedora base container images

We should maybe consider adding the torrent downloads to the main site, I guess?

The alternative architecture images page needs to be decommissioned,
as it's redundant with the content on the main site. The rest of
alt.fedoraproject.org is probably fine as it is, as I doubt we want to
put Rawhide somewhere on the main site.

(Also, as an aside, I learned that Workstation has a ppc64le ISO, I
guess we should ensure KDE has one too, it's not like we don't have it
for Kinoite already.)






--
真実はいつも一つ！/ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote:
> So here are three brainstorming proposals:
> 
> (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be
> careful about how we do it. I would still promote Fedora Workstation as the
> main/recommended "leading" desktop, would call Plasma an "alternative
> desktop option," and would strongly caution against use of the word
> "Workstation" anywhere in the branding for the Plasma version. That is,
> let's continue to steer undecided users towards Fedora Workstation, while
> making Plasma easier to find and presenting it more prominently than it is
> today.

I like this proposal. It would give the KDE spin more prominence and
would be a good reply to the huge work that has been put into the spin
in recent times. It also wouldn't disrupt our story about Fedora Workstation.

If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be
confused with Fedora Workstation.

> (b) Alternatively, elevate the positioning of all spins on the
> fedoraproject.org homepage. Place the link to the spins right next to the
> link to Fedora Workstation, above the atomic desktops (which are sadly still
> experimental), above the Fedora labs and ALT downloads, and honestly
> probably above the non-desktop Fedora editions. Nobody is going to be
> confused as to which one is the primary product.

I'm not sure. I think the getfedora.o page could use some work, but
just moving one or two things might not be enough. For me, when using
the website is the huge list semi-orthogonal categories:
the top-level split is:
  - editions, as individual items
  - atomic desktops
  - spins
  - labs
  - alt downloads
Alt downloads is split into:
  - Fedora 40 beta
  - network installer
  - torrent downloads
  - alternate architectures (even though download pages also have 
architectures?)
  - cloud base images
  - testing images
  - rawhide
The Fedora Spins looks great, IMO.
The Fedora Labs page looks nice too.

There's also a visual split 
I also always struggle to find Beta releases when I need them.
In some places there's a banner with a link, in other places there's a toogle.

And there are at least three domains:
getfedora.org, fedoraproject.org, alt.fedoraproject.org.

This is hard to navigate. It seems that each subpage uses a different
categorization and way to split things. And the different subpages
use different visual styles.

I think we should have:
  a) one domain

  b) a flat categorization where you first select the type
  (one of the editions or the desktops or spins or labs or network
  installer or cloud image).

  The editions should be listed prominently, and the other things can
  lower in the page or require a click to show.

  c) at all subpages there should be a toggle button to show
  pre-release

  d) once you know what to download, you can see
  the architecture and format options and torrent vs. iso.

In such a structure the same "procedure" would be used to navigate
different choices, making it easier to figure out what all the options
are.
  
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Aaron Rainbolt]

On 4/4/24 15:36, Przemek Klosowski via devel wrote:

On 4/3/24 17:49, Kevin Kofler via devel wrote:


And is there a statistical evaluation of that data somewhere? Downloading
350 MiB (!) of raw CSV data does not sound to me like a convenient way to
work with it.


It's messy, but interesting. Here's the architecture data for the last 
3 or so years:


from top to bottom, x86_64 aarch64 ppc64le s390x armhfp i386 arm 
powerpc64 riscv64


so you can see the decline of armhfp and i386.

I don't know what to make of the relatively large population of 
ppc64le and s390x; I think maybe IBM is eating their own dogfood and 
using it in some internal datacenters?


I am pleased to see RISC-V showing up within last year!

Very impressive. I tried to make a table of output using a Python script 
and it ended up being so inefficient for reasons I don't understand (a 
bug in my code possibly/likely) that I couldn't get the final report to 
ever come out.


sqlite -csv :memory:

.import totals.csv t

select date(round(julianday(week_end)/30)*30) as Tx, count(os_arch) 
filter (where os_arch like "x86_64") as x86_64, count(os_arch) filter 
(where os_arch like "aarch64") as aarch64,  count(os_arch) filter 
(where os_arch like "ppc64le") as ppc64le, count(os_arch) filter 
(where os_arch like "s390x") as s390x,  count(os_arch) filter (where 
os_arch like "armhfp") as armhfp, count(os_arch) filter (where os_arch 
like "i386") as i386,count(os_arch) filter (where os_arch like "arm") 
as arm, count(os_arch) filter (where os_arch like "powerpc64") as 
powerpc64, count(os_arch) filter (where os_arch like "riscv64") as 
riscv64 from t group by tx





--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:ubuntu.com
IRC: arraybolt3 on libera.chat and oftc.net
GitHub:https://github.com/ArrayBolt3
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Stephen Smoogen]

On Thu, 4 Apr 2024 at 16:37, Przemek Klosowski via devel <
devel@lists.fedoraproject.org> wrote:

> On 4/3/24 17:49, Kevin Kofler via devel wrote:
>
>
>
Thanks for doing this. I would have loved to find a way to just have
gnuplot do this nightly


> And is there a statistical evaluation of that data somewhere? Downloading
> 350 MiB (!) of raw CSV data does not sound to me like a convenient way to
> work with it.
>
> It's messy, but interesting. Here's the architecture data for the last 3
> or so years:
>

I found using a 4 day moving average cleaned up a lot of issues ranging
from Fedora proxy logs not being gotten due to script issues or similar. It
also evened out the Friday night to Monday morning drop on all items we
have seen in the older yum data also.


> from top to bottom, x86_64 aarch64 ppc64le s390x armhfp i386 arm powerpc64
> riscv64
>
> so you can see the decline of armhfp and i386.
>
> I don't know what to make of the relatively large population of ppc64le
> and s390x; I think maybe IBM is eating their own dogfood and using it in
> some internal datacenters?
>

When I looked at it several years ago it was being used all over from the
IP space. Some of it was IBM, some of it was IBM cloud and some of it was
various universities and stuff.



> I am pleased to see RISC-V showing up within last year!
>
>
> sqlite -csv :memory:
>
> .import totals.csv t
>
> select date(round(julianday(week_end)/30)*30) as Tx, count(os_arch) filter
> (where os_arch like "x86_64") as x86_64, count(os_arch) filter (where
> os_arch like "aarch64") as aarch64,  count(os_arch) filter (where os_arch
> like "ppc64le") as ppc64le, count(os_arch) filter (where os_arch like
> "s390x") as s390x,  count(os_arch) filter (where os_arch like "armhfp") as
> armhfp, count(os_arch) filter (where os_arch like "i386") as
> i386,count(os_arch) filter (where os_arch like "arm") as arm,
> count(os_arch) filter (where os_arch like "powerpc64") as powerpc64,
> count(os_arch) filter (where os_arch like "riscv64") as riscv64 from t
> group by tx
>
>
>
>

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Gordon Messmer]

On 2024-04-04 06:10, Zbigniew Jędrzejewski-Szmek wrote:

+1. I put the tool on my TODO list of things to look into.



When you get that time, I've also opened the following PR that includes 
a proof-of-concept test


https://src.fedoraproject.org/rpms/openssh/pull-request/73

It's sloppy at the moment.  The GEF extension should probably be 
packaged and not bundled in the test.  If this is an interesting 
approach it should probably be a shared test instead, and used in 
various other packages that commonly listed on network ports.  But I 
think this at least illustrates what I'm suggesting.
--
___
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

Heads-up: Planning retirement of rust-cpython and rust-python3-sys

[Fabio Valentini]

Hello Rustaceans and Pythonistas,

The "cpython" and "python3-sys" crates provide Rust bindings for
CPython, but the project is no longer actively maintained [0], and it
does not support CPython 3.12+ due to ABI / API changes. Programs that
use the "cpython" bindings for building against CPython 3.12+ crash at
runtime.

The upstream project recommends projects to move to the PyO3 bindings,
which are much more popular now, are actively maintained, and which
have been adding support for new versions of CPython pretty quickly
over the past few years.

The only package in Fedora that depends on the "cpython" bindings is
mercurial, which uses them for building the "mercurial-rust"
extensions. These extensions do not work on Fedora 39+ due to the
aforementioned changes in Python 3.12+. I reported this as an issue
half a year ago [1], but got no response from the mercurial
maintainers.

My recommendation would be to disable building the mercurial-rust
extensions on Fedora 39+ (where they already don't work!) until
mercurial upstream moves to PyO3 to properly support CPython 3.12+.

I am planning to retire the "rust-cpython" and "rust-python3-sys"
crates next week.

Fabio

[0]: https://github.com/dgrunwald/rust-cpython/commit/e81
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2249383
--
___
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 vim-editorconfig

[Ben Beasley]

I’m orphaning vim-editorconfig.

While it’s probably still useful in EPEL8 and EPEL9, it is (according to 
https://github.com/editorconfig/editorconfig-vim/issues/234) no longer 
needed by users of recent versions of vim and neovim since those editors 
now include its functionality. It’s therefore not clear that it needs to 
have a future in Fedora.


The package is in good condition and requires minimal maintenance; if 
anyone knows of a reason why it might still have users in Fedora, feel 
free to pick it up. Otherwise, it can fade away quietly.

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

[Fabio Valentini]

On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel
 wrote:
>
> On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > > The short answer is: No, "fedpkg local" is not expected to work for
> > > > Rust packages, and probably won't ever work as expected for Rust
> > > > packages.
> > > >
> > > > I am not really interested in adding the "--allow-dirty" flag (not
> > > > sure if it would even work in this case), since building Rust packages
> > > > with "fedpkg local" is not working for other reasons. Primarily,
> > > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > > this is only supported when building in mock.
> >
> > > I don't know what you mean? For me after patching the macro locally
> > > local builds work as expected. Maybe I'm overlooking something?
> >
> > You might be lucky and just tried to package a Rust crate with no
> > dependencies?
> > Dependencies on other Rust crates are only resolved dynamically at build
> > time, which "fedpkg local" does not support. So it works "by accident" for
> > Rust crates with no crate dependencies, but in general, it can't work.
>
> That would have been extremely lucky, but no, I'm building crates with
> dependencies. And the build generates the requires list just fine.
>
> What is not possible is installing build dependencies directly from a
> spec file from a fresh clone, if that is what you mean? But in this case
> running a local build generates a `.buildreqs.nosrc.rpm` file with the
> correct dependencies, which can be passed to `dnf builddep`.
>
> And since a local build does not manage build dependencies themselves,
> rather relies on them just being there, I don't really see an issue in
> that?

If you really don't mind jumping through multiple hoops just because
you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
guess I can't stop you.

All I *can* do is tell you that you're not going to like the experience:

- Using "fedpkg local" is not supported for Rust packages, and I won't
be adding workarounds to the Rust macros for it.
- Installing rust-*-devel packages on your local system (i.e. outside
of ephemeral build environments) is not supported.
- The "rust-*-devel" packages are build system implementation details,
if you want to say it like that.
- They are not shipped to users and are not useful for Rust developers.
- They are *only* intended to be installed in temporary chroots (like
those set up by mock).
- They don't get "Obsoletes" or "Provides" in case there are dropped
subpackages and / or incompatible updates. This is not an issue
because they are only ever *installed*, but never supposed to be
*upgraded* in-place. Any issues you get by installing them on your
host system are your own.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Przemek Klosowski via devel]

On 4/3/24 17:49, Kevin Kofler via devel wrote:


And is there a statistical evaluation of that data somewhere? Downloading
350 MiB (!) of raw CSV data does not sound to me like a convenient way to
work with it.


It's messy, but interesting. Here's the architecture data for the last 3 
or so years:


from top to bottom, x86_64 aarch64 ppc64le s390x armhfp i386 arm 
powerpc64 riscv64


so you can see the decline of armhfp and i386.

I don't know what to make of the relatively large population of ppc64le 
and s390x; I think maybe IBM is eating their own dogfood and using it in 
some internal datacenters?


I am pleased to see RISC-V showing up within last year!


sqlite -csv :memory:

.import totals.csv t

select date(round(julianday(week_end)/30)*30) as Tx, count(os_arch) 
filter (where os_arch like "x86_64") as x86_64, count(os_arch) filter 
(where os_arch like "aarch64") as aarch64, count(os_arch) filter (where 
os_arch like "ppc64le") as ppc64le, count(os_arch) filter (where os_arch 
like "s390x") as s390x, count(os_arch) filter (where os_arch like 
"armhfp") as armhfp, count(os_arch) filter (where os_arch like "i386") 
as i386,count(os_arch) filter (where os_arch like "arm") as arm, 
count(os_arch) filter (where os_arch like "powerpc64") as powerpc64, 
count(os_arch) filter (where os_arch like "riscv64") as riscv64 from t 
group by tx



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

Heads-up: Updating python-markdown to 3.6 in F41/Rawhide

[Thomas Moschny]

Dear all,

Just a heads up that python-markdown has just been updated in
rawhide/f41 to 3.6.

See here for the list of changes:
https://python-markdown.github.io/changelog/#36-2024-03-14

This will not be pushed to released Fedora branches.

Best regards
-- 
Thomas Moschny 
--
___
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

[pfed--- via devel]

On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > The short answer is: No, "fedpkg local" is not expected to work for
> > > Rust packages, and probably won't ever work as expected for Rust
> > > packages.
> > >
> > > I am not really interested in adding the "--allow-dirty" flag (not
> > > sure if it would even work in this case), since building Rust packages
> > > with "fedpkg local" is not working for other reasons. Primarily,
> > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > this is only supported when building in mock.
> 
> > I don't know what you mean? For me after patching the macro locally
> > local builds work as expected. Maybe I'm overlooking something?
> 
> You might be lucky and just tried to package a Rust crate with no
> dependencies?
> Dependencies on other Rust crates are only resolved dynamically at build
> time, which "fedpkg local" does not support. So it works "by accident" for
> Rust crates with no crate dependencies, but in general, it can't work.

That would have been extremely lucky, but no, I'm building crates with
dependencies. And the build generates the requires list just fine.

What is not possible is installing build dependencies directly from a
spec file from a fresh clone, if that is what you mean? But in this case
running a local build generates a `.buildreqs.nosrc.rpm` file with the
correct dependencies, which can be passed to `dnf builddep`.

And since a local build does not manage build dependencies themselves,
rather relies on them just being there, I don't really see an issue in
that?

Philip Matura
--
___
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: Orphaned packages looking for new maintainers

[Thomas Moschny]

Hi,

sorry for the late response, have been a bit busy recently...

Yes, we should remove botan (1) from Fedora - that has also been a request
by upstream. The point is, I want to keep monotone, and it needs a bit of
work to switch it over to botan2. There exists a branch that should have
the necessary changes, but no released version.

Anyway, the monotone switch will not make it in time for F40 I guess, but
I'll look into it.

Regarding botan3, I guess no one has volunteered yet to maintain it.

Regards,
Thomas


Am Do., 4. Apr. 2024 um 20:28 Uhr schrieb Jens-Ulrik Petersen <
peter...@redhat.com>:

> https://botan.randombit.net/handbook/support.html#branch-support-status
> can be referenced in the retirement commit:
>
> Branch
>
> First Release
>
> End of Active Development
>
> End of Life
>
> Botan 1.8
>
> 2008-12-08
>
> 2010-08-31
>
> 2016-02-13
>
> Botan 1.10
>
> 2011-06-20
>
> 2012-07-10
>
> 2018-12-31
> (Though 1.11.x also exists, or was that a devel series for botan2?)
> --
> ___
> 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
>


-- 
Thomas Moschny 
--
___
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: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 08:11:42PM +0200, Leon Fauster via devel wrote:
> 
> One approach that would be at least bring some light into "weak"
> (non technical layer) components (albeit not sure how feasible it is),
> could be:
> 
>  - Checking the resources of a packaged project.
>Resources in terms of man or firm power that backup the project
> 
>  - Contribution activity of people
> 
>  - General activity of the project
> 
>  - Transparency of the workflow / tools
> 
> and that for all projects that the distribution includes.
> 
> Why? This would allow to plan internal review activities
> (or processes) more effectively. They would be directed
> to the "weak" components with higher priority (recurrent, actions).
> 
> 
> Like the current process for checking the license (SPDX) of a project,
> it could also collect such metrics right away.

Well, as others have noted there is already OpenSSF scorecards.

I agree it's good to know this info, and for maintainers that have a ton
of packages they maintain, it might be good to be able to look at this
to remind them. For maintainers with fewer packages, they likely already
just know this from interacting with the upstream project already.

I don't think we can or should use that for things like deciding if we
allow packages into the collection or the like, there's a lot of ways a
low score there could not matter or be non represenative of what the
project is like.

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: F41 Change Proposal: Switch to DNF5 (system-wide)

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 07:00:13AM +0200, Jan Kolarik wrote:
> Hi guys,
> 
> the dnf-automatic command will be obsoleted.
> >
> 
> Oh, sorry about that. This portion of the text was inadvertently altered
> during the review process. I've already corrected the text on the wiki.
> 
> The dnf-automatic command will still be available, now provided as a plugin
> and functionally compatible with dnf4. Although the configuration files'
> location has changed, it will be documented in the dnf4 vs. dnf5 changes
> documentation .

Yeah, on digging more into the docs it looks like this should be fine.

Just needs adjustment of the config and enabling the timer you want.

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: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

https://botan.randombit.net/handbook/support.html#branch-support-status
can be referenced in the retirement commit:

Branch

First Release

End of Active Development

End of Life

Botan 1.8

2008-12-08

2010-08-31

2016-02-13

Botan 1.10

2011-06-20

2012-07-10

2018-12-31
(Though 1.11.x also exists, or was that a devel series for botan2?)
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Andreas Tunek]

Den ons 3 apr. 2024 kl 23:27 skrev Kevin Kofler via devel <
devel@lists.fedoraproject.org>:

> Andreas Tunek wrote:
> > From Red Hat's POV it is not Fedora Gnome Workstation (
> >
> https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/
> > ).
>
> TL;DR: "We do not want 'GNOME' in the name because we want to only support
> GNOME in Workstation, whereas 'GNOME Workstation' would imply that there
> are
> other Workstations."
>
> I am not sure I buy this argument. By the same argument, we should also
> not
> call the OS "Fedora Linux" because it implies there is also a "Fedora BSD"
> or "Fedora Hurd" or even "Fedora Windows" ;-) or something.
>
>
Yes, Fedora used to have a correct name, but it was changed.


> Giving a product a clear name does not imply existence of another product.
>
> (And that is not even arguing the premise of the "one single Workstation
> that happens to use GNOME" concept, only the branding implications!)
>
> > One of the best things with Fedora Workstation is that it is a complete
> > user facing OS (like Windows, macOS and iOS) that you actually can
> develop
> > applications for (if you want to). You don't have to target the extremely
> > fluffy "Linux desktop", you can target Fedora Workstation. This proposal
> > would totally eliminate the good points of having this single OS and app
> > platform.
>
> That "conveniently" ignores the existence of that pesky thing called
> "other
> distributions". The GNU/Linux version of vendor lock-in. Thanks Red Hat!
>
> And besides, a standalone application (as opposed to a desktop widget or
> similar) developed for one of the Fedora desktop deliverables (Workstation
> Edition, desktop Spins) is also going to work on any of the others.
>

>From the user facing app side, if you want to implement support for your
company's weird week numbering system in the calendar widget in Fedora
Workstation you can do that today. If there were two desktop systems it
would be more than twice the work (since you need two distinct dev
environments).

>From the infrastructure side it is even worse. Red Hat has been very
successful using Fedora as the first implementation from things like
systemd to PipeWire zero copy screen sharing. I believe that has been aided
by the fact that it is possible to do one implementation instead of
several. When you see that things work you can make everything "API
stable"*  and usable by other systems. If you have several desktop systems
they will have diverging feature set (as Schaller wrote in his blog post)
or development will slow down quite a lot.

You might call this "vendor lock in", but from my perspective things like
systemd and PipeWire have been very successful projects that have gotten
support from a majority of the free software eco-system. And I think they
have been aided by the focus on Fedora and the fact that Fedora Workstation
is ONE platform.

/Andreas

*Or how things are suppose to work together, it is hard to find the right
words.


>
> 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
>
--
___
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: Switching XZ for ZSTD?

[Alexander Sosedkin]

On Thu, Apr 4, 2024 at 8:00 PM Arnie T via devel
 wrote:
>
> Hello Kevin,
>
> > I'm hopeful some things will come out of this as it's a chance for us to
> > look at our processes and improve them.
>
> I'm glad that's happening.  It seems to me that improving those processes 
> would be Distro decisions.  Which I keep understanding don't really exist.  
> At least not quickly.
> So I'm confused still. But glad.
>
>
> > > 1] Lack of committer 'Real' identity confidence and verification is a 
> > > problem.
>
> > IMHO this isn't a problem. We don't have a right to demand anything from
> > open source projects. We can ask, we can urge, we can contribute and
> > change things, we can choose to not use something, or fork something.
>
> I really don't suggest 'demanding' anything.  I do think it's wise to make 
> choices to avoid it.  Like just my example of a critical-path XZ with one 
> developer vs a critical-path ZSTD built & maintained in a Facebook FOSS 
> project.
>
> I know from just a business view I would never enter into a 'critical' 
> contract without "knowing" the principal persons.  Of course you must know 
> what you need "knowing" to be.

Careful, for now you're approaching another scalability issue of the
community development model.
I mean, as chill as he is, even Daniel Stenberg [1] must have a limit
on the amount of beers he can handle.

> > > 2] Undetected differences source + packaging in repo vs tarballs are 
> > > unchecked.
> >
> >
> > Yeah, a lot of the discussion has been in this area.
> >
> > I'm wondering if perhaps we shouldn't revisit source-git, or at least
> > a variant of it where we keep the upstream sources in a branch always
> > and apply packaging on top of that and build from there.
>
> I'm not sure what the packaging tools and rules are here.
> It seems to me that repo source with an attested commit (signature? published 
> hash?) can serve as the one source of truth.
> Then users can pull the commit or the on-demand API-generated tarball.  I 
> guess that could be subject to for example Github's or Gitlab's API tarball 
> generators being hacked.  But that seems less probable of a concern.
>
> > > 3] Under-resourced development creates risk; 'Many eyes' bench depth in 
> > > development is needed.
> >
> > Yep. I think also visibility of changes can be improved.
> > So, maintainers know more about whats in a new version and how it works.
>
> You can implement tools to increase the visibility for sure. And procedures.
>
> Also just the "given enough eyeballs, all bugs are shallow" that comes with 
> using a larger project helps.
>
> Thanks for the discussion.
>
> Cheers!
>
>  Arnie

[1] https://daniel.haxx.se
--
___
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: Switching XZ for ZSTD?

[Leon Fauster via devel]

Am 04.04.24 um 19:23 schrieb Kevin Fenzi:

On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:

Hi,

I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version of 
Fedora 39 release and one of Fedora 40 to see where things are going.

I learned about this XZ-hack from Ars Technica & The Economist.

I got to the Fedora Magazine article and wasn't really clear on that.

So I followed the discussion to this thread in this Development mailing list.

I read a lot of it but _still_ can't 100% figure out what the final solution is 
going to be.


There's no 'solution' really... there's a lot of discussion around what
we can improve at the distro level, what we can urge upstreams to do,
how we can help out more, etc.

I'm hopeful some things will come out of this as it's a chance for us to
look at our processes and improve them.



One approach that would be at least bring some light into "weak"
(non technical layer) components (albeit not sure how feasible it is),
could be:

 - Checking the resources of a packaged project.
   Resources in terms of man or firm power that backup the project

 - Contribution activity of people

 - General activity of the project

 - Transparency of the workflow / tools

and that for all projects that the distribution includes.

Why? This would allow to plan internal review activities
(or processes) more effectively. They would be directed
to the "weak" components with higher priority (recurrent, actions).


Like the current process for checking the license (SPDX) of a project,
it could also collect such metrics right away.


--
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: Switching XZ for ZSTD?

[Arnie T via devel]

Hello Kevin,

> I'm hopeful some things will come out of this as it's a chance for us to
> look at our processes and improve them.

I'm glad that's happening.  It seems to me that improving those processes would 
be Distro decisions.  Which I keep understanding don't really exist.  At least 
not quickly.
So I'm confused still. But glad.


> > 1] Lack of committer 'Real' identity confidence and verification is a 
> > problem.

> IMHO this isn't a problem. We don't have a right to demand anything from
> open source projects. We can ask, we can urge, we can contribute and
> change things, we can choose to not use something, or fork something.

I really don't suggest 'demanding' anything.  I do think it's wise to make 
choices to avoid it.  Like just my example of a critical-path XZ with one 
developer vs a critical-path ZSTD built & maintained in a Facebook FOSS project.

I know from just a business view I would never enter into a 'critical' contract 
without "knowing" the principal persons.  Of course you must know what you need 
"knowing" to be.

> > 2] Undetected differences source + packaging in repo vs tarballs are 
> > unchecked.
> 
> 
> Yeah, a lot of the discussion has been in this area.
> 
> I'm wondering if perhaps we shouldn't revisit source-git, or at least
> a variant of it where we keep the upstream sources in a branch always
> and apply packaging on top of that and build from there.

I'm not sure what the packaging tools and rules are here.
It seems to me that repo source with an attested commit (signature? published 
hash?) can serve as the one source of truth.
Then users can pull the commit or the on-demand API-generated tarball.  I guess 
that could be subject to for example Github's or Gitlab's API tarball 
generators being hacked.  But that seems less probable of a concern.

> > 3] Under-resourced development creates risk; 'Many eyes' bench depth in 
> > development is needed.
> 
> Yep. I think also visibility of changes can be improved.
> So, maintainers know more about whats in a new version and how it works.

You can implement tools to increase the visibility for sure. And procedures.

Also just the "given enough eyeballs, all bugs are shallow" that comes with 
using a larger project helps.

Thanks for the discussion.

Cheers!

 Arnie
--
___
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: Switching XZ for ZSTD?

[Arnie T via devel]

Hi Guinevere,

> TL;DR: as with most security issues, end users should update their systems.
>
> I think you may be caught in some news exaggeration. Don't get me wrong, this 
> hack was a huge thing, but it was discovered early enough that most (i'd 
> guess almost all) fedora users wont' have to do anything.
>
> For Fedora, the problem package was only in Fedora 40 Beta and Fedora 
> Rawhide. If you are not running these packages, this isn't more than a "wow, 
> that was a near miss" for the end user. If you are running either version, 
> the xz maintainer has already rolled back the problem update, so if you use 
> "dnf update" you are safe.
>
> Because of a stroke of luck (finding this as early as we did) its as simple 
> as that, we have an assumed good version that users can 'update' to, and 
> beyond that, us developers need to verify that the assumed good version is 
> actually good, and if it isn't, issue new updates.

That was simply explained without burying it. Thanks.

Someone again in private complained at me for "I should have read" the Fedora 
Magazine.

Somehow I am supposed to know that Fedora *Magazine* is the official info 
source for FedoraProject, not the front page or even "News & Announcements".

I guess I do now.

Now read what is written at 
https://fedoramagazine.org/cve-2024-3094-security-alert-f40-rawhide/.

Let me say I wish I had found your comment written in your way sooner! Even 
when you suspect it may be the case it's harder to evade any news exaggeration 
when it's not clear where to look or the places you do look are written in ways 
you can't clearly understand. So one more time, Thanks.

Cheers!

Arnie--
___
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: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 05:04:20PM +, Arnie T via devel wrote:
> Hi Stephen,
> 
> Thanks for the explanation.
> 
> I just caught up with the article at the New York Times,
> 
> Did One Guy Just Stop a Huge Cyberattack?
> https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html
> 
> And the comic that looks like it fits the problem I'm most noticing here!
> 
> https://xkcd.com/2347/
> 
> I have to admit that I still don't know what the best or most official "At 
> least do this" instruction page is for a Fedora user.
> I don't see anything at the main https://fedoraproject.org/ website or its 
> "News & Announcements" page.

The magazine article should cover this. 

If you are using Fedora 38 or Fedora 39, nothing to do. The versions
affected were never in there.

If you are using Fedora 40 (prerelease) or Rawhide you should urgently update.
This will get you the clean version. If you wish to be extra cautious,
you could reinstall from current nightly media.

> In this thread its becoming about the details of the process. But not yet 
> about a solution. All of which I get.
> And in private emails people are insisting on sending to me about how I'm 
> unreasonable for asking the questions, and "should have" understood this or 
> that.
> So, with your discussion the best guess I can some up with is to make sure XZ 
> is downgraded and just hope that one of this Jia Tan's 6000+ commits are 
> still hidden in some other project with not enough eyes. Or that the XKCD 
> coming true doesn't happen again.

Lots of folks are scrutinizing those commits.
There were some minor things discovered, but nothing (at least that I
know of right now) that affects Fedora.

There are changes coming in systemd, openssh and other places that would
make this particular vector harder/impossible also.

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: Switching XZ for ZSTD?

[Guinevere Larsen]

On 4/4/24 14:04, Arnie T via devel wrote:

Hi Stephen,

Thanks for the explanation.

I just caught up with the article at the New York Times,

 Did One Guy Just Stop a Huge Cyberattack?
https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html

And the comic that looks like it fits the problem I'm most noticing here!

https://xkcd.com/2347/

I have to admit that I still don't know what the best or most official 
"At least do this" instruction page is for a Fedora user.
I don't see anything at the main https://fedoraproject.org/ website or 
its "News & Announcements" page.


TL;DR: as with most security issues, end users should update their systems.

I think you may be caught in some news exaggeration. Don't get me wrong, 
this hack was a huge thing, but it was discovered early enough that most 
(i'd guess almost all) fedora users wont' have to do anything.


For Fedora, the problem package was only in Fedora 40 Beta and Fedora 
Rawhide. If you are not running these packages, this isn't more than a 
"wow, that was a near miss" for the end user. If you are running either 
version, the xz maintainer has already rolled back the problem update, 
so if you use "dnf update" you are safe.


Because of a stroke of luck (finding this as early as we did) its as 
simple as that, we have an assumed good version that users can 'update' 
to, and beyond that, us developers need to verify that the assumed good 
version is actually good, and if it isn't, issue new updates.




In this thread its becoming about the details of the process.  But not 
yet about a solution.  All of which I get.
And in private emails people are insisting on sending to me about how 
I'm unreasonable for asking the questions, and "should have" 
understood this or that.


So, with your discussion the best guess I can some up with is to make 
sure XZ is downgraded and just hope that one of this Jia Tan's 6000+ 
commits are still hidden in some other project with not enough eyes.  
Or that the XKCD coming true doesn't happen again.


Cheers!

 Arnie



--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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



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

Re: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:
> Hi,
> 
> I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version of 
> Fedora 39 release and one of Fedora 40 to see where things are going.
> 
> I learned about this XZ-hack from Ars Technica & The Economist.
> 
> I got to the Fedora Magazine article and wasn't really clear on that.
> 
> So I followed the discussion to this thread in this Development mailing list.
> 
> I read a lot of it but _still_ can't 100% figure out what the final solution 
> is going to be.

There's no 'solution' really... there's a lot of discussion around what
we can improve at the distro level, what we can urge upstreams to do,
how we can help out more, etc. 

I'm hopeful some things will come out of this as it's a chance for us to
look at our processes and improve them. 

> I have a question about that.
> 
> I'm for sure OK that a responsibly developed FOSS project can contribute 
> value and should be welcomed.
> 
> ISTM that if a package is used on critical-path or security-path by default 
> in a Distro it needs a higher bar.
> 
> IIUC from this thread and online discussions about XZ & alternatives that
> 
> 1] Lack of committer 'Real' identity confidence and verification is a problem.

IMHO this isn't a problem. We don't have a right to demand anything from
open source projects. We can ask, we can urge, we can contribute and
change things, we can choose to not use something, or fork something. 

> 2] Undetected differences source + packaging in repo vs tarballs are 
> unchecked.

Yeah, a lot of the discussion has been in this area. 

I'm wondering if perhaps we shouldn't revisit source-git, or at least
a variant of it where we keep the upstream sources in a branch always
and apply packaging on top of that and build from there. 

> 3] Under-resourced development creates risk; 'Many eyes' bench depth in 
> development is needed.

Yep. I think also visibility of changes can be improved.
So, maintainers know more about whats in a new version and how it works. 



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: Switching XZ for ZSTD?

[Arnie T via devel]

Hi Stephen,

Thanks for the explanation.

I just caught up with the article at the New York Times,

Did One Guy Just Stop a Huge Cyberattack?
https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html

And the comic that looks like it fits the problem I'm most noticing here!

https://xkcd.com/2347/

I have to admit that I still don't know what the best or most official "At 
least do this" instruction page is for a Fedora user.
I don't see anything at the main https://fedoraproject.org/ website or its 
"News & Announcements" page.

In this thread its becoming about the details of the process. But not yet about 
a solution. All of which I get.
And in private emails people are insisting on sending to me about how I'm 
unreasonable for asking the questions, and "should have" understood this or 
that.
So, with your discussion the best guess I can some up with is to make sure XZ 
is downgraded and just hope that one of this Jia Tan's 6000+ commits are still 
hidden in some other project with not enough eyes. Or that the XKCD coming true 
doesn't happen again.

Cheers!

Arnie--
___
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: Switching XZ for ZSTD?

[Chris Adams]

Once upon a time, Simon Farnsworth  said:
> Fedora made the same switch back in Fedora 31, and thus doesn't need to do 
> anything about package compression right now.

About this... I was looking at RPMs and found there are a couple of
packages that override _binary_payload in the SPEC to use xz: kernel and
ceph.  It appears they're doing it to get parallel threads (I guess not
specifically to override the format itself), but should they be changed?
The kernel SPEC actually mentions it might need to be changed if the
global default is changed.

Also - if the reason to override it is to get threads, is there any
reason to not always use threads?  ceph is doing:

%global _binary_payload w7T%{_smp_build_ncpus}.xzdio

Assuming the zstd backend supports the threads option (I haven't
looked), it seems like embedding T%{_smp_build_ncpus} might be a
reasonable thing to always do (to go along with how make_build already
uses %{?_smp_mflags}).

In the case of ceph, it's overriding _source_payload as well, which
seems unwanted (feels like somebody just grepped and copied).

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

Re: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

On Thu, Apr 4, 2024 at 12:51 AM Sandro  wrote:

> On 03-04-2024 18:35, Jens-Ulrik Petersen wrote:
> > I took botan [...]
>

I guess that was a bad idea - so I have re-orphaned it after some detailed
discussions with @penguinpee in #devel.
He also helped to decouple monotone from ikiwiki in rawhide, so the impact
should be less now.

The last botan-1.1 release was in 2018 and I think Debian/Ubuntu dropped
botan1 at the same time?
So it seems high time to remove this unmaintained version from Fedora too.
(We have botan2 in Fedora of course and I hope to see botan3 as well?)

It seems too late to do more on this for F40 now? or we would need an Final
Exception

Thanks, Jens
--
___
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: Switching XZ for ZSTD?

[Simon Farnsworth via devel]

On Thursday, 4 April 2024 17:20:25 BST Arnie T via devel wrote:
> Hello Stephen,
> 
> > How a decision to drop xz for some other compression library for software
> > would be a fairly slow process. First a person who is willing to do the
> > work would come up with a proposal on why it should be done and how it
> > could be done. They would be expected to also test to see how much
> > trouble this would be (aka find all the packages which use xz and could
> > be changed to another library, which ones couldn't and what the effects
> > would be.) Once that is done, they would make a general proposal to be
> > reviewed by whatever technical committee a distribution has (Fedora has
> > one whose acronym is FESCO, Debian has another or multiple others, etc).
> > This would be reviewed and if accepted it would go as a future release
> > work with a staged plan where some packages are moved in X release, some
> > in X+1, and some final plan for X+2 (or backed out completely for some
> > reason before then). There would be some amount of software which would
> > rely on xz no matter what because either the upstream has no interest in
> > changing or it is meant to use xz period. ...
> > Currently most groups are between 0 and 1. There are a lot of things which
> > need to be looked at before moving off can be looked at as a goal to make
> > sure we aren't making things worse.
> > 
> > I hope the above helps
> 
> Thanks, I understand more of your explanation of how it's done.
> 
> I don't know how much time was needed to decide for example an Arch Distro
> change
> 
> "Now using Zstandard instead of xz for package compression"
> https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-com
> pression/ OK, that's my mistake. I thought that moving to open source Linux
> OS Distro like Redhat-related Fedora would result big or important issues
> can be fixed more efficiently than at Microsoft.
> 
That is not a distro-wide change; that's changing one thing from `xz` to 
`zstd`.

Fedora made the same switch back in Fedora 31, and thus doesn't need to do 
anything about package compression right now.

The remaining things are a long tail of various bits and pieces that use `xz` 
for a variety of reasons, and where there needs to be a decision made; fwupd, 
for example, has switched, while the `xz` tool in the repo will probably never 
switch from `xz` to `zstd`.

> I guess I'm learning that even important or wise choices (not saying _this_​
> is) can't be done with taking a long time. Even if they are security
> related issues.
> 
> Thanks one more time for the nice explanation!
> 
> Cheers!
> 
> Arnie



--
___
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: Switching XZ for ZSTD?

[Stephen Smoogen]

On Thu, 4 Apr 2024 at 12:21, Arnie T via devel <
devel@lists.fedoraproject.org> wrote:

> Hello Stephen,
>
> How a decision to drop xz for some other compression library for software
> would be a fairly slow process. First a person who is willing to do the
> work would come up with a proposal on why it should be done and how it
> could be done. They would be expected to also test to see how much trouble
> this would be (aka find all the packages which use xz and could be changed
> to another library, which ones couldn't and what the effects would be.)
> Once that is done, they would make a general proposal to be reviewed by
> whatever technical committee a distribution has (Fedora has one whose
> acronym is FESCO, Debian has another or multiple others, etc). This would
> be reviewed and if accepted it would go as a future release work with a
> staged plan where some packages are moved in X release, some in X+1, and
> some final plan for X+2 (or backed out completely for some reason before
> then). There would be some amount of software which would rely on xz no
> matter what because either the upstream has no interest in changing or it
> is meant to use xz period.
> ...
> Currently most groups are between 0 and 1. There are a lot of things which
> need to be looked at before moving off can be looked at as a goal to make
> sure we aren't making things worse.
>
> I hope the above helps
>
>
> Thanks, I understand more of your explanation of how it's done.
>
> I don't know how much time was needed to decide for example an Arch Distro
> change
>
> "Now using Zstandard instead of xz for package compression"
>
> https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
>
>
So that is an individual package choice a distribution maintainer(s) can
make. In this case the pacman maintainers decided to use a different
library for their packages. It doesn't change anything outside of that one
tool though. It is also not getting rid of xz from Arch. They will need to
keep xz around because older systems will have used the older compression
and pacman and similar tools will need to 'read' that. It mainly means that
newer packages will use zstandard versus xz.

A similar change in Fedora would be that rpm uses zstandard by default etc.
However rpm would need to keep xz because of 10 years of using xz as a
compression standard in various RPMs and people need to install older
software.


> OK, that's my mistake.  I thought that moving to open source Linux OS
> Distro like Redhat-related Fedora would result big or important issues can
> be fixed more efficiently than at  Microsoft.
>
>
Decisions are people issues and people issues move at people speeds. There
are about 1600 packagers in Fedora and I think 22,000 packages. Changes
take time to communicate, understand and implement. The worst thing to do
in a security situation is actually move too fast because you think you are
getting ahead of the attacker. I have seen too many times where the
attacker was waiting for said move and it makes their life easier. In this
case, a bit of time is needed to really get an idea of what else is screwed
up and where we need to fix things.



> I guess I'm learning that even important or wise choices (not saying _
> this_ is) can't be done with taking a long time.  Even if they are
> security related issues.
>
> Thanks one more time for the nice explanation!
>
> Cheers!
>
>  Arnie
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Switching XZ for ZSTD?

[Arnie T via devel]

Hello Stephen,

> How a decision to drop xz for some other compression library for software 
> would be a fairly slow process. First a person who is willing to do the work 
> would come up with a proposal on why it should be done and how it could be 
> done. They would be expected to also test to see how much trouble this would 
> be (aka find all the packages which use xz and could be changed to another 
> library, which ones couldn't and what the effects would be.) Once that is 
> done, they would make a general proposal to be reviewed by whatever technical 
> committee a distribution has (Fedora has one whose acronym is FESCO, Debian 
> has another or multiple others, etc). This would be reviewed and if accepted 
> it would go as a future release work with a staged plan where some packages 
> are moved in X release, some in X+1, and some final plan for X+2 (or backed 
> out completely for some reason before then). There would be some amount of 
> software which would rely on xz no matter what because either the upstream 
> has no interest in changing or it is meant to use xz period.
> ...
> Currently most groups are between 0 and 1. There are a lot of things which 
> need to be looked at before moving off can be looked at as a goal to make 
> sure we aren't making things worse.
>
> I hope the above helps

Thanks, I understand more of your explanation of how it's done.

I don't know how much time was needed to decide for example an Arch Distro 
change

"Now using Zstandard instead of xz for package compression"
https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
OK, that's my mistake. I thought that moving to open source Linux OS Distro 
like Redhat-related Fedora would result big or important issues can be fixed 
more efficiently than at Microsoft.

I guess I'm learning that even important or wise choices (not saying _this_​ 
is) can't be done with taking a long time. Even if they are security related 
issues.

Thanks one more time for the nice explanation!

Cheers!

Arnie--
___
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: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

[Steve Grubb]

Hello,

I have been deleting most of these emails, but I feel like this is a bit 
myopic.

On Tuesday, April 2, 2024 6:25:56 PM EDT Kevin Kofler via devel wrote:
> Gary Buhrmaster wrote:
> 
> > And, more importantly, the industry has agreed
> > to use the term supply chain.  Is the term
> > perhaps overloaded, or perhaps too
> > ill-defined/imprecise?  Sure.  But if one wants
> > to use a different term one would need to work
> > across the industry to change the term, and
> > that is not going to happen.
> 
> Well, one could argue that Free Software is a community, not an industry,
> so  "the industry" cannot agree on anything, and "supply chain" as an
> industrial term obviously does not apply.

But it does. The term "supply chain" refers to the process of acquiring, 
organizing, and distributing the necessary resources and components to build 
and maintain the distribution. This includes acquiring source code from 
various upstream projects, integrating them into the distribution, and then 
packaging and distributing the final product to end-users. The supply chain 
involves a variety of tasks such as software development, testing, quality 
assurance, responding to bug reports, documentation, and support. IOW, it is 
a process.

It is the community that carries out the process.

-Steve

--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Naheem Zaffar]

On Thu, 4 Apr 2024, 16:35 Kevin Kofler via devel, <
devel@lists.fedoraproject.org> wrote:

> Neal Gompa wrote:
> > By default, GNOME only presents the close window button. The other
> > buttons are missing, and there isn't really an intuitive way to
> > discover the other window management actions.
>
> In the version I tried, and judging from end user reports, for several
> years, it did not even present that, leading to fun issues such as some
> KDE
> dialogs that could not be closed at all (because they were missing a
> "Close"
> button and relying on the window decoration exclusively).
>
> >> "the shut down options in the mouse menu hidden behind a keyboard dead
> >> key, etc.)" this is also not the case for ages, or at least not in its
> >> completeness.
> >
> > Yes, this did change a few GNOME releases ago.
>
> Of course, having only tried GNOME 3 once, I could not know this.
>

Of course the right thing to do when faced with a topic where you lack
knowledge is to not throw shade and either learn it first or decide others
know better and not comment.

What has been really awkward about this proposal is that instead of
focussing on the benefits of Plasma, it's used as more of an axe to grind
about gnome. Not unexpected considering the lead proposer.

However that is not helpful.

If you need to define gnome in order to promote plasma, you are doing it
wrong.

>
> 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
>
--
___
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: Switching XZ for ZSTD?

[Stephen Smoogen]

On Thu, 4 Apr 2024 at 11:22, Arnie T via devel <
devel@lists.fedoraproject.org> wrote:

>
> Hi,
>
> > There's no such thing as a "distro decision" on this one, as was
> > explained in the thread already.
>
> I'm sure the 'explanation' is all clear to you and the other Developers.
>
> I'm also sure that it's not all that clear to non-Developers.
>
> If the explanation was clear and obvious to me, here or anywhere ales, I
> wouldn't be asking the question.
>
> So, sorry, I guess.
>
> I guess I don't understand how a Distro decision is different from a
> Distro IN-decision.
>
>
Linux distributions are generally 'collective anarchies' where most
packages are up to the individual packagers to support how they want
things. 'Collectively' they will elect some group who will work out various
high level things like 'where should the files go?' 'how should the files
be packaged', 'what should we call ourselves', etc. These decisions may
override what the upstream (aka the people who write the compiler, kernel,
compression libraries, graphics, etc) but again it is usually a compromise.

How a decision to drop xz for some other compression library for software
would be a fairly slow process. First a person who is willing to do the
work would come up with a proposal on why it should be done and how it
could be done. They would be expected to also test to see how much trouble
this would be (aka find all the packages which use xz and could be changed
to another library, which ones couldn't and what the effects would be.)
Once that is done, they would make a general proposal to be reviewed by
whatever technical committee a distribution has (Fedora has one whose
acronym is FESCO, Debian has another or multiple others, etc). This would
be reviewed and if accepted it would go as a future release work with a
staged plan where some packages are moved in X release, some in X+1, and
some final plan for X+2 (or backed out completely for some reason before
then). There would be some amount of software which would rely on xz no
matter what because either the upstream has no interest in changing or it
is meant to use xz period.

Usually this would take a key person to drive it who understands the
problem and a team of people who would be interested in actually doing the
work. Without that the change will move slowly over many releases like the
licensing change to SPDR.

This is how a change would happen if it were decided to be done. At the
moment the distributions are first trying to figure out a couple of more
important things:
0. What happened?
1. What else might have been affected
2. What projects that are also in similar straights
3. What can be done to help these projects (is it inside our sphere of
control or influence).
4. What is a list of things that need to change.
...
N. Is moving off of these projects needed or possible?

Currently most groups are between 0 and 1. There are a lot of things which
need to be looked at before moving off can be looked at as a goal to make
sure we aren't making things worse.

I hope the above helps




> For example from what I can read you were in contact with this Jia Tan
> 'person' during this story.
>
> I hope that a Distro decision would support whatever it takes to give you
> the tools, time and support to make sure that this sort of thing doesn't
> sneak past you or anyone.
>
> If there's no way to make that kind of decision then it seems to me
> Developers could use better support.
>
> This all seems like a very big deal.  Which is why I guess I am reading
> about it on The Economist.  And why I'm hoping that the Distro has some
> options to take some actions.
>
> Cheers!
>
>  Arnie
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 40 compose report: 20240404.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240403.n.0
NEW: Fedora-40-20240404.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

Neal Gompa wrote:
> By default, GNOME only presents the close window button. The other
> buttons are missing, and there isn't really an intuitive way to
> discover the other window management actions.

In the version I tried, and judging from end user reports, for several 
years, it did not even present that, leading to fun issues such as some KDE 
dialogs that could not be closed at all (because they were missing a "Close" 
button and relying on the window decoration exclusively).

>> "the shut down options in the mouse menu hidden behind a keyboard dead
>> key, etc.)" this is also not the case for ages, or at least not in its
>> completeness.
> 
> Yes, this did change a few GNOME releases ago.

Of course, having only tried GNOME 3 once, I could not know this.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

Leon Fauster via devel wrote:
> 10 minutes is not enough to do a remodeling of the "familiar"
> experience, so that you reaches the so called realm of intuition.
> The latter is something that we learn over time and the desktop
> environment does not offer this on its own. It provides only a
> framework where this can happen.

But that is exactly the issue with the GNOME design: It is really arrogant 
to expect me to unlearn decades of learned familiar experience and retrain 
to something completely different that in the end has at most minor 
advantages, it is not significantly better, just different.

I want the software to ideally behave the way I am used to (i.e., the way 
Windows 95 worked, see below) out of the box, or if not, at least have an 
"old-school mode" toggle in the preferences that makes it work that way (and 
I will almost certainly use that toggle).

> PS: Imagine the first CLI steps and the corresponding bad
> experience, but we have not given up :-)!

Oh, my first computer was actually an XT clone running IBM PC-DOS 3.3. So I 
actually started with a CLI. :-) Then Windows 95 on a Pentium 120 (MHz). And 
on that Pentium, I also got started with versions of Red Hat Linux of the 
time (not sure what the first one was), first from CD-ROMs bundled with 
computer magazines, then the downloadable FTP edition. And I also tried one 
magazine CD-ROM with an edition of Caldera "OpenLinux" (which was actually 
much less open than RHL, and Caldera eventually became the infamous SCO) 
with the at the time brand new KDE 1 (version 1.1.1). Having used DOS, the 
bash CLI was not that bad to work with, but the distros at the time already 
came with GUI environments (FVWM95, then came KDE 1 and GNOME 1).

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: Switching XZ for ZSTD?

[Arnie T via devel]

Hi,

> There's no such thing as a "distro decision" on this one, as was
> explained in the thread already.

I'm sure the 'explanation' is all clear to you and the other Developers.

I'm also sure that it's not all that clear to non-Developers.

If the explanation was clear and obvious to me, here or anywhere ales, I 
wouldn't be asking the question.

So, sorry, I guess.

I guess I don't understand how a Distro decision is different from a Distro 
IN-decision.

For example from what I can read you were in contact with this Jia Tan 'person' 
during this story.

I hope that a Distro decision would support whatever it takes to give you the 
tools, time and support to make sure that this sort of thing doesn't sneak past 
you or anyone.

If there's no way to make that kind of decision then it seems to me Developers 
could use better support.

This all seems like a very big deal.  Which is why I guess I am reading about 
it on The Economist.  And why I'm hoping that the Distro has some options to 
take some actions.

Cheers!

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

[Bug 2271881] Upgrade perl-Crypt-SMIME to 0.30

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2271881

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Crypt-SMIME-0.30-1.fc4
   ||1
 Resolution|--- |RAWHIDE
Last Closed||2024-04-04 15:16:13




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2271881
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262599] perl-Tie-Cycle-1.228 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2262599

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 CC||jples...@redhat.com
   Fixed In Version||perl-Tie-Cycle-1.228-1.fc40
   Doc Type|--- |If docs needed, set a value
 Status|NEW |CLOSED
Last Closed||2024-04-04 15:14:48




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2262599
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2273397] New: Upgrade perl-Net-Whois-Raw to 2.99038

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2273397

Bug ID: 2273397
   Summary: Upgrade perl-Net-Whois-Raw to 2.99038
   Product: Fedora
   Version: rawhide
   URL: https://metacpan.org/release/Net-Whois-Raw
Status: NEW
 Component: perl-Net-Whois-Raw
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.99.037 version. Upstream released 2.99038. When you
have free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273397

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273397%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2273395] New: Upgrade perl-HTTP-Body to 1.23

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2273395

Bug ID: 2273395
   Summary: Upgrade perl-HTTP-Body to 1.23
   Product: Fedora
   Version: rawhide
   URL: https://metacpan.org/release/HTTP-Body
Status: NEW
 Component: perl-HTTP-Body
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.22 version. Upstream released 1.23. When you have free
time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273395

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273395%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Switching XZ for ZSTD?

[Richard W.M. Jones]

On Thu, Apr 04, 2024 at 02:40:08PM +, Arnie T via devel wrote:
> Hello Rich,
> 
> > There's also the issue that liblzma is widely used and offers specific
> > features which zstd does not[1].
> > 
> > [1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
> 
> Is that about this?
> 
> https://github.com/facebook/zstd/tree/dev/contrib/seekable_format

If that was part of zstd or even actively being looked at, then yes.

> From a Distro decision viewpoint does an alternative like ZSTD have
> to solve all the problems XZ does to be considered?

There's no such thing as a "distro decision" on this one, as was
explained in the thread already.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

Kilian Hanich via devel wrote:
> About the release cycle: After the initial release of Plasma 6 when dust
> has mostly settled down (approx. 2 point releases), they want to switch
> over to a release cycle which would align (which is likely also the
> reason why F42 was choosen in this proposal).

Interesting point. And there I thought it was only because the answer is 
always 42. ;-)

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

Gordon Messmer wrote:
> If RPM's ELF dependency generator were better, the importance of
> stability would be debatable, but as it is, I really think Fedora should
> be more stable than it is, especially for whatever it defines as "the
> OS."  Today, dnf/rpm will happily allow users to install an application
> that will not run because that application actually depends on newer
> versions of dependencies than are installed on the system.  If a
> significant portion of the standard desktop regularly rebased in the
> middle of a release, I expect that would be a more common problem.

Symbol versioning helps with this, because the ELF dependency generator 
extracts the symbol versions (though not the individual symbols, only the 
versions) that are required. And, e.g., Qt uses symbol versioning.

The KDE packages also often have explicit versioned Requires on the 
dependencies where it matters.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

Gordon Messmer wrote:
> "When you are using the Linux mark pursuant to a sublicense, it should
> never be used as a verb or noun. It should be used only as an adjective
> followed by the generic name/noun. In other words, “Super Dooper Linux
> OS” is okay, but “Super Dooper Linux” isn’t."
> 
> https://www.linuxfoundation.org/legal/the-linux-mark

Kinda the same recommendation that also applies to the Fedora trademark, by 
the way. But everyone only cares about their own trademark.

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: Switching XZ for ZSTD?

[Arnie T via devel]

Hello Rich,

> There's also the issue that liblzma is widely used and offers specific
> features which zstd does not[1].
> 
> [1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379

Is that about this?

https://github.com/facebook/zstd/tree/dev/contrib/seekable_format

From a Distro decision viewpoint does an alternative like ZSTD have to solve 
all the problems XZ does to be considered?
Even if it solves a bunch of other problems? Like the 'many eyes' one?

My old manager was always quoting about "Analysis Paralysis" and "Don't let the 
perfect be the enemy of the good".

I'm no expert on this for sure but it seems that changing what CAN be changed 
has some value.  And dealing with the rest when you can.

So I'm just curious what "Good enough" looks like to act on something for 
Fedora ?

Cheers!

 Arnie
--
___
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: Switching XZ for ZSTD?

[Richard W.M. Jones]

On Thu, Apr 04, 2024 at 01:45:45PM -, Daniel Alley wrote:
> As long as there are existing xz-compressed files in the wild,
> Fedora will need to support consuming them - as long as there is
> software that expects xz compression, Fedora will need to support
> creating them.  It's not going to disappear any time soon, and until
> then we're stuck with xz

There's also the issue that liblzma is widely used and offers specific
features which zstd does not[1].

Rich.

[1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
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: Switching XZ for ZSTD?

[Arnie T via devel]

Hi,

> See also an upstream GNU discussion on whether more GNU packages
> should start providing zstd, or even lzip, tarballs in addition to xz:
> https://lists.gnu.org/archive/html/bug-standards/2024-04/msg00032.html


I'm sure not going to tell any developers here something they don't know!  But 
for anybody that's just starting to look at this I thought these were really 
helpful.

https://manishrjain.com/compression-algo-moving-data

https://linuxreviews.org/Comparison_of_Compression_Algorithms

From both of those I get that ZSTD is a pretty good option to consider.

Cheers!

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

[Gwyn Ciesla via devel]

Is there any chance fedpkg local can be adapted to support dynamic 
BuildRequires?

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

On Thursday, April 4th, 2024 at 2:51 AM, Fabio Valentini  
wrote:

> On Thu, Apr 4, 2024, 00:54 Philip Matura via devel 
>  wrote:
> 

> > On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> > > On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
> > >  wrote:
> > > >
> > > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > > > from the top of my head this should not break anything, but I'm not
> > > > sure. There does not seem to be a general "ignore-git" option for cargo.
> > > >
> > > > Or are there other ways to get this to work?
> > >
> > > The short answer is: No, "fedpkg local" is not expected to work for
> > > Rust packages, and probably won't ever work as expected for Rust
> > > packages.
> > >
> > > I am not really interested in adding the "--allow-dirty" flag (not
> > > sure if it would even work in this case), since building Rust packages
> > > with "fedpkg local" is not working for other reasons. Primarily,
> > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > this is only supported when building in mock.
> > 

> > I don't know what you mean? For me after patching the macro locally
> > local builds work as expected. Maybe I'm overlooking something?
> 

> 

> You might be lucky and just tried to package a Rust crate with no 
> dependencies?
> 

> Dependencies on other Rust crates are only resolved dynamically at build 
> time, which "fedpkg local" does not support. So it works "by accident" for 
> Rust crates with no crate dependencies, but in general, it can't work.
> 

> Fabio
> 

> 

> > 

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

Re: Switching XZ for ZSTD?

[Arnie T via devel]

Hi Daniel,

>> All that being said, there are plenty of bits of software that could start 
>> using zstd by default and it would probably make sense to do so.

I know this isn't the best test but just looking at

locate xz | grep xz$ | grep kernel.*xz$ | wc -l
 13206

ISTM there's a log of .xz compressed packages just related to the kernel.
And I would guess that to use them at runtime would need using XZ.

I think for example Arch uses ZSTD for this already?

Cheers!

 Arnie
--
___
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: Switching XZ for ZSTD?

[Eric Blake]

On Thu, Apr 04, 2024 at 01:45:45PM -, Daniel Alley wrote:
> It's not possible to simply substitute one for another universally, there's 
> no "Fedora default", it's something that would need to be handled on a 
> package-by-package basis.
> 
> As long as there are existing xz-compressed files in the wild, Fedora will 
> need to support consuming them - as long as there is software that expects xz 
> compression, Fedora will need to support creating them.  It's not going to 
> disappear any time soon, and until then we're stuck with xz
> 
> All that being said, there are plenty of bits of software that could *start* 
> using zstd by default and it would probably make sense to do so.

See also an upstream GNU discussion on whether more GNU packages
should start providing zstd, or even lzip, tarballs in addition to xz:
https://lists.gnu.org/archive/html/bug-standards/2024-04/msg00032.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org
--
___
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: Switching XZ for ZSTD?

[Arnie T via devel]

Hi Steve,

>> Who's to say that one doesn't have the same basic issue? Same with any other 
>> project in FOSS for that matter.

That's the idea I was trying to make. There are no guarantees are there? But 
you can minimize the social problems.

The 'basic issue' I see is the "one or two" developers, some that nobody knows 
in person, vis-à-vis "many" developers on a big project.

For me it's most important when the project is on a Distro critical- or 
security-path.

Cheers!
Arnie

On Thursday, April 4th, 2024 at 9:41 AM, Steve Cossette  
wrote:

> I have definitely not read 75% of the comments and articles about the xz 
> issues but I understand the general reason why this happened.
>
> Issue here is, let's say we do switch to an alternative, whatever it is. 
> Who's to say that one doesn't have the same basic issue? Same with any other 
> project in FOSS for that matter.
>
> I'd say keep using XZ if the maintainers are quick to fix issues and quick to 
> respond to the community's issues, this one for example. Everyone does 
> mistakes. It's fine as long as we learn from them.
>
> On Thu, Apr 4, 2024 at 9:26 AM Arnie T via devel 
>  wrote:
>
>> Hi,
>>
>> I just installed Fedora on 2 of my PCs a couple of weeks ago. One version of 
>> Fedora 39 release and one of Fedora 40 to see where things are going.
>>
>> I learned about this XZ-hack from Ars Technica & The Economist.
>>
>> I got to the Fedora Magazine article and wasn't really clear on that.
>>
>> So I followed the discussion to this thread in this Development mailing list.
>>
>> I read a lot of it but _still_ can't 100% figure out what the final solution 
>> is going to be.
>>
>> I have a question about that.
>>
>> I'm for sure OK that a responsibly developed FOSS project can contribute 
>> value and should be welcomed.
>>
>> ISTM that if a package is used on critical-path or security-path by default 
>> in a Distro it needs a higher bar.
>>
>> IIUC from this thread and online discussions about XZ & alternatives that
>>
>> 1] Lack of committer 'Real' identity confidence and verification is a 
>> problem.
>> 2] Undetected differences source + packaging in repo vs tarballs are 
>> unchecked.
>> 3] Under-resourced development creates risk; 'Many eyes' bench depth in 
>> development is needed.
>> 4] XZ has a single, unsupported committer.
>> 5] ZSTD is developed & used at Facebook.
>> 6] ZSTD matches or outperforms XZ and most other compression in most metrics.
>> 7] ZSTD is already used for default compression by Distros.
>>
>> I get that there's never going to be 100% perfect solution.
>>
>> But wouldnt' switching Fedora from using XZ to ZSTD by default fix a lot of 
>> the uncertainty around at least this current issue?
>>
>> Is that being considered in Fedora?
>> Or is the focus trying to fix XZ to continue to use it?
>>
>> Thanks for any help to understand all this :-)
>>
>> Cheers!
>>
>> Arnie
>> --
>> ___
>> 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: Switching XZ for ZSTD?

[Daniel Alley]

It's not possible to simply substitute one for another universally, there's no 
"Fedora default", it's something that would need to be handled on a 
package-by-package basis.

As long as there are existing xz-compressed files in the wild, Fedora will need 
to support consuming them - as long as there is software that expects xz 
compression, Fedora will need to support creating them.  It's not going to 
disappear any time soon, and until then we're stuck with xz

All that being said, there are plenty of bits of software that could *start* 
using zstd by default and it would probably make sense to do so. 
--
___
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

[Bug 2273376] New: perl-Data-Munge-0.101 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2273376

Bug ID: 2273376
   Summary: perl-Data-Munge-0.101 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Data-Munge
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.101
Upstream release that is considered latest: 0.101
Current version/release in rawhide: 0.100-4.fc40
URL: https://metacpan.org/dist/Data-Munge/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5887/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Data-Munge


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2273376

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202273376%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Switching XZ for ZSTD?

[Steve Cossette]

I have definitely not read 75% of the comments and articles about the xz
issues but I understand the general reason why this happened.

Issue here is, let's say we do switch to an alternative, whatever it is.
Who's to say that one doesn't have the same basic issue? Same with any
other project in FOSS for that matter.

I'd say keep using XZ if the maintainers are quick to fix issues and quick
to respond to the community's issues, this one for example. Everyone does
mistakes. It's fine as long as we learn from them.

On Thu, Apr 4, 2024 at 9:26 AM Arnie T via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
> I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version
> of Fedora 39 release and one of Fedora 40 to see where things are going.
>
> I learned about this XZ-hack from Ars Technica & The Economist.
>
> I got to the Fedora Magazine article and wasn't really clear on that.
>
> So I followed the discussion to this thread in this Development mailing
> list.
>
> I read a lot of it but _still_ can't 100% figure out what the final
> solution is going to be.
>
> I have a question about that.
>
> I'm for sure OK that a responsibly developed FOSS project can contribute
> value and should be welcomed.
>
> ISTM that if a package is used on critical-path or security-path by
> default in a Distro it needs a higher bar.
>
> IIUC from this thread and online discussions about XZ & alternatives that
>
> 1] Lack of committer 'Real' identity confidence and verification is a
> problem.
> 2] Undetected differences source + packaging in repo vs tarballs are
> unchecked.
> 3] Under-resourced development creates risk; 'Many eyes' bench depth in
> development is needed.
> 4] XZ has a single, unsupported committer.
> 5] ZSTD is developed & used at Facebook.
> 6] ZSTD matches or outperforms XZ and most other compression in most
> metrics.
> 7] ZSTD is already used for default compression by Distros.
>
> I get that there's never going to be 100% perfect solution.
>
> But wouldnt' switching Fedora from using XZ to ZSTD by default fix a lot
> of the uncertainty around at least this current issue?
>
> Is that being considered in Fedora?
> Or is the focus trying to fix XZ to continue to use it?
>
> Thanks for any help to understand all this :-)
>
> Cheers!
>
>  Arnie
> --
> ___
> 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: 20240404.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240403.n.0
NEW: Fedora-Rawhide-20240404.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  2
Dropped packages:0
Upgraded packages:   103
Downgraded packages: 1

Size of added packages:  1.43 MiB
Size of dropped packages:0 B
Size of upgraded packages:   6.03 GiB
Size of downgraded packages: 698.59 KiB

Size change of upgraded packages:   42.62 MiB
Size change of downgraded packages: -10.35 KiB

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

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: html-xml-utils-8.6-1.fc41
Summary: A number of simple utilities for manipulating HTML and XML files
RPMs:html-xml-utils
Size:1.41 MiB

Package: python-jaraco-test-5.4.0-1.fc41
Summary: Testing support by jaraco
RPMs:python3-jaraco-test
Size:14.56 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  OpenImageIO-2.5.7.0-2.fc41
Old package:  OpenImageIO-2.5.7.0-1.fc40
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 18.09 MiB
Size change:  -14.73 KiB
Changelog:
  * Tue Apr 02 2024 Benjamin A. Beasley  - 2.5.7.0-2
  - Rebuild for OpenVDB 11 with backward-compatible ABI


Package:  alsa-sof-firmware-2024.03-2.fc41
Old package:  alsa-sof-firmware-2023.12.1-1.fc41
Summary:  Firmware and topology files for Sound Open Firmware project
RPMs: alsa-sof-firmware alsa-sof-firmware-debug
Size: 6.17 MiB
Size change:  1.78 MiB
Changelog:
  * Wed Apr 03 2024 Jaroslav Kysela  - 2024.03-2
  - Update to v2024.03


Package:  azure-cli-2.59.0-1.fc41
Old package:  azure-cli-2.58.0-1.fc41
Summary:  Microsoft Azure Command-Line Tools
RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry 
python3-azure-cli-testsdk
Size: 13.36 MiB
Size change:  494.15 KiB
Changelog:
  * Wed Apr 03 2024 Jeremy Cline  - 2.59.0-1
  - Update to v2.59 (rhbz #2272746)


Package:  babeltrace2-2.0.6-1.fc41
Old package:  babeltrace2-2.0.5-6.fc40
Summary:  A trace manipulation toolkit
RPMs: babeltrace2 libbabeltrace2 libbabeltrace2-devel python3-bt2
Size: 5.47 MiB
Size change:  -1.87 KiB
Changelog:
  * Tue Apr 02 2024 Kienan Stewart  - 2.0.6-1
  - New upstream release


Package:  cffconvert-2.0.0-11.fc41
Old package:  cffconvert-2.0.0-10.fc40
Summary:  Command line program to validate and convert CITATION.cff files
RPMs: cffconvert
Size: 183.32 KiB
Size change:  94 B
Changelog:
  * Wed Apr 03 2024 Benjamin A. Beasley  - 2.0.0-11
  - Fix pytest 8 compatibility and failing tests (close RHBZ#2272969)


Package:  clevis-20-2.fc41
Old package:  clevis-20-1.fc41
Summary:  Automated decryption framework
RPMs: clevis clevis-dracut clevis-luks clevis-systemd clevis-udisks2
Size: 517.41 KiB
Size change:  2.49 KiB
Changelog:
  * Wed Apr 03 2024 Sergio Correia  - 20-2
  - Make clevis-pin-tpm2 the default tpm2 pin
  - Also remove cracklib-dicts dependency as it is not required anymore


Package:  coreutils-9.5-1.fc41
Old package:  coreutils-9.4-6.fc40
Summary:  A set of basic GNU tools commonly used in shell scripts
RPMs: coreutils coreutils-common coreutils-single
Size: 15.93 MiB
Size change:  -308.57 KiB
Changelog:
  * Tue Apr 02 2024 Luk Zaoral  - 9.5-1
  - rebase to latest upstream version (rhbz#2272063)
  - sync i18n patch with SUSE (Kudos to Berny V??lker!)
  - add some test dependencies to execute additional part of the upstream 
test-suite


Package:  cyrus-imapd-3.8.2-1.fc41
Old package:  cyrus-imapd-3.8.1-11.fc41
Summary:  A high-performance email, contacts and calendar server
RPMs: cyrus-imapd cyrus-imapd-devel cyrus-imapd-doc-extra 
cyrus-imapd-libs cyrus-imapd-utils cyrus-imapd-virusscan perl-Cyrus
Size: 17.06 MiB
Size change:  370.43 KiB
Changelog:
  * Fri Mar 22 2024 Martin Osvald  - 3.8.2-1
  - New version 3.8.2
  - spec file clean up


Package:  davix-0.8.6-1.fc41
Old package:  davix-0.8.5-5.fc40
Summary:  Toolkit for http based file management
RPMs: davix davix-devel davix-doc davix-libs davix-tests
Size: 4.86 MiB
Size change:  -15.60 KiB
Changelog:
  * Wed Apr 03 2024 Mihai Patrascoiu  - 0.8.6-1
  - New upstream release 0.8.6


Package:  deepin-account-faces-1.0.16-1.fc41
Old package:  deepin-account-faces-1.0.14-3.fc40
Summary:  Account faces for Linux Deepin
RPMs: deepin-account-faces
Size: 1.61 MiB
Size change:  679.92 KiB
Changelog:
  * Wed Apr 03 2024 topazus  - 1.0.16-1
  - 1.0.16


Package:  dnf5-5.1.17-1.fc41
Old package:  dnf5-5.1.16-1.fc41
Summary:  Command-line package manager
RPMs: dnf5 dnf5-devel dnf5-plugin-automatic dnf5-plugins 
dnf5daemon-client dnf5daemon-server libdnf5 libdnf5-cli

Switching XZ for ZSTD?

[Arnie T via devel]

Hi,

I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version of 
Fedora 39 release and one of Fedora 40 to see where things are going.

I learned about this XZ-hack from Ars Technica & The Economist.

I got to the Fedora Magazine article and wasn't really clear on that.

So I followed the discussion to this thread in this Development mailing list.

I read a lot of it but _still_ can't 100% figure out what the final solution is 
going to be.

I have a question about that.

I'm for sure OK that a responsibly developed FOSS project can contribute value 
and should be welcomed.

ISTM that if a package is used on critical-path or security-path by default in 
a Distro it needs a higher bar.

IIUC from this thread and online discussions about XZ & alternatives that

1] Lack of committer 'Real' identity confidence and verification is a problem.
2] Undetected differences source + packaging in repo vs tarballs are unchecked.
3] Under-resourced development creates risk; 'Many eyes' bench depth in 
development is needed.
4] XZ has a single, unsupported committer.
5] ZSTD is developed & used at Facebook.
6] ZSTD matches or outperforms XZ and most other compression in most metrics.
7] ZSTD is already used for default compression by Distros.

I get that there's never going to be 100% perfect solution.

But wouldnt' switching Fedora from using XZ to ZSTD by default fix a lot of the 
uncertainty around at least this current issue?

Is that being considered in Fedora?
Or is the focus trying to fix XZ to continue to use it?

Thanks for any help to understand all this :-)

Cheers!

 Arnie
--
___
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 Tue, Apr 02, 2024 at 04:32:24PM +0100, Richard W.M. Jones wrote:
> On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> > On 2024-04-01 23:59, Gordon Messmer wrote:
> > >Now gdb can print the GOT with the paths providing the memory
> > >section containing a function.  For example, on a Debian 12 system
> > >with liblzma 5.6:

> Since no one else replied yet, this is a nice bit of analysis.

+1. I put the tool on my TODO list of things to look into.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Steve Cossette]

With that being said though, I would rather this discussion not to devolve
into a "Which DE is better".

I've said that in the past, but each Desktop Environment has their merits,
and discussing "Which is better" is as fruitless as "Mac vs PC" or "Android
vs iOS" fights.

On Thu, Apr 4, 2024 at 8:34 AM Steve Cossette  wrote:

> Problem with extensions is, while they are *technically* supported by
> gnome, they can break with any update (It has happened to me in the past).
> Heck, it kinda reminds me of hacks people use to get around the junk people
> put in Windows 10/11...
>
> On Thu, Apr 4, 2024 at 8:09 AM Leslie Satenstein via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> There is, if you add 1 extension, a category menu.  That is the menu that
>> is similar to other desktop interfaces such as Budgie, XFCE, and other.
>>
>>
>> Leslie Satenstein
>>
>>
>>
>> On Thursday, April 4, 2024 at 08:03:13 a.m. EDT, Stephen Smoogen <
>> ssmoo...@redhat.com> wrote:
>>
>>
>>
>>
>> On Thu, 4 Apr 2024 at 04:38, Vít Ondruch  wrote:
>>
>>
>>
>> Maybe you should give it second try.
>>
>>
>>
>> What I am going to say is not meant to be a bash in any way.
>>
>> I am on my 10th try for GNOME3/40. For everything they move to somewhere
>> my brain says is intuitive, there always seems to be something else
>> moved which I have to relearn or fight past patterns for.  Just like code
>> refactoring, I realize all the movements and changes are for good reasons
>> versus just 'moving for movement sake'. My brain just rebels against it in
>> an almost painful way.
>>
>> Again this isn't a rag on GNOME. I find that I can adapt only so much to
>> desktop changes and prefer something which stays the same while I focus on
>> my work. Other people find such changes easy and others find the lack of
>> changes I want to be painful for their brains. I understand where GNOME is
>> going and I agree that it is a purpose they should shoot for 100%. It just
>> isn't easy for me to stay on the bus.
>>
>>
>> --
>> Stephen Smoogen, Red Hat Automotive
>> Let us be kind to one another, for most of us are fighting a hard battle.
>> -- Ian MacClaren
>>
>> --
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Steve Cossette]

Problem with extensions is, while they are *technically* supported by
gnome, they can break with any update (It has happened to me in the past).
Heck, it kinda reminds me of hacks people use to get around the junk people
put in Windows 10/11...

On Thu, Apr 4, 2024 at 8:09 AM Leslie Satenstein via devel <
devel@lists.fedoraproject.org> wrote:

> There is, if you add 1 extension, a category menu.  That is the menu that
> is similar to other desktop interfaces such as Budgie, XFCE, and other.
>
>
> Leslie Satenstein
>
>
>
> On Thursday, April 4, 2024 at 08:03:13 a.m. EDT, Stephen Smoogen <
> ssmoo...@redhat.com> wrote:
>
>
>
>
> On Thu, 4 Apr 2024 at 04:38, Vít Ondruch  wrote:
>
>
>
> Maybe you should give it second try.
>
>
>
> What I am going to say is not meant to be a bash in any way.
>
> I am on my 10th try for GNOME3/40. For everything they move to somewhere
> my brain says is intuitive, there always seems to be something else
> moved which I have to relearn or fight past patterns for.  Just like code
> refactoring, I realize all the movements and changes are for good reasons
> versus just 'moving for movement sake'. My brain just rebels against it in
> an almost painful way.
>
> Again this isn't a rag on GNOME. I find that I can adapt only so much to
> desktop changes and prefer something which stays the same while I focus on
> my work. Other people find such changes easy and others find the lack of
> changes I want to be painful for their brains. I understand where GNOME is
> going and I agree that it is a purpose they should shoot for 100%. It just
> isn't easy for me to stay on the bus.
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>
> --
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leslie Satenstein via devel]

There is, if you add 1 extension, a category menu.  That is the menu that is 
similar to other desktop interfaces such as Budgie, XFCE, and other.


Leslie Satenstein
 

On Thursday, April 4, 2024 at 08:03:13 a.m. EDT, Stephen Smoogen 
 wrote:  
 
 

On Thu, 4 Apr 2024 at 04:38, Vít Ondruch  wrote:



Maybe you should give it second try.



What I am going to say is not meant to be a bash in any way. 
I am on my 10th try for GNOME3/40. For everything they move to somewhere my 
brain says is intuitive, there always seems to be something else moved which I 
have to relearn or fight past patterns for.  Just like code refactoring, I 
realize all the movements and changes are for good reasons versus just 'moving 
for movement sake'. My brain just rebels against it in an almost painful way. 
Again this isn't a rag on GNOME. I find that I can adapt only so much to 
desktop changes and prefer something which stays the same while I focus on my 
work. Other people find such changes easy and others find the lack of changes I 
want to be painful for their brains. I understand where GNOME is going and I 
agree that it is a purpose they should shoot for 100%. It just isn't easy for 
me to stay on the bus.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- 
Ian MacClaren
-- 
  --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Stephen Smoogen]

On Thu, 4 Apr 2024 at 04:38, Vít Ondruch  wrote:

>
>
> Maybe you should give it second try.
>
>
What I am going to say is not meant to be a bash in any way.

I am on my 10th try for GNOME3/40. For everything they move to somewhere my
brain says is intuitive, there always seems to be something else
moved which I have to relearn or fight past patterns for.  Just like code
refactoring, I realize all the movements and changes are for good reasons
versus just 'moving for movement sake'. My brain just rebels against it in
an almost painful way.

Again this isn't a rag on GNOME. I find that I can adapt only so much to
desktop changes and prefer something which stays the same while I focus on
my work. Other people find such changes easy and others find the lack of
changes I want to be painful for their brains. I understand where GNOME is
going and I agree that it is a purpose they should shoot for 100%. It just
isn't easy for me to stay on the bus.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2024-04-05 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10568/

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

[EPEL-devel] Re: activemq-cpp in epel8

[Ward, Evan M CIV USN NRL (8112) Washington DC (USA) via epel-devel]

Wow, that was fast! Thanks Jonathan!


Regards,

Evan


From: Jonathan Wright 
Sent: Wednesday, April 3, 2024 10:55:40 PM
To: EPEL Development List
Cc: Ward, Evan M CIV USN NRL (8112) Washington DC (USA)
Subject: Re: [EPEL-devel] activemq-cpp in epel8

Managed to get this packed up.  Now we just wait for the peer review from 
another packager.

https://bugzilla.redhat.com/show_bug.cgi?id=2273288

On Wed, Apr 3, 2024 at 10:01 AM Jonathan Wright 
mailto:jonat...@almalinux.org>> wrote:
Evan,

I will look into this.  Looks like it was retired years ago for failing to 
build: https://bugzilla.redhat.com/show_bug.cgi?id=1674632

It will have to be re-reviewed since it was retired/orphaned more than 6 weeks 
ago so a reasonable timeframe to (potentially) get it back into repos and EPEL8 
is a 2-6 weeks depending on how quickly a reviewer will pick it up, and if it 
will build against modern versions of Fedora/RHEL.

On Wed, Apr 3, 2024 at 9:57 AM Ward, Evan M CIV USN NRL (8112) Washington DC 
(USA) via epel-devel 
mailto:epel-devel@lists.fedoraproject.org>> 
wrote:
Hi,

Are there any packagers who would like to package activemq-cpp in
epel8? It's already in epel7.

https://bugzilla.redhat.com/show_bug.cgi?id=2244652

Regards,
Evan Ward
--
___
epel-devel mailing list -- 
epel-devel@lists.fedoraproject.org
To unsubscribe send an email to 
epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat


--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272408] perl-PDL-2.086 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2272408

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||Github
   ||PDLPorters/pdl/issues/469
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Jitka Plesnikova  ---
Test slice.t is failing on i386.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272408

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272408%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 08:59:32PM +0200, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > I sometimes see unit test failures. The developer ran the tests, but not
> > on S390.
> 
> Why would I want a test failure on such an exotic architecture to fail my 
> build?

The architecture is weird enough (big endian!) that it may show your
code has various incorrect assumptions.  We found one the other day
actually:

https://sourceware.org/pipermail/binutils/2024-January/132096.html

Rich.

> The only reason Fedora supports that architecture at all is pressure 
> from IBM. Basically nobody uses it.
> 
> Kevin Kofler
> 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Neal Gompa]

On Thu, Apr 4, 2024 at 4:38 AM Vít Ondruch  wrote:
>
>
> Dne 04. 04. 24 v 0:44 Kevin Kofler via devel napsal(a):
> > Leon Fauster via devel wrote:
> >> I already had RHL installed on a Sun IPX with Gnome, so I'm biased.
> > Interesting that you were not put off by the changes that have happened to
> > GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
> > actually pretty good. (It was very configurable back then. Remember when it
> > shipped Enlightenment as the window manager, how many options that had?)
> > Then GNOME 2 came, removing much of the configurability of GNOME 1. And then
> > GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME
> > 2, leading to a very hardcoded experience. GNOME 2 was already too much for
> > me, and I switched back to KDE, back because I had already tried KDE 1.1.1
> > on another distro. And I have never looked back.
> >
> > Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it
> > out once. But it took less than 10 minutes for me to realize that it is not
> > for me. The user experience is just too unfamiliar (the unified application
> > menu and open window selector (launch menu AND task bar replacement), the
> > always maximized windows, the lack of a system tray, the shut down options
> > in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does
> > not make it easy for you to change it. (You can actually get a pretty
> > standard desktop experience nowadays if you install a lot of "unbreak this",
> > "unbreak that" GNOME Shell extensions, but that kinda defeats the point of
> > GNOME.) The default experience felt pretty much unusable to me personally.
>
>
> Uh, from your description, I would really have hard time to decipher you
> are talking about Gnome 3.
>
> "the always maximized windows" what is this about? Maybe you are missing
> some maximize/normalize buttons.
>

By default, GNOME only presents the close window button. The other
buttons are missing, and there isn't really an intuitive way to
discover the other window management actions.

> "the shut down options in the mouse menu hidden behind a keyboard dead
> key, etc.)" this is also not the case for ages, or at least not in its
> completeness.
>

Yes, this did change a few GNOME releases ago.


-- 
真実はいつも一つ！/ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Vít Ondruch]

Dne 04. 04. 24 v 0:44 Kevin Kofler via devel napsal(a):

Leon Fauster via devel wrote:

I already had RHL installed on a Sun IPX with Gnome, so I'm biased.

Interesting that you were not put off by the changes that have happened to
GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
actually pretty good. (It was very configurable back then. Remember when it
shipped Enlightenment as the window manager, how many options that had?)
Then GNOME 2 came, removing much of the configurability of GNOME 1. And then
GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME
2, leading to a very hardcoded experience. GNOME 2 was already too much for
me, and I switched back to KDE, back because I had already tried KDE 1.1.1
on another distro. And I have never looked back.

Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it
out once. But it took less than 10 minutes for me to realize that it is not
for me. The user experience is just too unfamiliar (the unified application
menu and open window selector (launch menu AND task bar replacement), the
always maximized windows, the lack of a system tray, the shut down options
in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does
not make it easy for you to change it. (You can actually get a pretty
standard desktop experience nowadays if you install a lot of "unbreak this",
"unbreak that" GNOME Shell extensions, but that kinda defeats the point of
GNOME.) The default experience felt pretty much unusable to me personally.



Uh, from your description, I would really have hard time to decipher you 
are talking about Gnome 3.


"the always maximized windows" what is this about? Maybe you are missing 
some maximize/normalize buttons.


"the shut down options in the mouse menu hidden behind a keyboard dead 
key, etc.)" this is also not the case for ages, or at least not in its 
completeness.


Maybe you should give it second try.


Vít



KDE Plasma not only has more familiar defaults (actually looking and feeling
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily
change those defaults that you do not like.

 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


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

Re: Issues with pytest and python-pytest-postgresql

[Lumír Balhar]

Hi Mikel.

It might look like simple bump but you are upgrading from 4.1.1 to 6.0.0 
and there are some breaking changes between those releases.


The error message looks like the plugin is loaded twice for some reason 
and the second try to register the same CLI option fails. %pytest macro 
sets PYTHONPATH so it's possible that the plugin is first loaded from 
buildroot and then from the current working directory or vice-versa. I 
also see some settings for pytest in pyproject.toml you might want to 
take a look.


Have a nice day.

Lumír

On 4/3/24 15:55, Mikel Olasagasti wrote:

Hi all,

I'm trying to update python-pytest-postgresql (simple bump) and during
the %check phase I find the following error:

+ /usr/bin/pytest --postgresql-exec=/usr/bin/pg_ctl -k 'not docker' --no-cov
(...)
   File 
"/builddir/build/BUILDROOT/python-pytest-postgresql-6.0.0-1.fc41.x86_64/usr/lib/python3.12/site-packages/pytest_postgresql/plugin.py",
line 67, in pytest_addoption
 parser.addoption(
   File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 104, in addoption
 self._anonymous.addoption(*opts, **attrs)
   File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 385, in addoption
 raise ValueError("option names %s already added" % conflict)
ValueError: option names {'--postgresql-exec'} already added

What I found is that once the postgresql plugin is loaded it conflicts
with the tests of the module.

Any advice on how to solve this issue?

Best regards,
Mikel
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-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

[Fabio Valentini]

On Thu, Apr 4, 2024, 00:54 Philip Matura via devel <
devel@lists.fedoraproject.org> wrote:

> On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> > On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
> >  wrote:
> > >
> > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > > from the top of my head this should not break anything, but I'm not
> > > sure. There does not seem to be a general "ignore-git" option for
> cargo.
> > >
> > > Or are there other ways to get this to work?
> >
> > The short answer is: No, "fedpkg local" is not expected to work for
> > Rust packages, and probably won't ever work as expected for Rust
> > packages.
> >
> > I am not really interested in adding the "--allow-dirty" flag (not
> > sure if it would even work in this case), since building Rust packages
> > with "fedpkg local" is not working for other reasons. Primarily,
> > "fedpkg local" does not support dynamically generated BuildRequires -
> > this is only supported when building in mock.
>
> I don't know what you mean? For me after patching the macro locally
> local builds work as expected. Maybe I'm overlooking something?
>

You might be lucky and just tried to package a Rust crate with no
dependencies?

Dependencies on other Rust crates are only resolved dynamically at build
time, which "fedpkg local" does not support. So it works "by accident" for
Rust crates with no crate dependencies, but in general, it can't work.

Fabio


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