Re: Suggestion: Use a unified kernel image by default in the future.

[Gerd Hoffmann]

On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote:
> On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann  wrote:
> >
> > On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> > > Use unified kernel images by default for new releases. This can allow
> > > for the local installation to sign the kernel and the initrd, so the
> > > boot chain can be verified until after the uefi. Currently, the initrd
> > > can be modified by attackers, so even if the / partition is encrypted,
> > > the systems data can be read on the next boot. If the kernel image,
> > > which includes the command line, and the initrd, is signed  then it is
> > > harder to comprimise the system. The system can still be comprimised
> > > if the uefi is modified.
> > >
> > > If this was used, then the kernel could no longer be signed in the
> > > package by the fedora infrastructure.
> >
> > I'd rather have fedora ship a unified + signed kernel image with a
> > generic (aka 'dracut --no-hostonly') initrd instead of generating one
> > on the local system.
> 
> I think the issue with this is the initrd side blows out a lot, you
> include all the firmware for all the modules in the system and then
> you have 3 of them in /boot.
> 
> I do wonder if it's possible to use multiple initrds, and maybe have
> the firmware in a separate initrd shared between all installed kernels
> if we go down this route.

grub supports multiple initrds just fine.  According to 
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub
supports multiple initrd files also with bls.  That seems to be a
derivation from the original boot loader spec though, so not sure this
works with systemd-boot too.

When going for multiple initrds the best approach is probably to simply
split out the kernel modules into a version-specific initrd and store
everything else in another, shared initrd.

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

Re: Support for Realtek RTL8811CU (WiFi)

[Naheem Zaffar]

On Thu, 30 Jun 2022, 23:50 Christopher Klooz,  wrote:

> It seems that Fedora does not support the Realtek RTL8811CU for WiFi. A
> user at ask.Fedora just had the issue. `lsusb` classifies it just as
> "Bus 001 Device 010: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac
> NIC"; correspondingly, `nmcli` does not recognize it at all.
>
> A bug report with some improvised interim-solutions seems to already
> exist https://bugzilla.redhat.com/show_bug.cgi?id=1957828 , the most
> widespread solution seems to be https://github.com/brektrou/rtl8821CU
> (but unknown maintenance).
>
> Is it known why the 8811CU remains unsupported? Or have I missed something?
>
> Regards,
> Chris
>

Fedora does not include out of tree kernel modules. To get it into fedora,
the module will need to be included in the upstream kernel.

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

Support for Realtek RTL8811CU (WiFi)

[Christopher Klooz]

It seems that Fedora does not support the Realtek RTL8811CU for WiFi. A 
user at ask.Fedora just had the issue. `lsusb` classifies it just as 
"Bus 001 Device 010: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac 
NIC"; correspondingly, `nmcli` does not recognize it at all.


A bug report with some improvised interim-solutions seems to already 
exist https://bugzilla.redhat.com/show_bug.cgi?id=1957828 , the most 
widespread solution seems to be https://github.com/brektrou/rtl8821CU 
(but unknown maintenance).


Is it known why the 8811CU remains unsupported? Or have I missed something?

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

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Richard W.M. Jones]

On Thu, Jun 30, 2022 at 03:23:34PM +, Alexander Sosedkin wrote:
> Quoting Kevin Kofler via devel (2022-06-30 14:15:04)
> > You are making two doubtful assumptions:
> >
> > 1. That the users will bother reporting their issues to the server
> > administrators at all. I would expect them to just blame Fedora for it and
> > move to a different operating system that just works, or at most to apply a
> > local workaround (what I called "jump through hoops", e.g., changing the
> > system crypto policy to LEGACY and/or loading the legacy provider with its
> > legacy algorithms into OpenSSL) and then forget about it.
> 
> > 2. That the server administrators will actually care about complaints from
> > non-Windows users, assuming they even read user complaints at all to begin
> > with, and that they will be willing to switch to newer (more secure)
> > algorithms that may break compatibility with some ancient operating systems
> > that other users might still use.
> 
> I agree with your statements
> but I do not make the assumptions you prescribe to me.
> I'm painfully aware that progress doesn't happen magically
> when we break something in Fedora.
> Hoops are a horrible propellant of progress,
> but still the best one we have.

Practically what would help is an easier way to reduce security for
only specific sites + protocols.  It's very easy right now to set the
whole system to LEGACY, and much harder to set legacy for a specific
site + protocol.  (In fact I have no idea how to go about it for this
particular case we're talking about.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Suggestion: Use a unified kernel image by default in the future.

[David Airlie]

On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann  wrote:
>
> On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> > Use unified kernel images by default for new releases. This can allow
> > for the local installation to sign the kernel and the initrd, so the
> > boot chain can be verified until after the uefi. Currently, the initrd
> > can be modified by attackers, so even if the / partition is encrypted,
> > the systems data can be read on the next boot. If the kernel image,
> > which includes the command line, and the initrd, is signed  then it is
> > harder to comprimise the system. The system can still be comprimised
> > if the uefi is modified.
> >
> > If this was used, then the kernel could no longer be signed in the
> > package by the fedora infrastructure.
>
> I'd rather have fedora ship a unified + signed kernel image with a
> generic (aka 'dracut --no-hostonly') initrd instead of generating one
> on the local system.

I think the issue with this is the initrd side blows out a lot, you
include all the firmware for all the modules in the system and then
you have 3 of them in /boot.

I do wonder if it's possible to use multiple initrds, and maybe have
the firmware in a separate initrd shared between all installed kernels
if we go down this route.

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

Soname bumps: flint, antic, eclib

[Jerry James]

Next week I plan to update the following packages to the indicated versions.

flint: 2.9.0
antic: 0.2.5
arb: 2.23.0
eclib: 20220621

The flint, antic, and eclib updates come with bumped sonames.  I will
rebuild all dependent packages, namely:

e-antic
normaliz
Singular
polymake
sagemath

The sagemath build will incidentally resolve its failure to build with
python 3.11.
-- 
Jerry James
http://www.jamezone.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Carlos O'Donell]

On 6/30/22 04:54, Kevin Kofler via devel wrote:
> I am still strongly opposed to degrading performance and size for all users 
> just to help the handful users of poorly-designed profiling tools.

I agree.

My career experience has been that the performance impact of having an extra 
register
for compiler scheduling and to reduce register pressure has real and tangible 
benefit.

I have had to use frame pointers, but only for deeply embedded projects where 
the cost
tradeoffs are different and a smaller constrained unwinder was needed.

I would not recommend the use of -fno-omit-frame-pointer in Fedora.

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Naheem Zaffar]

and the proprietary one could have a blacklist for very bad packages.

The ability remains to filter if there is a package that is considered bad
or malicous. The default is just changed to an allow list. Secondly if
there is a malicious package, it will probably be faster to contact flathub
and have them take action that make a downstream update to block it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Sharpened Blade via devel]

> The Flathub remote is available to users who opt-in to enabling
> third-party software repositories in either GNOME Initial Setup or
> GNOME Software.

A lot of flatpaks in Flathub have debatable quality, and are closed source. If 
we could wait until flathub separates open-source and proprietary repos, the 
open-source one could be unfiltered, and the proprietary one could have a 
blacklist for very bad packages. I think it would be better if there could be 
some sort of warning in GNOME software, so maintainers could mark certain 
packages as unsafe or low-quality.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Suggestion: Use a unified kernel image by default in the future.

[Sharpened Blade via devel]

Also, can it be fixed so adding the --uefi flag to dracut works with the 
default generation scripots
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

[Francisco J . Tsao Santín via devel]

Hello Alfredo,
Transferred. Thanks! :-)

On Thu, 30 Jun 2022, Alfredo Moralejo Alonso wrote:

> 
> I can take python-sysv_ipc if nobody did it already.

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Robbie Harwood]

Charalampos Stratakis  writes:

> So I presume then that python2.7 in Debian works flawlessly with
> OpenSSL 3.0.0, no regressions, no security issues and no ABI problems
> right?

I'm hearing hostility from you and I don't know why.  From your sarcasm,
I take it to mean that no, you haven't looked.

So my original question of "can we adapt this to Fedora" still stands.
I'm confused that you're asking me to do this legwork for you, given I
neither represent Debian in any way nor am I a Python developer, but
since it's not hard to check...

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=python2.7
here is the Debian bugtracker for python2.7.  The only openssl bug
present there is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954418 (i.e., upstream
https://bugs.python.org/issue40018 ) which, as it affects python3
versions as well, isn't relevant to this discussion.

https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches
here is the patches Debian carries for python2.7.  All but one of them
are backports from upstream, mostly by Christian Heimes
.  Commit logs say that the backport was performed
by Stefano Rivera , and applied by Matthias Klose
.  If it were me in your shoes, I would ask them how
things have gone and for any pointers in potentially applying the
backport yourself.

Be well,
--Robbie


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Richard W.M. Jones]

On Thu, Jun 30, 2022 at 01:52:34PM -0400, Demi Marie Obenour wrote:
> On 6/30/22 13:11, Charalampos Stratakis wrote:
> > So I presume then that python2.7 in Debian works flawlessly with OpenSSL
> > 3.0.0, no regressions, no security issues and no ABI problems right?
>
> What about stubbing out all networking in Python 2.7?  I believe
> that the only users of Python 2.7 in Fedora are various build
> scripts, and those are all entirely offline.  If so, nothing would
> break if the ssl module was replaced by a stub module that threw an
> exception when any of its functions was called.  Using an EOL
> version of Python in a network-facing program is a bad idea anyway.

