Re: Fedora Elections - Voting is now open!

[Steven A. Falco]

On 5/21/24 10:39 AM, Sandro wrote:

On 21-05-2024 16:32, Ben Cotton wrote:

On Tue, May 21, 2024 at 10:28 AM Sandro  wrote:


However, now the link is in the open, we might have to change it again
and invalidate the link you posted. It's not meant to be out in the open.


It's probably fine. If someone who didn't vote claims the badge,
there's no real harm. (And I say that as someone who takes the Badges
Leaderboard very seriously)


Contradictio in terminis?


I cleared my browser cache, and this time the link worked.

Sorry for posting the link.

Steve

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

Re: Fedora Elections - Voting is now open!

[Steven A. Falco]

On 5/21/24 10:17 AM, Sandro wrote:

On 21-05-2024 15:47, Vít Ondruch wrote:

Dne 21. 05. 24 v 15:45 Vít Ondruch napsal(a):


Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):

I'm getting the "410 Gone" message, too. Tried multiple times since yesterday 
with no luck.



Yes, this is the message.


+

~~~

This resource is no longer available. No forwarding address is given.

That invitation is expired.

~~~


That should no longer be the case. Which election precisely did you follow the 
link from? Maybe we missed updating one of them. That said, I still see other 
people claiming it.

Could it be that you just need to fully refresh the page?

I'll have a look at the links meanwhile. Maybe I spot something.


I just tried from 
https://elections.fedoraproject.org/vote/fedora%20mindshare%20election%20for%20f40

Badge link: 
https://badges.fedoraproject.org/invitations/716f01bd050fefd9a0647ae956af2b13/claim

Error message:
410 Gone
This resource is no longer available. No forwarding address is given.

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

Re: Fedora Elections - Voting is now open!

[Steven A. Falco]

I'm getting the "410 Gone" message, too.  Tried multiple times since yesterday 
with no luck.

Steve

On 5/21/24 05:21 AM, Aoife Moloney wrote:

I've seen someone in the Red Hat Waterford office be able to claim it no 
problem so the issue may be individually based as the link is definitely active 
and claimable. Interested to know too how its working for some nd not others.

On Tue, May 21, 2024 at 9:41 AM Sandro mailto:li...@penguinpee.nl>> wrote:

On 21-05-2024 09:47, Vít Ondruch wrote:
 > And it does not work again

What issue / error are you experiencing?

It seems to work for others. Looking at the badges front page, the badge
has been awarded as recently as 15 minutes ago.

-- Sandro
--
___
devel mailing list -- devel@lists.fedoraproject.org 

To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 

List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 

Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue 




--

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im 

IRC: amoloney



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

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

Re: Fedora 40 apache now giving errors

[Steven A. Falco]

On 4/24/24 06:50 AM, Tom Hughes wrote:

On 24/04/2024 02:28, Xose Vazquez Perez wrote:


# mkdir /etc/systemd/system/httpd.service.d/

# vi /etc/systemd/system/httpd.service.d/override.conf
[Service]
ProtectHome=false


Better than just opening up whole trees again would
be to use ReadWritePaths= to specify which paths should
be allowed for writing.


Creating the override.conf to allow write access to /home worked.  But I can 
see the point that this could be dangerous, so I'll investigate how to use the 
ReadWritePaths variable.

BTW, selinux was not involved, because I have it turned off.  So it looks like 
the systemd changes were what broke httpd.

Thanks all for the help - I'm back in business.

Steve

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

Fedora 40 apache now giving errors

[Steven A. Falco]

I upgraded to F40, and suddenly an apache cgi script that was working perfectly in F39 
(and earlier) is giving me a "Read-only file system" error when trying to write 
data into a file.

The directory where the cgi is trying to write is owned by apache:apache, and 
it is mode 777.  The file the cgi is trying to write to is also owned by 
apache:apache and is mode 666.

If I manually run the cgi (a trivial perl script), it works perfectly, but apache gives 
the "Read-only file system" error.  Apache can read the file fine, it just 
cannot write to it.

I also tried having the cgi simply touch a file in /tmp, and that fails too.

Any suggestions gratefully accepted.

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

spice-vdagent

[Steven A. Falco]

I noticed that the load average on a rawhide vm was higher than expected, and 
according to 'top' I had two copies of /usr/bin/spice-vdagent running, with one 
of them taking up a whole cpu core.

I removed /etc/xdg/autostart/spice-vdagent.desktop and rebooted.  Now there is 
only one copy of spice-vdagent running, and the load average is back to normal. 
 The vm behaves normally, with cut/paste, resize, etc. all working fine.

This vm is running with the KDE desktop in x11 mode.

Can anyone suggest why I might have two copies of spice-vdagent running?  I'm 
happy to have found a work-around, but this really doesn't make sense.

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

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

[Steven A. Falco]

On 4/2/24 03:50 PM, Steve Cossette wrote:

Well, we did submit this yesterday around 2:30-3:00PM EST, guessing it was a 
bit too late.

But the proposal is 1000% serious.


I'm glad to hear you say that, as I switched to KDE around the time of Gnome3 
and never looked back.

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

Re: GCC perhaps not honoring -std?

[Steven A. Falco]

On 2/21/24 11:46 AM, Jakub Jelinek wrote:

On Wed, Feb 21, 2024 at 11:34:37AM -0500, Steven A. Falco wrote:

I am getting an error "template-id not allowed for constructor in C++20" but 
according to the Copr log [0], the compiler is being given -std=c++17:


It is a warning, but you've asked for all warnings to be errors, right?
As documented
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wtemplate-id-cdtor
the warning is enabled by default when compiling with -std=c++20 or newer,
or when -Wc++20-compat warning is enabled, and the latter as documented
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wc_002b_002b20-compat
is enabled by default in -Wall, which you asked for.
The purpose of the warning is to warn that this won't be accepted in C++20
anymore and there is no reason not to make it valid C++20 right away by
removing the redundant part.


Thanks!  I'll work with the upstream folks to see how they want to handle it.

Steve




Building CXX object 
thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o
cd /builddir/build/BUILD/kicad-7.0.11/redhat-linux-build/thirdparty/clipper2 && 
/usr/bin/g++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad 
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SIGNAL_INTEGRITY -DKICAD_SPICE -DUSINGZ -DWXUSINGDLL 
-DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include -isystem 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/pybind11/include -isystem 
/usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 
-isystem /usr/include/harfbuzz -isystem /usr/include/opencascade -isystem 
/usr/lib64/wx/include/gtk3-unicode-3.2 -isystem /usr/include/wx-3.2 -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wno-attributes 
-pthread -O2 -g -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wpedantic -Werror -MD -MT 
thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o -MF 
CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o.d -o 
CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o -c 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp

In file included from 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.engine.h:22,
  from 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp:17:
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.core.h:139:22:
 error: template-id not allowed for constructor in C++20 
[-Werror=template-id-cdtor]
   139 | explicit Point(const Point& p)


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


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

GCC perhaps not honoring -std?

[Steven A. Falco]

I am getting an error "template-id not allowed for constructor in C++20" but 
according to the Copr log [0], the compiler is being given -std=c++17:

Building CXX object 
thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o
cd /builddir/build/BUILD/kicad-7.0.11/redhat-linux-build/thirdparty/clipper2 && 
/usr/bin/g++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad 
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SIGNAL_INTEGRITY -DKICAD_SPICE -DUSINGZ -DWXUSINGDLL 
-DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include -isystem 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/pybind11/include -isystem 
/usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 
-isystem /usr/include/harfbuzz -isystem /usr/include/opencascade -isystem 
/usr/lib64/wx/include/gtk3-unicode-3.2 -isystem /usr/include/wx-3.2 -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wno-attributes 
-pthread -O2 -g -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wpedantic -Werror -MD -MT 
thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o -MF 
CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o.d -o 
CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o -c 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp

In file included from 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.engine.h:22,
 from 
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/src/clipper.engine.cpp:17:
/builddir/build/BUILD/kicad-7.0.11/thirdparty/clipper2/Clipper2Lib/include/clipper2/clipper.core.h:139:22:
 error: template-id not allowed for constructor in C++20 
[-Werror=template-id-cdtor]
  139 | explicit Point(const Point& p)

Steve

[0] 
https://download.copr.fedorainfracloud.org/results/@kicad/kicad-stable/fedora-rawhide-x86_64/07046109-kicad/builder-live.log.gz
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/8/24 05:44 AM, Neal Gompa wrote:

The Wayland protocol in question is this one:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

That said, even X11's version isn't widely supported. Typically,
support for this is plumbed through linking libSM, and GTK notably
does not use it. Qt does, of course.

This is one of the things I've had on my radar for quite some time.
macOS-style automatic relaunch of applications is slated upstream for
6.1: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523

Support for the Wayland protocol will come after, but the combination
of the two approaches means that pretty much everything will be able
to relaunch as desired in some form on restart.


My approach on X11 is to have a script that launches the apps that I want, 
where I want them placed, and of what size I want.  For example:

/usr/bin/konsole --qwindowgeometry 1757x1468+2614+0 &

But that doesn't work in wayland, so I wrote [0].

Steve

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=2239016


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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/3/24 01:12 AM, Kevin Kofler via devel wrote:

Any interested people can already request comaintainership now (e.g., by
replying to this mail), and I will almost certainly grant it (though I will
have reservations about some specific types of requests, such as blanket
admin permissions for the entire @kde-sig group), but of course contingent
on the packages being approved (i.e., the FESCo hold on them being lifted,
and the reviews subsequently passing), because there is nothing to
comaintain before that point and also nowhere I can fill in those
comaintainership requests before the dist-git Pagure repository is created.


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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/1/24 11:46 AM, Neal Gompa wrote:

I'd like to think that the gaps will be fixed, but it seems to me that because 
of policy, some gaps (like apps controlling their own window placement) will 
never be fixed.



That is not necessarily true. For your example about window placement,
there is this: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264


Is there a way to see what gaps remain, which ones are being worked on, and which ones 
will be declared "not a gap - won't fix"?





Sorry, I meant to point to this as well:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247


Thanks for the links.  I am hopeful that the issues you are tracking will make 
it in time for f40.

Steve

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 2/1/24 11:28 AM, Neal Gompa wrote:

On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa  wrote:


On 2/1/24 14:29, Steve Cossette wrote:


And yes, that /is/ the whole point: We want to foster the use of Wayland, to 
increase it's adoption, to force people using it to hit snags along the road 
and fill tickets so those issues can be fixed.

"force people" "hit snag"

With this kind of attitude, don't be surprised when people describe Fedora
as "the beta test" for Red Hat.



To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
less about KDE. A "beta test" for Red Hat is pretty useless when it
has basically no impact for Red Hat, positively or negatively.

We are doing this because without doing so, the gaps will *never* be
identified to be fixed in the first place. And they *are* getting
fixed at a rapid clip.


I'd like to think that the gaps will be fixed, but it seems to me that because 
of policy, some gaps (like apps controlling their own window placement) will 
never be fixed.

Is there a way to see what gaps remain, which ones are being worked on, and which ones 
will be declared "not a gap - won't fix"?

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Steven A. Falco]

On 1/30/24 08:55 AM, Richard W.M. Jones wrote:

On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:

3) Fedora has a long-standing and well-communicated stance that we are
a Wayland distribution first and foremost and that X11 support is
intended as a migration-support tool rather than a first-class
citizen.


Does it?  This is very much news to me, so I don't think you can call
it "well-communicated".  We also have an XFCE desktop spin and
probably others that require X11.
https://fedoraproject.org/uk/spins/xfce/

In addition Wayland doesn't actually replace all the basic
functionality of X11 even after all these years, which is why I need
to use it.


I'm in the same boat.  Back in September when this topic came up, folks were 
invited to write bugs so the missing functionality could presumably be worked 
on.

I wrote two bugs:

Bug 2239016 - Plasma(Wayland) does not honor window positioning when setting 
window geometry
Bug 2239029 - Plasma(Wayland) does not save windows between sessions

For 2239016 the response was "That's just how wayland works" and for 2239029 
someone added a reference to an upstream KDE bug (from 2021).

I realize that this is a volunteer-driven project, and that I cannot expect 
someone to address the above wayland limitations, especially since the wayland 
design philosophy appears to exclude such features.

But that doesn't change the fact that I need the missing functionality, and 
based on how this discussion is going, I personally doubt wayland will ever 
meet my needs.

I'm delighted that there are like-minded folks who want to maintain X11.  
Please allow them to do so.

Steve


4) There was a comment on the FESCo ticket to the effect of '"you must
move to Wayland because no one maintains X11!". Here are some people
who are maintaining X11 packages, so let them do their thing.' This is
misleading, as the move to Wayland is specifically because the
upstream of X11 *itself* is largely unmaintained. These packages are
not maintaining X11, they are adding new dependencies on it.


They're maintaining parts of the X11 stack.


My proposal for consideration is this:
"FESCo will allow these packages in the main Fedora repositories,
however they may not be included by default on any release-blocking
deliverable (ISO, image, etc.)"


It seems quite strong.  I'm unclear why having X11 packages and spins
for those that want to use them is a problem.  It seems like the
missing functionality of Wayland is the bigger issue that needs to be
addressed.

Rich.


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

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Steven A. Falco]

On 12/21/23 08:53 AM, Neal Gompa wrote:

On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott  wrote:


I'm -1 for this change, it shouldn't be enabled by default as it will cause 
issues for users using router mac filtering.


What this seems to state is that the MAC address would be unique for
each SSID, but once it's picked, it would be locked in. That should
still make router-level MAC filtering possible, since the MAC address
would be stable for that network.


What would happen on a network where I've set up the DHCP server in my router 
to map mac addresses to static IP addresses?  Sounds like I'd have to disable 
the feature, at least on my home network.

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/18/23 11:33 AM, Neal Gompa wrote:

On Mon, Sep 18, 2023 at 11:12 AM Steven A. Falco  wrote:


On 9/17/23 05:48 PM, Kevin Kofler via devel wrote:

Ian Laurie wrote:

I didn't think the greeter used Wayland?  So there may be something else
going on.  I cannot swear to it, but I don't think I've noticed problems
in the greeter before.

As Adam posted, the offset problem already has a bug for it.  Wayland is
certainly unusable in VirtualBox, but now even the greeter has issues,
and I think that's newish.


SDDM was switched to Wayland for F38 and newer. If you want it to use X11,
you have to edit /etc/sddm.conf and set:

[General]
DisplayServer=x11

there.

  Kevin Kofler


Yes - I had to do that because the Wayland version of the SDDM greeter 
apparently doesn't honor xrandr.

I have the following in my /etc/sddm/Xsetup file:

 #!/usr/bin/sh
 # Xsetup - run as root before the login dialog appears
 xrandr --output DisplayPort-0 --right-of DisplayPort-1

If I have the greeter set to x11 that works perfectly, but if I have the 
greeter set to wayland it is ignored.

I don't know if there is a way to tell wayland the desired screen arrangement.  
If there is a way I'd like to hear about it.  If there isn't a way, then I 
guess that should be another bug.



