Re: Serial port sniffing?

[Steven A. Falco]

On 7/19/20 5:23 PM, Richard Shaw wrote:

I would like to monitor serial port communications read only, but I haven't 
found a tool that makes that easy in the Fedora repos.


I've done that with "socat" to monitor communications with an APC UPS.  Here is 
my recipe:

socat /dev/ttyU3412A,raw,echo=0 \
SYSTEM:'tee in.txt |socat - "PTY,link=/tmp/ttyV0,raw,echo=0,waitslave" |tee 
out.txt'

In the above, ttyU3412A is the physical serial port.  ttyV0 is created by 
socat, and that is what you connect to.  All traffic gets logged to the two 
.txt files.

Please note that this is one long command line.  The SYSTEM thing is an 
argument to the first socat.

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

ckermit?

[Steven A. Falco]

There was a failed build of ckermit for F32 back in early February by releng 
[1], and I don't see any later attempts for F32.  There is a successful build 
for ckermit for F33 from yesterday [2].

I'd like to request a rebuild for F32.  Is it sufficient to request that here, 
or is there some other procedure that I should use?

Also, I use ckermit daily as a terminal emulator, so if a co-maintainer is 
wanted, I'd be happy to volunteer - FAS ID stevenfalco.

Steve

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1434605
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1498879
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ckermit?

[Steven A. Falco]

On 4/29/20 4:12 AM, Florian Weimer wrote:

* Steven A. Falco:


I'd like to request a rebuild for F32.  Is it sufficient to request
that here, or is there some other procedure that I should use?


I've merged the F33 change (dropping termcap-devel) and kicked off a new
build.  Please test the update and provide karma
<https://bodhi.fedoraproject.org/updates/FEDORA-2020-484e5f8673>,
so that it can ship to users.


Thanks for building it so quickly!  I've tested it and given it +1 karma.

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

Re: Intent to retire OCE (OpenCascade Community Edition)

[Steven A. Falco]

On 11/15/19 4:58 PM, Ian McInerney wrote:
> A repoquery for build-requires on the OCE-devel package only gives these 4 
> packages:
> gmsh-0:4.4.1-3.fc32.src
> kicad-1:5.1.4-5.fc32.src
> netgen-mesher-0:6.2.1810-4.fc32.src
> smesh-0:6.7.5-7.fc31.src
> 
> I know that switching KiCad to use opencascade instead should be simple (just 
> switch a CMake flag), but I am not sure about the other 2 listed there.

I'm doing a trial build of KiCad now, with OCC.  I had to explicitly turn 
KICAD_USE_OCE=OFF and turn KICAD_USE_OCC=ON.  The CMakeLists.txt file makes it 
look like it would be sufficient just to turn OCC on (around line 472), but 
that doesn't work for some reason.

Naturally, I also had to replace "BuildRequires:  OCE-devel" with 
"BuildRequires:  opencascade-devel".

Steve

> 
> -Ian
> 
> On Fri, Nov 15, 2019 at 9:33 PM Richard Shaw  > wrote:
> 
> It has a lot of libraries so I haven't tried figuring out what all 
> packages are affected but since OCC (OpenCASCADE) went GPL OCE has not been 
> updated and appears to be no longer maintained.
> 
> I have moved FreeCAD over to my new "opencascade" package and am working 
> on moving netgen-mesher over. Once complete, unless there's a good reason to 
> keep it, I plan to retire it in Rawhide.
> 
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intent to retire OCE (OpenCascade Community Edition)

[Steven A. Falco]

On 11/15/19 4:58 PM, Ian McInerney wrote:
> A repoquery for build-requires on the OCE-devel package only gives these 4 
> packages:
> gmsh-0:4.4.1-3.fc32.src
> kicad-1:5.1.4-5.fc32.src
> netgen-mesher-0:6.2.1810-4.fc32.src
> smesh-0:6.7.5-7.fc31.src
> 
> I know that switching KiCad to use opencascade instead should be simple (just 
> switch a CMake flag), but I am not sure about the other 2 listed there.

I'm doing a trial build of KiCad now, with OCC.  I had to explicitly turn 
KICAD_USE_OCE=OFF and turn KICAD_USE_OCC=ON.  The CMakeLists.txt file makes it 
look like it would be sufficient just to turn OCC on (around line 472), but 
that doesn't work for some reason.

Naturally, I also had to replace "BuildRequires:  OCE-devel" with 
"BuildRequires:  opencascade-devel".

Steve

> 
> -Ian
> 
> On Fri, Nov 15, 2019 at 9:33 PM Richard Shaw  > wrote:
> 
> It has a lot of libraries so I haven't tried figuring out what all 
> packages are affected but since OCC (OpenCASCADE) went GPL OCE has not been 
> updated and appears to be no longer maintained.
> 
> I have moved FreeCAD over to my new "opencascade" package and am working 
> on moving netgen-mesher over. Once complete, unless there's a good reason to 
> keep it, I plan to retire it in Rawhide.
> 
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intent to retire OCE (OpenCascade Community Edition)

[Steven A. Falco]

On 11/16/19 11:24 AM, Steven A. Falco wrote:
> On 11/15/19 4:58 PM, Ian McInerney wrote:
>> A repoquery for build-requires on the OCE-devel package only gives these 4 
>> packages:
>> gmsh-0:4.4.1-3.fc32.src
>> kicad-1:5.1.4-5.fc32.src
>> netgen-mesher-0:6.2.1810-4.fc32.src
>> smesh-0:6.7.5-7.fc31.src
>>
>> I know that switching KiCad to use opencascade instead should be simple 
>> (just switch a CMake flag), but I am not sure about the other 2 listed there.
> 
> I'm doing a trial build of KiCad now, with OCC.  I had to explicitly turn 
> KICAD_USE_OCE=OFF and turn KICAD_USE_OCC=ON.  The CMakeLists.txt file makes 
> it look like it would be sufficient just to turn OCC on (around line 472), 
> but that doesn't work for some reason.
> 
> Naturally, I also had to replace "BuildRequires:  OCE-devel" with 
> "BuildRequires:  opencascade-devel".
> 
>   Steve