This sounds like one of the better ideas to come out of this thread,
and should be done regardless of the other stuff.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Demi Marie Obenour]

On 6/30/22 13:11, Charalampos Stratakis wrote:
> So I presume then that python2.7 in Debian works flawlessly with OpenSSL
> 3.0.0, no regressions, no security issues and no ABI problems right?
What about stubbing out all networking in Python 2.7?  I believe that
the only users of Python 2.7 in Fedora are various build scripts,
and those are all entirely offline.  If so, nothing would break if
the ssl module was replaced by a stub module that threw an exception
when any of its functions was called.  Using an EOL version of Python
in a network-facing program is a bad idea anyway.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Charalampos Stratakis]

So I presume then that python2.7 in Debian works flawlessly with OpenSSL
3.0.0, no regressions, no security issues and no ABI problems right?

On Thu, Jun 30, 2022 at 5:13 PM Robbie Harwood  wrote:

> Charalampos Stratakis  writes:
>
> > Unfortunately that effort is moot, it's really not possible to make
> > python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
> > versions are not 100% compatible for various reasons.
> >
> > In trying to make it compatible there are also ABI changes introduced,
> > it's not only about having the tests pass. The ssl module is already
> > complex enough in backporting changes from the master Python branch to
> > previous 3.x versions, doing that for 2.7 without a full fledged
> > effort from SSL and the Python C API experts guarantee there's gonna
> > be regressions. And that's not even taking into account the security
> > implications of randomly cherry-picking commits just to have the
> > package compile.
>
> I'm having trouble understanding this because Debian seems to have
> carried out what you're saying is impossible: in testing, they ship a
> python2.7 that appears to be using openssl 3, and do not ship openssl
> 1.1 at all.  There are also a handful of clearly openssl 3-related
> patches in their tree
> https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches
>
> Have folks looked at how they do this, and whether we could adapt it to
> Fedora?
>
> Be well,
> --Robbie
>


-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220630.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 15/236 (x86_64), 20/165 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220629.n.0):

ID: 1311291 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1311291
ID: 1311344 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1311344
ID: 1311367 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1311367
ID: 1311401 Test: x86_64 Silverblue-dvd_ostree-iso clocks
URL: https://openqa.fedoraproject.org/tests/1311401
ID: 1311413 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1311413
ID: 1311420 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1311420
ID: 1311443 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1311443
ID: 1311445 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1311445
ID: 1311549 Test: aarch64 Workstation-upgrade help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1311549
ID: 1311559 Test: aarch64 Workstation-upgrade clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1311559
ID: 1311670 Test: aarch64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/1311670
ID: 1311683 Test: aarch64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/1311683
ID: 1311692 Test: aarch64 Workstation-raw_xz-raw.xz clocks@uefi
URL: https://openqa.fedoraproject.org/tests/1311692
ID: 1311696 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1311696
ID: 1311707 Test: aarch64 Workstation-raw_xz-raw.xz help_viewer@uefi
URL: https://openqa.fedoraproject.org/tests/1311707

Old failures (same test failed in Fedora-Rawhide-20220629.n.0):

ID: 1311374 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1311374
ID: 1311381 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1311381
ID: 1311396 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1311396
ID: 1311406 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1311406
ID: 1311410 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1311410
ID: 1311414 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1311414
ID: 1311440 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1311440
ID: 1311450 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1311450
ID: 1311451 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1311451
ID: 1311477 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1311477
ID: 1311519 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1311519
ID: 1311531 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1311531
ID: 1311539 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1311539
ID: 1311550 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1311550
ID: 1311553 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1311553
ID: 1311562 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1311562
ID: 1311587 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1311587
ID: 1311652 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1311652
ID: 1311674 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1311674
ID: 1311703 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1311703

Soft failed openQA tests: 20/236 (x86_64), 14/165 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Rawhide-20220629.n.0):

ID: 1311288 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/1311288
ID: 1311289 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1311289
ID: 1311346 

Re: Orphaning my packages

[Alfredo Moralejo Alonso]

On Wed, Jun 29, 2022 at 5:00 PM Francisco J. Tsao Santín via devel <
devel@lists.fedoraproject.org> wrote:

> Hello, I've been maintaining some packages, but I can't at this time
> continue taking care of them. So, next Sunday I'll orphan them if nobody
> ask me the transfer:
>
> * ascii
> * netmask
> * ez-pine-gpg
> * python-meld3
> * gpart
> * python-sysv_ipc
>

I can take python-sysv_ipc if nobody did it already.


> * reptyr
> * supervisor
>
> --
> Francisco J. Tsao Santín
> http://gattaca.es
> 1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kevin P. Fleming]

On 6/30/22 11:08, Vitaly Zaitsev via devel wrote:

On 30/06/2022 17:47, Gary Buhrmaster wrote:

If you do not understand this, talk to*your*
lawyer (only your lawyer is responsible to
you) and have them explain the details
and distinctions and reasonings to you.


Each court publishes the reasoning part of the decision.


This is not a court. It is a group of attorneys providing advice to 
their client (which happens to be their employer).


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 17:47, Gary Buhrmaster wrote:

If you do not understand this, talk to*your*
lawyer (only your lawyer is responsible to
you) and have them explain the details
and distinctions and reasonings to you.


Each court publishes the reasoning part of the decision.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

[przemek klosowski via devel]

How about a middle ground, by splitting langpacks into several larger 
groups (roman-alphabet+arabic&persian+far-eastern?, asian+european?). 
This way we wouldn't have to constantly twiddle with new packages and 
keep the number of packages sane.


p


On 6/30/22 06:32, Jens-Ulrik Petersen wrote:
On Thu, Jun 30, 2022 at 2:27 AM Vitaly Zaitsev via devel 
 wrote:


On 29/06/2022 19:00, Vipul Siddharth wrote:
> Firefox langpacks, which have been bundled in the Fedora firefox
base
> package until now, will be moved to a firefox-langpacks subpackage.

+1. It might be better to split it even more:
firefox-langpack-%{lang}
and depend on the system-wide language (just like spelling
dictionaries).

Users will be able to install only the required locales.


Right, I am aware of that.

One problem is that the number of firefox langpacks changes somewhat 
over releases,
so Martin was hesitant to take this approach in the past.  Probably 
still applies.
So the proposed approach seems like a reasonable compromise and step 
forward.


(I have pondered if we could decide on a set of core firefox langpacks 
which are "guaranteed" to exist
and so hopefully could be safely subpackaged - but this makes the 
handling more complicated

and delicate - it would have to be done very carefully in langpacks.)

Jens

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