kwin can be configured using kscreen-doctor, as long as the kwin
wayland socket is up.


Thanks, Neal.  I'll give that a try at some point.

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/17/23 05:48 PM, Kevin Kofler via devel wrote:

Ian Laurie wrote:

I didn't think the greeter used Wayland?  So there may be something else
going on.  I cannot swear to it, but I don't think I've noticed problems
in the greeter before.
  
As Adam posted, the offset problem already has a bug for it.  Wayland is

certainly unusable in VirtualBox, but now even the greeter has issues,
and I think that's newish.


SDDM was switched to Wayland for F38 and newer. If you want it to use X11,
you have to edit /etc/sddm.conf and set:

[General]
DisplayServer=x11

there.

 Kevin Kofler


Yes - I had to do that because the Wayland version of the SDDM greeter 
apparently doesn't honor xrandr.

I have the following in my /etc/sddm/Xsetup file:

   #!/usr/bin/sh
   # Xsetup - run as root before the login dialog appears
   xrandr --output DisplayPort-0 --right-of DisplayPort-1

If I have the greeter set to x11 that works perfectly, but if I have the 
greeter set to wayland it is ignored.

I don't know if there is a way to tell wayland the desired screen arrangement.  
If there is a way I'd like to hear about it.  If there isn't a way, then I 
guess that should be another bug.

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/14/23 04:20 PM, Steven A. Falco wrote:

I've written a bug [1] stating that window placement appears to be ignored.  
Specifically the following command ignores the requested placement under 
Plasma(Wayland) but the placement is honored under Plasma(X11).  That is a big 
problem in a multi-screen environment:

/usr/bin/konsole --qwindowgeometry 675x678+3754+870 &

 Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239016


One more for now, but then I have to go back to X11.  For some reason, some 
windows are not remembered between sessions [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239029

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/14/23 06:36 AM, Ian McInerney wrote:



On Thu, 14 Sep 2023, 00:17 Neal Gompa, mailto:ngomp...@gmail.com>> wrote:

On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
 >
 > On 9/13/23 05:23 PM, Neal Gompa wrote:
 > > Right. And I want to stress we are not dropping support for X11
 > > applications. Anything running as an X client in a desktop should work
 > > as it has before.
 >
 > I'm not convinced KiCad will work in that scenario, so please let me 
summarize what I've read here, and please correct me if I have any of this wrong.
 >
 > The thing being removed is "Plasma(X11)", which is a native X11 stack; 
i.e. no Wayland or Xwayland is involved when using Plasma(X11).  This mode is well supported 
by KiCad, and additionally it works well with my multi-monitor setup.
 >
 > Should the change proposal be accepted, "Plasma(X11)" will be removed, leaving 
"Plasma(Wayland)" as the only available KDE mode.  Also, all X11 applications will then be 
forced to use XWayland rather than X11, at least under KDE.
 >
 > Assuming my summary is correct, here are my personal problems:
 >
 > Problem 1: The KiCad team says they don't support XWayland (nor do they 
support pure Wayland) because of bugs.
 >

 >From what I've read through the issues, the ultimate problem is in
GTK, not wxWidgets, as there is in fact a supported Wayland protocol
for mouse warping[1]. Does this issue exist when using wxQt instead of
wxGTK? Admittedly, I'm not sure of the state of things with wxWidgets
and the backends...

[1]: https://wayland.app/protocols/pointer-constraints-unstable-v1 
<https://wayland.app/protocols/pointer-constraints-unstable-v1>


Speaking as a member of the KiCad core development team, I am not convinced that 
extension will be easy to use. When I looked at it a few weeks ago, it still seemed 
to have portability problems between compositors/WM implementations. (See here for my 
conclusion 
https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-1680398578 
<https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-1680398578>). 
As a project, we already have to deal with enough problems from supporting MSW, macOS 
and Linux that having to now workaround quirks in different graphics stacks is not 
something we have the time or developer effort to do. We would rather be actually 
creating the features all our users need for their work instead of having to fight 
with the graphics stacks all the time.

And aside from the mouse warping, we also want the ability to control where 
windows are placed on the screen. We are a multi-window application, and our 
users usually have a preferred setup for how the windows are arranged on their 
screen. Right now, we can save/restore that for them, but my understanding of 
the Wayland spec is that this is not allowed and so we are at the mercy of the 
desktop to put the windows where it wants.

-Ian


I've written a bug [1] stating that window placement appears to be ignored.  
Specifically the following command ignores the requested placement under 
Plasma(Wayland) but the placement is honored under Plasma(X11).  That is a big 
problem in a multi-screen environment:

/usr/bin/konsole --qwindowgeometry 675x678+3754+870 &

Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239016
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/13/23 07:16 PM, Neal Gompa wrote:

On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco  wrote:


On 9/13/23 05:23 PM, Neal Gompa wrote:

Right. And I want to stress we are not dropping support for X11
applications. Anything running as an X client in a desktop should work
as it has before.


I'm not convinced KiCad will work in that scenario, so please let me summarize 
what I've read here, and please correct me if I have any of this wrong.

The thing being removed is "Plasma(X11)", which is a native X11 stack; i.e. no 
Wayland or Xwayland is involved when using Plasma(X11).  This mode is well supported by 
KiCad, and additionally it works well with my multi-monitor setup.

Should the change proposal be accepted, "Plasma(X11)" will be removed, leaving 
"Plasma(Wayland)" as the only available KDE mode.  Also, all X11 applications will then 
be forced to use XWayland rather than X11, at least under KDE.

Assuming my summary is correct, here are my personal problems:

Problem 1: The KiCad team says they don't support XWayland (nor do they support 
pure Wayland) because of bugs.




From what I've read through the issues, the ultimate problem is in

GTK, not wxWidgets, as there is in fact a supported Wayland protocol
for mouse warping[1]. Does this issue exist when using wxQt instead of
wxGTK? Admittedly, I'm not sure of the state of things with wxWidgets
and the backends...

[1]: https://wayland.app/protocols/pointer-constraints-unstable-v1


Problem 2: Plasma(Wayland) doesn't work with my multi-monitor setup.



Do you have a bug report filed at bugs.kde.org about your setup? The
KDE folks can take a look and we can try to have things fixed in
Plasma (in Plasma 5 today or Plasma 6 when it lands).


Conclusion: If there are remaining Fedora desktops using X11, I might be able 
to continue using Fedora, and I might be able to continue supporting KiCad, 
_assuming_ I'm willing to switch to another desktop.  Of course, after having 
used KDE for 20+ years, switching is not very appealing, nor is it very likely, 
frankly.



Part of the reason for filing this Change is to shake out these cases
and make sure we can get them covered. For what it's worth, I want you
to have a good experience on Plasma Wayland, and I'm happy to help try
to facilitate that however I can.


Thanks, I appreciate that.  I'll give Plasma(Wayland) another try soon and 
write some bugs.

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/13/23 05:23 PM, Neal Gompa wrote:

Right. And I want to stress we are not dropping support for X11
applications. Anything running as an X client in a desktop should work
as it has before.


I'm not convinced KiCad will work in that scenario, so please let me summarize 
what I've read here, and please correct me if I have any of this wrong.

The thing being removed is "Plasma(X11)", which is a native X11 stack; i.e. no 
Wayland or Xwayland is involved when using Plasma(X11).  This mode is well supported by 
KiCad, and additionally it works well with my multi-monitor setup.

Should the change proposal be accepted, "Plasma(X11)" will be removed, leaving 
"Plasma(Wayland)" as the only available KDE mode.  Also, all X11 applications will then 
be forced to use XWayland rather than X11, at least under KDE.

Assuming my summary is correct, here are my personal problems:

Problem 1: The KiCad team says they don't support XWayland (nor do they support 
pure Wayland) because of bugs.

Problem 2: Plasma(Wayland) doesn't work with my multi-monitor setup.

Conclusion: If there are remaining Fedora desktops using X11, I might be able 
to continue using Fedora, and I might be able to continue supporting KiCad, 
_assuming_ I'm willing to switch to another desktop.  Of course, after having 
used KDE for 20+ years, switching is not very appealing, nor is it very likely, 
frankly.

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/13/23 12:10 PM, Steven A. Falco wrote:

On 9/13/23 11:53 AM, Aoife Moloney wrote:

Wiki  https://fedoraproject.org/wiki/Changes/KDE_Plasma_6



== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
changes and improvements over previous versions. For Fedora Linux, the
transition to KDE Plasma 6 will also include dropping support for the
X11 session entirely, leaving only Plasma Wayland as the sole offered
desktop mode.


I'm more than a bit concerned about dropping X11.  I am the packager for KiCad 
on Fedora.  The upstream KiCad team has stated [1] that they won't support 
Wayland issues unless they can be recreated on X11, meaning that I'll be left 
with no way to support the Fedora KiCad packages.

For convenience, here is the relevant part of the KiCad position:

  It is known that KiCad does not work well under Wayland. There are a 
number of known issues with wxWidgets and Wayland. See the wxWidgets bug 
tracker for details [2].  KiCad requests the XWayland compatibility layer when 
starting, however this is an emulation mode and issues arising while using this 
mode need to be recreated under X11 before they will be addressed.  At the 
moment, Wayland has no support for cursor warping, which means that the KiCad 
features of centering the cursor when zooming, and continuously panning the 
canvas, are broken on Wayland systems.

 Steve

[1] https://www.kicad.org/help/known-system-related-issues/
[2] https://github.com/wxWidgets/wxWidgets/labels/Wayland


A question about this - the removal of X11 is listed on a change proposal for 
KDE.  Does the removal just apply to KDE or would it be distribution wide; i.e. 
affecting all desktops?

Steve

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Steven A. Falco]

On 9/13/23 11:53 AM, Aoife Moloney wrote:

Wiki  https://fedoraproject.org/wiki/Changes/KDE_Plasma_6



== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
changes and improvements over previous versions. For Fedora Linux, the
transition to KDE Plasma 6 will also include dropping support for the
X11 session entirely, leaving only Plasma Wayland as the sole offered
desktop mode.


I'm more than a bit concerned about dropping X11.  I am the packager for KiCad 
on Fedora.  The upstream KiCad team has stated [1] that they won't support 
Wayland issues unless they can be recreated on X11, meaning that I'll be left 
with no way to support the Fedora KiCad packages.

For convenience, here is the relevant part of the KiCad position:

 It is known that KiCad does not work well under Wayland. There are a 
number of known issues with wxWidgets and Wayland. See the wxWidgets bug 
tracker for details [2].  KiCad requests the XWayland compatibility layer when 
starting, however this is an emulation mode and issues arising while using this 
mode need to be recreated under X11 before they will be addressed.  At the 
moment, Wayland has no support for cursor warping, which means that the KiCad 
features of centering the cursor when zooming, and continuously panning the 
canvas, are broken on Wayland systems.

Steve

[1] https://www.kicad.org/help/known-system-related-issues/
[2] https://github.com/wxWidgets/wxWidgets/labels/Wayland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Steven A. Falco]

On 8/23/23 04:12 PM, Richard Shaw wrote:

On Wed, Aug 23, 2023 at 1:41 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 8/23/23 02:22 PM, Miroslav Suchý wrote:
 > dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
 > --enablerepo=updates-testing \
 > $(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
 > --assumeno distro-sync
   Problem 1: problem with installed package freecad-1:0.20.2-3.fc38.x86_64
    - freecad-1:0.20.2-3.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-modular
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular
   Problem 2: problem with installed package 
freecad-data-1:0.20.2-3.fc38.noarch
    - package freecad-data-1:0.20.2-4.fc39.noarch from fedora requires 
freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
    - package freecad-data-1:0.20.2-4.fc39.noarch from fedora-modular 
requires freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
    - package freecad-data-1:0.20.2-4.fc39.noarch from updates-modular 
requires freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
    - package freecad-data-1:0.20.2-4.fc39.noarch from 
updates-testing-modular requires freecad = 1:0.20.2-4.fc39, but none of the 
providers can be installed
    - freecad-data-1:0.20.2-3.fc38.noarch from @System  does not belong to 
a distupgrade repository
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-modular
    - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular
   Problem 3: problem with installed package 
python3-shiboken2-1:5.15.7-2.fc38.x86_64
    - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from @System 
requires python(abi) = 3.11, but none of the providers can be installed
    - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora requires 
python(abi) = 3.11, but none of the providers can be installed
    - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora-modular 
requires python(abi) = 3.11, but none of the providers can be installed
    - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from updates-modular 
requires python(abi) = 3.11, but none of the providers can be installed
    - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from 
updates-testing-modular requires python(abi) = 3.11, but none of the providers 
can be installed
    - python3-3.11.4-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
   Problem 4: problem with installed package 
python3-pyside2-1:5.15.7-2.fc38.x86_64
    - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from @System requires 
python(abi) = 3.11, but none of the providers can be installed
    - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora requires 
python(abi) = 3.11, but none of the providers can be installed
    - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora-modular 
requires python(abi) = 3.11, but none of the providers can be installed
    - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from updates-modular 
requires python(abi) = 3.11, but none of the providers can be installed
    - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from 
updates-testing-modular requires python(abi) = 3.11, but none of the providers 
can be installed
    - package python3-3.11.4-1.fc38.x86_64 from @System requires 
python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed
    - python3-libs-3.11.4-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository


FreeCAD is a known issue since the upgrade to Python 3.12. PySide2 is not 
compatible with Python 3.12 and upstream has no intention of making it 
compatible as they are only supporting PySide6 for Qt6 now. There's also a TBB 
dependency issue.

For now it would be better to use the appimage.


Thanks, Richard - I had missed that thread.

Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Steven A. Falco]

On 8/23/23 02:22 PM, Miroslav Suchý wrote:

dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync

 Problem 1: problem with installed package freecad-1:0.20.2-3.fc38.x86_64
  - freecad-1:0.20.2-3.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-modular
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular
 Problem 2: problem with installed package freecad-data-1:0.20.2-3.fc38.noarch
  - package freecad-data-1:0.20.2-4.fc39.noarch from fedora requires freecad = 
1:0.20.2-4.fc39, but none of the providers can be installed
  - package freecad-data-1:0.20.2-4.fc39.noarch from fedora-modular requires 
freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
  - package freecad-data-1:0.20.2-4.fc39.noarch from updates-modular requires 
freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
  - package freecad-data-1:0.20.2-4.fc39.noarch from updates-testing-modular 
requires freecad = 1:0.20.2-4.fc39, but none of the providers can be installed
  - freecad-data-1:0.20.2-3.fc38.noarch from @System  does not belong to a 
distupgrade repository
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-modular
  - nothing provides libboost_python311.so.1.81.0()(64bit) needed by 
freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular
 Problem 3: problem with installed package 
python3-shiboken2-1:5.15.7-2.fc38.x86_64
  - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from @System requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora-modular 
requires python(abi) = 3.11, but none of the providers can be installed
  - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from updates-modular 
requires python(abi) = 3.11, but none of the providers can be installed
  - package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from 