The Rawhide (F32) build of KiCad now uses opencascade-devel in place of 
OCE-devel.

https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0c951d584

Steve

> 
>>
>> -Ian
>>
>> On Fri, Nov 15, 2019 at 9:33 PM Richard Shaw > <mailto:hobbes1...@gmail.com>> wrote:
>>
>> It has a lot of libraries so I haven't tried figuring out what all 
>> packages are affected but since OCC (OpenCASCADE) went GPL OCE has not been 
>> updated and appears to be no longer maintained.
>>
>> I have moved FreeCAD over to my new "opencascade" package and am working 
>> on moving netgen-mesher over. Once complete, unless there's a good reason to 
>> keep it, I plan to retire it in Rawhide.
>>
>> Thanks,
>> Richard
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org 
>> <mailto:devel@lists.fedoraproject.org>
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
>> <mailto:devel-le...@lists.fedoraproject.org>
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Question about mass rebuilds

[Steven A. Falco]

I have a general question about mass rebuilds - I noticed that my F31 machine 
still has a few packages that appear to be fc30 versions, and I got curious as 
to why.

For example, I have avr-libc-2.0.0-7.fc30.noarch installed.  It has a build 
date of Thu 31 Jan 2019 09:23:34 AM EST

I looked at the list of packages needing a rebuild for F31.  As of the run on 
2019-08-20 20:46:01.547095 UTC, avr-libc was listed: 
https://kojipkgs.fedoraproject.org/mass-rebuild/f31-need-rebuild.html

Yet according to koji, there is no build for fc31: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=avr-libc

I'm not saying that anything is wrong - I'm just curious as to why the package 
wasn't rebuilt.  Any guidance/info would be appreciated.

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

Re: Vim and spec template

[Steven A. Falco]

On 7/18/19 7:44 AM, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
> 
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
> 
> Recently I found out someone can find it as bad behavior
> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
> changing the default vimrc to tell Vim 'Don't do it'.
> 
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?

I've never had a problem with it, but then I only edit rpm spec files.

If you were to remove it from /etc/vimrc, would the normal syntax system still 
provide a good way to edit rpm spec files?

Steve




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Steven A. Falco]

On 7/18/19 10:28 AM, Zdenek Dohnal wrote:
> 
> On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
>> Hello, Zdenek Dohnal.
>>
>> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>>
>>> Even the new .spec files, which do not have to be RPM spec files?
>>> Because Vim provides spec template for such cases.
>> I never used this feature, so I think it can be disabled by default.
> That's the thing which I asked for opinion on, not about syntax
> highlighting.

Ah - now I understand.  I thought you were asking about syntax highlighting.

I had never noticed the feature of creating a new spec file from a template, 
because I have my own .vimrc file, so the /etc/vimrc file has no effect for me.

I think having a template for just this single file type is kind of "strange".  
I'd personally be fine with removing that line from /etc/vimrc.  I'd expect 
users who want templates to set them up for themselves, rather than forcing 
users to disable templates they don't want.

Steve




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS from 
the Fedora package, as described here: 
https://bugs.launchpad.net/kicad/+bug/1838448

What is the best way to do that?  I can add "%undefine _hardened_build" (which 
I am testing now) but I think that will remove other hardening features that I 
might want to leave enabled.

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 11:09 AM, Tom Hughes wrote:
> On 01/08/2019 19:28, Steven A. Falco wrote:
>> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS 
>> from the Fedora package, as described here: 
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>> What is the best way to do that?  I can add "%undefine _hardened_build" 
>> (which I am testing now) but I think that will remove other hardening 
>> features that I might want to leave enabled.
> 
> Well you just need to add -U_GLIBCXX_ASSERTIONS to the end of the
> compiler flags.
> 
> But I think upstream is giving very bad advice...
> 
> That define does not "add extra crashes" in the way that they
> seem to think - well I mean it does literally but those crashes
> are reports of program errors on their part.
> 
> Specifically in this case they appear to be accessing a
> std::vector at an index beyond the end, so they are accessing
> memory that may not be allocated at all, and if it is does
> not belong to the vector in question. So the program is quite
> likely to crash there one day anyway, the extra assertion just
> makes sure it always does.

I agree that it sounds like bad advice, and I've raised that exact issue in 
comment #22 (https://bugs.launchpad.net/kicad/+bug/1838448/comments/22).  We'll 
see if I can convince upstream to rethink this.

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 11:39 AM, Florian Weimer wrote:
> * Steven A. Falco:
> 
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
>> https://bugs.launchpad.net/kicad/+bug/1838448
> 
> I commented on the bug.  I think removal of these security checks is not
> the right thing to do.
> 
> Thanks,
> Florian
> 

Thanks for doing that.  The more I think about it, the less I like removing the 
GLIBCXX_ASSERTIONS.

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

Untag a build?

[Steven A. Falco]

A bug was discovered in a pending KiCAD rawhide build, so I'd like to untag 
kicad-5.1.3-1.fc31 to keep it from going into rawhide.  Koji ID 1344019.

I've never done that before, but I tried doing "koji untag-build 
f31-updates-pending kicad-5.1.3-1.fc31", which gave me an error:

koji: ActionNotAllowed: tag requires admin permission

Is that the correct command, and if so, is there a way for me to get suitable 
permissions, or can someone with permissions do it?

I'd also like to untag kicad-5.1.3-1.fc30 from f30-updates-candidate.  I 
"unpushed" it in bohdi, but I'm not sure if that is sufficient to kill it.  
Koji ID 1344020.

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 1:13 PM, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here: 
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>> What is the best way to do that?  I can add "%undefine
>> _hardened_build" (which I am testing now) but I think that will remove
>> other hardening features that I might want to leave enabled.
>>
>>  Steve
> 
> Simply add this to your spec file:
> 
> # Upstream recommends to turn off _GLIBCXX_ASSERTIONS.
> # See: $UPSTREAM_BUG
> %global optflags %optflags -U_GLIBCXX_ASSERTIONS

Thanks for all the replies!  I will resist turning off the glibcxx assertions - 
I am convinced now that it would be a bad idea.

But at least now I know how to do that sort of thing, if I ever do need to 
modify the default flags in the future.

Steve



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages to be retired (~400 during this week)