Re: [HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th

[Karolina Surma]

Hi,

On 6/30/22 17:44, Bob Mauchin wrote:
> On Thu, 30 Jun 2022, 17:35 Karolina Surma,  > wrote:
> 
> Hello packagers,
> 
> The new major version of the popular documentation framework Sphinx has
> been recently released[0]. It brings many changes, among which there is
> support of docutils 0.18.1. We aim to update both packages together in
> Fedora Rawhide on **July 11th**.
> 
> Common issues and mitigation
> 
> - `None` is no longer accepted as value of `language` in conf.py
> Solution: Use `language = 'en'` instead.
> 
> - Build/ tests fail with: `AttributeError: 'path' object has no
> attribute 'text'`
> Solution: use `path.read_text()` instead
>  
> 
> 
> Full list of known affected packages
> 
> eclipseo   python-graphviz python-h2 python-priority
> 
> 
> Hello,
> 
> If we fix the common issues in Rawhide, will these fixes work on Fedora
> 36 with older Sphinx/docutils? 
> 
> Best regards, 
> 
> Robert-André

There is a good news.

`path.text()` has been deprecated since Sphinx 3 - the fix will work on
all active Fedora branches.

Regarding the language, it hasn't been automatically set to `None` since
at least Sphinx 2, but Sphinx 5 is the first one to enforce the string
value there. Fixing it should also work with all active Fedora releases.

The other issues will have to be checked case by case.

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

Re: Help needed: liquidctl and python3.11

[Petr Viktorin]

On 30. 06. 22 15:13, Artur Frenszek-Iwicki wrote:

Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent 
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my 
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.


Hello,
I replied on the bug: https://bugzilla.redhat.com/show_bug.cgi?id=2098741#c3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Gary Buhrmaster]

On Thu, Jun 30, 2022 at 3:33 PM Vitaly Zaitsev via devel
 wrote:
>
> On 30/06/2022 17:23, Michael Catanzaro wrote:
> > I do not expect Fedora Legal will likely come onto a public mailing list to 
> > debate liability with you. Hopefully it should be obvious why that's not a 
> > good idea. There's nothing more I can do except link you back to Matthew's 
> > post. Sorry.
>
> These are double standards. I don't why they hate RPM Fusion.
>
> Fedora is a public, community-driven distribution, so they must post an
> official response to our request.

No, they do not, really.  Community driven does
not (never has) meant that the community has
the final decision on everything.

If you do not understand this, talk to *your*
lawyer (only your lawyer is responsible to
you) and have them explain the details
and distinctions and reasonings to you.

Whether the RH lawyers recommendations in
this case are good or not, or whether anyone
agrees or not, is, ultimately, not really relevant.

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

Re: [HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th

[Bob Mauchin]

On Thu, 30 Jun 2022, 17:35 Karolina Surma,  wrote:

> Hello packagers,
>
> The new major version of the popular documentation framework Sphinx has
> been recently released[0]. It brings many changes, among which there is
> support of docutils 0.18.1. We aim to update both packages together in
> Fedora Rawhide on **July 11th**.
>
> Common issues and mitigation
>
> - `None` is no longer accepted as value of `language` in conf.py
> Solution: Use `language = 'en'` instead.
>
> - Build/ tests fail with: `AttributeError: 'path' object has no
> attribute 'text'`
> Solution: use `path.read_text()` instead
>
>
>
> Full list of known affected packages
>
> eclipseo   python-graphviz python-h2 python-priority


Hello,

If we fix the common issues in Rawhide, will these fixes work on Fedora 36
with older Sphinx/docutils?

Best regards,

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

[HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th

[Karolina Surma]

Hello packagers,

The new major version of the popular documentation framework Sphinx has
been recently released[0]. It brings many changes, among which there is
support of docutils 0.18.1. We aim to update both packages together in
Fedora Rawhide on **July 11th**.

As usual, an ongoing attempt to smoothly integrate the updates takes
place using Copr[1]. There are some packages impacted with the new
changes. Please take time to review an fix the package, or coordinate
with the upstream.

If your package hasn't succeeded to build with Python 3.11 yet, we can't
test whether it will work with this update.


Common issues and mitigation

- `None` is no longer accepted as value of `language` in conf.py
Solution: Use `language = 'en'` instead.

- Build/ tests fail with: `AttributeError: 'path' object has no
attribute 'text'`
Solution: use `path.read_text()` instead


Test your package locally in mock using the provided test Copr

$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
--no-clean 
$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
 shell


Packages that pin Sphinx and docutils to lower versions than are about
to be introduced, and will effectively stop working after the update has
reached Rawhide:

Sphinx < 5:
python-h2-0:4.1.0-7.fc37.src
python-priority-0:2.0.0-7.fc37.src
python-sphinx-panels-0:0.6.0-3.fc37.src
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinxcontrib-zopeext-0:0.3.2-3.fc37.noarch

docutils < 0.18:
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinx_rtd_theme-0:1.0.0-6.fc37.noarch


Full list of known affected packages

Maintainers by package:
copr-keygen  clime dturecek frostyx msuchy praiskup
coq  amdunn jjames
diceware kushal
kea  fjanus mosvald zdohnal
libcamerajavierm
liblognorm   alakatos rsroka zfridric
python-djangobkabrda churchyard jdornak mrunge rdopiera salimma
sgallagh
python-graphviz  eclipseo
python-h2eclipseo
python-pikepdf   qulogic zdohnal
python-priority  eclipseo
python-sphinx-panels qulogic
python-sphinx-tabs   hobbes1069
python-sphinx_rtd_theme jjames ksurma piotrp
python-sphinxcontrib-bibtex jjames
python-sphinxcontrib-htmlhelp churchyard cstratak
python-sphinxcontrib-jsmath churchyard cstratak
python-sphinxcontrib-qthelp churchyard cstratak
python-sphinxcontrib-zopeext jjames

Packages by maintainer:
alakatos   liblognorm
amdunn coq
bkabrdapython-django
churchyard python-django python-sphinxcontrib-htmlhelp
python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp
clime  copr-keygen
cstratak   python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath
python-sphinxcontrib-qthelp
dturecek   copr-keygen
eclipseo   python-graphviz python-h2 python-priority
fjanus kea
frostyxcopr-keygen
hobbes1069 python-sphinx-tabs
javiermlibcamera
jdornakpython-django
jjames coq python-sphinx_rtd_theme python-sphinxcontrib-bibtex
python-sphinxcontrib-zopeext
ksurma python-sphinx_rtd_theme
kushal diceware
mosvaldkea
mrunge python-django
msuchy copr-keygen
piotrp python-sphinx_rtd_theme
praiskup   copr-keygen
qulogicpython-pikepdf python-sphinx-panels
rdopiera   python-django
rsroka liblognorm
salimmapython-django
sgallagh   python-django
zdohnalkea python-pikepdf
zfridric   liblognorm


Cheers,
Karolina Surma


[0] https://www.sphinx-doc.org/en/master/changes.html
[1] https://copr.fedorainfracloud.org/coprs/ksurma/sphinx-5/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 17:23, Michael Catanzaro wrote:
I do not expect Fedora Legal will likely come onto a public mailing list to debate liability with you. Hopefully it should be obvious why that's not a good idea. There's nothing more I can do except link you back to Matthew's post. Sorry. 


These are double standards. I don't why they hate RPM Fusion.

Fedora is a public, community-driven distribution, so they must post an 
official response to our request.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

[luya]

On 2022-06-30 12:44 a.m., Peter Robinson  wrote:

On Thu, Jun 30, 2022 at 2:39 AM Luya Tshimbalanga
 wrote:
>
> On 2022-06-29 01:24, Peter Robinson wrote:
>
> On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga
>  wrote:
>
> Hello team,
>
> What is the way to disable `-mss2 for aarch64 build in embree?
>
> I think you mean msse2, the build should be using the distro default C
> flags for builds so it shouldn't be an issue, if you fix the build to
> use the proper distro flags the problem should go away. Details in the
> docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
>
> Which is strange as the used flag is `%{optflags} -Wl,--as-needed`as listed 
on the attached spec file.
>
> Extract:
>
> export CXXFLAGS="%{optflags} -Wl,--as-needed"
>
> The issue currently affects the new version of embree.

Have you filed a bug upstream?


Similar bug is already filed:
https://github.com/embree/embree/issues/383
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Alexander Sosedkin]

Quoting Kevin Kofler via devel (2022-06-30 14:15:04)
> You are making two doubtful assumptions:
>
> 1. That the users will bother reporting their issues to the server
> administrators at all. I would expect them to just blame Fedora for it and
> move to a different operating system that just works, or at most to apply a
> local workaround (what I called "jump through hoops", e.g., changing the
> system crypto policy to LEGACY and/or loading the legacy provider with its
> legacy algorithms into OpenSSL) and then forget about it.

> 2. That the server administrators will actually care about complaints from
> non-Windows users, assuming they even read user complaints at all to begin
> with, and that they will be willing to switch to newer (more secure)
> algorithms that may break compatibility with some ancient operating systems
> that other users might still use.

I agree with your statements
but I do not make the assumptions you prescribe to me.
I'm painfully aware that progress doesn't happen magically
when we break something in Fedora.
Hoops are a horrible propellant of progress,
but still the best one we have.

> I do not believe that Fedora actually has any levy to get server
> administrators to upgrade their setups.
> We have to work with whatever obsolete junk is out there.

Is Fedora supposed to be a locomotive of secure defaults?
In an attempt to slow down devolving into opinion-vs-opinion,
let me back mine with https://docs.fedoraproject.org/en-US/project:

> Four Foundations: First
>
> We are committed to innovation.
>
> We are not content to let others do all the heavy lifting on our behalf;
> we provide the latest in stable and robust, useful,
> and powerful free software in our Fedora distribution.
>
> At any point in time, the latest Fedora platform
> shows the future direction of the operating system
> as it is experienced by everyone from the home desktop user
> to the enterprise business customer.
> Our rapid release cycle
> is a major enabling factor in our ability to innovate.
>
> We recognize that there is also a place for long-term stability in the
> Linux ecosystem, and that there are a variety of community-oriented
> and business-oriented Linux distributions available to serve that need.
> However, the Fedora Project’s goal of advancing free software dictates
> that the Fedora Project itself pursue a strategy
> that preserves the forward momentum of our technical,
> collateral, and community-building progress.
> Fedora always aims to provide the future, first.

In terms of cryptographic defaults, Fedora even lags behind RHEL,
so requests to slow down even further don't elicit much support from me.
If one day this page replaces "First" with, say,
"Compatibility: we have to work with whatever obsolete junk is out there,
security comes second", I will concede.
But today, I think the current pace of
deprecations *in the default configuration*
doesn't just align with Fedora's goals, it's slower than it should be.

Non-default configurations are a different beast altogether,
and the users' feet-shooting freedom is something we should defend, yes.
But the defaults have to march on unabated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael Catanzaro]

On Thu, Jun 30 2022 at 05:02:35 PM +0200, Vitaly Zaitsev via devel 
 wrote:

This is not a real answer. These are double standards.


It's not a double standard: Matthew explained precisely why RPM Fusion 
is different and riskier than Flathub. I'm sorry it's not the answer 
that you wanted to hear, but rest assured it is the actual answer.


I do not expect Fedora Legal will likely come onto a public mailing 
list to debate liability with you. Hopefully it should be obvious why 
that's not a good idea. There's nothing more I can do except link you 
back to Matthew's post. Sorry.


Michael

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

Re: Can we start changing License to SPDX now?

[Ben Beasley]

As I read it, the Change text strongly implies that package maintainers should 
wait for FPC to approve updated Licensing guidelines. That work seems to be in 
progress here: https://pagure.io/packaging-committee/pull-request/1142

– Ben

On Wed, Jun 29, 2022, at 3:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote:
>> > #2799 F38 Change proposal: SPDX License Phase 1
>> > APPROVED (+5,0,-0)
>> 
>> Do I understand it correctly that we can change License tags in our spec 
>> files
>> to SPDX syntax right now?
>> 
>> Or should we wait until updating
>>  to SPDX
>> identifiers? 
>
> That's my understanding. The plan is to not treat the wiki as the
> authoritative source, but instead to generate a Docs page from a table
> in fedora-license-data.rpm. If the license is listed in
> /usr/share/fedora-license-data/licenses/fedora-licenses.json as approved:yes,
> then this should be enough. The plan is to rework the wiki too, but that'll
> likely take more time.
>
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Robbie Harwood]

Charalampos Stratakis  writes:

> Unfortunately that effort is moot, it's really not possible to make
> python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
> versions are not 100% compatible for various reasons.
>
> In trying to make it compatible there are also ABI changes introduced,
> it's not only about having the tests pass. The ssl module is already
> complex enough in backporting changes from the master Python branch to
> previous 3.x versions, doing that for 2.7 without a full fledged
> effort from SSL and the Python C API experts guarantee there's gonna
> be regressions. And that's not even taking into account the security
> implications of randomly cherry-picking commits just to have the
> package compile.

I'm having trouble understanding this because Debian seems to have
carried out what you're saying is impossible: in testing, they ship a
python2.7 that appears to be using openssl 3, and do not ship openssl
1.1 at all.  There are also a handful of clearly openssl 3-related
patches in their tree
https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches

Have folks looked at how they do this, and whether we could adapt it to
Fedora?

Be well,
--Robbie


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Ben Beasley]

I agree (vigorously and in detail) with Fabio’s message.

– Ben Beasley

On Wed, Jun 29, 2022, at 12:42 PM, Fabio Valentini wrote:
> On Wed, Jun 29, 2022 at 5:46 PM Dmitry Belyavskiy  wrote:
>>
>> On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok  wrote:
>>>
>>> Please don't remove the devel package if you aim for deprecation. As other 
>>> have
>>> said, removing the devel package is essentially retirement, not deprecation.
>>
>> OK, it's not a problem to deprecate the package in the sense of  
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
>
> I agree with Miro.If you want to ensure no new packages start
> depending on openssl1.1, then adding "Provides: deprecated()" (to both
> the openssl1.1 and openssl1.1-devel packages) is exactly what you
> want. fedora-review includes a check that prints a warning when a
> package depends on something that has "Provides: deprecated()", so no
> new packages should ever be added to Fedora that depend on something
> that is deprecated.
>
> Removing a (sub-)package is not a "deprecation", because it already
> breaks dependent packages, and *does not* give any advance warning to
> affected people, which a deprecation is supposed to provide.
>
>> But we still want to get rid of it.
>
> I understand this goal, but starting with a deprecation means that
> this will be a two-step process:
>
> 1) deprecate openssl1.1 and openssl1.1 packages (adding "Provides:
> deprecated()" to them): this ensures no new packages depend on them
> (fine to do that for Fedora 37)
> 2) once no Fedora packages (only third-party binaries) depend on
> openssl1.1, you *can* drop openssl1.1-devel (too early in Fedora 37,
> target 38 or 39 instead?, see EOL dates listed below)
>
> Dropping openssl1.1-devel (and keeping openssl1.1) *before* all
> official Fedora components have been ported to openssl 3 is
> essentially making them hang by the thinnest of threads - the packages
> will fail to build, but still be *installable* - if only for so long.
>
> These packages will also start to fail to install after any soname
> bump (or another similar change) in their dependency trees - because
> they won't be able to be rebuilt for that (unrelated) change, because
> openssl1.1-devel is gone. It will also block any critical / security
> updates for affected packages, which is certainly not what we want.
>
> So, please, don't remove the openssl1.1-devel package while there's
> still Fedora packages that depend on it. I assume openssl1.1 itself
> will be kept for some time, to provide support for third-party
> applications that require it? So keeping the -devel package around
> does not create any additional work for you, but it will make life for
> maintainers of dependent packages much easier, until they can switch
> their packages to OpenSSL 3.
>
>>> > I don't think that the community really requires support for this package 
>>> > for 7
>>> > years after its upstream sunset.
>>>
>>> OpenSSL 3 was introduced in Fedora 36, that has *just* been released this 
>>> year.
>>> This is a change proposal for Fedora 37, that is half a year after, not 7 
>>> years :/
>>
>>
>> Well, speaking about 7 years, I mean the idea to support the compat package 
>> synchronously with RHEL 8.
>> I'd like to retire this package not later than, well, a release after 
>> OpenSSL 1.1.1 EOL.
>
> According to the OpenSSL website
> (https://www.openssl.org/policies/releasestrat.html) OpenSSL 1.1.1
> will be supported until 2023-09-11.
> Fedora 37 will be EOL at around 2023-11-14
> (https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html),
> so OpenSSL 1.1.1 will still be officially supported for most of its
> lifecycle - I don't see why it already needs to be removed in Fedora
> 37.
>
> This alignment of EOL dates make me wonder whether the removal of
> openssl1.1(-devel) should be targeted at Fedora 38 (more than half its
> supported lifetime is after OpenSSL 1.1.1 is EOL) or Fedora 39
> (released after OpenSSL 1.1.1 is EOL) instead, but Fedora 37 seems too
> early for a *removal*, but officially deprecating it in Fedora 37
> sounds very reasonable to me.
>
> Fabop
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidel

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael Catanzaro]

On Thu, Jun 30 2022 at 02:20:58 PM +0200, Kevin Kofler via devel 
 wrote:


That would make a lot of sense indeed (though the default would still 
need
to be agreed on). But unfortunately, asking for any kind of user 
preference
to be added to a GNOME application is usually a lost cause. GNOME has 
a

strict "take it or leave it" policy.


I actually agree that it makes sense to have a preference for this. We 
discussed it in the past but gave up because it required effort. The 
current Software Sources page is not designed to allow you to reorder 
sources in arbitrary ways. It would be easy to expose a switch for the 
current "prefer flatpak vs. prefer RPM setting," but that might not be 
powerful enough for what users actually want, e.g. it doesn't allow you 
to prefer Fedora flatpak > Fedora RPM > Flathub, or Flathub > Fedora 
RPM > Fedora Flatpak. I think this is probably a "help welcome" area.


Of course, users have the final choice when installing.

Michael

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael Catanzaro]

On Thu, Jun 30 2022 at 01:54:16 PM +0200, Vitaly Zaitsev via devel 
 wrote:

Flathub is already preloaded and enabled by default,


Actually it's NOT enabled by default, and we do not propose to change 
that. To get Flathub, users must either:


* Press the Enable Third-Party Repositories button on the Third-Party 
Repositories page in gnome-initial-setup, or
* Flip one or more switches at the bottom of the Software Repositories 
dialog in GNOME Software


The goal is to make it easy for users to find third-party software if 
they choose to enable it, but by default stay limited to only open 
source software provided by Fedora.


Michael

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 16:44, Michael Catanzaro wrote:
You actually linked straight to the answer. Matthew's response there is 
not some passing speculation; that's the real answer based on discussion 
with Fedora Legal.


This is not a real answer. These are double standards.

RPM Fusion is a third-party repository too which provides software for 
various Linux distributions: Fedora Linux, Red Hat Enterprise Linux, 
Rocky Linux and Alma Linux.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 16:18, Artur Frenszek-Iwicki wrote:

That's debatable. Does the*average user*  even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.


True. Most users don't care, so they will get Flatpaks instead of RPMs.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 16:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is untrusted" 
and "Flathub packaging is poor" since proponents of these arguments 
conveniently ignore the fact that traditional RPMs are totally unsandboxed.


I would prefer a non-sandboxed app instead of a third-party DEB repack.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael Catanzaro]

On Thu, Jun 30 2022 at 12:16:09 PM +0200, Vitaly Zaitsev via devel 
 wrote:

They don't want to answer why they can't preload RPM Fusion:
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/TCULL55CJGEAYKK5SLHNHZ4BGEUWM3KL/


You actually linked straight to the answer. Matthew's response there is 
not some passing speculation; that's the real answer based on 
discussion with Fedora Legal.


Michael

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael Catanzaro]

Please remember that Flathub remains disabled by default even if this 
change proposal is fully implemented. It's gated behind the "enable 
third-party software?" switch. So if you only want free software from 
Fedora, you'll just leave that switch off and never see anything from 
Flathub. (In fact, enabling it by default would actually be prohibited 
by previous FESCo and Fedora Council decisions.) But users who do 
choose enable third-party software really want to see Flathub 
unfiltered, not our confusing and annoying limited view of Flathub.


On Thu, Jun 30 2022 at 11:18:04 AM +0200, Kevin Kofler via devel 
 wrote:

Users of RPM-based variants will expect the default package manager to
install RPMs, not Flatpaks, or they would have chosen a Flatpak-based
variant.


Any such expectations are misplaced. The people working on Silverblue 
do not feel that it is ready to become Fedora Workstation yet, but 
Flatpaks are certainly ready and there's no need to wait. Various 
discussions about using more flatpaks:


https://pagure.io/fedora-workstation/issue/151 (resolved long ago)
https://pagure.io/fedora-workstation/issue/269 (next up)
https://pagure.io/fedora-workstation/issue/300 (this change proposal)

I take a pretty dim view towards arguments about "Flathub is untrusted" 
and "Flathub packaging is poor" since proponents of these arguments 
conveniently ignore the fact that traditional RPMs are totally 
unsandboxed. One memory safety bug and your PDF reader, video player, 
or other native app has full control of your user account and can do 
whatever it wants with all your files. And Linux apps have *lots* of 
memory safety bugs. With the exception of web browsers (all of which 
have strong sandboxes), few other apps are even trying to sandbox 
themselves. I'm not too interested in rehashing the same old arguments 
about this because it has all been well-known and said many, many, many 
times before. (Yes, system libraries are generally safer than bundled 
libraries. No, this is not anywhere near as important as having a 
strong sandbox. Yes, many apps on Flathub sabotage the sandboxing to 
the point where it is meaningless, and yes that should be discouraged 
harder somehow.)


Opponents of Flatpak have had seven years since Flatpak launched to 
figure out an alternative model to make apps safe using firejail or 
bwrap or whatever, but nobody ever seriously did, and at this point the 
endgame has arrived with a *commanding* lead in favor of Flatpak. So 
it's time to move on.


Having third-party Flatpaks take precedence over Fedora RPMs that 
nobody has bothered to Flatpak is a very intentional choice to improve 
user safety (again, only if users opt-in to third-party software). But 
you can ensure the Fedora version of an app takes precedence by 
creating a Fedora Flatpak for it. And users ultimately have full 
control over which source they use to install.


Regardless, Fedora will still be RPM-based no matter what. ;) Even if 
our future is OS images composed of RPMs plus Flatpaks composed by 
RPMs, it's still based on RPMs. (Of course stuff from Flathub is not 
based on RPMs, but we wouldn't expect third-party stuff to be.)


Michael

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> Too complicated for the average user.
That's debatable. Does the *average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.

> It should be visible when you click the "Install" button.
I agree that the current placement makes the source dropdown
not very visible and easy to miss. I was thinking if having some
kind of combo-button (i.e. button + dropdown) would be a
better option - something like:
+ --+---+
| Install   |   |
| (From Fedora RPM) | v |
+---+---+
This would make the selected source prominent
and allow to easily switch to a different one.

Either way, this is all a UX discussion, and with
GNOME's take-it-or-leave-it approach, I fear
we'd have to patch gnome-software to achieve
something like the above, which would probably
create a lot of maintenance burden.

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 14:18, Artur Frenszek-Iwicki wrote:

Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.


Too complicated for the average user. It should be visible when you 
click the "Install" button.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 14:22, Kevin Kofler via devel wrote:

You are conveniently ignoring the drawbacks of the approach, see, e.g.:
http://flatkill.org/
and that is by no means a complete list.


See also: https://ludocode.com/blog/flatpak-is-not-the-future

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Charalampos Stratakis]

And I would very much prefer to remedy the issue of having packages still
relying on python2 rather than thinking about removing OpenSSL 1.1.1 that's
still supported upstream and many packages depend on it.

On Thu, Jun 30, 2022 at 3:29 PM Charalampos Stratakis 
wrote:

> Unfortunately that effort is moot, it's really not possible to make
> python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
> versions are not 100% compatible for various reasons.
>
> In trying to make it compatible there are also ABI changes introduced,
> it's not only about having the tests pass. The ssl module is already
> complex enough in backporting changes from the master Python branch to
> previous 3.x versions, doing that for 2.7 without a full fledged effort
> from SSL and the Python C API experts guarantee there's gonna be
> regressions. And that's not even taking into account the security
> implications of randomly cherry-picking commits just to have the package
> compile.
>
> On Wed, Jun 29, 2022 at 5:12 PM Dmitry Belyavskiy 
> wrote:
>
>> Dear colleagues,
>>
>> If I correctly follow the discussion, the biggest show-stopper is Python
>> 2.*, which has some incomplete patches to deal with OpenSSL 3.0.
>> If we assist you in moving these patches forward, can we get rid of the
>> devel package and leave the compat package only for 3rd-party packages?
>>
>> I don't think that the community really requires support for this package
>> for 7 years after its upstream sunset.
>>
>> Many thanks!
>>
>> On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok  wrote:
>>
>>> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
>>> > ==
>>> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
>>> > --
>>> > Traceback (most recent call last):
>>> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382,
>>> in test_openssl_version
>>> >  (s, t))
>>> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>>>
>>> Might be https://github.com/python/cpython/issues/90272
>>>
>>> --
>>> Miro Hrončok
>>> --
>>> Phone: +420777974800
>>> IRC: mhroncok
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>> Do not reply to spam on the list, report it:
>>> https://pagure.io/fedora-infrastructure
>>>
>>
>>
>> --
>> Dmitry Belyavskiy
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Regards,
>
> Charalampos Stratakis
> Senior Software Engineer
> Python Maintenance Team, Red Hat
>


-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Charalampos Stratakis]

Unfortunately that effort is moot, it's really not possible to make
python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
versions are not 100% compatible for various reasons.

In trying to make it compatible there are also ABI changes introduced, it's
not only about having the tests pass. The ssl module is already complex
enough in backporting changes from the master Python branch to previous 3.x
versions, doing that for 2.7 without a full fledged effort from SSL and the
Python C API experts guarantee there's gonna be regressions. And that's not
even taking into account the security implications of randomly
cherry-picking commits just to have the package compile.

On Wed, Jun 29, 2022 at 5:12 PM Dmitry Belyavskiy 
wrote:

> Dear colleagues,
>
> If I correctly follow the discussion, the biggest show-stopper is Python
> 2.*, which has some incomplete patches to deal with OpenSSL 3.0.
> If we assist you in moving these patches forward, can we get rid of the
> devel package and leave the compat package only for 3rd-party packages?
>
> I don't think that the community really requires support for this package
> for 7 years after its upstream sunset.
>
> Many thanks!
>
> On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok  wrote:
>
>> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
>> > ==
>> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
>> > --
>> > Traceback (most recent call last):
>> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382, in
>> test_openssl_version
>> >  (s, t))
>> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>>
>> Might be https://github.com/python/cpython/issues/90272
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Dmitry Belyavskiy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Help needed: liquidctl and python3.11

[Artur Frenszek-Iwicki]

Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent 
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my 
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.

Strictly speaking, the package builds fine, and it passes all tests, save one - 
the doctest,
which, as I understand it, somehow checks if the doc-comments match the code.
The doctest fails in a couple of places, but to give you an example, here's one 
of them:

__ [doctest] liquidctl.driver.ddr4.VengeanceRgb.Mode 
___
320 A collection of name/value pairs.
321 
322 Access them by:
323 
324 - attribute access::
325 
326 >>> Mode.FIXED
UNEXPECTED EXCEPTION: NameError("name 'Mode' is not defined")
Traceback (most recent call last):
  File "/usr/lib64/python3.11/doctest.py", line 1350, in __run
exec(compile(example.source, filename, "single",

  File "", line 1, in 

NameError: name 'Mode' is not defined
/builddir/build/BUILD/liquidctl-1.9.1/liquidctl/driver/ddr4.py:326: 
UnexpectedException

The full build log can be found here:
https://kojipkgs.fedoraproject.org//work/tasks/7849/88567849/build.log

If someone knows how to fix this, help will be appreciated.

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

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Miro Hrončok]

On 29. 06. 22 17:45, Dmitry Belyavskiy wrote:
OK, it's not a problem to deprecate the package in the sense of 
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ 


But we still want to get rid of it.


Consider also not allowing packages to use openss1.1-devel unless they have a 
FESCo exception.


See e.g. https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

[Francisco J . Tsao Santín via devel]

On Thu, 30 Jun 2022, Didier FABERT wrote:

> I'll take ascii if nobody wants it.
> 

Done! :-) Thanks!
-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kevin Kofler via devel]

Richard Hughes wrote:
> As the person who's been driving AppStream to make desktop
> applications easier to install on Linux for the last decade (!) I can
> tell you that flatpaks are in almost all cases what users should be
> using. By any metric (e.g. live updates, portals, sandboxing,
> per-user/per-system) they blow apps-as-packages out of the water. Use
> packaged versions of your apps if you want to, but please don't veto a
> feature that 99.99% of Fedora users categorically should be using.

You are conveniently ignoring the drawbacks of the approach, see, e.g.:
http://flatkill.org/
and that is by no means a complete list.

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

Re: Orphaning my packages

[Francisco J . Tsao Santín via devel]

On Thu, 30 Jun 2022, Ali Erdinc Koroglu wrote:

> I'll take reptyr and supervisor, thank you.

Sorry, reptyr has already been taken by František Šumšal. But I
transfered you supervisor :-) Thanks!

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kevin Kofler via devel]

Artur Frenszek-Iwicki wrote:
> That being said, what about allowing users to set this preference by
> themselves?

That would make a lot of sense indeed (though the default would still need 
to be agreed on). But unfortunately, asking for any kind of user preference 
to be added to a GNOME application is usually a lost cause. GNOME has a 
strict "take it or leave it" policy.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> I'd imagine a single slider (or drop-down menu or whatever)
Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.

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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Neal Gompa]

On Thu, Jun 30, 2022 at 8:11 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
> > On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
> > > That being said, what about allowing users to set this preference by 
> > > themselves?
> >
> > +1. Let's let users make choices, not choose for them.
> >
> > Gnome Software should explicitly ask the user to select a package source
> > before starting installation.
>
> "Explicitly" is maybe too much. I'd imagine a single slider (or
> drop-down menu or whatever) that says "rpm", "flatpak from flathub",
> "flatpak from …" when there's more than one choice, with the default
> selected by the global preference.
>

I want GNOME Software to prefer Fedora sources before third party
ones. For me, I also would prefer RPM > Flatpak, because I don't like
the experience I've had with Flatpaks and Flathub, but that's a
different preference.

GNOME Software should always offer Fedora content first, because it's
first-party. If a Fedora RPM and a Flathub Flatpak are on the table,
it should prefer to offer the Fedora RPM.

GNOME Software should not be implicitly discouraging the Fedora
community's efforts.

Keep in mind the alternative to people packaging RPMs isn't that they
do something else, it's that they stop contributing entirely.



--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Ankur Sinha]

Thanks Clemens for commenting on the Ask Fedora post. Hopefully that'll
help the user and others.

I understand the idea behind deprecating things---otherwise they never
improve---but I also note that while individual users may be pushed to
update etc., the same does not apply to institutions.

When I "solved" my issue, it took me about a while to figure out[1].
Then I gave IT all the info and received a "thank you, we'll look into
it when we upgrade our systems next". So, they'll have their own plans
and constrains, they are slow moving bodies, and we users can do very
little to force them to do pretty much anything. They're certainly not
going to align to Fedora community release cycles---they tend to be
Windows based institutions in general

So, as always, if a middle ground can be found, that's all we can strive
for. Once the new issue is solved on Ask Fedora, it'll hopefully become
another resource that users can easily find.

[1] 
https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288/8

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


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

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Kevin Kofler via devel]

Alexander Sosedkin wrote:
>> without having to jump through hoops.
> 
> No, or nothing ever moves on, squarely because
> 
>> Users want to be able to connect to their WPA* WiFi networks,
>> view their HTTPS websites, etc.
>> They do not care whether those use the latest,
>> most secure versions of the standard or not.

You are making two doubtful assumptions:

1. That the users will bother reporting their issues to the server 
administrators at all. I would expect them to just blame Fedora for it and 
move to a different operating system that just works, or at most to apply a 
local workaround (what I called "jump through hoops", e.g., changing the 
system crypto policy to LEGACY and/or loading the legacy provider with its 
legacy algorithms into OpenSSL) and then forget about it.

2. That the server administrators will actually care about complaints from 
non-Windows users, assuming they even read user complaints at all to begin 
with, and that they will be willing to switch to newer (more secure) 
algorithms that may break compatibility with some ancient operating systems 
that other users might still use.

I do not believe that Fedora actually has any levy to get server 
administrators to upgrade their setups. We have to work with whatever 
obsolete junk is out there.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
> On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
> > That being said, what about allowing users to set this preference by 
> > themselves?
> 
> +1. Let's let users make choices, not choose for them.
> 
> Gnome Software should explicitly ask the user to select a package source
> before starting installation.

"Explicitly" is maybe too much. I'd imagine a single slider (or
drop-down menu or whatever) that says "rpm", "flatpak from flathub",
"flatpak from …" when there's more than one choice, with the default
selected by the global preference.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220630.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220629.n.0
NEW: Fedora-Rawhide-20220630.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  8
Dropped packages:3
Upgraded packages:   86
Downgraded packages: 0

Size of added packages:  12.09 MiB
Size of dropped packages:126.87 KiB
Size of upgraded packages:   5.23 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20220629.n.0.iso
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20220629.n.0.aarch64.raw.xz
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20220629.n.0.iso

= ADDED PACKAGES =
Package: golang-github-derekparker-trie-0-0.1.20220629git1fdf38b.fc37
Summary: Data structure and algorithms for fast prefix/fuzzy string searching
RPMs:golang-github-derekparker-trie-devel
Size:13.92 KiB

Package: golang-github-rabbitmq-amqp091-1.3.4-1.fc37
Summary: An AMQP 0-9-1 Go client maintained by the RabbitMQ team
RPMs:golang-github-rabbitmq-amqp091-devel
Size:83.42 KiB

Package: mopac-22.0.3-1.fc37
Summary: A semiempirical quantum chemistry program
RPMs:mopac mopac-devel mopac-libs
Size:9.12 MiB

Package: oddjob-gpupdate-0.2.1-1.fc37
Summary: An oddjob helper which applies group policy objects
RPMs:oddjob-gpupdate
Size:93.58 KiB

Package: php-sebastian-type3-3.0.0-2.fc37
Summary: Collection of value objects that represent the types of the PHP type 
system, v3
RPMs:php-sebastian-type3
Size:17.95 KiB

Package: python-isoduration-20.11.0-1.fc37
Summary: Operations with ISO 8601 durations
RPMs:python3-isoduration
Size:31.05 KiB

Package: python-uri-template-1.2.0-2.fc37
Summary: RFC 6570 URI Template Processor
RPMs:python3-uri-template
Size:32.21 KiB

Package: switchtec-3.1-1.fc37
Summary: Userspace code for the Microsemi PCIe switch
RPMs:switchtec switchtec-devel switchtec-doc switchtec-libs
Size:2.70 MiB


= DROPPED PACKAGES =
Package: php-sebastian-type2-2.3.4-3.fc36
Summary: Collection of value objects that represent the types of the PHP type 
system, version 2
RPMs:php-sebastian-type2
Size:17.88 KiB

Package: python-language-server-0.36.2-6.fc35
Summary: Python Language Server for the Language Server Protocol
RPMs:python3-language-server
Size:92.78 KiB

Package: python-pyls_black-0.4.7-4.fc37
Summary: Black plugin for the Python Language Server
RPMs:python3-pyls_black
Size:16.21 KiB


= UPGRADED PACKAGES =
Package:  american-fuzzy-lop-4.01c-1.fc37
Old package:  american-fuzzy-lop-4.00c-3.git285a5cb3.fc37
Summary:  Practical, instrumentation-driven fuzzer for binary formats
RPMs: american-fuzzy-lop american-fuzzy-lop-clang
Size: 1.37 MiB
Size change:  10.85 KiB
Changelog:
  * Wed Jun 29 2022 Richard W.M. Jones  - 4.01c-1
  - New upstream version 4.01c (RHBZ#2101976)


Package:  ansible-lint-1:6.3.0-1.fc37
Old package:  ansible-lint-1:6.2.2-2.fc37
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 322.25 KiB
Size change:  1.56 KiB
Changelog:
  * Fri Jun 17 2022 Parag Nemade  - 1:6.3.0-1
  - Update to 6.3.0 version (#2095420)


Package:  argyllcms-2.3.1-1.fc37
Old package:  argyllcms-2.3.0-2.fc36
Summary:  ICC compatible color management system
RPMs: argyllcms argyllcms-data argyllcms-doc
Size: 23.50 MiB
Size change:  22.67 KiB
Changelog:
  * Wed Jun 29 2022 Vitaly Zaitsev  - 2.3.1-1
  - Updated to version 2.3.1.


Package:  blueman-1:2.3-1.beta1.fc37
Old package:  blueman-1:2.2.5-2.fc37
Summary:  GTK+ Bluetooth Manager
RPMs: blueman blueman-caja blueman-nautilus blueman-nemo blueman-thunar
Added RPMs:   blueman-caja blueman-nautilus blueman-nemo blueman-thunar
Size: 5.83 MiB
Size change:  -41.57 KiB
Changelog:
  * Wed Jun 29 2022 Artur Frenszek-Iwicki  - 1:2.3-1.beta1
  - Update to v2.3.beta1
  - Call configure manually, instead of letting autogen.sh do that
  - Add subpackages providing caja/nautilus/nemo/thunar integration


Package:  buildbot-3.3.0-5.fc37
Old package:  buildbot-3.3.0-4.fc36
Summary:  Build/test automation system
RPMs: buildbot buildbot-master buildbot-master-container 
buildbot-master-ec2 buildbot-master-libvirt buildbot-master-openstack 
buildbot-worker buildbot-www
Size: 4.37 MiB
Size change:  505.02 KiB
Changelog:
  * Wed Jun 29 2022 Python Maint  - 3.3.0-5
  - Rebuilt for Python 3.11


Package:  cfn-lint-0.61.1-3.fc37
Old package:  cfn-lint-0.61.1-1.fc37
Summary:  CloudFormation Linter
RPMs: cfn-lint
Size: 2.30 MiB
Size change:  -9.22 KiB
Changelog:
  * Tue Jun 28 2022 Benjamin A. Beasley  0.61.1-2
  - Allow jsonschema 4.x (close RHBZ#2101852)

  * Wed Jun 29 2022 Benjamin A

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 12:40, Michael J Gruber wrote:

Note that the proposal is not about enabling Flathub, only about its filtering. 
As far as I understand it remains off by default.


Flathub is already preloaded and enabled by default, but filtered. Now 
they want to remove this filter.


This will make the Fedora packagers work useless, because GNOME Software 
will always prefer Flathub packages.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Alexander Sosedkin]

Quoting Kevin Kofler via devel (2022-06-30 13:16:55)
> Clemens Lang wrote:
> > I hope you’re not suggesting we keep the defaults insecure because there
> > are some institutions out there that don’t support modern standards.
>
> Sorry, but I am.
> The defaults need to work out there in the real world.

Your model lacks the driver for deprecating anything for good,
in neither defaults nor the real world.

> If legacy standards are still widespread,
> they need to be supported out of the box,

Yes.

> without having to jump through hoops.

No, or nothing ever moves on, squarely because

> Users want to be able to connect to their WPA* WiFi networks,
> view their HTTPS websites, etc.
> They do not care whether those use the latest,
> most secure versions of the standard or not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Richard Hughes]

On Thu, 30 Jun 2022 at 10:41, Dominik 'Rathann' Mierzejewski
 wrote:
> ... *when* they are sandboxed ...
> Unfortunately, in many cases, they aren't.

I don't think that "some apps have lots of holes punched in the
sandbox, but can be locked down easily using a GUI tool, where the
majority are indeed locked down" can reasonably be compared to the
distro packages that are never run in sandboxes and cannot be locked
down in the same way. By that logic we should remove all distro
applications because they can't be locked down or sandboxed by the
user in any meaningful way.

As the person who's been driving AppStream to make desktop
applications easier to install on Linux for the last decade (!) I can
tell you that flatpaks are in almost all cases what users should be
using. By any metric (e.g. live updates, portals, sandboxing,
per-user/per-system) they blow apps-as-packages out of the water. Use
packaged versions of your apps if you want to, but please don't veto a
feature that 99.99% of Fedora users categorically should be using.

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

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Kevin Kofler via devel]

Clemens Lang wrote:
> I hope you’re not suggesting we keep the defaults insecure because there
> are some institutions out there that don’t support modern standards.

Sorry, but I am. The defaults need to work out there in the real world. If 
legacy standards are still widespread, they need to be supported out of the 
box, without having to jump through hoops. Users want to be able to connect 
to their WPA* WiFi networks, view their HTTPS websites, etc. They do not 
care whether those use the latest, most secure versions of the standard or 
not. (In fact, most users do not even care that encryption is used at all, 
they only use encryption at all because the other end forces them to, i.e., 
because the WiFi network requires it, or the website uses HTTP to HTTPS 
redirection and/or HSTS, etc.)

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Clemens Lang]

Hi,

Kevin Kofler via devel  wrote:


If the default crypto policies fail with the world's largest WiFi network,
then surely they are too strict to be useful in practice and need to be
relaxed.


It may be the world’s largest WiFi network, but authentication is delegated
to the various institutions. The TLS server that handles authentication is
probably run by this user’s university IT department, and their server does
not support modern TLS.

I hope you’re not suggesting we keep the defaults insecure because there are
some institutions out there that don’t support modern standards.


--
Clemens Lang
RHEL Crypto Team
Red Hat


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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:

That being said, what about allowing users to set this preference by themselves?


+1. Let's let users make choices, not choose for them.

Gnome Software should explicitly ask the user to select a package source 
before starting installation.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Michael J Gruber]

> On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
>  
> Given that flathub provides similar / overlapping content compared to
> RPMFusion (or often, even more "legally problematic" than what's
> available from RPMFusion, i.e. prebuilt blobs), doesn't this same
> reasoning also apply there? I.e. can Fedora enable the full rpmfusion
> repositories by default, as well, instead of only the separate
> ("filtered") repositories for the proprietary NVidia drivers and the
> Steam client?

Note that the proposal is not about enabling Flathub, only about its filtering. 
As far as I understand it remains off by default.

But RPMfusion was my first thought , too. We don't even ship the repo 
definitions, do we, and enabling "third party software" in Gnome software 
center does not enable RPMfusion. Why not?

My second thought was about packaging. Why should I inverst my free time into 
rpm packaging, especially unbundling, caring about dependent packages etc. - 
i.e. evreything which makes a distro a distro - when the preferred "packaging" 
switches to flatpaks?

"Additionally, the filtered Flathub has not been popular with users.
[...]
Dropping the filter will resolve this criticism."

While we do our packaging work *for* the users, that argument really doesn't 
convice me. Give them "curl | sudo sh" because it's so simple and provides more 
applications? Let npm and cargo and pip install right into /usr? Much easier 
and so many apps! What could go wrong?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Dominik 'Rathann' Mierzejewski]

On Thursday, 30 June 2022 at 09:52, Marc Pervaz Boocha via devel wrote:
> On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
> > On 29/06/2022 20:25, Michael Catanzaro wrote:
> > > GNOME Software already has a hidden setting for this:
> > 
> > Yes and it should be configured to "['RPM', 'flatpak']" for all 
> > non-ostree Fedora variants (Workstation, Spins).
> Flatpak should come first as that what will be used in the long term.

That's not true for all editions. I guess you mean GNOME/Workstation
here. I'm not the only one here who's convinced that flatpaks are the
wrong way to package software, so please don't assume whatever the
Workstation WG is doing with flatpaks will be picked up by other
editions.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> Users of RPM-based variants will expect the default package manager to 
> install RPMs,
> not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that one.

That being said, what about allowing users to set this preference by themselves?

I also think that the repository information should also be made more visible;
if a package is available from multiple sources, gnome-software will display
a separate search entry for each of those, which looks very odd from a UX
perspective - I'd expect some kind of match-by-id to be performed and
for duplicated packages to either be merged into a single button,
or to have some additional bit of text on them telling me which one
comes from where.

Btw, shouldn't gnome-sofware pull in PackageKit?
I typically only use dnf, so I installed gnome-software and it was unusable
until I manually installed PackageKit as well.

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

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Matti Pulkkinen]

to, 2022-06-30 kello 11:54 +0200, Kevin Kofler via devel kirjoitti:
> If the default crypto policies fail with the world's largest WiFi
> network, 
> then surely they are too strict to be useful in practice and need to
> be 
> relaxed.
> 

I'm not a developer but I just wanted to chime in here and mention that
while Eduroam is a very widespread network, different institutions can
configure it in different ways. I have had no difficulty connecting to
Eduroam in my home institution with F36.

-- 
Terveisin / Regards,
Matti Pulkkinen

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

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

[Jens-Ulrik Petersen]

On Thu, Jun 30, 2022 at 2:27 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 29/06/2022 19:00, Vipul Siddharth wrote:
> > Firefox langpacks, which have been bundled in the Fedora firefox base
> > package until now, will be moved to a firefox-langpacks subpackage.
>
> +1. It might be better to split it even more: firefox-langpack-%{lang}
> and depend on the system-wide language (just like spelling dictionaries).
>
> Users will be able to install only the required locales.
>

Right, I am aware of that.

One problem is that the number of firefox langpacks changes somewhat over
releases,
so Martin was hesitant to take this approach in the past.  Probably still
applies.
So the proposed approach seems like a reasonable compromise and step
forward.

(I have pondered if we could decide on a set of core firefox langpacks
which are "guaranteed" to exist
and so hopefully could be safely subpackaged - but this makes the handling
more complicated
and delicate - it would have to be done very carefully in langpacks.)

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 09:52, Marc Pervaz Boocha via devel wrote:

Flatpak should come first as that what will be used in the long term.


RPM is the main packaging format for Fedora.


Can we investigate why is the case, its not like the packages in the
repo cannot be package as flatpak.


Fedora Flatpak packages are hack-built from RPM modules.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Vitaly Zaitsev via devel]

On 30/06/2022 11:35, Fabio Valentini wrote:

I.e. can Fedora enable the full rpmfusion
repositories by default, as well, instead of only the separate
("filtered") repositories for the proprietary NVidia drivers and the
Steam client?


They don't want to answer why they can't preload RPM Fusion:
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/TCULL55CJGEAYKK5SLHNHZ4BGEUWM3KL/

LWN news article: https://lwn.net/Articles/897793/

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Kevin Kofler via devel]

Ankur Sinha wrote:
> Could someone with sufficient OpenSSL knowledge please take a look at
> this post?
> 
> https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-openssl-error/23909
> 
> I'd managed to debug another one related to Eduroam and come up with a
> workaround, but this is a new one that I'm not going to be able to
> figure out any time soon:
> 
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288

If the default crypto policies fail with the world's largest WiFi network, 
then surely they are too strict to be useful in practice and need to be 
relaxed.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> However, I believe Flatpaks built from Fedora RPMs should take
> precedence over Flatpaks built from Flathub. Flathub should only be
> preferred when there is no Fedora Flatpak available.

That is not a solution, because Fedora Flatpaks are effectively an abandoned 
feature, as evidenced by the next thread, which points out that a required 
tool was removed from the repository more than 6 months ago.

We need Fedora RPMs to take precedence over Flatpaks built from Flathub, not 
just Flatpaks built from Fedora RPMs.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 29 June 2022 at 20:25, Michael Catanzaro wrote:
> On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel
>  wrote:
> > 1. GNOME Software need to be patched to prefer RPMs over Flatpaks for
> > non-ostree Fedora variants, because it will replace Fedora packages with
> > Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for
> > Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM"
> > for Silverblue/Kinoite will be better.
> 
> GNOME Software already has a hidden setting for this:
> 
> https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a062d24c543174346b36d8/data/org.gnome.software.gschema.xml#L137
> 
> It defaults to Flatpaks because they are sandboxed and are much safer than
> unsandboxed applications.

... *when* they are sandboxed ...
Unfortunately, in many cases, they aren't.

> However, I believe Flatpaks built from Fedora RPMs should take precedence
> over Flatpaks built from Flathub. Flathub should only be preferred when
> there is no Fedora Flatpak available.

+1

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Fabio Valentini]

On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
 wrote:
>
> == Detailed Description ==
>
> Fedora includes a flatpak repo definition for Flathub in the
> fedora-flathub-remote package. So far, this remote
> was filtered by an allowlist that only made a limited subset of
> software from Flathub available. We've been told
> that it is ok for us to remove the filtering and make all of Flathub 
> available.

Given that flathub provides similar / overlapping content compared to
RPMFusion (or often, even more "legally problematic" than what's
available from RPMFusion, i.e. prebuilt blobs), doesn't this same
reasoning also apply there? I.e. can Fedora enable the full rpmfusion
repositories by default, as well, instead of only the separate
("filtered") repositories for the proprietary NVidia drivers and the
Steam client?

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:

> On 29/06/2022 20:25, Michael Catanzaro wrote:
>> GNOME Software already has a hidden setting for this:
> 
> Yes and it should be configured to "['RPM', 'flatpak']" for all
> non-ostree Fedora variants (Workstation, Spins).

+1. Native packages ought to be preferred over random repackaged binaries 
from untrusted infrastructure (see the links posted by Vitaly for proof).

Users of RPM-based variants will expect the default package manager to 
install RPMs, not Flatpaks, or they would have chosen a Flatpak-based 
variant.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220630.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220629.0):

ID: 1311274 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1311274
ID: 1311287 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1311287

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Kofler via devel]

Daan De Meyer via devel wrote:
> Which shows a smaller than 1% slowdown between the binary built with frame
> pointers and the binary built without frame pointers.

Still 1% too many just to work around broken debugging tools when DWARF 
unwinding has been available for years and is already supported by many 
tools. (GCC would not default to -fomit-frame-pointer on -O2 otherwise. It 
does not do that on platforms where frame pointers are really needed for 
debugging.)

And what is the impact on code size? In my experience, -fomit-frame-pointer 
also generates smaller code than -fno-omit-frame-pointer, so I would like to 
see the sizes in your test cases.

I am still strongly opposed to degrading performance and size for all users 
just to help the handful users of poorly-designed profiling tools.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Dmitry Belyavskiy]

Dear Ankur,

Your solution looks like not a workaround but a recommended solution.
You can find more information in Clemens Lang's blog post here:
https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-enterprise-linux-9
This blog post also contains links to two relevant bugs.

Hope this helps.

On Thu, Jun 30, 2022 at 9:59 AM Ankur Sinha  wrote:

> Hi folks,
>
> Could someone with sufficient OpenSSL knowledge please take a look at
> this post?
>
>
> https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-openssl-error/23909
>
> I'd managed to debug another one related to Eduroam and come up with a
> workaround, but this is a new one that I'm not going to be able to
> figure out any time soon:
>
>
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Daniel P . Berrangé]

On Wed, Jun 29, 2022 at 08:41:51PM +0200, Vitaly Zaitsev via devel wrote:
> On 29/06/2022 20:25, Michael Catanzaro wrote:
> > GNOME Software already has a hidden setting for this:
> 
> Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree
> Fedora variants (Workstation, Spins).
> 
> When the Flathub filtering is removed, most Fedora packages will be silently
> replaced by Flatpaks, some of them very low quality (DEB rebuids) because
> the Flathub versions are always greater than in Fedora.
> 
> > It defaults to Flatpaks because they are sandboxed and are much safer
> > than unsandboxed applications.
> 
> - https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
> - https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
> 
> > However, I believe Flatpaks built from Fedora RPMs should take precedence 
> > over Flatpaks built from Flathub.
> 
> Fedora Flatpaks are almost dead. Let's check this page:
> https://bodhi.fedoraproject.org/releases/
> 
> Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).

   The link above says '3' for F36 Flatpaks

> Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
> Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).

Comparing the raw number of RPMs v Flatpaks is not very relevant,
because the count for RPMs includes every single library, cli
tool, graphical app, whatever, while Flatpaks only count the
graphical apps, not the building blocks they comprise.

Better to compare Flatpaks to the number of RPMs containing
a .desktop file. None the less, I expect it would still show
that Flatpaks are the minority of Fedora deliverables.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Ankur Sinha]

Hi folks,

Could someone with sufficient OpenSSL knowledge please take a look at
this post?

https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-openssl-error/23909

I'd managed to debug another one related to Eduroam and come up with a
workaround, but this is a new one that I'm not going to be able to
figure out any time soon:

https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288

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


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

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Marc Pervaz Boocha via devel]

On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
> On 29/06/2022 20:25, Michael Catanzaro wrote:
> > GNOME Software already has a hidden setting for this:
> 
> Yes and it should be configured to "['RPM', 'flatpak']" for all 
> non-ostree Fedora variants (Workstation, Spins).
Flatpak should come first as that what will be used in the long term.

> 
> When the Flathub filtering is removed, most Fedora packages will be 
> silently replaced by Flatpaks, some of them very low quality (DEB 
> rebuids) because the Flathub versions are always greater than in
> Fedora.
> 
> > It defaults to Flatpaks because they are sandboxed and are much
> > safer than unsandboxed applications. 
> 
> -
> https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
> -
> https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
> 
> > However, I believe Flatpaks built from Fedora RPMs should take
> > precedence over Flatpaks built from Flathub.
> 
> Fedora Flatpaks are almost dead. Let's check this page:
> https://bodhi.fedoraproject.org/releases/
> 
> Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
> Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
> Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).

Can we investigate why is the case, its not like the packages in the
repo cannot be package as flatpak. We could be crafty here as we can
control extensions too (and can patch application if needed). I mean
fedora silverblue 36 was shipping with gnome 41 apps on release.
Maybe have fedora flatpak for certain popular applications(which can be
flatpaked) as a blocker for this proposal.

> 
> > Flathub should only be preferred when there is no Fedora Flatpak
> > available. 
> 
> I don't see it in the proposal.
> 
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org)
> 

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

Re: Fix aarch64 build on embree

[Peter Robinson]

On Thu, Jun 30, 2022 at 2:39 AM Luya Tshimbalanga
 wrote:
>
> On 2022-06-29 01:24, Peter Robinson wrote:
>
> On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga
>  wrote:
>
> Hello team,
>
> What is the way to disable `-mss2 for aarch64 build in embree?
>
> I think you mean msse2, the build should be using the distro default C
> flags for builds so it shouldn't be an issue, if you fix the build to
> use the proper distro flags the problem should go away. Details in the
> docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
>
> Which is strange as the used flag is `%{optflags} -Wl,--as-needed`as listed 
> on the attached spec file.
>
> Extract:
>
> export CXXFLAGS="%{optflags} -Wl,--as-needed"
>
> The issue currently affects the new version of embree.

Have you filed a bug upstream?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

[Panu Matilainen]

On 6/29/22 21:26, Vitaly Zaitsev via devel wrote:

On 29/06/2022 19:00, Vipul Siddharth wrote:

Firefox langpacks, which have been bundled in the Fedora firefox base
package until now, will be moved to a firefox-langpacks subpackage.


+1. It might be better to split it even more: firefox-langpack-%{lang} 
and depend on the system-wide language (just like spelling dictionaries).


Users will be able to install only the required locales.



Indeed.

There's some variance in how packages handle this but AIUI the preferred 
scheme is per-language subpackages named -langpack-.


For an example: 
https://src.fedoraproject.org/rpms/tesseract-tessdata/blob/rawhide/f/tesseract-tessdata.spec#_55


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

Re: Unresponsive maintainer: Alex Chernyakhovsky

[Daniel P . Berrangé]

On Wed, Jun 29, 2022 at 09:23:10PM +0200, Vitaly Zaitsev via devel wrote:
> On 29/06/2022 20:58, Miro Hrončok wrote:
> > No, it isn't. It's great ;)
> 
> Why? I doubt fighting maintainers is a good thing for Fedora.

Why are you assuming the added EPEL maintainers want to fight
the existing maintainers. That's an unwarranted negative
viewpoint. People aren't asking to be EPEL maintainers with
malicious intent to hijack a package, they are working to
try to benefit the Fedora project in cases where the existing
maintainer doesn't want to get involved in EPEL maint work.

After demonstrating their skills in EPEL maint the main package
maintainer may choose to invite them to get involved in Fedora
branch maint too. Spreading the load is a very good thing, since
so many package maintainers in Fedora are over-stretched in what
they try to cope with. Reducing the bus factor is a good backup
for time periods when real life prevents a maintainer doing work
on Fedora.

We should be openly welcoming people who want to get involved
in EPEL, and assume positive intent by default because that will
be the overwhealming common case.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

[Didier FABERT]

I'll take ascii if nobody wants it.

thank you.

Didier FABERT
didier.fab...@gmail.com
TZ Europe/Paris

Le 29/06/2022 à 16:56, Francisco J. Tsao Santín via devel a écrit :

Hello, I've been maintaining some packages, but I can't at this time
continue taking care of them. So, next Sunday I'll orphan them if nobody
ask me the transfer:

* ascii
* netmask
* ez-pine-gpg
* python-meld3
* gpart
* python-sysv_ipc
* reptyr
* supervisor


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

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