updates-testing-modular requires python(abi) = 3.11, but none of the providers 
can be installed
  - python3-3.11.4-1.fc38.x86_64 from @System  does not belong to a distupgrade 
repository
 Problem 4: problem with installed package 
python3-pyside2-1:5.15.7-2.fc38.x86_64
  - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from @System requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora-modular requires 
python(abi) = 3.11, but none of the providers can be installed
  - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from updates-modular 
requires python(abi) = 3.11, but none of the providers can be installed
  - package python3-pyside2-1:5.15.7-2.fc38.x86_64 from updates-testing-modular 
requires python(abi) = 3.11, but none of the providers can be installed
  - package python3-3.11.4-1.fc38.x86_64 from @System requires 
python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed
  - python3-libs-3.11.4-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Rawhide build failures

[Steven A. Falco]

Looks like it is a mirror issue.  Adding --enablerepo=local corrects it.

Please disregard my previous email.

Steve

On 8/21/23 02:41 PM, Steven A. Falco wrote:

Not sure if this is a known problem, but I'm getting build failures from mock 
on rawhide.  F37, F38, and F39 are ok.

 Steve

Error:
  Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora requires 
libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers can be 
installed
   - cannot install the best candidate for the job
   - nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
   - nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)
Finish: build setup for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
Finish: build phase for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
ERROR: Exception(kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm) 
Config(fedora-rawhide-x86_64) 1 minutes 6 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
  # /usr/bin/dnf-3 builddep --installroot 
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 40 
--setopt=deltarpm=False --setopt=allow_vendor_change=yes --allowerasing 
--disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock 
/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
No matches found for the following disable plugin patterns: local, spacewalk, 
versionlock
fedora  121 kB/s |  20 kB 00:00
Error:
  Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora requires 
libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers can be 
installed
   - cannot install the best candidate for the job
   - nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
   - nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)

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

Rawhide build failures

[Steven A. Falco]

Not sure if this is a known problem, but I'm getting build failures from mock 
on rawhide.  F37, F38, and F39 are ok.

Steve

Error:
 Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora requires 
libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers can be 
installed
  - cannot install the best candidate for the job
  - nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
  - nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)
Finish: build setup for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
Finish: build phase for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
ERROR: Exception(kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm) 
Config(fedora-rawhide-x86_64) 1 minutes 6 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
 # /usr/bin/dnf-3 builddep --installroot 
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 40 
--setopt=deltarpm=False --setopt=allow_vendor_change=yes --allowerasing 
--disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock 
/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm
No matches found for the following disable plugin patterns: local, spacewalk, 
versionlock
fedora  121 kB/s |  20 kB 00:00
Error:
 Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora requires 
libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers can be 
installed
  - cannot install the best candidate for the job
  - nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
  - nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by 
wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

[Steven A. Falco]

On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote:

## How to run things locally?

You can use mock. Make sure to:
     1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
     2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local 
...


That doesn't appear correct.  At least I still get 3.11 when I try.  I assume I 
need to refer to the side tag instead.

Also there is a typo - there needs to be a space between fedora-rawhide-x86_64 
and --scrub=all :-)

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

Re: ppc64le builds taking ages

[Steven A. Falco]

I ran a KiCad build yesterday on Copr [1] (so not the same as Koji), but while 
it all completed, curiously the rawhide PPC build took 6 hours while the f37 
and f38 PPC builds only took 2 hours.

The corresponding Koji build [2] took close to 4 hours, so it is in the 
ball-park.

KiCad is a bit unique because it includes a data package that is close to 6 GB 
uncompressed and about 420 MB after compression.  I don't know if that plays a 
role.

[1] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad-stable/build/5942232/
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2204170

On 5/23/23 05:41 AM, Miroslav Lichvar wrote:

On Sat, May 20, 2023 at 02:51:06PM -0700, Kevin Fenzi wrote:

I've moved all the power9 virthosts running builders over to a 6.3.x
kernel.

Please let me know if this helps or doesn't with slowness issues.


It seems the execution is still freezing occasionally. My recent build
of chrony failed on ppc in %check due to a test not being able to
start and connect within 10 seconds.


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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Steven A. Falco]

I've gotten a similar result.  Without --allowerasing:

Error:
 Problem 1: conflicting requests
  - problem with installed package gimp-heif-plugin-1.1.0-12.fc37.x86_64
  - gimp-heif-plugin-1.1.0-12.fc37.x86_64 does not belong to a distupgrade 
repository
 Problem 2: problem with installed package libswscale-free-5.1.3-1.fc37.x86_64
  - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libswscale-free 
provided by libswscale-free-6.0-2.fc38.x86_64
  - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libswscale-free 
provided by libswscale-free-6.0-4.fc38.x86_64
  - package ffmpeg-6.0-6.fc38.x86_64 requires ffmpeg-libs(x86-64) = 6.0-6.fc38, 
but none of the providers can be installed
  - libswscale-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade 
repository
  - conflicting requests
 Problem 3: problem with installed package firefox-112.0-3.fc37.x86_64
  - conflicting requests
  - package ffmpeg-libs-6.0-6.fc38.i686 conflicts with libavcodec-free provided 
by libavcodec-free-6.0-2.fc38.x86_64
  - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libavcodec-free 
provided by libavcodec-free-6.0-2.fc38.x86_64
  - problem with installed package libavcodec-free-5.1.3-1.fc37.x86_64
  - package ffmpeg-libs-6.0-6.fc38.i686 conflicts with libavcodec-free provided 
by libavcodec-free-6.0-4.fc38.x86_64
  - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libavcodec-free 
provided by libavcodec-free-6.0-4.fc38.x86_64
  - firefox-112.0-3.fc37.x86_64 does not belong to a distupgrade repository
  - libavcodec-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade 
repository

If I add --allowerasing, I get:

Skipping packages with conflicts:
(add '--best' to command line to force their upgrade):
 qt5-qtbase x86_64 5.15.9-1.fc38updates  3.5 M

Steve

On 4/19/23 03:19 AM, Neal Becker wrote:

If I add --allowerasing, some packages will be removed:
Removing dependent packages:
  ffmpeg-free                           x86_64 5.1.3-1.fc37                     
    @updates       2.2 M
  libavcodec-free                       x86_64 5.1.3-1.fc37                     
    @updates       9.6 M
  libavdevice-free                      x86_64 5.1.3-1.fc37                     
    @updates       228 k
  libavfilter-free                      x86_64 5.1.3-1.fc37                     
    @updates       4.4 M
  libavformat-free                      x86_64 5.1.3-1.fc37                     
    @updates       2.6 M
  libavutil-free                        x86_64 5.1.3-1.fc37                     
    @updates       836 k
  libpostproc-free                      x86_64 5.1.3-1.fc37                     
    @updates       127 k
  libswresample-free                    x86_64 5.1.3-1.fc37                     
    @updates       152 k
  libswscale-free                       x86_64 5.1.3-1.fc37                     
    @updates       632 k

On Tue, Apr 18, 2023 at 7:40 PM Neal Becker mailto:ndbeck...@gmail.com>> wrote:

Error:
  Problem 1: problem with installed package ffmpeg-free-5.1.3-1.fc37.x86_64
   - package ffmpeg-6.0-6.fc38.x86_64 conflicts with ffmpeg-free provided 
by ffmpeg-free-6.0-2.fc38.x86_64
   - ffmpeg-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade 
repository
   - conflicting requests
  Problem 2: problem with installed package firefox-112.0-3.fc37.x86_64
   - conflicting requests
   - package ffmpeg-libs-6.0-6.fc38.i686 conflicts with libavcodec-free 
provided by libavcodec-free-6.0-2.fc38.x86_64
   - package ffmpeg-libs-6.0-6.fc38.x86_64 conflicts with libavcodec-free 
provided by libavcodec-free-6.0-2.fc38.x86_64
   - problem with installed package libavcodec-free-5.1.3-1.fc37.x86_64
   - libavcodec-free-5.1.3-1.fc37.x86_64 does not belong to a distupgrade 
repository
   - firefox-112.0-3.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)

On Sun, Apr 16, 2023 at 5:49 AM Zbigniew Jędrzejewski-Szmek mailto:zbys...@in.waw.pl>> wrote:

On Sat, Apr 15, 2023 at 06:30:36PM -0400, Elliott Sales de Andrade 
wrote:
 > > >   - problem with installed package 
msv-xsdlib-1:2013.6.1-19.fc33.noarch
 > > > (try to add '--skip-broken' to skip uninstallable packages)
 > >
 > > I'll add this one to fedora-obsolete-packages.
 > >
 > >
 > It looks like you've only added the main package msv [0]. However, 
that
 > package doesn't exist as a binary rpm, the srpm only produces msv-*
 > subpackages [1]. And obsoleting the main package won't obsolete the
 > subpackages, so this conflict is not fixed yet. I'm not sure if any 
of the
 > other msv-* subpackages should also be obsoleted or just msv-xsdlib.

I adjusted f-o-p to just list them all. I don't think we want to keep 
some

Re: redhat-lsb-core

[Steven A. Falco]

On 4/4/23 09:56 AM, Neal Gompa wrote:

On Tue, Apr 4, 2023 at 9:49 AM Steven A. Falco  wrote:


On 4/4/23 05:58 AM, ser...@serjux.com wrote:

On 2023-04-03 21:13, Steven A. Falco wrote:

I'm confused by the Requires for redhat-lsb-core.

According to "dnf repoquery --requires redhat-lsb-core" there is no
requirement for esmtp.  But according to "dnf repoquery --whatrequires
esmtp", redhat-lsb-core does require esmtp.

Perhaps there is some sort of transitive requirement that the above
commands don't show, but the curious thing is that I have
redhat-lsb-core installed on my F37 machine, and that didn't pull in
esmtp.


Please open a bug report , I'm reviewing redhat-lsb [1] , this package is so 
old that still called redhat ...
Anyone suggest another name ?

I'm happy to write a bug.  Do you prefer something along the lines of "Split lsb_release into 
a subpackage" or perhaps "Split redhat-lsb-core into finer-grained subpackages"?

For me, having an lsb_release subpackage would be best, because that is all I 
need for KiCad.  But I'll also pursue Neal's comment about changing wxWidgets 
to get the info another way.



The distro command from python3-distro may also help if you *must* use
a command-line tool.

But reading the file directly would be better.


I've created a bug [2] requesting that wxGTK use a file from os-release rather 
than lsb_release.


Worst case scenario, I could bring over a port of SUSE's lsb_release
package that uses os-release for its data into Fedora[1].


That is a very interesting approach that could potentially help other customers 
of the information.

Steve


[1]: https://copr.fedorainfracloud.org/coprs/ngompa/lsb_release-shim-el9/


[2] https://bugzilla.redhat.com/show_bug.cgi?id=2184391
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: redhat-lsb-core

[Steven A. Falco]

On 4/4/23 05:58 AM, ser...@serjux.com wrote:

On 2023-04-03 21:13, Steven A. Falco wrote:

I'm confused by the Requires for redhat-lsb-core.

According to "dnf repoquery --requires redhat-lsb-core" there is no
requirement for esmtp.  But according to "dnf repoquery --whatrequires
esmtp", redhat-lsb-core does require esmtp.

Perhaps there is some sort of transitive requirement that the above
commands don't show, but the curious thing is that I have
redhat-lsb-core installed on my F37 machine, and that didn't pull in
esmtp.


Please open a bug report , I'm reviewing redhat-lsb [1] , this package is so 
old that still called redhat ...
Anyone suggest another name ?

I'm happy to write a bug.  Do you prefer something along the lines of "Split lsb_release into 
a subpackage" or perhaps "Split redhat-lsb-core into finer-grained subpackages"?

For me, having an lsb_release subpackage would be best, because that is all I 
need for KiCad.  But I'll also pursue Neal's comment about changing wxWidgets 
to get the info another way.


https://pagure.io/redhat-lsb/commits/main


Why do I care?  Well, KiCad now Recommends redhat-lsb-core to help
with upstream bug reports (wx uses redhat-lsb-core to report OS info).

Since I added "Recommends: redhat-lsb-core" to KiCad, some users are
now apparently also getting esmtp, which they really don't need/want.

I don't understand that.  Why are some users getting esmtp when they
install KiCad, yet I didn't get esmtp when I installed KiCad?

A bigger question would be how to restructure OS information
gathering, since redhat-lsb-core does pull in a lot of stuff, but that
is a question for another day...


The problem is lsb specification it self is very outdated, last version is LSB 
5.0, released June 3, 2015.

https://refspecs.linuxfoundation.org/lsb.shtml

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

Re: redhat-lsb-core

[Steven A. Falco]

On 4/3/23 04:21 PM, Stephen Gallagher wrote:

On Mon, Apr 3, 2023 at 4:15 PM Steven A. Falco  wrote:


I'm confused by the Requires for redhat-lsb-core.

According to "dnf repoquery --requires redhat-lsb-core" there is no requirement for 
esmtp.  But according to "dnf repoquery --whatrequires esmtp", redhat-lsb-core does 
require esmtp.

Perhaps there is some sort of transitive requirement that the above commands 
don't show, but the curious thing is that I have redhat-lsb-core installed on 
my F37 machine, and that didn't pull in esmtp.

Why do I care?  Well, KiCad now Recommends redhat-lsb-core to help with 
upstream bug reports (wx uses redhat-lsb-core to report OS info).

Since I added "Recommends: redhat-lsb-core" to KiCad, some users are now 
apparently also getting esmtp, which they really don't need/want.

I don't understand that.  Why are some users getting esmtp when they install 
KiCad, yet I didn't get esmtp when I installed KiCad?

A bigger question would be how to restructure OS information gathering, since 
redhat-lsb-core does pull in a lot of stuff, but that is a question for another 
day...


esmtp provides /usr/sbin/sendmail which is needed by redhat-lsb-core.

However, it's only one of multiple packages that can provide it. If
you already have one of exim, msmtp, opensmtpd, postfix or sendmail
installed, then it won't pull esmtp in.


That explains it - I have sendmail on my machine.  Thanks!

Steve

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

redhat-lsb-core

[Steven A. Falco]

I'm confused by the Requires for redhat-lsb-core.

According to "dnf repoquery --requires redhat-lsb-core" there is no requirement for 
esmtp.  But according to "dnf repoquery --whatrequires esmtp", redhat-lsb-core does 
require esmtp.

Perhaps there is some sort of transitive requirement that the above commands 
don't show, but the curious thing is that I have redhat-lsb-core installed on 
my F37 machine, and that didn't pull in esmtp.

Why do I care?  Well, KiCad now Recommends redhat-lsb-core to help with 
upstream bug reports (wx uses redhat-lsb-core to report OS info).

Since I added "Recommends: redhat-lsb-core" to KiCad, some users are now 
apparently also getting esmtp, which they really don't need/want.

I don't understand that.  Why are some users getting esmtp when they install 
KiCad, yet I didn't get esmtp when I installed KiCad?

A bigger question would be how to restructure OS information gathering, since 
redhat-lsb-core does pull in a lot of stuff, but that is a question for another 
day...

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

Re: New machine - no virtual terminals