[Steven A. Falco]

On 9/9/19 6:06 PM, Elliott Sales de Andrade wrote:
> On Mon, 9 Sep 2019 at 18:02, David Sommerseth  wrote:
>>
>> On 09/09/2019 23:49, Miro Hrončok wrote:
>>> The following packages are orphaned and will be retired when they
>>> are orphaned for six weeks, unless someone adopts them. If you know for sure
>>> that the package should be retired, please do so now with a proper reason:
>>> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>>
>> [...snip...]
>>
>>> dsommers: python-which
>>
>> This surprises me quite a lot.  I have never been a package maintainer for
>> this package.
>>
> 
> It's not saying you're a package maintainer for this package. It's
> saying you'll be affected by its orphaning.
> 
> Search for python-which and you'll see it's because python-ethtool
> depends on it, and you maintain _that_.

I too am apparently affected by python-which.  But I'm not sure how to 
determine why.  I maintain kicad and bvi.  Neither directly requires 
python-which, as far as I can see:

saf# dnf repoquery --requires kicad | grep python
Last metadata expiration check: 0:00:29 ago on Tue 10 Sep 2019 09:33:45 AM EDT.
libpython3.7m.so.1.0
libpython3.7m.so.1.0()(64bit)
python(abi) = 3.7
python3-wxpython4
saf#

saf# dnf repoquery --requires bvi | grep python
Last metadata expiration check: 0:00:39 ago on Tue 10 Sep 2019 09:33:45 AM EDT.
saf#

How do I determine why I am affected?