[Steven A. Falco]

On 3/23/23 06:14 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 22 March 2023 at 17:12, Steven A. Falco wrote:

On 3/22/23 11:23 AM, stan via devel wrote:

On Tue, 21 Mar 2023 17:14:44 -0400
"Steven A. Falco"  wrote:


I think I'm finally getting somewhere with this problem.

My motherboard has a built-in VGA interface, which shows up as
"astdrmfb" on fb0.  My AMD video card is "amdgpudrmfb" on fb1.

For some reason, the kernel uses fb1 for the graphical desktop, but
when I type Ctrl-Alt-F3 it switches to the VGA interface on fb0.

So my question is now probably simpler - I need to find a way to tell
the kernel to ignore fb0 completely, and just use fb1 for everything.

I'll do some searching to see if I can figure that out, but if
someone knows off the top of their head how to force a framebuffer to
be ignored, I'd appreciate it.


Is there a way to turn off the fb0 in the BIOS?  Hit F2 or Del to get
into the bios while booting.  Yours might be different, but I think
these are pretty standard.


I read through the motherboard manual and while I don't see a way to
turn off the on-board VGA hardware from the BIOS, there is a physical
switch on the motherboard to disable it completely.

I tried that, and it worked.  Now the kernel only sees my AMD video
card and assigns it to fb0.  And all the virtual consoles now work
properly.

Thanks again for your help, Stan.  I appreciate it!


For future reference and for others who bump into similar issue, you can
use the fbcon=map:1 kernel option to map the second fb to the console.
See https://www.kernel.org/doc/html/latest/fb/fbcon.html for more
details.


Thanks, Dominik.  I've added that to my kernel cheat-sheet.  Very good 
information to keep handy.

Steve

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

Re: New machine - no virtual terminals

[Steven A. Falco]

On 3/22/23 11:23 AM, stan via devel wrote:

On Tue, 21 Mar 2023 17:14:44 -0400
"Steven A. Falco"  wrote:


I think I'm finally getting somewhere with this problem.

My motherboard has a built-in VGA interface, which shows up as
"astdrmfb" on fb0.  My AMD video card is "amdgpudrmfb" on fb1.

For some reason, the kernel uses fb1 for the graphical desktop, but
when I type Ctrl-Alt-F3 it switches to the VGA interface on fb0.

So my question is now probably simpler - I need to find a way to tell
the kernel to ignore fb0 completely, and just use fb1 for everything.

I'll do some searching to see if I can figure that out, but if
someone knows off the top of their head how to force a framebuffer to
be ignored, I'd appreciate it.


Is there a way to turn off the fb0 in the BIOS?  Hit F2 or Del to get
into the bios while booting.  Yours might be different, but I think
these are pretty standard.


I read through the motherboard manual and while I don't see a way to turn off 
the on-board VGA hardware from the BIOS, there is a physical switch on the 
motherboard to disable it completely.

I tried that, and it worked.  Now the kernel only sees my AMD video card and 
assigns it to fb0.  And all the virtual consoles now work properly.

Thanks again for your help, Stan.  I appreciate it!

Steve



Check the frame buffer configs in your kernel, /boot/config*.

Mine are
CONFIG_SYSFB=y
CONFIG_SYSFB_SIMPLEFB=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=200
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_BACKLIGHT=m
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_SIMPLE=m
but I run a custom kernel, so yours could be significantly different.
You could compare a grep of the f38 kernel config that works with a
grep of the f37 kernel config that doesn't to see if there is a
difference in their framebuffer configuration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Re: New machine - no virtual terminals

[Steven A. Falco]

I think I'm finally getting somewhere with this problem.

My motherboard has a built-in VGA interface, which shows up as "astdrmfb" on fb0.  My AMD 
video card is "amdgpudrmfb" on fb1.

For some reason, the kernel uses fb1 for the graphical desktop, but when I type 
Ctrl-Alt-F3 it switches to the VGA interface on fb0.

So my question is now probably simpler - I need to find a way to tell the 
kernel to ignore fb0 completely, and just use fb1 for everything.

I'll do some searching to see if I can figure that out, but if someone knows 
off the top of their head how to force a framebuffer to be ignored, I'd 
appreciate it.

Steve

On 3/21/23 03:26 PM, Steven A. Falco wrote:

On 3/21/23 02:26 PM, stan via devel wrote:

On Tue, 21 Mar 2023 10:25:36 -0400
"Steven A. Falco"  wrote:


I recently put a new machine together using an AMD Radeon PRO W6600
Graphics Card.  CPU is a threadripper pro.  Motherboard is an ASUS
Pro WS WRX80E-SAGE SE WIFI II sWRX8 E-ATX.  Software is the KDE spin
of Fedora 37.

It mostly works perfectly, but if I try to access a virtual terminal
with Ctrl-Alt-F3 my monitors go to sleep, so apparently the video
sync shuts off.  Typing Ctrl-Alt-F2 brings me back to my KDE session.

Also Ctrl-Alt-F1 shows me the text that occurred during boot - I have
rhgb and quiet disabled in my grub configuration.  So Ctrl-Alt-F1 and
F2 work, but F3 and above do not.

I don't see anything in /var/log/messages that would give me a hint
as to where to start with debugging this.  I've tried running SDDM in
wayland and in x11 modes, but that doesn't make a difference.

I'd like to write a bug for this, but I'm not sure how to gather
enough data for a meaningful report.  Are there some kernel options I
can try, or other ways to get more data?

> Is the number of consoles in /etc/systemd/logind.conf set to more than
2?  The default is 6, and so systemd should set up 6 virtual consoles
for use.  They usually don't actuate until visited, but they should
still be available to a Ctrl-Alt-[3-6].


This is good info - thanks!  Everything is commented out in logind.conf, so I 
should be getting the default of 6 virtual consoles.

I tried booting to multi-user using a 3 at the end of the boot line, as you suggested.  I 
had a login prompt on virtual console 1 and was able to log in.  Then I switched to 
virtual console 5, which was completely blank, but I carefully typed a user name and 
password and started a "top" running (all without being able to see what I was 
typing), went back to virtual console 1, did a ps, and saw that the top was running.  So 
the problem is that the video output is only working in the first virtual console, but 
the others are functional - they just don't show any text or cursor!

One other experiment that I tried: I put 
Fedora-KDE-Live-x86_64-38-20230320.n.0.iso on a USB drive, booted that, and saw 
that the virtual consoles were work perfectly.  I could switch between them, 
and they displayed properly.  But if I repeat that experiment with an F37 live 
USB drive, then I have the no-display problem.

So it looks like something has been corrected in F38 that is broken in F37.  
I'm tempted to upgrade to F38, but this is my main machine, so I'm a little 
hesitant.  I'll see if I can load an F38 kernel; it should be easy to back that 
out if it doesn't help.


I boot to multiuser and start X from there, and I always get virtual
consoles.  If you do a
journalctl -r
and then a
/vcon
do you see lines like

fedora dracut[128053]: -rwxr-xr-x   1 root root    20528 Mar 13 13:01 
usr/lib/systemd/systemd-vconsole-setup
fedora dracut[128053]: -rw-r--r--   1 root root  650 Mar 13 12:59 
usr/lib/systemd/system/systemd-vconsole-setup.service


For completeness, yes, I do see those lines.


If the setup isn't occurring it would be a systemd bug.  But check if
systemd is reporting errors when it tries to set the vconsoles up.  And
try booting into multiuser by hitting a key during boot, and putting a
3 at the end of the boot line options to see if that sets them up.

Fedora recently dropped support from the kernel for the old fbcon and
replaced it with the new simple version.  Might be related if it wasn't
taken into account.  Or KDE might have decided virtual consoles were
obsolete and dropped support for them (unlikely).

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

Re: New machine - no virtual terminals

[Steven A. Falco]

On 3/21/23 02:26 PM, stan via devel wrote:

On Tue, 21 Mar 2023 10:25:36 -0400
"Steven A. Falco"  wrote:


I recently put a new machine together using an AMD Radeon PRO W6600
Graphics Card.  CPU is a threadripper pro.  Motherboard is an ASUS
Pro WS WRX80E-SAGE SE WIFI II sWRX8 E-ATX.  Software is the KDE spin
of Fedora 37.

It mostly works perfectly, but if I try to access a virtual terminal
with Ctrl-Alt-F3 my monitors go to sleep, so apparently the video
sync shuts off.  Typing Ctrl-Alt-F2 brings me back to my KDE session.

Also Ctrl-Alt-F1 shows me the text that occurred during boot - I have
rhgb and quiet disabled in my grub configuration.  So Ctrl-Alt-F1 and
F2 work, but F3 and above do not.

I don't see anything in /var/log/messages that would give me a hint
as to where to start with debugging this.  I've tried running SDDM in
wayland and in x11 modes, but that doesn't make a difference.

I'd like to write a bug for this, but I'm not sure how to gather
enough data for a meaningful report.  Are there some kernel options I
can try, or other ways to get more data?

> Is the number of consoles in /etc/systemd/logind.conf set to more than
2?  The default is 6, and so systemd should set up 6 virtual consoles
for use.  They usually don't actuate until visited, but they should
still be available to a Ctrl-Alt-[3-6].


This is good info - thanks!  Everything is commented out in logind.conf, so I 
should be getting the default of 6 virtual consoles.

I tried booting to multi-user using a 3 at the end of the boot line, as you suggested.  I 
had a login prompt on virtual console 1 and was able to log in.  Then I switched to 
virtual console 5, which was completely blank, but I carefully typed a user name and 
password and started a "top" running (all without being able to see what I was 
typing), went back to virtual console 1, did a ps, and saw that the top was running.  So 
the problem is that the video output is only working in the first virtual console, but 
the others are functional - they just don't show any text or cursor!

One other experiment that I tried: I put 
Fedora-KDE-Live-x86_64-38-20230320.n.0.iso on a USB drive, booted that, and saw 
that the virtual consoles were work perfectly.  I could switch between them, 
and they displayed properly.  But if I repeat that experiment with an F37 live 
USB drive, then I have the no-display problem.

So it looks like something has been corrected in F38 that is broken in F37.  
I'm tempted to upgrade to F38, but this is my main machine, so I'm a little 
hesitant.  I'll see if I can load an F38 kernel; it should be easy to back that 
out if it doesn't help.


I boot to multiuser and start X from there, and I always get virtual
consoles.  If you do a
journalctl -r
and then a
/vcon
do you see lines like

fedora dracut[128053]: -rwxr-xr-x   1 root root20528 Mar 13 13:01 
usr/lib/systemd/systemd-vconsole-setup
fedora dracut[128053]: -rw-r--r--   1 root root  650 Mar 13 12:59 
usr/lib/systemd/system/systemd-vconsole-setup.service


For completeness, yes, I do see those lines.


If the setup isn't occurring it would be a systemd bug.  But check if
systemd is reporting errors when it tries to set the vconsoles up.  And
try booting into multiuser by hitting a key during boot, and putting a
3 at the end of the boot line options to see if that sets them up.

Fedora recently dropped support from the kernel for the old fbcon and
replaced it with the new simple version.  Might be related if it wasn't
taken into account.  Or KDE might have decided virtual consoles were
obsolete and dropped support for them (unlikely).

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

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

New machine - no virtual terminals

[Steven A. Falco]

I recently put a new machine together using an AMD Radeon PRO W6600 Graphics 
Card.  CPU is a threadripper pro.  Motherboard is an ASUS Pro WS WRX80E-SAGE SE 
WIFI II sWRX8 E-ATX.  Software is the KDE spin of Fedora 37.

It mostly works perfectly, but if I try to access a virtual terminal with 
Ctrl-Alt-F3 my monitors go to sleep, so apparently the video sync shuts off.  
Typing Ctrl-Alt-F2 brings me back to my KDE session.

Also Ctrl-Alt-F1 shows me the text that occurred during boot - I have rhgb and 
quiet disabled in my grub configuration.  So Ctrl-Alt-F1 and F2 work, but F3 
and above do not.

I don't see anything in /var/log/messages that would give me a hint as to where 
to start with debugging this.  I've tried running SDDM in wayland and in x11 
modes, but that doesn't make a difference.

I'd like to write a bug for this, but I'm not sure how to gather enough data 
for a meaningful report.  Are there some kernel options I can try, or other 
ways to get more data?

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

Re: Status of AVIF support in Fedora

[Steven A. Falco]

As a workaround until the dust settles, I did a dnf downgrade of libheif and 
added an exclude in dnf.conf.  I'll revert that when the add-ons are published.

Steve

On 3/20/23 02:39 PM, Kalev Lember wrote:

On Mon, Mar 20, 2023 at 7:29 PM Vitaly Zaitsev via devel mailto:devel@lists.fedoraproject.org>> wrote:

On 20/03/2023 17:08, Dominik 'Rathann' Mierzejewski wrote:
 > Going forward, I'm going to turn it into an add-on package, i.e. ship
 > only the two plugins we can't ship in Fedora:

In a subpackage libheif-freeworld?


I think it would look cleaner to name them according to the plugins, so that it 
would be:

%files -n libheif-libde265
%{_libdir}/libheif/libheif-libde265.so

%files -n libheif-x265
%{_libdir}/libheif/libheif-x265.so

and then add reverse soft deps from the newly added packages to the libheif 
package so that they'd get pulled in when enabling rpmfusion. Although thinking 
about it some more, there was a somewhat recent dnf change that made it not 
pull in newly added soft deps, so maybe this approach would not work so well 
after all, at least not to automatically pull in the extra plugins ...

Anyway, libheif-freeworld sounds to me more like something that would replace 
the entire libheif package with an alternative version. In this case, it's only 
two additional plugins and I think it would be better to avoid the -freeworld 
pattern here.

--
Kalev

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

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Steven A. Falco]

On 2/22/23 10:28 AM, Steven A. Falco wrote:

I got the following errors:

Error:
  Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires 
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
   - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
   - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64
  Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires 
libembree3.so.3()(64bit), but none of the providers can be installed
   - problem with installed package blender-1:3.4.1-2.fc37.x86_64
   - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository
   - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

I then tried removing blender and its dependencies, and I got the following 
downgrades:

  Lmod    x86_64 8.7.18-1.fc38  
fedora 258 k
  autorandr   noarch 1.12.1-3.fc38  
fedora  43 k
  autorandr-bash-completion   noarch 1.12.1-3.fc38  
fedora 8.1 k
  cscope  x86_64 15.9-18.fc38   
fedora 286 k


Please ignore the cscope downgrade.  I built my own, so that is a false report.


  fwupd   x86_64 1.8.10-1.fc38  
fedora 1.8 M
  fwupd-plugin-flashrom   x86_64 1.8.10-1.fc38  
fedora  26 k
  fwupd-plugin-modem-manager  x86_64 1.8.10-1.fc38  
fedora  60 k
  fwupd-plugin-uefi-capsule-data  x86_64 1.8.10-1.fc38  
fedora 1.8 M



  gimp    x86_64 2:2.10.32-7.fc38   
fedora  21 M
  gimp-devel  x86_64 2:2.10.32-7.fc38   
fedora 1.2 M
  gimp-devel-tools    x86_64 2:2.10.32-7.fc38   
fedora  20 k
  gimp-libs   x86_64 2:2.10.32-7.fc38   
fedora 526 k


Same for gimp - not really a downgrade.


  gputils x86_64 1.5.2-1.fc38   
fedora 2.2 M
  gputils-doc noarch 1.5.2-1.fc38   
fedora 1.9 M
  inxi    noarch 3.3.24-2.fc38  
fedora 493 k

 Steve

On 2/22/23 04:30 AM, Miroslav Suchý wrote:

Do you want to make Fedora 38 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveals 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F38FailsToInstall) 
reports:

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

Thank you

Miroslav


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



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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Steven A. Falco]

I got the following errors:

Error:
 Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires 
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
  - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
  - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64
 Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires 
libembree3.so.3()(64bit), but none of the providers can be installed
  - problem with installed package blender-1:3.4.1-2.fc37.x86_64
  - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository
  - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

I then tried removing blender and its dependencies, and I got the following 
downgrades:

 Lmodx86_64 8.7.18-1.fc38  
fedora 258 k
 autorandr   noarch 1.12.1-3.fc38  
fedora  43 k
 autorandr-bash-completion   noarch 1.12.1-3.fc38  
fedora 8.1 k
 cscope  x86_64 15.9-18.fc38   
fedora 286 k
 fwupd   x86_64 1.8.10-1.fc38  
fedora 1.8 M
 fwupd-plugin-flashrom   x86_64 1.8.10-1.fc38  
fedora  26 k
 fwupd-plugin-modem-manager  x86_64 1.8.10-1.fc38  
fedora  60 k
 fwupd-plugin-uefi-capsule-data  x86_64 1.8.10-1.fc38  
fedora 1.8 M
 gimpx86_64 2:2.10.32-7.fc38   
fedora  21 M
 gimp-devel  x86_64 2:2.10.32-7.fc38   
fedora 1.2 M
 gimp-devel-toolsx86_64 2:2.10.32-7.fc38   
fedora  20 k
 gimp-libs   x86_64 2:2.10.32-7.fc38   
fedora 526 k
 gputils x86_64 1.5.2-1.fc38   
fedora 2.2 M
 gputils-doc noarch 1.5.2-1.fc38   
fedora 1.9 M
 inxinoarch 3.3.24-2.fc38  
fedora 493 k

Steve

On 2/22/23 04:30 AM, Miroslav Suchý wrote:

Do you want to make Fedora 38 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveals 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F38FailsToInstall) 
reports:

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

Thank you

Miroslav


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

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

libhackrf soname bump

[Steven A. Falco]

libhackrf has updated from 0.7.0 to 0.8.0 in rawhide.

No dependent packages depend on the exact version, so nothing else should need 
rebuilding.  Tested with CubicSDR and gnuRadio.

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

Heads up for KiCad in Rawhide

[Steven A. Falco]

KiCad will shortly be upgraded from 6.0.11 to 7.0.0-rc2 in Rawhide.

Designs created with KiCad 6 and earlier are readable / editable by KiCad 7.

However, once a design is saved with KiCad 7, it will no longer be readable by 
KiCad 6 or earlier.

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

Re: Fedora 35 End Of Life in one week

[Steven A. Falco]

On 12/7/22 09:14 AM, Tomas Hrcka wrote:

Fedora 36 will continue to receive updates until approximately one
month after the release of Fedora 37.


Shouldn't that be "until approximately one month after the release of Fedora 
_38_"?

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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/24/22 08:45 AM, Kalev Lember wrote:

Hi Scott,

On Wed, Nov 23, 2022 at 6:23 PM Scott Talbert mailto:s...@techie.net>> wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
currently built with OpenGL EGL support) and several package users which
are expecting OpenGL GLX support, I need to rebuild wxWidgets with a
different configuration option.  Unfortunately, this results in an ABI
change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be
rebuilt.  Unfortunately #2, this also needs to be done in F37.  I've
opened two side tags to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198

The following packages need to be rebuilt in the above side tags (note,
I've already taken care of python-wxpython4 and CubicSDR, which are also
affected):

0ad


I did 0ad rebuilds for both F37 and F38:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092061 

F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092060 



The KiCad builds are also complete:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092087
F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092086

Steve

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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/23/22 12:58 PM, Steven A. Falco wrote:

On 11/23/22 12:23 PM, Scott Talbert wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which are 
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different 
configuration option.  Unfortunately, this results in an ABI change, so all 
packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt.  
Unfortunately #2, this also needs to be done in F37.  I've opened two side tags 
to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198


Builds for kicad started:

f37: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463878
f38: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463846


The kicad builds failed.  Here is a link to one of the build logs: 
https://kojipkgs.fedoraproject.org//work/tasks/4020/94464020/build.log

The errors start around line 1846 in that log.  Apparently I'll need to remove 
the EGL flag and try again.

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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/23/22 12:23 PM, Scott Talbert wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which are 
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different 
configuration option.  Unfortunately, this results in an ABI change, so all 
packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt.  
Unfortunately #2, this also needs to be done in F37.  I've opened two side tags 
to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198


Builds for kicad started:

f37: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463878
f38: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463846

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

Non-responsive maintainer check for cottsay

[Steven A. Falco]

The package hackrf has several open bugs [1], [2].

I've started the non-responsive maintainer process by filing [3].

I've CC'd the maintainer on this email, but if anyone knows how else to contact 
them, please let me know.

Thanks,
Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1941132
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2113439
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2143712
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: hackrf package

[Steven A. Falco]

On 11/16/22 06:25 PM, Scott Talbert wrote:

I just upgraded my system to Fedora 37 and noticed that the package "hackrf" was
still from Fedora 36.  I found a failed build from the f37-rebuild, dated 
2022-07-21 [1].
It apparently failed on aarch64, but the logs are long gone - at least I don't 
see
them on koji.

I tried a scratch build, and it went fine [2].

What is the correct procedure to request a rebuild for situations like this?  
Should I ask
the maintainers, or file an infra ticket, or ...?

Steve

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=89804049
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=94253032


There's already an open bug: https://bugzilla.redhat.com/show_bug.cgi?id=2113439

You might want to follow-up on that bug, or perhaps initiate a non-responsive 
maintainer process, if the maintainer continues to not respond.


I added a comment to the bug, and offered to co-maintain.  Thanks for the 
pointer.

Steve

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

hackrf package

[Steven A. Falco]

I just upgraded my system to Fedora 37 and noticed that the package "hackrf" 
was still from Fedora 36.  I found a failed build from the f37-rebuild, dated 2022-07-21 
[1].  It apparently failed on aarch64, but the logs are long gone - at least I don't see 
them on koji.

I tried a scratch build, and it went fine [2].

What is the correct procedure to request a rebuild for situations like this?  
Should I ask the maintainers, or file an infra ticket, or ...?

Steve

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=89804049
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=94253032
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update

[Steven A. Falco]

On 11/10/22 09:47 AM, Eike Rathke wrote:

Hi Miroslav,

On Monday, 2022-11-07 18:46:26 +0100, Miroslav Suchý wrote:


Tl;dr Please start migrating your license tag to SPDX now.


Is it ok to have SPDX tags on all currently supported release branches,
i.e. f37, f36, f35?


Yes.

Steve

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

Re: How do I "unstick" koji?

[Steven A. Falco]

On 9/28/22 09:59 AM, Stephen Smoogen wrote:



On Wed, 28 Sept 2022 at 09:53, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

Yesterday, I had a build that failed.  The task ID is 92381483.

I tried rebuilding it today in task 92397327 but I get the error message:

"GenericError: Build already in progress (task 92381483)"

I tried doing "koji cancel 92381483" but that doesn't help.  Another 
attempt (task 92398262) failed the same way.

Is it possible to clear this state or do I just have to bump the release 
number and try again?


There was an outage and some other issues with koji in the last 24 hours. It may take 
a releng person to clear this. Could you open a ticket at https://pagure.io/releng/ 
<https://pagure.io/releng/> for that to happen?


I opened #11055 https://pagure.io/releng/issue/11055

Thanks for the suggestion.

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

How do I "unstick" koji?

[Steven A. Falco]

Yesterday, I had a build that failed.  The task ID is 92381483.

I tried rebuilding it today in task 92397327 but I get the error message:

"GenericError: Build already in progress (task 92381483)"

I tried doing "koji cancel 92381483" but that doesn't help.  Another attempt 
(task 92398262) failed the same way.

Is it possible to clear this state or do I just have to bump the release number 
and try again?

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

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Steven A. Falco]

On 9/12/22 08:59 AM, Miroslav Suchý wrote:

dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


Error:
 Problem: package nautilus-dropbox-1:2020.03.04-3.fc35.x86_64 requires 
libnautilus-extension.so.1()(64bit), but none of the providers can be installed
  - nautilus-extensions-42.2-1.fc36.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package nautilus-dropbox-1:2020.03.04-3.fc35.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

License change for bvi

[Steven A. Falco]

License changed from GPLv3 to GPL-3.0-or-later

(In the past it should have been GPLv3+ rather than GPLv3, so I fixed that in 
the process of converting to SPDX, in case anyone was wondering...)

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

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

[Steven A. Falco]

On 9/8/22 06:44 AM, Miroslav Suchý wrote:

Quick heads up where we are:


I had been following this discussion, and I vaguely remember that there was 
talk of it having to be conditional, perhaps with a macro.

Has all that now been resolved?  Can one simply convert to the new SPDX license 
identifier for all active Fedora releases, i.e. F35 through Rawhide?

Steve



* people started voluntary migrating the identifiers to SPDX. When the license 
is not on our list, you can open issue or even merge request here:
https://gitlab.com/fedora/legal/fedora-license-data
Richard and Jilayne are doing awesome work reviewing the license and they added 
huge amount of licenses on list.

* We have list of allowed licenses

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

and script which generate the page [1] but the result is not yet deployed to 
prod. Neither automation is set yet.

We also have list of not allowed license with reasons of rejections

https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/

* We have MR [2] which creates the data for rpmlint. Again, this is not merged 
and not yet in Fedora.

* Richard and Jilayne are submitting licenses which are missing in spdx.org 
list to SPDX.

* Package fedora-license-data is included in Fedora. We are in process of 
setting automation which will create new update when there are new data.

[1] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/55

[2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76


We still have lot of work on our plates due to voluntary migration. Once we 
clean all these things and and workflow from voluntary migration gets lower we 
will start preparing for phase 2 - it will include migration of the remaining 
packages. My guess is that we are few months away from that.

If you want to migrate your package and you hit a problem, do not hesitate to 
jump to legal mailing list and ask for a help

https://lists.fedoraproject.org/admin/lists/legal.lists.fedoraproject.org/

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

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/16/22 09:29 AM, Steven A. Falco wrote:

On 8/15/22 08:38 PM, Scott Talbert wrote:

On Sat, 13 Aug 2022, Steven A. Falco wrote:


On 8/12/22 11:35 AM, Steven A. Falco wrote:

On 8/12/22 11:00 AM, Scott Talbert wrote:

On Fri, 12 Aug 2022, Steven A. Falco wrote:


It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2]. Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152


The KiCad build in the side-tag completed, and I've tested it on x86_64 and 
aarch64.  It all looks good, so I am fine with merging the side-tag.

Scott - What will be the process for getting this into F37?  I'm curious as to 
the timeline so I can handle the changes there.


OK, I went ahead and submitted the bodhi request to merge the side-tag.

On F37, do you have any strong feelings about whether this should or should not 
go in F37?  If yes, we should probably do a similar side-tag build.


Thanks for allowing us to have input on that, Scott.

I posted a message to the KiCad developers to get their comments, since I would 
need their support to fix any bugs that might come up.

I'll forward their preferences as soon as I hear from them.


The KiCad developers are in favor of updating to wxPython 4.2.0 in Fedora 37.

Scott - if you agree, please set up a side-tag when convenient.  I'll then make 
the necessary KiCad changes and run a build in the side-tag.


Done, created side tag f37-build-side-56650 and built wxPython there.


Thanks - I've started a KiCad build [1].  It should be ready later today.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90874286


The KiCad build for F37 is complete in f37-build-side-56650.

Scott - please merge the tag when convenient.  Thanks.

Steve

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/15/22 08:38 PM, Scott Talbert wrote:

On Sat, 13 Aug 2022, Steven A. Falco wrote:


On 8/12/22 11:35 AM, Steven A. Falco wrote:

On 8/12/22 11:00 AM, Scott Talbert wrote:

On Fri, 12 Aug 2022, Steven A. Falco wrote:


It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2]. Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152


The KiCad build in the side-tag completed, and I've tested it on x86_64 and 
aarch64.  It all looks good, so I am fine with merging the side-tag.

Scott - What will be the process for getting this into F37?  I'm curious as to 
the timeline so I can handle the changes there.


OK, I went ahead and submitted the bodhi request to merge the side-tag.

On F37, do you have any strong feelings about whether this should or should not 
go in F37?  If yes, we should probably do a similar side-tag build.


Thanks for allowing us to have input on that, Scott.

I posted a message to the KiCad developers to get their comments, since I would 
need their support to fix any bugs that might come up.

I'll forward their preferences as soon as I hear from them.


The KiCad developers are in favor of updating to wxPython 4.2.0 in Fedora 37.

Scott - if you agree, please set up a side-tag when convenient.  I'll then make 
the necessary KiCad changes and run a build in the side-tag.


Done, created side tag f37-build-side-56650 and built wxPython there.


Thanks - I've started a KiCad build [1].  It should be ready later today.

Steve

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

Re: rawhide: GPG check FAILED

[Steven A. Falco]

On 8/14/22 04:42 PM, Christian Kujau wrote:

Rawhide n00b here, but struggling with:

---
$ dnf upgrade --assumeyes --releasever=rawhide zip


Since Fedora 37 has been branched, you need to grab the new Rawhide packages.  
Rawhide is now the future F38.  This should work:

dnf update fedora-gpg-keys --nogpgcheck
dnf update fedora-repos --release 38
dnf update --refresh

Steve


[]
[SKIPPED] zip-3.0-33.fc37.x86_64.rpm: Already downloaded
Fedora rawhide - x86_64 

1.6 MB/s | 1.6 kB 00:00
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64 
(0x5323552A) is already installed
The GPG keys listed for the "Fedora rawhide - x86_64" repository are already 
installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing 
package is: zip-3.0-33.fc37.x86_64
  GPG Keys are configured as: 
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64
The downloaded packages were saved in cache until the next successful 
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED


$ rpm -K /var/cache/dnf/fedora*/packages/zip*.rpm --verbose
/var/cache/dnf/fedora-ebd04873699a984e/packages/zip-3.0-33.fc37.x86_64.rpm:
 Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
 Header SHA256 digest: OK
 Header SHA1 digest: OK
 Payload SHA256 digest: OK
 V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY
 MD5 digest: OK
---