Steve  (FAS ID 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

Re: Orphaned packages to be retired (~400 during this week)

[Steven A. Falco]

Excellent.  Thanks for the help.

Steve

On 9/10/19 9:47 AM, Anne Mulhern wrote:
> Look at the full report:
> https://churchyard.fedorapeople.org/orphans-2019-09-09.txt
> 
> kicad uses asciidoc, which depends on python-which.
> 
> - mulhern
> 
> 
> 
> - Original Message -
>> From: "Steven A. Falco" 
>> To: devel@lists.fedoraproject.org
>> Sent: Tuesday, September 10, 2019 9:39:17 AM
>> Subject: Re: Orphaned packages to be retired (~400 during this week)
>>
>> On 9/9/19 6:06 PM, Elliott Sales de Andrade wrote:
>>> On Mon, 9 Sep 2019 at 18:02, David Sommerseth  wrote:
>>>>
>>>> On 09/09/2019 23:49, Miro Hrončok wrote:
>>>>> The following packages are orphaned and will be retired when they
>>>>> are orphaned for six weeks, unless someone adopts them. If you know for
>>>>> sure
>>>>> that the package should be retired, please do so now with a proper
>>>>> reason:
>>>>> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>>>>
>>>> [...snip...]
>>>>
>>>>> dsommers: python-which
>>>>
>>>> This surprises me quite a lot.  I have never been a package maintainer for
>>>> this package.
>>>>
>>>
>>> It's not saying you're a package maintainer for this package. It's
>>> saying you'll be affected by its orphaning.
>>>
>>> Search for python-which and you'll see it's because python-ethtool
>>> depends on it, and you maintain _that_.
>>
>> I too am apparently affected by python-which.  But I'm not sure how to
>> determine why.  I maintain kicad and bvi.  Neither directly requires
>> python-which, as far as I can see:
>>
>> saf# dnf repoquery --requires kicad | grep python
>> Last metadata expiration check: 0:00:29 ago on Tue 10 Sep 2019 09:33:45 AM
>> EDT.
>> libpython3.7m.so.1.0
>> libpython3.7m.so.1.0()(64bit)
>> python(abi) = 3.7
>> python3-wxpython4
>> saf#
>>
>> saf# dnf repoquery --requires bvi | grep python
>> Last metadata expiration check: 0:00:39 ago on Tue 10 Sep 2019 09:33:45 AM
>> EDT.
>> saf#
>>
>> How do I determine why I am affected?
>>
>>  Steve  (FAS ID 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
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F30 to F31

[Steven A. Falco]

On 9/11/19 8:54 AM, Miroslav Suchý wrote:
> Do you want to make Fedora 31 better? Please spend 1 minute of your time and 
> try to run [*]:
> 
>   sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 
> --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the actual upgrade.
> 
> But very likely you get some dependency problem now. In that case, please 
> report it against the appropriate package. Or
> against fedora-obsolete-packages if that package should be removed in Fedora 
> 31. Please check existing reports first:
> https://red.ht/2kuBDPu
> 
> Thank you
> 
> [*] this command does not replace `dnf system-upgrade`, but it will reveal 
> potential problems. You may also run `dnf
> upgrade` before running this command.
> 

Below are the three problems that I get.  There are already bugs filed against 
chirp for python2, but I didn't see any relating to PyQwt or crypto-utils.  
Should I create new bugs for them?

Steve

Error: 
 Problem 1: package PyQwt-devel-5.2.0-42.fc30.x86_64 requires PyQwt(x86-64) = 
5.2.0-42.fc30, but none of the providers can be installed
  - PyQwt-5.2.0-42.fc30.x86_64 does not belong to a distupgrade repository
  - problem with installed package PyQwt-devel-5.2.0-42.fc30.x86_64
 Problem 2: package crypto-utils-2.5-4.fc29.x86_64 requires 
libperl.so.5.28()(64bit), but none of the providers can be installed
  - package crypto-utils-2.5-4.fc29.x86_64 requires 
perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed
  - perl-libs-4:5.28.2-438.fc30.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package crypto-utils-2.5-4.fc29.x86_64
 Problem 3: package chirp-20190812-1.fc31.noarch requires python2dist(future), 
but none of the providers can be installed
  - problem with installed package chirp-20190812-1.fc30.noarch
  - python2-future-0.17.0-2.fc30.noarch does not belong to a distupgrade 
repository
  - chirp-20190812-1.fc30.noarch 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

Re: Defining the future of the packager workflow in Fedora

[Steven A. Falco]

On 9/26/19 11:14 AM, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline  wrote:
>>
>> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
>>> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
>>>  wrote:

 On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> Instead I prefer a clone of the master upstream git repo and maintain a
> branch with patches cherry-picked into it. This is used to auto-generate
> patches for the Fedora RPM, at the same time updating the patch file list
> in the RPM spec. The only manual step is adding the changelog entry &
> bumping release number.

 Quick note: this is essentially what debian does.
>>>
>>> Ugh. Can we please just agree that source-git (vs. dist-git) is almost
>>> always a bad idea?
>>>
>>
>> Can you expand on that? To me it is a much easier way to maintain
>> packages, but I don't have tons of experience doing that and I'm
>> perhaps not the "average package maintainer". Hearing other perspectives
>> would be helpful.
> 
> Sorry, I should have expanded on that short statement.
> 
> I literally maintain hundreds of packages, mostly by myself (yes,
> that's too many, but that's a problem that tooling can't fix).
> I'd hazard to guess that 90% of these packages don't contain *any*
> patches on top of an upstream release. So pointing the .spec file to
> an upstream tarball is the *absolute easiest thing* possible, and I
> don't want to have to deal with the upstream git repo contents for
> these packages at all.
> For another 9% of packages, I maintain a small set of local patches
> (up to two patches or so), which I can "generate on the fly" for every
> new upstream release (if necessary), and which is only a small amount
> of work.
> For the remaining 1% (about 2-3 of my packages), I maintain a local
> git repository with branches for every release, where I maintain a
> small downstream patch-set. This seems to correspond to a source-git
> approach, and might be similar to what you're doing.
> 
> So, to summarize: I just don't want the absolute edge case to become
> the general case. It would make things *massively* more complicated
> for me, and I guess that applies to the "average packager" in fedora,
> as well.
> 
> Fabio

KiCAD is the main project I help maintain.  It consists of seven separate 
upstream repositories.  One is on launchpad; the rest are on github.  I would 
not want to have to mirror them all into Fedora.  The tarball / dist-git 
approach works very well for this project.

Steve

> 
 If you want to go this way, I hope we can avoid the need to generate
 a "pristine" tarball and patches. Instead, the contents of the repo should
 be directly used for a build. A tarball can be created, but this tarball
 would always be the tip of the tree containing both the sources and
 the packaging.

 Zbyszek
 ___
 devel mailing list -- devel@lists.fedoraproject.org
 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
 Fedora Code of Conduct: 
 https://docs.fedoraproject.org/en-US/project/code-of-conduct/
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives: 
 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: htt

Re: mock log output has DOS line endings?

[Steven A. Falco]

On 1/30/20 9:19 AM, Richard Shaw wrote:

Am I the only one having this problem? I don't know exactly when it started but 
all of a sudden all of the log output has DOS line endings and it's very 
annoying. I have to run dox2unix on the logs to make them readable.


I am seeing that too, and you are right - it is very annoying.

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

Getting an error on rawhide importing wx

[Steven A. Falco]

There appears to be something wrong with python wx:

rawhide# python
Python 3.8.1 (default, Jan 30 2020, 00:00:00)
[GCC 10.0.1 20200126 (Red Hat 10.0.1-0.6)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import wx

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 17, in 
from wx.core import *
  File "/usr/lib64/python3.8/site-packages/wx/core.py", line 12, in 
from ._core import *
ImportError: 
/usr/lib64/python3.8/site-packages/wx/_core.cpython-38-x86_64-linux-gnu.so: 
undefined symbol: 
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version 
WXU_3.0

Should I write a bug for this or am I doing something wrong?

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

Re: Getting an error on rawhide importing wx

[Steven A. Falco]

On 2/10/20 1:26 PM, Miro Hrončok wrote:

On 10. 02. 20 17:56, Steven A. Falco wrote:

There appears to be something wrong with python wx:

rawhide# python
Python 3.8.1 (default, Jan 30 2020, 00:00:00)
[GCC 10.0.1 20200126 (Red Hat 10.0.1-0.6)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import wx

Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 17, in 

 from wx.core import *
   File "/usr/lib64/python3.8/site-packages/wx/core.py", line 12, in 
 from ._core import *
ImportError: 
/usr/lib64/python3.8/site-packages/wx/_core.cpython-38-x86_64-linux-gnu.so: 
undefined symbol: 
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version 
WXU_3.0

Should I write a bug for this or am I doing something wrong?


We have encountered the same problem when rebuilding stuff against Python 3.9:

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


Thanks.  I added a comment to that bug.  I found that by rebuilding python3 and 
python-wxpython4 I could then import wx without error.

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

New guy - with a question

[Steven A. Falco]

I'm new to this list, but I have been building packages for KiCad for a little 
while now.  I have a question about rawhide; is it in a freeze right now?

The reason I ask is that I built kicad-5.1.0-0.1.rc2.fc31 on koji back on March 
2, but I don't see it (or any other fc31) packages on dl.fedoraproject.org in 
the rawhide area.  I'm sure this is perfectly normal, but I don't know what to 
expect.

If someone could please educate me or point me to documentation on how this 
works, I'd appreciate it.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New guy - with a question

[Steven A. Falco]

On 3/6/19 12:25 PM, Adam Williamson wrote:
> On Wed, 2019-03-06 at 18:13 +0100, Miro Hrončok wrote:
>> On 06. 03. 19 18:01, Steven A. Falco wrote:
>>> I'm new to this list, but I have been building packages for KiCad for a 
>>> little while now.  I have a question about rawhide; is it in a freeze right 
>>> now?
>>>
>>> The reason I ask is that I built kicad-5.1.0-0.1.rc2.fc31 on koji back on 
>>> March 2, but I don't see it (or any other fc31) packages on 
>>> dl.fedoraproject.org in the rawhide area.  I'm sure this is perfectly 
>>> normal, but I don't know what to expect.
>>>
>>> If someone could please educate me or point me to documentation on how this 
>>> works, I'd appreciate it.
>>
>> Hey. I don't know if this is documented or just tribal knowledge, but there 
>> is 
>> this process called a "compose" - it composes the images and repositories 
>> from 
>> packages in Koji.
> 
> https://fedoraproject.org/wiki/Releases/Rawhide
> 
> "Each day (or sometimes more than once per day) , a full 'compose' of
> the tree is attempted. This will usually result in the creation of all
> or most of the usual install, live and disk images, installer trees and
> so forth. The composes are synced to the /fedora/linux/development/
> directory on the mirrors, and you can find the images there."
> 
> Later on there's the section
> https://fedoraproject.org/wiki/Releases/Rawhide#Producing_Rawhide ,
> which includes more detail, but also talks about a mechanism which
> hasn't actually been activated yet...I will tweak it a bit.
> 
>> If it doesn't compose, there is no update in the repo.
>>
>> And it has been broken since 2019-02-17:
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/
>>
>> see STATUS file in each dir.
>>
>> Also see issues reported at:
>>
>> https://pagure.io/dusty/failed-composes/issues
>>
>> (search for Fedora-Rawhide and DOOMED)
> 
> To be clear, it's not that no-one is trying to fix it. Releng and QA
> folks have been investigating and fixing the problems the whole time -
> we've probably fixed about a dozen different ones. The problem is that
> every time we fix *one* issue, a new package shows up in the mean time
> and breaks something else. Since each compose attempt takes about 10
> hours, this is a slow and painful cycle when it happens...
> 

Thanks for all the replies.  I didn't know about the connection between 
(successful) composes and repo contents.  It makes sense now.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating Rawhide vs GPG keys

[Steven A. Falco]

On 3/11/19 7:31 AM, Vít Ondruch wrote:
> Hi,
> 
> Can somebody please enlighten me, how to update Rawhide after branching
> and not using --nogpgcheck?
> 
> It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
> the package which is still "rawhide" package and has "f31" keys. But
> this package was not probably signed, because this directory is empty:
> 
> https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
> 
> Installing anything from Rawhide fails, because of missing GPG keys.
> 
> So is there a way to get the GPG keys via DNF? Would it be possible to
> sign fedora-repos and fedora-release packages by older key to allow
> smooth updates?
 
I was able to update by first manually updating the keys via:

cd /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages
rpm -Uvh \
fedora-gpg-keys-31-0.1.noarch.rpm \
fedora-release-31-0.1.noarch.rpm \
fedora-release-common-31-0.1.noarch.rpm \
fedora-repos-31-0.1.noarch.rpm \
fedora-repos-rawhide-31-0.1.noarch.rpm

Then I was able to do a normal "dnf update --refresh".

Note that your package directory location may be slightly different.  I don't 
know if the "rawhide-2d95c80a1fa0a67d" part is consistent or just where mine 
happened to be.  But if you search for one of the "keys" packages inside the 
dnf cache area you should be able to find it.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Rawhide issue with python3-wxpython4

[Steven A. Falco]

The KiCad package uses python3-wxpython4 - I'm one of the package maintainers.  
KiCad is building correctly on Fedora 30, but my rawhide builds are failing 
with the following error:

BUILDSTDERR:   - nothing provides python3-sip-api(12)(x86-64) = 12.5 needed by 
python3-wxpython4-4.0.4-2.fc30.x86_64

It looks like the sip package was upgraded to 12.6 recently (March 21, 2019).  
Here is part of the changelog from the sip.spec file:

%changelog
* Thu Mar 21 2019 Rex Dieter  - 4.19.15-1
- 4.19.15, - sip-api(12)=12.6

It seems like the python3-wxpython4 package should be rebuilt to pick up that 
change.

I am new to this part of the process.  How might I request a rebuild of 
python3-wxpython4, and would that fix the problem or is something additional 
needed?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide issue with python3-wxpython4

[Steven A. Falco]

On 4/7/19 8:35 PM, Scott Talbert wrote:
> On Sun, 7 Apr 2019, Steven A. Falco wrote:
> 
>> The KiCad package uses python3-wxpython4 - I'm one of the package 
>> maintainers.  KiCad is building correctly on Fedora 30, but my rawhide 
>> builds are failing with the following error:
>>
>> BUILDSTDERR:   - nothing provides python3-sip-api(12)(x86-64) = 12.5 needed 
>> by python3-wxpython4-4.0.4-2.fc30.x86_64
>>
>> It looks like the sip package was upgraded to 12.6 recently (March 21, 
>> 2019).  Here is part of the changelog from the sip.spec file:
>>
>> %changelog
>> * Thu Mar 21 2019 Rex Dieter  - 4.19.15-1
>> - 4.19.15, - sip-api(12)=12.6
>>
>> It seems like the python3-wxpython4 package should be rebuilt to pick up 
>> that change.
>>
>> I am new to this part of the process.  How might I request a rebuild of 
>> python3-wxpython4, and would that fix the problem or is something additional 
>> needed?
> 
> The python-wxpython4 package needs to be rebuilt every time that the SIP API 
> changes.  @Rex - can you please initiate a build when you bump the SIP API?
> 
> Currently, though, wxPython is FTBFS in Rawhide [1] due to changes in SIP 
> 4.19.14 and 4.19.15.  I've got the SIP 4.19.14 changes addressed in wxPython, 
> but 4.19.15 introduced some bugs in SIP which I'm addressing with SIP 
> upstream.  Hopefully, there should be a new SIP release soon.
> 
> Bottom line - the issues are being worked on.  :)
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1696302

Thanks Scott.  I tried building wxPython locally and ran into the same FTBFS.  
I'll stand by until the upstream issues get resolved.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: urw-base35-fonts package missing from f30 and rawhide composes

[Steven A. Falco]

On 4/14/19 10:42 AM, Fabio Valentini wrote:
> On Sun, Apr 14, 2019 at 4:03 PM Fabio Valentini  wrote:
>>
>> Hi everybody,
>>
>> I've noticed today that several of my packages are starting to fail to
>> build in koschei due to missing dependencies - on urw-base35-fonts.
>> Attempting fedpkg scratch builds in koji confirmed the issue.
>>
>> For example:
>>
>> Problem: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but
>> none of the providers can be installed
>> - conflicting requests
>> - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
>>
>> The same issue makes inkscape and some other packages uninstallable on
>> fedora 30 and rawhide.
>>
>> I've looked at koji, src.fp.org, and the compose report e-mails, but
>> didn't see anything obvious happen to the urw-base35-fonts package,
>> but it seems to be missing from the latest rawhide and f30 composes
>> for some reason.
>>
>> Fabio
> 
> Looking at the koschei status, ~2000 of all ~13000 tracked source
> packages are now reported as un-buildable due to this - and this
> doesn't include the number of un-installable packages.
> 
> Just saying.

I just built KiCad, which uses doxygen, via mock on my local machine.  The 
build was fine.

I'm also building KiCad via Copr, and Copr was able to install doxygen, so I 
expect that build to be fine.

However, I also tried to build via koji, and that one fails with essentially 
the same error that you reported:

Error: 
 Problem 1: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but none 
of the providers can be installed
  - conflicting requests
  - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
 Problem 2: package asciidoc-8.6.10-0.9.20180605git986f99d.fc30.noarch requires 
graphviz, but none of the providers can be installed
  - conflicting requests
  - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Summary:

mock build - pass
copr build - pass
koji build - fail

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Kernel upgrades

[Steven A. Falco]

I just upgraded my machine from F29 to F30.  Now, whenever I install a new 
kernel, the new kernel does not automatically become the default.  In other 
words, when I reboot, the previous kernel is still chosen by grub2.

I can manually choose the new kernel in the grub2 menu, at which point it 
_does_ become the new default.  I don't wind up at the "grub>" prompt, so I 
think grub2 itself is fine.  It is just that the grubenv is not updated when 
the new kernel is installed.

The machine has UEFI, but the system boots using the legacy BIOS compatibility 
layer.  I know that the boot mechanism changed a bit for F30, but I'm not sure 
where to look to identify the cause of this problem.  It doesn't seem to be the 
same issue as described in BZ 1652806.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kernel upgrades

[Steven A. Falco]

On 5/5/19 2:04 PM, Nico Kadel-Garcia wrote:
> On Sun, May 5, 2019 at 10:22 AM Steven A. Falco  wrote:
>>
>> I just upgraded my machine from F29 to F30.  Now, whenever I install a new 
>> kernel, the new kernel does not automatically become the default.  In other 
>> words, when I reboot, the previous kernel is still chosen by grub2.
>>
>> I can manually choose the new kernel in the grub2 menu, at which point it 
>> _does_ become the new default.  I don't wind up at the "grub>" prompt, so I 
>> think grub2 itself is fine.  It is just that the grubenv is not updated when 
>> the new kernel is installed.
>>
>> The machine has UEFI, but the system boots using the legacy BIOS 
>> compatibility layer.  I know that the boot mechanism changed a bit for F30, 
>> but I'm not sure where to look to identify the cause of this problem.  It 
>> doesn't seem to be the same issue as described in BZ 1652806.
>>
>> Steve
> 
> It can be tricky for the grubby scripts to deduce which kernel was
> *really* the last one, especially if you've been hand-editing kernel
> entries or adding them manually, well, there might be debris.
> 
> /boog/grub/ has gotten *fascinating* Perhaps you can back up the
> system, and then delete *all* the extraneous kernels, to reset any
> confused default tracking mechanism in place?.

"Fascinating" is a good word for it.  I tried reading through the various 
scripts.  They are a twisty little maze of passages.  :-)

The problem has suddenly gone away.  I just installed kernel 5.0.11, and this 
time it correctly became the default.  I'm not sure what fixed my issue, but I 
can think of two possibilities.

1) Prior to installing 5.0.11, I did run the grub2-install command, as 
mentioned in the Common_F30_bugs wiki page.  Perhaps that helped, even though 
my symptoms were very different.

2) Also, installing 5.0.11 obsoleted the last of the F29 kernels on my machine. 
 Now there are only F30 kernels in /boot.

I'll keep an eye on it, but for now I'm good.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kernel upgrades

[Steven A. Falco]

On 5/5/19 6:29 PM, Chris Murphy wrote:
> On Sun, May 5, 2019 at 8:22 AM Steven A. Falco  wrote:
>>
>> I just upgraded my machine from F29 to F30.  Now, whenever I install a new 
>> kernel, the new kernel does not automatically become the default.  In other 
>> words, when I reboot, the previous kernel is still chosen by grub2.
>>
>> I can manually choose the new kernel in the grub2 menu, at which point it 
>> _does_ become the new default.  I don't wind up at the "grub>" prompt, so I 
>> think grub2 itself is fine.  It is just that the grubenv is not updated when 
>> the new kernel is installed.
>>
>> The machine has UEFI, but the system boots using the legacy BIOS 
>> compatibility layer.  I know that the boot mechanism changed a bit for F30, 
>> but I'm not sure where to look to identify the cause of this problem.  It 
>> doesn't seem to be the same issue as described in BZ 1652806.
> 
> Post your /etc/default/grub file
> 
> I'm willing to bet there's a line
> 
> GRUB_SAVEDEFAULT=true
> 
> If so, delete that line or comment it out and then run the usual
> grub2-mkconfig and directing the output to the proper grub.cfg path
> for your firmware type.
> 
> The default that should be honored is found in the grubenv file, which
> (curiously) is found at the same path no matter your firmware type:
> /boot/efi/EFI/fedora/grubenv
> 
> You can list its contents
> 
> # grub2-editenv list
> 
> And you can change it with
> 
> #grub2-set-default 
> 
> The title of the kernel is found in the /boot/loader/entries/*conf
> files - there is one file for each kernel.

Thanks for the explanation.  Here are the contents of /etc/default/grub.  As 
you suspected, there is a GRUB_DEFAULT=saved line in there.

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root 
rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 
rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

I looked for grubenv, and the only one I found is at /boot/grub2/grubenv.  
There is nothing in /boot/efi/EFI/fedora.  This machine was set up on 
2018-11-24, so it started life as a Fedora 29 machine.

Is there a command I should run to move grubenv to /boot/efi/EFI/fedora?  I 
think I would also have to create a symlink from /boot/efi/EFI/fedora/grubenv 
to /etc/default/grub.  I could of course do it manually, but if there is a 
better procedure, like re-installing some package(s), that would be preferable.

Steve


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kernel upgrades

[Steven A. Falco]

On 5/6/19 2:53 PM, Chris Murphy wrote:
> On Mon, May 6, 2019 at 7:39 AM Steven A. Falco  wrote:
>>
>> Thanks for the explanation.  Here are the contents of /etc/default/grub.  As 
>> you suspected, there is a GRUB_DEFAULT=saved line in there.
>>
>> GRUB_TIMEOUT=5
>> GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
>> GRUB_DEFAULT=saved
>> GRUB_DISABLE_SUBMENU=true
>> GRUB_TERMINAL_OUTPUT="console"
>> GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root 
>> rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 
>> rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap"
>> GRUB_DISABLE_RECOVERY="true"
>> GRUB_ENABLE_BLSCFG=true
> 
> This is a stock /etc/default/grub - there's nothing custom about it.
> 
>> I looked for grubenv, and the only one I found is at /boot/grub2/grubenv.  
>> There is nothing in /boot/efi/EFI/fedora.  This machine was set up on 
>> 2018-11-24, so it started life as a Fedora 29 machine.
> 
> Ahh not sure. Might be new in Fedora 30 and doesn't get changed on upgrades?
> 
>> Is there a command I should run to move grubenv to /boot/efi/EFI/fedora?  I 
>> think I would also have to create a symlink from 
>> /boot/efi/EFI/fedora/grubenv to /etc/default/grub.  I could of course do it 
>> manually, but if there is a better procedure, like re-installing some 
>> package(s), that would be preferable.
> 
> The purpose of the symlink is so that grubenv commands and usage just
> work without respect to firmware type. You don't have to fix this. But
> I'm still curious about the contents of that grubenv, so what do you
> get fro
> 
> # grub2-editenv list

Here is the command output:

saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64
boot_success=1
boot_indeterminate=1
kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap 
rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 
rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap

I'm reading through the various scripts trying to understand the impact of 
GRUB_DEFAULT.  It seems like having GRUB_DEFAULT=saved is not currently hurting 
me.  The last upgrade, to 5.0.11-300, properly made that kernel the new default.

If GRUB_DEFAULT is commented out, then I think grub will always choose the 
first item in its menu, which would be fine, because the newest kernel always 
appears first in the grub menu.  Is that why you recommended commenting it 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kernel upgrades

[Steven A. Falco]

On 5/6/19 4:47 PM, Chris Murphy wrote:
> On Mon, May 6, 2019 at 1:04 PM Steven A. Falco  wrote:
>>
>>> # grub2-editenv list
>>
>> Here is the command output:
>>
>> saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64
>> boot_success=1
>> boot_indeterminate=1
>> kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap 
>> rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 
>> rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap
> 
> Looks normal.
> 
> Also, about the /boot/grub2/grubenv symlink to
> /boot/efi/EFI/fedora/grubenv - I'm only seeing this on clean installs
> from Fedora-Workstation-Live-x86_64-30-1.2.iso so it might be related
> to how the lives are assembled and rsync'd over. It doesn't happen
> with a minimal or server installation on a BIOS VM.

The install originated as a "server edition", so that is consistent.

> At the moment, I think whatever problem there was has been cleared and
> it's now behaving normally.

Agreed.

>> I'm reading through the various scripts trying to understand the impact of 
>> GRUB_DEFAULT.  It seems like having GRUB_DEFAULT=saved is not currently 
>> hurting me.  The last upgrade, to 5.0.11-300, properly made that kernel the 
>> new default.
>>
>> If GRUB_DEFAULT is commented out, then I think grub will always choose the 
>> first item in its menu, which would be fine, because the newest kernel 
>> always appears first in the grub menu.  Is that why you recommended 
>> commenting it out?
> 
> Nope, sorry, you're confused. I referred to GRUB_SAVEDEFAULT -
> thinking maybe you had a customized /etc/default/grub. GRUB_DEFAULT
> and GRUB_SAVEDEFAULT are two different things, but the latter depends
> on the former.

It wouldn't be the first time I was confused. :-)

> I suggest keeping things as is, with saved_entry set in the grubenv.
> And that's because GRUB and the grub-boot-success.service are able to
> do an automatic fallback to the previous working kernel if boot fails
> following a kernel upgrade.

I will leave it alone, as you recommend.

As I was reading through the documentation, I came across a statement that 
grubenv is unavailable on RAID - please see the second to last sentence here:

https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html

My machine is set up with /boot on SW RAID-1 (and everything else on SW RAID-5 
/ LVM).  That said, grubenv appears to update properly.  I don't know if the 
manual is not quite current, or if there is some other explanation - perhaps 
any updates always occur under Linux, while the RAID-1 is assembled.

Regardless, everything is good now, so I'll stop obsessing about it. :-)

And thanks for all your help!

Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Kernel upgrades

[Steven A. Falco]

On 5/6/19 5:51 PM, Chris Murphy wrote:

> But it's worth keeping an eye on anomalies. There is the potential for
> goofy things happening. Unrelated to this particular feature, rather
> it was grub.cfg being updated, in cases where that update happened
> very quickly followed by an immediate reboot, GRUB only saw the
> previous grub.cfg. On journaled file systems, the new file gets
> written out, and indicated only in the journal, and a particular set
> of circumstances preventing the root fs from being cleanly unmounted
> resulted in a hidden new grub.cfg that only became revealed after
> journal replay by the kernel code. The GRUB code can't read file
> system journals, so it was seeing the stale file as a result of
> reading stale file system metadata without the benefit of reading the
> journal. :P

I may indeed have tripped over that a time or two.  I've had cases where 
strange things happened following a kernel update / immediate reboot.  Given 
the relative non-volatility of /boot, it's starting to make sense to use a 
plain ext2 fs for /boot rather than a more modern fs.

If I ever have to reload this machine, I may switch to UEFI.  While I don't 
like the FAT filesystems, their simplicity has an advantage in this application.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

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

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

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]

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

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

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/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: 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
subse

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

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

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

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

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: Donate 1 minute of your time to test upgrades from F40 to F41

[Steven A. Falco]

On 9/5/24 06:57 AM, Miroslav Suchý wrote:

dnf --releasever=41 --enablerepo=updates-testing --assumeno distro-sync


Most of my issues are due to gimp: gutenprint-plugin, gimp-resynthesizer, 
gimp-lqr-plugin.

Problem #2 relates to kicad-nightly which comes from Copr, so that may not be a 
fair test.

The list below is generated by dnf.  When I tried dnf5 there were no errors 
reported.

Error:
 Problem 1: package gutenprint-plugin-5.3.4-16.fc40.x86_64 from @System 
requires libgimp-2.0.so.0()(64bit), but none of the providers can be installed
  - package gutenprint-plugin-5.3.4-16.fc40.x86_64 from @System requires 
libgimpbase-2.0.so.0()(64bit), but none of the providers can be installed
  - package gutenprint-plugin-5.3.4-16.fc40.x86_64 from @System requires 
libgimpui-2.0.so.0()(64bit), but none of the providers can be installed
  - gimp-libs-2:2.10.38-1.fc40.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package gutenprint-plugin-5.3.4-16.fc40.x86_64
 Problem 2: package kicad-nightly-1:8.99.0-1.20240827gita9e1159.fc40.x86_64 
from @System requires libTKMath.so.7()(64bit), but none of the providers can be 
installed
  - package kicad-nightly-1:8.99.0-1.20240827gita9e1159.fc40.x86_64 from 
@System requires libTKernel.so.7()(64bit), but none of the providers can be 
installed
  - opencascade-foundation-7.6.3-4.fc39.x86_64 from @System  does not belong to 
a distupgrade repository
  - problem with installed package 
kicad-nightly-1:8.99.0-1.20240827gita9e1159.fc40.x86_64
 Problem 3: package gimp-resynthesizer-2.0.3-14.20190428gitadfa25a.fc41.x86_64 
from fedora requires gimp, but none of the providers can be installed
  - package gimp-2:2.99.19^20240826git3ded3c47fe-1.fc41.x86_64 from fedora 
requires gimp-libs(x86-64) = 2:2.99.19^20240826git3ded3c47fe-1.fc41, but none 
of the providers can be installed
  - package gimp-2:2.99.19^20240902gitb44687eb2f-1.fc41.x86_64 from 
updates-testing requires gimp-libs(x86-64) = 
2:2.99.19^20240902gitb44687eb2f-1.fc41, but none of the providers can be 
installed
  - cannot install both gimp-libs-2:2.99.19^20240826git3ded3c47fe-1.fc41.x86_64 
from fedora and gimp-libs-2:2.10.38-1.fc40.x86_64 from @System
  - cannot install both gimp-libs-2:2.99.19^20240902gitb44687eb2f-1.fc41.x86_64 
from updates-testing and gimp-libs-2:2.10.38-1.fc40.x86_64 from @System
  - package gimp-jxl-plugin-1:0.10.3-3.fc41.x86_64 from fedora requires 
libgimp-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-jxl-plugin-1:0.10.3-3.fc41.x86_64 from fedora requires 
libgimpcolor-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-jxl-plugin-1:0.10.3-3.fc41.x86_64 from fedora requires 
libgimpui-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-jxl-plugin-1:0.10.3-3.fc41.x86_64 from fedora requires 
libgimpwidgets-2.0.so.0()(64bit), but none of the providers can be installed
  - problem with installed package 
gimp-resynthesizer-2.0.3-13.20190428gitadfa25a.fc40.x86_64
  - problem with installed package gimp-jxl-plugin-1:0.8.3-1.fc40.x86_64
  - gimp-resynthesizer-2.0.3-13.20190428gitadfa25a.fc40.x86_64 from @System  
does not belong to a distupgrade repository
  - gimp-jxl-plugin-1:0.8.3-1.fc40.x86_64 from @System  does not belong to a 
distupgrade repository
  - gimp-2:2.10.38-1.fc40.x86_64 from @System  does not belong to a distupgrade 
repository
 Problem 4: package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
gimp(x86-64) >= 2.4, but none of the providers can be installed
  - package gimp-2:2.99.19^20240826git3ded3c47fe-1.fc41.x86_64 from fedora 
requires gimp-libs(x86-64) = 2:2.99.19^20240826git3ded3c47fe-1.fc41, but none 
of the providers can be installed
  - package gimp-2:2.99.19^20240902gitb44687eb2f-1.fc41.x86_64 from 
updates-testing requires gimp-libs(x86-64) = 
2:2.99.19^20240902gitb44687eb2f-1.fc41, but none of the providers can be 
installed
  - cannot install both gimp-libs-2:2.99.19^20240826git3ded3c47fe-1.fc41.x86_64 
from fedora and gimp-libs-2:2.10.38-1.fc40.x86_64 from @System
  - cannot install both gimp-libs-2:2.99.19^20240902gitb44687eb2f-1.fc41.x86_64 
from updates-testing and gimp-libs-2:2.10.38-1.fc40.x86_64 from @System
  - package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
libgimp-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
libgimpbase-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
libgimpcolor-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
libgimpui-2.0.so.0()(64bit), but none of the providers can be installed
  - package gimp-lqr-plugin-0.7.2-26.fc41.x86_64 from fedora requires 
libgimpwidgets-2.0.so.0()(64bit), but none of the providers can be installed
 

Re: Updating xorg-x11-server

[Steven A. Falco]

On 9/5/24 10:54 AM, Simone Caronni wrote:

Hi everyone,

I've noticed that we're really behind on xorg-x11-server releases (almost 3 
years!) and that by rebasing we would drop tons of patches that have already 
been upstreamed during this time.

No one that is listed in the maintainer list of that package seems to have been 
active on it for quite some time, so I would like to step up (proven packager).

If there are no objections, I will create an update, make a few tests (also at 
work, where we have plenty of legacy X applications, different Nvidia drivers 
and any possible proprietary screen sharing solution to test) and then post an 
update with a long karma threshold for those karma farmers.

If there are no objections I will proceed starting from the current pull 
request that has been sitting there for a few months now.

Thanks,
--Simone


That sounds great!  Thanks for taking it on!

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

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

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: 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...@list

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: 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 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 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/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/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/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/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: 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: 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: 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 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/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/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

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

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

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

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

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

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

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: [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

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/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: 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

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

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

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

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

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: [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: [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: 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: 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

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

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: [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