So, RPM-GPG-KEY-fedora-rawhide-x86_64 is present (via 
"gpg-pubkey-5323552a-6112bcdc"), but rawhide packages appear to be signed with 
a key called 0xeb10b464 -- I could not find that key mentioned anywhere on the interwebs, 
what's going on here?

Also, the "zip" package is just an example, I was actually trying to "dnf 
system-upgrade" and that warning above was printed for every package. Yes, one could add 
--nogpgcheck, but that should not be needed, right?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/12/22 11:35 AM, Steven A. Falco wrote:

On 8/12/22 11:00 AM, Scott Talbert wrote:

On Fri, 12 Aug 2022, Steven A. Falco wrote:


It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2]. Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152


The KiCad build in the side-tag completed, and I've tested it on x86_64 and 
aarch64.  It all looks good, so I am fine with merging the side-tag.

Scott - What will be the process for getting this into F37?  I'm curious as to 
the timeline so I can handle the changes there.


OK, I went ahead and submitted the bodhi request to merge the side-tag.

On F37, do you have any strong feelings about whether this should or should not 
go in F37?  If yes, we should probably do a similar side-tag build.


Thanks for allowing us to have input on that, Scott.

I posted a message to the KiCad developers to get their comments, since I would 
need their support to fix any bugs that might come up.

I'll forward their preferences as soon as I hear from them.


The KiCad developers are in favor of updating to wxPython 4.2.0 in Fedora 37.

Scott - if you agree, please set up a side-tag when convenient.  I'll then make 
the necessary KiCad changes and run a build in the side-tag.

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/12/22 11:00 AM, Scott Talbert wrote:

On Fri, 12 Aug 2022, Steven A. Falco wrote:


It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2]. Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152


The KiCad build in the side-tag completed, and I've tested it on x86_64 and 
aarch64.  It all looks good, so I am fine with merging the side-tag.

Scott - What will be the process for getting this into F37?  I'm curious as to 
the timeline so I can handle the changes there.


OK, I went ahead and submitted the bodhi request to merge the side-tag.

On F37, do you have any strong feelings about whether this should or should not 
go in F37?  If yes, we should probably do a similar side-tag build.


Thanks for allowing us to have input on that, Scott.

I posted a message to the KiCad developers to get their comments, since I would 
need their support to fix any bugs that might come up.

I'll forward their preferences as soon as I hear from them.

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/11/22 03:43 PM, Steven A. Falco wrote:

It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2].  Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152


The KiCad build in the side-tag completed, and I've tested it on x86_64 and 
aarch64.  It all looks good, so I am fine with merging the side-tag.

Scott - What will be the process for getting this into F37?  I'm curious as to 
the timeline so I can handle the changes there.

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/11/22 12:26 PM, Steven A. Falco wrote:

On 8/11/22 09:56 AM, Steven A. Falco wrote:

On 8/10/22 07:41 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 06:00 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 05:06 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.


Yeah, we can get the changes into F37.

So KiCad isn't quite ready to move yet?  I can hold off until you're ready.


I've spoken with the upstream KiCad developers, and based on that conversation 
I think you should go ahead and put the new wxWidgets / wxPython into Rawhide 
when it is convenient for you, without waiting for KiCad.

There is a KiCad Copr [1], where we make nightly pre-release builds of what 
will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end 
of the year.  The KiCad 7 series is where the upstream devs prefer to integrate 
with the new wxWidgets / wxPython both because of the risk of new bugs and also 
so they don't have to backport fixes to the older KiCad 6.x series.

So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out 
locally and in our Copr.  Based on how that goes, we can consider switching 
over the downstream Rawhide builds.  But based on the way the timing has worked 
out, and because we don't want to do a major version upgrade of KiCad in a 
stable Fedora release, we may not be able to switch KiCad to the new wxWidgets 
/ wxPython in F37.


The problem though, is that while wxWidgets versions are parallel installable, 
wxPython versions are not.  So, once I update to wxPython 4.2.0 (which links 
with wxWidgets 3.2.0), wxPython 4.0.7 will be gone. I'm presuming that's going 
to break KiCad?


It is a bit awkward to be mediating between the Fedora devel list and the KiCad 
one, but I think we are nearly there.  According to one of the KiCad leads:

"The Flatpak has been running the wx 3.1 branch since v6 was released, and so far 
there have been no issues. We already have Windows and macOS running the 3.1 versions, so 
I don't see why we need to hold the Linux builds back."

So, I think we are good to go forward and retire wxPython 4.0.7 at your 
convenience.  If it is not too much trouble to use a side-tag, I'll make the 
KiCad build there and it can all go in together.  My schedule is quite open, so 
I shouldn't hold you up.

Please let me know whenever you are ready.  No rush.  And thanks for your 
patience. :-)


OK, I pushed wxPython 4.2.0 to Rawhide (now F38) and am building in side tag 
f38-build-side-56468.  It's still building at the moment.

Also, I sent you a pull request to rebuild kicad with wxWidgets 3.2.0 and 
wxPython 4.2.0.  I was able to rebuild it in a copr successfully with these 
changes.


I merged your pull request.  For some reason the merge button on the pull 
request page threw an error, so I added your fork as a remote, and merged it 
that way.

It is building now [1] and will probably take 4 hours or so.  Thanks for the 
patch!

 Steve

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90701098


I've cancelled that build.  I tried running the x86_64 version in a VM and it 
crashes at various points.  I'll have to investigate further.


It turns out that there is a bug in wxPython whereby it installs an error 
handler that should not be installed by a library [1].  KiCad can work around 
that by adding a compile flag to disable its own error handler [2].  Credit to 
Ian for identifying the problem and the work-around.

I've started a new KiCad build [3] in the side-tag.

Steve

[1] https://github.com/wxWidgets/wxWidgets/issues/22717
[2] https://gitlab.com/kicad/code/kicad/-/issues/12217
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=90710152
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/11/22 09:56 AM, Steven A. Falco wrote:

On 8/10/22 07:41 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 06:00 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 05:06 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.


Yeah, we can get the changes into F37.

So KiCad isn't quite ready to move yet?  I can hold off until you're ready.


I've spoken with the upstream KiCad developers, and based on that conversation 
I think you should go ahead and put the new wxWidgets / wxPython into Rawhide 
when it is convenient for you, without waiting for KiCad.

There is a KiCad Copr [1], where we make nightly pre-release builds of what 
will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end 
of the year.  The KiCad 7 series is where the upstream devs prefer to integrate 
with the new wxWidgets / wxPython both because of the risk of new bugs and also 
so they don't have to backport fixes to the older KiCad 6.x series.

So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out 
locally and in our Copr.  Based on how that goes, we can consider switching 
over the downstream Rawhide builds.  But based on the way the timing has worked 
out, and because we don't want to do a major version upgrade of KiCad in a 
stable Fedora release, we may not be able to switch KiCad to the new wxWidgets 
/ wxPython in F37.


The problem though, is that while wxWidgets versions are parallel installable, 
wxPython versions are not.  So, once I update to wxPython 4.2.0 (which links 
with wxWidgets 3.2.0), wxPython 4.0.7 will be gone. I'm presuming that's going 
to break KiCad?


It is a bit awkward to be mediating between the Fedora devel list and the KiCad 
one, but I think we are nearly there.  According to one of the KiCad leads:

"The Flatpak has been running the wx 3.1 branch since v6 was released, and so far 
there have been no issues. We already have Windows and macOS running the 3.1 versions, so 
I don't see why we need to hold the Linux builds back."

So, I think we are good to go forward and retire wxPython 4.0.7 at your 
convenience.  If it is not too much trouble to use a side-tag, I'll make the 
KiCad build there and it can all go in together.  My schedule is quite open, so 
I shouldn't hold you up.

Please let me know whenever you are ready.  No rush.  And thanks for your 
patience. :-)


OK, I pushed wxPython 4.2.0 to Rawhide (now F38) and am building in side tag 
f38-build-side-56468.  It's still building at the moment.

Also, I sent you a pull request to rebuild kicad with wxWidgets 3.2.0 and 
wxPython 4.2.0.  I was able to rebuild it in a copr successfully with these 
changes.


I merged your pull request.  For some reason the merge button on the pull 
request page threw an error, so I added your fork as a remote, and merged it 
that way.

It is building now [1] and will probably take 4 hours or so.  Thanks for the 
patch!

 Steve

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90701098


I've cancelled that build.  I tried running the x86_64 version in a VM and it 
crashes at various points.  I'll have to investigate further.

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/10/22 07:41 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 06:00 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 05:06 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.


Yeah, we can get the changes into F37.

So KiCad isn't quite ready to move yet?  I can hold off until you're ready.


I've spoken with the upstream KiCad developers, and based on that conversation 
I think you should go ahead and put the new wxWidgets / wxPython into Rawhide 
when it is convenient for you, without waiting for KiCad.

There is a KiCad Copr [1], where we make nightly pre-release builds of what 
will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end 
of the year.  The KiCad 7 series is where the upstream devs prefer to integrate 
with the new wxWidgets / wxPython both because of the risk of new bugs and also 
so they don't have to backport fixes to the older KiCad 6.x series.

So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out 
locally and in our Copr.  Based on how that goes, we can consider switching 
over the downstream Rawhide builds.  But based on the way the timing has worked 
out, and because we don't want to do a major version upgrade of KiCad in a 
stable Fedora release, we may not be able to switch KiCad to the new wxWidgets 
/ wxPython in F37.


The problem though, is that while wxWidgets versions are parallel installable, 
wxPython versions are not.  So, once I update to wxPython 4.2.0 (which links 
with wxWidgets 3.2.0), wxPython 4.0.7 will be gone. I'm presuming that's going 
to break KiCad?


It is a bit awkward to be mediating between the Fedora devel list and the KiCad 
one, but I think we are nearly there.  According to one of the KiCad leads:

"The Flatpak has been running the wx 3.1 branch since v6 was released, and so far 
there have been no issues. We already have Windows and macOS running the 3.1 versions, so 
I don't see why we need to hold the Linux builds back."

So, I think we are good to go forward and retire wxPython 4.0.7 at your 
convenience.  If it is not too much trouble to use a side-tag, I'll make the 
KiCad build there and it can all go in together.  My schedule is quite open, so 
I shouldn't hold you up.

Please let me know whenever you are ready.  No rush.  And thanks for your 
patience. :-)


OK, I pushed wxPython 4.2.0 to Rawhide (now F38) and am building in side tag 
f38-build-side-56468.  It's still building at the moment.

Also, I sent you a pull request to rebuild kicad with wxWidgets 3.2.0 and 
wxPython 4.2.0.  I was able to rebuild it in a copr successfully with these 
changes.


I merged your pull request.  For some reason the merge button on the pull 
request page threw an error, so I added your fork as a remote, and merged it 
that way.

It is building now [1] and will probably take 4 hours or so.  Thanks for the 
patch!

Steve

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/9/22 06:00 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 05:06 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.


Yeah, we can get the changes into F37.

So KiCad isn't quite ready to move yet?  I can hold off until you're ready.


I've spoken with the upstream KiCad developers, and based on that conversation 
I think you should go ahead and put the new wxWidgets / wxPython into Rawhide 
when it is convenient for you, without waiting for KiCad.

There is a KiCad Copr [1], where we make nightly pre-release builds of what 
will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end 
of the year.  The KiCad 7 series is where the upstream devs prefer to integrate 
with the new wxWidgets / wxPython both because of the risk of new bugs and also 
so they don't have to backport fixes to the older KiCad 6.x series.

So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out 
locally and in our Copr.  Based on how that goes, we can consider switching 
over the downstream Rawhide builds.  But based on the way the timing has worked 
out, and because we don't want to do a major version upgrade of KiCad in a 
stable Fedora release, we may not be able to switch KiCad to the new wxWidgets 
/ wxPython in F37.


The problem though, is that while wxWidgets versions are parallel installable, 
wxPython versions are not.  So, once I update to wxPython 4.2.0 (which links 
with wxWidgets 3.2.0), wxPython 4.0.7 will be gone. I'm presuming that's going 
to break KiCad?


It is a bit awkward to be mediating between the Fedora devel list and the KiCad 
one, but I think we are nearly there.  According to one of the KiCad leads:

"The Flatpak has been running the wx 3.1 branch since v6 was released, and so far 
there have been no issues. We already have Windows and macOS running the 3.1 versions, so 
I don't see why we need to hold the Linux builds back."

So, I think we are good to go forward and retire wxPython 4.0.7 at your 
convenience.  If it is not too much trouble to use a side-tag, I'll make the 
KiCad build there and it can all go in together.  My schedule is quite open, so 
I shouldn't hold you up.

Please let me know whenever you are ready.  No rush.  And thanks for your 
patience. :-)

Steve



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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/9/22 05:06 PM, Scott Talbert wrote:

On Tue, 9 Aug 2022, Steven A. Falco wrote:


On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.


Yeah, we can get the changes into F37.

So KiCad isn't quite ready to move yet?  I can hold off until you're ready.


I've spoken with the upstream KiCad developers, and based on that conversation 
I think you should go ahead and put the new wxWidgets / wxPython into Rawhide 
when it is convenient for you, without waiting for KiCad.

There is a KiCad Copr [1], where we make nightly pre-release builds of what 
will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end 
of the year.  The KiCad 7 series is where the upstream devs prefer to integrate 
with the new wxWidgets / wxPython both because of the risk of new bugs and also 
so they don't have to backport fixes to the older KiCad 6.x series.

So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out 
locally and in our Copr.  Based on how that goes, we can consider switching 
over the downstream Rawhide builds.  But based on the way the timing has worked 
out, and because we don't want to do a major version upgrade of KiCad in a 
stable Fedora release, we may not be able to switch KiCad to the new wxWidgets 
/ wxPython in F37.

Steve

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/9/22 02:25 PM, Steven A. Falco wrote:

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.


I should add that I would like to see this in F37 at some point, because that 
will help with retiring the old wxWidgets code from KiCad sooner.

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

Re: [HEADS UP] wxPython 4.2.0 in Rawhide

[Steven A. Falco]

On 8/9/22 01:09 PM, Scott Talbert wrote:

Hi,

Upstream wxPython has finally made a new release and this involves migrating to 
wxWidgets 3.2.0 at the same time.  I'm planning to build the new wxPython in 
Rawhide after F37 branch (although could put it in F37 later).

For those packages that use both wxPython and wxWidgets (I *think* this is just 
kicad?), do you want me to do this in a side-tag so we can switch the packages 
at the same time?  Or just build in rawhide and let you fix things up?


That is very good news, Scott.  The upstream KiCad devs are working on 3.2.0 
right now, as part of their efforts to support the new M1 Apple machines.

If KiCad is the only customer, I'd say there is no need to do a side-tag, 
unless that is easier for you.  I'm fine either way.

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

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Steven A. Falco]

On 7/26/22 10:07 AM, Scott Talbert wrote:

On Tue, 26 Jul 2022, Steven A. Falco wrote:


At long last wxWidgets 3.2.0 has been released and I'm getting it into Rawhide. 
 This comes with an soname bump (but this should be the last one as 3.2.x 
should now be ABI stable).

NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged to 
move their packages to use wxWidgets 3.2.

I've rebuilt these existing users in a side tag (f37-build-side-7):
- CubicSDR
- audacity
- wxmacmolplot

I see that erlang also snuck in as a user recently.  :)  @Peter, can you please 
rebuild erlang in side tag f37-build-side-7?  It should rebuild fine 
without any changes (I tested in copr).


That is great news.  Will the corresponding python3-wxpython4 package also be 
part of this?  I'll need that in order to move KiCad to the new version.


Not immediately.  I need to see if I can push upstream wxPython into making a 
release.  If not, I'll look into packaging a snapshot release as 4.0.7 is 
getting quite old and harder to maintain.


Thanks for the info, and I'll stay tuned for a compatible wxPython component.

Steve

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

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Steven A. Falco]

On 7/25/22 10:18 PM, Scott Talbert wrote:

At long last wxWidgets 3.2.0 has been released and I'm getting it into Rawhide. 
 This comes with an soname bump (but this should be the last one as 3.2.x 
should now be ABI stable).

NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged to 
move their packages to use wxWidgets 3.2.

I've rebuilt these existing users in a side tag (f37-build-side-7):
- CubicSDR
- audacity
- wxmacmolplot

I see that erlang also snuck in as a user recently.  :)  @Peter, can you please 
rebuild erlang in side tag f37-build-side-7?  It should rebuild fine 
without any changes (I tested in copr).


That is great news.  Will the corresponding python3-wxpython4 package also be 
part of this?  I'll need that in order to move KiCad to the new version.

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

Re: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Steven A. Falco]

I like this proposal.  Is the intent to use the raw.xz image or the "iso + 
UEFI" mechanism?

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

Re: Where does "redhat-linux-build" come from?

[Steven A. Falco]

On 6/24/22 11:51 AM, Dan Horák wrote:

On Fri, 24 Jun 2022 11:36:18 -0400
"Steven A. Falco"  wrote:


I'm trying to debug a package that uses cmake to build "out of tree".  It looks like the 
build happens in a directory called "redhat-linux-build".  Is there a macro that contains 
that string?


[dan@talos linux]$ rpmbuild --eval %cmake

...
   /usr/bin/cmake \
 -S "." \
 -B "redhat-linux-build" \
 -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
 -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
 -DCMAKE_INSTALL_PREFIX:PATH=/usr \
 -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
 -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
 -DSYSCONF_INSTALL_DIR:PATH=/etc \
 -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
%if "lib64" == "lib64"
 -DLIB_SUFFIX=64 \
%endif
 -DBUILD_SHARED_LIBS:BOOL=ON


Perfect.  Thanks.

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

Where does "redhat-linux-build" come from?

[Steven A. Falco]

I'm trying to debug a package that uses cmake to build "out of tree".  It looks like the 
build happens in a directory called "redhat-linux-build".  Is there a macro that contains 
that string?

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Steven A. Falco]

On 6/21/22 10:34 AM, Miro Hrončok wrote:

On 21. 06. 22 16:27, Steven A. Falco wrote:

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 3.11side tag 
to Rawhide, despite several builds not succeeding. We always aim for some 
compromise between having the side tag open for too long and having too many 
failures.


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?



$ cat /etc/yum.repos.d/koji.repo
[koji]
name=koji
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0

[koji-source]
name=koji-source
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0

$ sudo dnf --enablerepo=koji upgrade



Perfect - thanks!

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Steven A. Falco]

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

As you might already know, we have recently merged in the Python 3.11side tag 
to Rawhide, despite several builds not succeeding. We always aim for some 
compromise between having the side tag open for too long and having too many 
failures.


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?

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

Re: [HEADS UP] wxGTK update to 3.1.7

[Steven A. Falco]

On 6/10/22 03:39 PM, Scott Talbert wrote:

On Fri, 10 Jun 2022, Steven A. Falco wrote:


On 6/10/22 10:43 AM, Scott Talbert wrote:

Hi,

I'm updating wxGTK to 3.1.7 in Rawhide - this involves an soname bump.

I've created side tag f37-build-side-54462 to perform the build with its 
dependencies.

I've built wxGTK, CubicSDR and audacity in the side tag.

@rathann, can you please build wxmacmolplt in the f37-build-side-54462 side 
tag?  Also, feel free to add me as a co-maintainer if you'd rather not have to 
deal with these requests.  :)


Is it still too soon to consider a corresponding wxPython?  I know you had made 
a testing build of python3-wxpython4-4.1.2 in mid January.  The latest version 
I see on wxpython.org is wxPython-4.1.2a1.dev5434+7d45ee6a.tar.gz which 
suggests it is still in alpha.


As soon as there is a new upstream release (non-snapshot - which is what those 
4.1.2a builds are) of wxPython, I'm planning to move to it. Thankfully, the 
upstream maintainer, Robin, has become active again recently, so there should 
be a new release hopefully soon.


Makes sense.  Thanks for the update, Scott.

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

Re: [HEADS UP] wxGTK update to 3.1.7

[Steven A. Falco]

On 6/10/22 10:43 AM, Scott Talbert wrote:

Hi,

I'm updating wxGTK to 3.1.7 in Rawhide - this involves an soname bump.

I've created side tag f37-build-side-54462 to perform the build with its 
dependencies.

I've built wxGTK, CubicSDR and audacity in the side tag.

@rathann, can you please build wxmacmolplt in the f37-build-side-54462 side 
tag?  Also, feel free to add me as a co-maintainer if you'd rather not have to 
deal with these requests.  :)


Is it still too soon to consider a corresponding wxPython?  I know you had made 
a testing build of python3-wxpython4-4.1.2 in mid January.  The latest version 
I see on wxpython.org is wxPython-4.1.2a1.dev5434+7d45ee6a.tar.gz which 
suggests it is still in alpha.

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

Re: F37 proposal: BIOS boot.iso with GRUB2 (System-Wide Change proposal)

[Steven A. Falco]

+1

My main machine still uses bios boot.

Steve


On 5/13/22 10:27 AM, Ben Cotton wrote:

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

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

== Summary ==
Modify [https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic
lorax-generic-templates] to use GRUB2 when booting the boot.iso on
BIOS systems, instead of syslinux. Upstream syslinux development is
dead, and the Fedora maintainer would like to drop the package from
the distribution. GRUB2 works as a replacement in most situations and
continues to have upstream support.

== Owner ==
* Name: [[User:bcl| Brian C. Lane]]
* Email: b...@redhat.com


== Detailed Description ==
After the recent discussion surrounding removing BIOS support from the
boot.iso I have modified the templates used to build it to use GRUB2
with help from the xorriso author Thomas Schmitt. In testing so far
this seems to work in the majority of cases, which should be
sufficient to keep Fedora working on most BIOS systems.

== Feedback ==
The community is strongly in favor of continuing to support BIOS
booting for the boot.iso, we figured out how to use GRUB2 instead of
syslinux so that we can continue to support BIOS systems.

== Benefit to Fedora ==
The benefit to Fedora is that it will continue to be available on BIOS
systems, at least until GRUB2 stops supporting it.

== Scope ==
* Proposal owners:
Update lorax-generic-templates to use GRUB2. See the
[https://github.com/weldr/lorax/pull/1226 Lorax PR]

* Other developers:
Pungi uses the boot.iso as the basis for the DVD and may need changes.
I have opened a [https://pagure.io/pungi/issue/1608 Pungi issue] to
track this.

* Release engineering: [https://pagure.io/releng/issues/10788]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
This will have no effect on upgrades, it only effects the installation
boot media.

== How To Test ==
Testing can be done with the test iso from
[https://bcl.fedorapeople.org/boot-grub2-f36.iso] or by checking out
the [https://github.com/weldr/lorax/pull/1226 Lorax PR] and running
Lorax from the git repo to build a new boot.iso locally:

  sudo PATH="./src/sbin:$PATH" PYTHONPATH=./src/ ./src/sbin/lorax \
  -p Fedora -v rawhide -r rawhide \
  -s 
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/
\
  --logfile=lorax-build.log --sharedir ./share/ --tmp /var/tmp/ \
  ./rawhide-lorax/ |& tee lorax-build-out.log


== User Experience ==
Users will notice that the boot.iso menu is now using GRUB2 when
booting on BIOS and UEFI systems.

== Dependencies ==
Pungi uses Lorax to create the base of the DVD, it then repackages it
without using the templates. These changes may cause problems for that
workflow, an issue has been filed with Pungi for this.

== Contingency Plan ==

* Contingency mechanism: I will revert the changes to the templates
and return to syslinux.
* Contingency deadline: Beta Freeze
* Blocks release? Yes

If the change does not work we can easily fall back to the previous
templates, as long as syslinux is still available.
Without syslinux, and without this change, we will have to remove BIOS
support from the boot.iso as implemented in
[https://github.com/weldr/lorax/pull/1205 this draft PR]

== Documentation ==
There will be documentation included in the Lorax PR.

== Release Notes ==



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

Copr PPC builders down?

[Steven A. Falco]

I have some jobs queued up on copr, and while the x86_64 builders are working fine, the ppc64le 
builders appear to be down.  "State" has remained "pending" for about an hour, 
so far.

Is this a planned outage?

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

Re: [HEADS UP] Fedora 37 Boost 1.78 rebuilds starting in a side tag

[Steven A. Falco]

Great!  Thanks for the info - and I'll add the syntax to my notes.

Steve

On 5/5/22 09:20 AM, Ben Beasley wrote:

As far as I can tell, only those packages with an install-time dependency on 
Boost, i.e., those that link a Boost shared library, are being rebuilt in the 
side tag. While KiCad does BuildRequire boost-devel, it looks like it needs 
only header-only libraries from Boost.

Since a lot of packages don’t need to link any of the shared-library parts of 
Boost, it won’t be surprising if a few FTBFS’s associated with this update are 
flushed out later by Koschei or in the F37 mass rebuild.

For reference, though, the syntax to build in a side tag is simply:

     fedpkg build --target=side-tag-name

and these work as well:

     fedpkg scratch-build --srpm --target=side-tag-name

     koji build --scratch side-tag-name foo.src.rpm

On 5/5/22 09:02, Steven A. Falco wrote:

On 5/5/22 05:41 AM, Miro Hrončok wrote:

On 05. 05. 22 11:39, Caolán McNamara wrote:

On Wed, 2022-05-04 at 23:44 +0200, Miro Hrončok wrote:

On 04. 05. 22 1:34, Thomas Rodgers wrote:

We are starting the rebuilds for
https://fedoraproject.org/wiki/Changes/F37Boost178
<https://fedoraproject.org/wiki/Changes/F35Boost176>  in the f37-
boost
side tag.

If your package depends on Boost, or just if you see a "Rebuilt for
Boost 1.78" commit pushed to your package's dist-git repo, please
co-ordinate with me about any updates to the
package. If you need to push other changes to rawhide then you will
need to build in the side tag, or we'll have to rebuild it multiple
times.

I hope we'll merge the side tag back to rawhide on Friday.


I had updated and built KiCad just slightly before your notice came out [1].  
It was built with boost 1.76.

Do you need me to rebuild it in the side-tag?  If so, please let me know the 
command syntax as I haven't had to build in a side-tag before.

Thanks,
Steve

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1961329
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Fedora 37 Boost 1.78 rebuilds starting in a side tag

[Steven A. Falco]

On 5/5/22 05:41 AM, Miro Hrončok wrote:

On 05. 05. 22 11:39, Caolán McNamara wrote:

On Wed, 2022-05-04 at 23:44 +0200, Miro Hrončok wrote:

On 04. 05. 22 1:34, Thomas Rodgers wrote:

We are starting the rebuilds for
https://fedoraproject.org/wiki/Changes/F37Boost178
  in the f37-
boost
side tag.

If your package depends on Boost, or just if you see a "Rebuilt for
Boost 1.78" commit pushed to your package's dist-git repo, please
co-ordinate with me about any updates to the
package. If you need to push other changes to rawhide then you will
need to build in the side tag, or we'll have to rebuild it multiple
times.

I hope we'll merge the side tag back to rawhide on Friday.


I had updated and built KiCad just slightly before your notice came out [1].  
It was built with boost 1.76.

Do you need me to rebuild it in the side-tag?  If so, please let me know the 
command syntax as I haven't had to build in a side-tag before.

Thanks,
Steve

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1961329
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: FESCo wants to know what you use i686 packages for

[Steven A. Falco]

On 3/20/22 04:38 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Mar 18, 2022 at 12:30:52AM -, Steven Ellis wrote:

The issue on our home systems is 3rd party printer drivers.

Eg
mfc9140cdncupswrapper-1.1.4-0.i386
dcpj4120dwlpr-3.0.1-1.i386
dcpj4120dwcupswrapper-3.0.1-1.i386
mfc9140cdnlpr-1.1.2-1.i386


Could you show 'rpm -qR mfc9140cdncupswrapper-1.1.4-0.i386 
dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 
mfc9140cdnlpr-1.1.2-1.i386' ?


On my system, for dcpl2540dwcupswrapper-3.2.0-1.i386 and 
dcpl2540dwlpr-3.2.0-1.i386, I get:

# rpm -qR dcpl2540dwcupswrapper-3.2.0-1.i386 dcpl2540dwlpr-3.2.0-1.i38
/bin/sh
/bin/sh
/bin/sh
/usr/bin/perl
cups
dcpl2540dwlpr
perl
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/usr/bin/perl
ghostscript
perl
perl(Cwd)
perl(File::Copy)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

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

Re: FESCo wants to know what you use i686 packages for

[Steven A. Falco]

On 3/16/22 09:57 AM, Felix Schwarz wrote:


I use wine and lutris (+ 32bit mingw packages).


wine is also the big one for me.  On my system, roughly 1000 executables (exe 
and dll) are PE32 (32 bit), and another 1000 executables are PE32+ (64 bit).

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

Re: Problem with cmake 3.23.0

[Steven A. Falco]

On 3/4/22 10:17 AM, Sérgio Basto wrote:

On Fri, 2022-03-04 at 16:04 +0100, Michal Schorm wrote:

On Fri, Mar 4, 2022 at 3:40 PM Sérgio Basto  wrote:

The fix is just remove "\  ." (the dot) on %cmake


That isn't a fix, that's a workaround for a broken CMake - atleast
that I believe, as you can read in that BZ.
I haven't found anything on CMake upstream that would suggest such
change is needed, I found the contrary.




And even if this change would be actually intended, it would be nice
from the CMake maintainer to announce it.



I think you missed the
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
(Targeted release: Fedora 33 ) and
https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/


My deduction also came from here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IGQFBIEBMFHIAHY45SKF5MXOJP43TVQS/

i.e. the builds that still aren't completely out of the source (i.e.
have the dot), can have (new) problems, one solution is make the build
out of the source as recommended  on
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds


I removed the "." from the %cmake macros, and the build is progressing properly for 
rawhide.  I still have to make sure that deleting the "." doesn't break F34 through F36.

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

Problem with cmake 3.23.0

[Steven A. Falco]

There is a new FTBFS for KiCad [1].  I filed an issue with KiCad [2] and got a 
comment from the project leader:

This looks like cmake issue to me. For some reason cmake is creating an 
incorrect build folder:

-- Build files have been written to: /builddir/build/BUILD/kicad-6.0.2

so the build command:

+ /usr/bin/cmake --build redhat-linux-build -j6 --verbose

cannot find the redhat-linux-build folder that was passed on the cmake 
command line.

In the last successful build, we have:

  -- Build files have been written to: 
/builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
  + /usr/bin/cmake --build redhat-linux-build -j6 --verbose

For some reason, the build file directory has changed:

Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
Failure case: /builddir/build/BUILD/kicad-6.0.2

Is this a bug in cmake or did something in RPM macros change?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781
[2] https://gitlab.com/kicad/code/kicad/-/issues/11043

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

Re: copr expired security certificate?

[Steven A. Falco]

On 3/2/22 04:35 PM, Scott Talbert wrote:

On Wed, 2 Mar 2022, Steven A. Falco wrote:


I just tried to connect to copr [1] with firefox, and got a "Did Not Connect: 
Potential Security Issue" error.

And apparently copr uses HSTS, so I cannot override it.  Is anyone else having 
the problem?

[1] https://copr.fedoraproject.org/coprs/g/kicad/kicad/build/3541862/


https://pagure.io/fedora-infrastructure/issue/10583

You can go to https://copr.fedorainfracloud.org/ as a workaround for the time 
being.


Thanks all - I appreciate the links.  The "bad" link I reported was from a 
notification email I got regarding a build failure. :-)

I'm glad an infra issue has already been filed, and I'll use the workaround 
mentioned.

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

copr expired security certificate?

[Steven A. Falco]

I just tried to connect to copr [1] with firefox, and got a "Did Not Connect: 
Potential Security Issue" error.

And apparently copr uses HSTS, so I cannot override it.  Is anyone else having 
the problem?

[1] https://copr.fedoraproject.org/coprs/g/kicad/kicad/build/3541862/

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

Re: CVE's and older versions of software

[Steven A. Falco]

On 2/17/22 09:58 AM, Ben Beasley wrote:

This is covered by the Updates Policy[1]. There is quite a bit written there 
about why an incompatible update might or might not be allowed in a stable 
release. It also specifically addresses security updates[2], and describes how 
you can petition FESCo for an exception, either for a particular update or as a 
blanket exception for your package.


[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions

[2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes



Thanks for the links.  I've opened an issue [1].

[1] https://pagure.io/fesco/issue/2762

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

Re: CVE's and older versions of software

[Steven A. Falco]

On 2/17/22 06:46 AM, Stephen Snow wrote:

On Wed, 2022-02-16 at 22:50 -0500, Demi Marie Obenour wrote:

On 2/16/22 18:05, Adam Williamson wrote:

On Wed, 2022-02-16 at 14:20 -0500, Steven A. Falco wrote:

On 2/16/22 01:58 PM, Dan Horák wrote:

On Wed, 16 Feb 2022 13:53:04 -0500
"Steven A. Falco"  wrote:


There are some CVE's against KiCad that have been fixed in
the latest version, namely KiCad 6.0.2.  I've built that for
F36 and Rawhide.

I have not released KiCad 6.0.2 into Fedora 34 and 35,
because my understanding is that by policy, we don't
generally allow "major version" updates in stable Fedora
releases.  Thus F34 and F35 still ship KiCad 5.1.12, which is
affected by the CVE's.

I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I
have done so in the KiCad Copr repository.

So, should this situation be an exception to the policy of
"no major version changes in a stable release"?


as often, it depends :-)

- what's the severity level of the CVEs?
- does KiCad 6 come with substantial changes like UI redesign,
compatibility issues with previous release, etc?


The vulnerability is rated as "7.8 -
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that
means. :-)

Basically, attempting to read a malicious file can cause a buffer
overflow, and then execute malicious code.

KiCad is not suid, so the risk would be to an individual user
rather than the whole system.


As shown in https://xkcd.com/1200/, this is not a mitigation in
practice, because most Linux systems are single-user, which means
that
a user compromise is effectively equivalent to root compromise


KiCad 6 does have UI changes and files it creates cannot be read
by KiCad 5 or earlier.

I contacted upstream, and I know what patches form a part of the
solution, but they don't apply cleanly to KiCad 5.  I might be
able to sort them out...


The 'ideal' solution is to backport the security fix, yes. If
you're
not able to do this, or find anyone else who can do it for you, I
guess
it kinda becomes a judgment call whether fixing the security issue
is
"worth" the compatibility problems. I don't think we have a
definite
guide/policy to what to do if the optimal solution isn't practical,
here?


Security researcher here.  My view is that there are some packages
for
which the release cycle needs to be that of upstream, even if Fedora
has a different one.  Browser engines and the Linux kernel certainly
fall into that category, and complex desktop software such as KiCad
might as well.  I would rather take the compatibility breakage a bit
early than have an insecure system.


Fedora Linux user here +1 on these comments by Demi


That is a good point.  KiCad now plans to have annual major version bumps - 
these will naturally not coincide with Fedora releases.  Thus I expect that 
Fedora will often have unsupported versions of KiCad for long periods of time, 
going forward.

Is approval from FESCO or other group needed to permit major version bumps in a 
stable Fedora release?

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

Re: CVE's and older versions of software

[Steven A. Falco]

On 2/16/22 01:58 PM, Dan Horák wrote:

On Wed, 16 Feb 2022 13:53:04 -0500
"Steven A. Falco"  wrote:


There are some CVE's against KiCad that have been fixed in the latest version, 
namely KiCad 6.0.2.  I've built that for F36 and Rawhide.

I have not released KiCad 6.0.2 into Fedora 34 and 35, because my understanding is that 
by policy, we don't generally allow "major version" updates in stable Fedora 
releases.  Thus F34 and F35 still ship KiCad 5.1.12, which is affected by the CVE's.

I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I have done so in the 
KiCad Copr repository.

So, should this situation be an exception to the policy of "no major version changes 
in a stable release"?


as often, it depends :-)

- what's the severity level of the CVEs?
- does KiCad 6 come with substantial changes like UI redesign,
compatibility issues with previous release, etc?


The vulnerability is rated as "7.8 - 
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that means. :-)

Basically, attempting to read a malicious file can cause a buffer overflow, and 
then execute malicious code.

KiCad is not suid, so the risk would be to an individual user rather than the 
whole system.

KiCad 6 does have UI changes and files it creates cannot be read by KiCad 5 or 
earlier.

I contacted upstream, and I know what patches form a part of the solution, but 
they don't apply cleanly to KiCad 5.  I might be able to sort them out...

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

CVE's and older versions of software

[Steven A. Falco]

There are some CVE's against KiCad that have been fixed in the latest version, 
namely KiCad 6.0.2.  I've built that for F36 and Rawhide.

I have not released KiCad 6.0.2 into Fedora 34 and 35, because my understanding is that 
by policy, we don't generally allow "major version" updates in stable Fedora 
releases.  Thus F34 and F35 still ship KiCad 5.1.12, which is affected by the CVE's.

I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I have done so in the 
KiCad Copr repository.

So, should this situation be an exception to the policy of "no major version changes 
in a stable release"?

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

Re: Problems building on F36, F37 caused by vtk?

[Steven A. Falco]

On 2/12/22 11:54 AM, Steven A. Falco wrote:

I'm still having problems building - vtk-9.1.0-6.fc36 is present in the x86_64 
chroot on copr, but it is not present in the ppc64le chroot as shown in the 
failure in [0].

Is there any way to tell why the ppc64le chroot hasn't picked up 
vtk-9.1.0-6.fc36?  It looks like the build of vtk succeeded [1], and it looks 
like the compose of F36 succeeded [2].

 Steve

[0] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/3476205/
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1915642
[2] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220212.n.0/


Alright - it is getting even more strange.  On another (later) copr run [3], we 
have the fedora-36-x86_64 chroot failing because it got 
vtk-9.1.0-5.fc36.x86_64, while the fedora-36-ppc64le chroot managed to get 
vtk-9.1.0-6.fc36.ppc64le.  That is exactly backwards from what happened on the 
earlier copr run described above.

So while this is just a guess on my part, it is looking like copr is picking 
different mirrors at different times, and it is random as to whether one will 
get the -5 or -6 version of vtk.

Is it just a question of waiting a day or two, or is something really wrong 
here?

Steve

[3] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/3476752/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Problems building on F36, F37 caused by vtk?

[Steven A. Falco]

I'm still having problems building - vtk-9.1.0-6.fc36 is present in the x86_64 
chroot on copr, but it is not present in the ppc64le chroot as shown in the 
failure in [0].

Is there any way to tell why the ppc64le chroot hasn't picked up 
vtk-9.1.0-6.fc36?  It looks like the build of vtk succeeded [1], and it looks 
like the compose of F36 succeeded [2].

Steve

[0] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/3476205/
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1915642
[2] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220212.n.0/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Problems building on F36, F37 caused by vtk?

[Steven A. Falco]

On 2/10/22 02:21 PM, Michael Catanzaro wrote:

On Thu, Feb 10 2022 at 02:09:32 PM -0500, Steven A. Falco 
 wrote:

g++: fatal error: Killed signal terminated program cc1plus


This indicates the builder ran out of memory. cc1plus received SIGKILL from the 
OOM killer. Try using the %limit_build macro to reduce parallelism, and file an 
infrastructure ticket if that's not enough. Example of using %limit_build:

https://src.fedoraproject.org/rpms/webkit2gtk3/blob/rawhide/f/webkit2gtk3.spec#_223


Thanks, Michael.  Copying Orion to be sure he is in the loop - I am not a 
packager for vtk.

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

Re: Problems building on F36, F37 caused by vtk?

[Steven A. Falco]

On 2/10/22 01:49 PM, Ben Beasley wrote:

There was an missed/unannounced .so version bump in glew[1] which affected a 
lot of packages, including vtk.

It looks like vtk builds for F36-F37 are currently in progress.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DLZLYNVJOMAACLAKW4OF63ZHFVFQ3GV5/


Fair enough, but the failure of 
https://koji.fedoraproject.org/koji/taskinfo?taskID=82622658 is concerning.  
I'd expect that to require another attempt to build vtk.

I'm not sure what happened to that vtk build, but the build.log on that page 
has:

g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
gmake[2]: Leaving directory '/builddir/build/BUILD/VTK-9.1.0/build'
gmake[2]: *** 
[Rendering/OpenGL2/Testing/Cxx/CMakeFiles/vtkRenderingOpenGL2CxxTests.dir/build.make:289:
 
Rendering/OpenGL2/Testing/Cxx/CMakeFiles/vtkRenderingOpenGL2CxxTests.dir/TestCompositePolyDataMapper2Pickability.cxx.o]
 Error 1

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

Problems building on F36, F37 caused by vtk?

[Steven A. Falco]

I now have two "Fails to install" bugs: 
https://bugzilla.redhat.com/show_bug.cgi?id=2053075 and 
https://bugzilla.redhat.com/show_bug.cgi?id=2053054.

These appear to be due to a chain of unmet dependencies as shown in the mock 
log:

Error:
 Problem: package opencascade-devel-7.5.0-6.fc36.x86_64 requires 
opencascade-draw(x86-64) = 7.5.0-6.fc36, but none of the providers can be 
installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkCommonCore.so.1()(64bit), but none of the providers can be installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkCommonExecutionModel.so.1()(64bit), but none of the providers can be 
installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkRenderingCore.so.1()(64bit), but none of the providers can be installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkInteractionStyle.so.1()(64bit), but none of the providers can be installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkRenderingOpenGL2.so.1()(64bit), but none of the providers can be installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkIOImage.so.1()(64bit), but none of the providers can be installed
  - package opencascade-draw-7.5.0-6.fc36.x86_64 requires 
libvtkImagingCore.so.1()(64bit), but none of the providers can be installed
  - conflicting requests
  - nothing provides libGLEW.so.2.1()(64bit) needed by vtk-9.1.0-5.fc36.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

I don't think there is anything I can do, other than wait for all the pieces to 
be rebuilt.  But I am a little concerned that one of the vtk rebuilds is 
showing a failure: https://koji.fedoraproject.org/koji/taskinfo?taskID=82622658.

The point of this email is simply to alert folks of the problem - I'm not sure 
how many packages are affected or whether anything should be untagged or moved 
to a side-tag.

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

Re: mock, %{buildroot}, fc35

[Steven A. Falco]

On 2/2/22 10:07 AM, Alain Vigne wrote:

Can someone explain to me why my  .srpm  [1]
is not building in mock ?

I ran
 > mock filename.srpm

Will it work in COPR, Koji ?

[1] https://avigne.fedorapeople.org/libfungw-1.2.0-1.fc35.src.rpm 

TIA


You say it didn't build.  What error messages did you get when you ran the mock 
command?

You may already know this, but if you are a new mock user, you have to add 
yourself to the 'mock' group.  If you run the 'id' command, it should tell you 
what groups you are in, and 'mock' has to be one of the ones the 'id' command 
lists.

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

Re: Fwd: conditional require (RPM dependency solving puzzle)

[Steven A. Falco]

On 2/2/22 05:19 AM, Miro Hrončok wrote:

On 01. 02. 22 19:45, przemek klosowski wrote:


On 2/1/22 12:54, Miro Hrončok wrote:

Thanks to Steven, Stephen and Miro for finding this solution. Still, having to 
add flags and deleting the existing doc package is not completely 
gruntling---it works, but it's not automatic and, for the future, I am curious 
if there's another way.

Sorry for flogging this fine stallion, but I believe that 'dnf update kicad 
kicad-doc' would have worked (I did check that updating kicad-doc followed by 
updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages instead 
of deleting kicad-doc?


This should work without --allowerasing once the packages are actually in a repository. "dnf update kicad" will see the newer version of kicad-doc and it will update both at the same time. 

This is after enabling Steven's COPR 
copr:copr.fedorainfracloud.org:group_kicad:kicad , which contains kicad, 
kicad-doc and kicad-packages3d. Are you saying that it would make a difference 
when they are in the main Fedora - Updates repo?


Nah, having the copr enabled should solve this:

$ mock -r fedora-rawhide-x86_64 init
$ mock -r fedora-rawhide-x86_64 install kicad kicad-doc
$ mock -r fedora-rawhide-x86_64 
--addrepo='https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-rawhide-$basearch/'
 --update kicad
...
Dependencies resolved.

  Package   Arch   Version    Repository    Size

Upgrading:
  kicad x86_64 1:6.0.1-4.fc36 
downloadcoprfedorainfracloudorg_results_kicad_kicad_fedorarawhidebasearch_
    72 M
  kicad-doc noarch 1:6.0.1-4.fc36 
downloadcoprfedorainfracloudorg_results_kicad_kicad_fedorarawhidebasearch_
   128 M

Transaction Summary

Upgrade  2 Packages
...


Thanks for running that test, Miro.

The -4 builds finished around 2:13 UTC, so everything in Copr now has the fix, 
and once we get a successful rawhide compose, they will land in the Rawhide 
Updates repo too.

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