Re: Several questionable packages installed on fresh system

[Rex Dieter]

(sorry, first reply was sent privately, doing again to include list)
Seems like you may have not considered the translations angle, so let me
spin it another way...

If I adjusted where translations are packaged (put with -libs), so that the
base 'exiv2' package was < 1mb (~200k uncompressed), would we still be
having this conversation?

On Thu, Jul 13, 2023 at 10:10 AM Vít Ondruch  wrote:

> 1) I am sure I never had any need to use the exiv2 executable and I would
> be surprised if majority of Fedora users had different experience
>
> 2) I don't understand what else then space saving and e.g. optimization of
> install media should be the reason for the split.
>
> But given that the split as well as the recommends are correct, then I'll
> probably ask to remove the `exiv2` from the install media via kickstart or
> whatever is the right way to customize the install media content.
>
>
> Vít
>
>
> Dne 13. 07. 23 v 15:45 Rex Dieter napsal(a):
>
> I don't see any good reason to change here.  Mostly because the status quo
> is already a compromise to leave the base package as an optional Recommends
> (ie, removable).
>
> This is considering that most of the space in question here are
> translations, that strictly-speaking, probably ought to be included in the
> -libs package anyway.  if those files were moved, the space saving for the
> base package would be negligible.
>
> On Thu, Jul 13, 2023 at 7:42 AM Vít Ondruch  wrote:
>
>> (now hopefully with correct maintainer email)
>>
>>
>> Dne 13. 07. 23 v 14:38 Vít Ondruch napsal(a):
>> >
>> > Dne 10. 07. 23 v 10:38 Vít Ondruch napsal(a):
>> >>
>> >> exiv2
>> >>
>> >>
>> >
>> > So this is pulled in by exiv2-libs:
>> >
>> >
>> https://src.fedoraproject.org/rpms/exiv2/blob/rawhide/f/exiv2.spec#_53-58
>> >
>> > I am not sure I agree with the comment `# not strictly required, but
>> > convenient and expected`. But I think dependencies like this should be
>> > reevaluated at least in the install media context. This would save 4+
>> > MB of space.
>> >
>> > Or is the exiv2 maintainer (in CC) going to revisit this dependency?
>> >
>> >
>> > Vít
>> >
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Several questionable packages installed on fresh system

[Rex Dieter]

I don't see any good reason to change here.  Mostly because the status quo
is already a compromise to leave the base package as an optional Recommends
(ie, removable).

This is considering that most of the space in question here are
translations, that strictly-speaking, probably ought to be included in the
-libs package anyway.  if those files were moved, the space saving for the
base package would be negligible.

On Thu, Jul 13, 2023 at 7:42 AM Vít Ondruch  wrote:

> (now hopefully with correct maintainer email)
>
>
> Dne 13. 07. 23 v 14:38 Vít Ondruch napsal(a):
> >
> > Dne 10. 07. 23 v 10:38 Vít Ondruch napsal(a):
> >>
> >> exiv2
> >>
> >>
> >
> > So this is pulled in by exiv2-libs:
> >
> >
> https://src.fedoraproject.org/rpms/exiv2/blob/rawhide/f/exiv2.spec#_53-58
> >
> > I am not sure I agree with the comment `# not strictly required, but
> > convenient and expected`. But I think dependencies like this should be
> > reevaluated at least in the install media context. This would save 4+
> > MB of space.
> >
> > Or is the exiv2 maintainer (in CC) going to revisit this dependency?
> >
> >
> > Vít
> >
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)

[Rex Dieter]

Kevin Kofler via devel wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
>> Why would anyone want to do that? (I'm not talking about the case
>> mentioned elsewhere in the thread were a non-libtool file is removed
>> by a mistake, but the actual case where one would want to keep
>> distributing a libtool file.)
> 
> The kdelibs3 plugin loader breaks down horribly if you remove the .la file
> under it. (This was fixed in kdelibs 4, but the kdelibs3 compat library
> stack still ships those .la files for that reason.)

I'm sure there's a way to opt-out of this behavior (right?)

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Donate 1 minute of your time to test upgrades from F34 to F35

[Rex Dieter]

Should be fixed with

https://src.fedoraproject.org/rpms/qt5-qtbase/c/70d501d41e08f3f2b18d54367d46c0be81afc73f

On Tue, Sep 7, 2021 at 2:13 PM Marcin Juszkiewicz 
wrote:

> On 07.09.2021 20:47, Marcin Juszkiewicz wrote:
> > [root@puchatek hrw]# LANGUAGE=C LC_ALL=C LANG=C dnf --releasever=35
> > --setopt=module_platform_id=platform:f35 --enablerepo=updates-testing
> > --enablerepo=updates-testing-modular distro-sync
> > Last metadata expiration check: 0:28:08 ago on Tue Sep  7 20:16:12 2021.
> > Error:
> >   Problem: package qt5-qtbase-ibase-5.15.2-16.fc34.x86_64 requires
> > qt5-qtbase(x86-64) = 5.15.2-16.fc34, but none of the providers can be
> > installed
> >- qt5-qtbase-5.15.2-16.fc34.x86_64 does not belong to a distupgrade
> > repository
> >- problem with installed package
> qt5-qtbase-ibase-5.15.2-16.fc34.x86_64
> > (try to add '--skip-broken' to skip uninstallable packages)
> >
> >
> > Removed "qt5-qtbase-ibase" package and distrosync command went fine:
>
>  From qt5-qtbase changelog it looks like this package was disabled due
> to Firebird FTBFS on s390x which was later fixed.
>
> So probably qt5-qtbase maintainers (Cc-ed) need to enable it back.
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Plasmashell: Alt+F2 not working

[Rex Dieter]

Sergio Belkin wrote:

> Since a few days ago, the keyboard shortcut Alt+F2 for opening "run
> command" box is not working.

Please followup on upstream bug report on the topic,
https://bugs.kde.org/show_bug.cgi?id=437364

In particular, if you can attach your
/.config/kglobalshortcutsrc file there, that would help, thanks.

We also have a downstream bug, but it needs to be fixed upstream, why I'm 
encouraging feedback there instead
https://bugzilla.redhat.com/show_bug.cgi?id=1974589

-- Rex

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

Re: Can comps handle virtual provides?

[Rex Dieter]

Miro Hrončok wrote:

> Hello.
> 
> We have recently renamed pypy3 to pypy3.7.
> As a result, the pypy3-devel package is now called pypy3.7-devel, however
> it still provides pypy3-devel.
> 
> pypy3-devel is part of the python-classroom comps group in
> comps-f36.xml.in.
> 
> Normally, I'd rename the package there, but in this case I'd rather keep
> "pypy3-devel" as it requires less maintenance. Does it work with virtual
> provides?

Pretty sure answer is no

(based on past experience, though the situation may have changed/improved 
since then)

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: KDE Autostart in F34

[Rex Dieter]

Ravindra Kumar wrote:

> Hi,
> 
> I hope there are some KDE experts on the list who can help me debug this -
> https://bugzilla.redhat.com/show_bug.cgi?id=1953472.
> 
> It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart
> script in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work
> fine.
> 
> Could you please confirm if KDE supports autostart scripts from
> /etc/xdg/autostart dir? If yes, is there a regression in F34?

kde plasma on f34 uses systemd user session and systemd-xdg-autostart-
generator, so yes, autostart is supported (but this new method has some 
quirks).

I commented in the bug with some debugging steps to try.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Thoughts about packaging a standalone python-PyQt5-sip?

[Rex Dieter]

Scott Talbert wrote:

> Yes, I got fairly far with porting all PyQt5 SIP consumers (including
> calibre) to use SIPv5.  I think I then got discouraged at the thought of
> making a bunch of PRs and having to nag maintainers to merge them in some
> sort of coordinated fashion.
> 
> I guess - if I get everything working, would you be willing to merge a
> bunch of related PRs as provenpackager and do rebuilds in a side tag?

I'd be able and willing to assist here too, thanks for working on it!

As far as sip6 goes, I'd venture the adjustment from v5 to v6 will be 
smaller than what v4 to v5 was.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Rex Dieter]

Rex Dieter wrote:

> Rex Dieter wrote:
> 
>> Antonio T. sagitter wrote:
>> 
>>> Hi all.
>>> 
>>> I can't compile IceCat on Fedora 33+ since some days because of these
>>> errors:
>>> 
>>> ...
>>> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
>> 
>> This is impacting plasma-discover and flatpak, the latter's flatpak.h
>> header will need to fixed first (I think) before plasma-discover can
>> build again.
> 
> Filed flatpak bug,
> https://bugzilla.redhat.com/1927439
> 
> which blocks fixing plasma-discover FTBFS

nominated as f34 blocker, and filed upstream issue
https://github.com/flatpak/flatpak/issues/4117

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Rex Dieter]

Rex Dieter wrote:

> Antonio T. sagitter wrote:
> 
>> Hi all.
>> 
>> I can't compile IceCat on Fedora 33+ since some days because of these
>> errors:
>> 
>> ...
>> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
> 
> This is impacting plasma-discover and flatpak, the latter's flatpak.h
> header will need to fixed first (I think) before plasma-discover can build
> again.

Filed flatpak bug,
https://bugzilla.redhat.com/1927439

which blocks fixing plasma-discover FTBFS

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Rex Dieter]

Antonio T. sagitter wrote:

> Hi all.
> 
> I can't compile IceCat on Fedora 33+ since some days because of these
> errors:
> 
> ...
> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

This is impacting plasma-discover and flatpak, the latter's flatpak.h header 
will need to fixed first (I think) before plasma-discover can build again.

I already fixed appstream, pulling in upstream fix 
https://github.com/ximion/appstream/commit/8a179f14619103247e4a14d96ea03c358d9c1492

Needless to say, this is a pain (that's about the best constructive 
criticism I can give right now).

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake FTBFS in rawhide

[Rex Dieter]

Benjamin Beasley wrote:


> I think you will need to either skip the multi-threaded TXZ test, or bound
> its memory requirements by patching it to use some fixed value for
> CPACK_ARCHIVE_THREADS instead of 0. See
> https://cmake.org/cmake/help/latest/cpack_gen/archive.html#variables-used-by-cpack-archive-generator.

Thanks!  Opted to set CPACK_ARCHIVE_THREADS to some reasonable number (like 
4 for now).

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

cmake FTBFS in rawhide

[Rex Dieter]

I'm a bit perplexed by some recent cmake FTBFS issues on rawhide/i686

My source of confusion is that it *seems* scratch builds succeed (3 times) 
but real/non-scratch builds fail.  I've tried at least 3 times both ways.

Success example,
https://koji.fedoraproject.org/koji/taskinfo?taskID=59523225

Failure example,
https://koji.fedoraproject.org/koji/taskinfo?taskID=59540035

Can anyone explain how/why scratch builds would behave differently?


Full disclosure, when it does fail, the source of the failure is always the 
same, one of the %%check tests errors:

554:actual-err>   CPack error: 'CPack Error: Problem to open archive
554:actual-err>   ,
554:actual-err>   ERROR = archive_write_open: Internal error 
initializing compression
554:actual-err>   library: Cannot allocate memory
554:actual-err> 
554:actual-err>   CPack Error: Problem compressing the directory

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Could you add another build in existing bodhi update？

[Rex Dieter]

Ok, will do

-- Rex

On Wed, Jan 6, 2021, 8:02 PM 西木野羰基  wrote:

> Hello rdieter,
>
> I have built fcitx5-configtool-5.0.1-1.fc33 in f33-kde tag, since this
> version of fcitx5-configtool depends on latest version of
> kf5-kirigami2. And I think this build should belong to
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-b6c17b6872
>
> So, could you please add this build to the update?
>
> --
> Best regards,
> Qiyu Yan
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: runtime dependencies not in Requires spec section

[Rex Dieter]

Kevin Kofler via devel wrote:

> Rex Dieter wrote:
>> It's a linked library, so *yes*, rpmbuild will add it.
> 
> Depends on whether the application links directly to libQt5Svg.so.5 or
> whether it uses it only through the plugin-based imageformats

In this context, for the software/package in question, I verified that it 
links libQt5Svg.so.5

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Thoughts about packaging a standalone python-PyQt5-sip?

[Rex Dieter]

Scott Talbert wrote:

> On Sat, 2 Jan 2021, Kevin Fenzi wrote:
> 
> I think fundamentally the version of PyQt5-sip probably needs to match
> (or be very close to) the version of sip that PyQt5 itself was
> compiled with.

 I think for calibre (which is currently failing with):

 ...
 /usr/bin/python3 -c import os;
 os.chdir('/builddir/build/BUILD/calibre-5.8.1/build/pyqt/pictureflow');
 from sipbuild.tools.build import main; main(); --verbose --no-make
 --qmake /usr/bin/qmake-qt5 Querying qmake about your Qt installation...
 /usr/bin/qmake-qt5 -query These bindings will be built: pictureflow.
 Generating the pictureflow bindings... -c: Unable to find file
 "QtWidgets/QtWidgetsmod.sip"

 ...we need python-qt5 to be using sip5 also. I looked into it a bit, it
 completely changes from using a configure.py to using sip-build and
 PyQt-builder.

 Or can we just add a subpackage there that uses sip5 and keep the sip4
 ones for sip4 users? something like python3-qt5-sip5-devel ?

 Or should we just convert everything to sip5 now?

 I'd really like to get calibre building again... :)
>>>
>>> It looks like technically you can still use configure.py to build PyQt5
>>> with sip5, but it does seem more forward looking to switch to sip-build
>>> / sip-install.
>>>
>>> BTW, can you please build PyQt-builder for F33?  Thanks.
>>
>> Sure. Also, co-maintainers welcome. :)
> 
> Thanks!  BTW, I starting looking into moving python-qt5 to sip5.  It
> doesn't look like it would be *that* difficult.  I thought about doing a
> PR, but it might be better if the regular pyqt5 maintainer (if
> interested/available) did it.

With my "regular maintainer" hat on, I'll say unfortunately I've not had 
time to look into this and probably won't for the foreseeable immediate 
future.  

I'll also chime in with "co-maintainers" welcome if there are folks 
interested in able in moving this forward.  Just take care to minimize 
breakage.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: runtime dependencies not in Requires spec section

[Rex Dieter]

Vitaly Zaitsev via devel wrote:

> On 30.12.2020 22:49, Germano Massullo wrote:
>> My question is: how can keepassxc trigger the installation of such
>> libraries if the spec file does not contain any Requires dependency that
>> should be the attribute to identify runtime dependencies that are needed
>> by the package?
> 
> Yes, it must. Qt5Svg is a Qt runtime plugin, so it will not be added
> automatically by rpmbuild.

It's a linked library, so *yes*, rpmbuild will add it.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Rex Dieter]

Fulko Hew wrote:

> a) is there an easy (i.e. documented) way of testing it?

Keeping in mind that testing anything now (before plasma 5.21 is 
preliminary), but... best way to test:

1.  create a new user for testing purposes
2.  make sure plasma-workspace-wayland pkg is installed
3.  login using Desktop Session: Plasma (wayland)

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Rex Dieter]

Sérgio Basto wrote:

> On Mon, 2020-09-14 at 00:46 +0200, Kevin Kofler wrote:
>> Ben Cotton wrote:
>> > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
>> > 
>> > == Summary ==
>> > Change the default session selection in SDDM to prefer the
>> > Wayland-based KDE Plasma Desktop session over the X11-based one.

> 
> Can we revert this decision, seems almost all the people have the same
> opinion ... that Plasma on Wayland is not ready for production.
> IMHO, try run it in wayland should be a optin .

This can't be fully appreciated until plasma-5.21 lands.  No formal 
decisions will be made until at least then.

And until then, if there are any issues you want to be considered blocking, 
please file bugs.  Currently I see nothing blocking the tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1882465

> Also, I'm against add workarounds on desktop files like this one [1]
> forcing apps running with QT_QPA_PLATFORM=xcb , because is just hidden
> the real problem.
...
> Note upstream app developers can opt by not support wayland and
> internally force use of X11, but we shouldn't do that on desktop files
> because app could be called  by other method ...

That's related, but different.  However, applications will have to adapt 
sooner or later, may as well be sooner.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: gcc11/kconfig_compiler (was: weird build failure on i686)

[Rex Dieter]

Jeff Law wrote:

> 
> 
> On 12/19/20 9:40 PM, Rex Dieter wrote:
>> Mattia Verga via devel wrote:
>>
>>> While trying to build a new kde-partitionmanager release, I get a
>>> strange build failure which seems related to character encoding:
>>>
>>> https://kojipkgs.fedoraproject.org//work/tasks/8985/57428985/build.log
>>>
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>>48 | 挀漀渀猀琀 挀栀愀爀⨀ 挀漀渀猀琀 Config::EnumFileSystem::enumToString[] = {
>>>"Unknown", "Extended", "Ext2", "Ext3", "Ext4", "LinuxSwap", "Fat16",
>>>"Fat32", "Ntfs", "ReiserFS", "Reiser4", "Xfs", "Jfs", "Hfs",
>>>"HfsPlus", "Ufs", "Unformatted", "Btrfs", "Hpfs", "Luks", "Ocfs2",
>>>"Zfs", "Exfat", "Nilfs2", "Lvm2_PV", "F2fs", "Udf", "Iso9660",
>>>"Luks2", "Fat12", "LinuxRaidMember", "BitLocker", "Apfs", "Minix" };
>>>   | ^
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character ⨀ is not valid in an identifier
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>>
>>> This seems to happen only on i686 arch, so I don't think sources are
>>> corrupted in some way. Also, there seems to be no relevant changes
>>> between the latest built release and this one that could justify the
>>> failure:
>>>
>>> https://github.com/KDE/kpmcore/compare/v20.11.90...v20.12.0
>>>
>>> Any idea what's going on?
>> Wierd issue with kconfig_compiler on i686 when built with gcc-11, see bug
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1907799
> I wouldn't be surprised if this turns out to be a gcc bug.  In fact,
> I've got my eye on upstream gcc bug 98366.
> 
> While I'm on PTO for the next two weeks, I'll probably be checking-in on
> a few things.  If there's a good way to test this I expect I'll have a
> compiler with the 98366 fix handy today/tomorrow.

Tentatively, looks like this gcc issue is fixed using gcc-11.0.0-0.11.fc34, 
thanks!

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: gcc11/kconfig_compiler (was: weird build failure on i686)

[Rex Dieter]

Mattia Verga via devel wrote:

> While trying to build a new kde-partitionmanager release, I get a strange
> build failure which seems related to character encoding:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/8985/57428985/build.log
> 
> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
gnu/src/config.cpp:48:1:
> error: extended character   is not valid in an identifier
>48 | 挀漀渀猀琀 挀栀愀爀⨀ 挀漀渀猀琀 Config::EnumFileSystem::enumToString[] = {
>"Unknown", "Extended", "Ext2", "Ext3", "Ext4", "LinuxSwap", "Fat16",
>"Fat32", "Ntfs", "ReiserFS", "Reiser4", "Xfs", "Jfs", "Hfs", "HfsPlus",
>"Ufs", "Unformatted", "Btrfs", "Hpfs", "Luks", "Ocfs2", "Zfs", "Exfat",
>"Nilfs2", "Lvm2_PV", "F2fs", "Udf", "Iso9660", "Luks2", "Fat12",
>"LinuxRaidMember", "BitLocker", "Apfs", "Minix" };
>   | ^
> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
gnu/src/config.cpp:48:1:
> error: extended character ⨀ is not valid in an identifier
> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
gnu/src/config.cpp:48:1:
> error: extended character   is not valid in an identifier
> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
gnu/src/config.cpp:48:1:
> error: extended character   is not valid in an identifier
> 
> This seems to happen only on i686 arch, so I don't think sources are
> corrupted in some way. Also, there seems to be no relevant changes between
> the latest built release and this one that could justify the failure:
> 
> https://github.com/KDE/kpmcore/compare/v20.11.90...v20.12.0
> 
> Any idea what's going on?

Wierd issue with kconfig_compiler on i686 when built with gcc-11, see bug

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

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: qt5-qtbase-devel breakage on s390x

[Rex Dieter]

Vitaly Zaitsev via devel wrote:

> Hello all.
> 
> Unable to build anything with qt5-qtbase-devel dependency in Koji on
> s390x for Fedora 33 due to the following:
> 
> Error:
>   Problem 1: package qt5-qtbase-devel-5.15.2-2.fc33.s390x requires
> pkgconfig(vulkan), but none of the providers can be installed

Should be fixed with
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9cbc7b3d68

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: s390x only buildroot problem

[Rex Dieter]

Richard Shaw wrote:

> Never mind, it has been reported and "fixed" it just needs to propagate to
> the builders I suppose.

Only part of it is fixed (worked-around): qt5-qtbase

Other packages are (still) affected, including:

vulkan-loader

(and anything else that depends on it, including:
gstreamer1-plugins-bad-free

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

The root cause is this commit, that dropped provding vulkan driver pkgs for 
s390:

https://src.fedoraproject.org/rpms/mesa/c/26ef46f507559d980e1e91f20e66463d5503bf3e

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: What package provide qmake?

[Rex Dieter]

Robbi Nespu wrote:

> Hello there, I want to get involve with KDE development. I have follow
> the step from https://community.kde.org/Get_Involved/development but
> unable to proceed to next step to build dolphin

(as root):
dnf builddep dolphin

will install everything the fedora's packaged dolphin needs to build.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: error: configuration file docs/doxygen.cfg not found!

[Rex Dieter]

Rex Dieter wrote:

> Martin Gansser wrote:
> 
>> Hi,
>> 
>> when trying to compile sayonara with the recent doxygen-1.8.20 version,
>> the built fails with this error:
>> 
>> /usr/bin/cmake -E cmake_progress_start
>> /builddir/build/BUILD/sayonara-player-1.6.0-beta6/x86_64-redhat-linux-
> gnu/CMakeFiles
>> 0 + doxygen -u docs/doxygen.cfg error: configuration file
>> docs/doxygen.cfg not found! Doxygen version 1.8.20
>> Copyright Dimitri van Heesch 1997-2019
>> 
>> 
>> [1]
>> [https://src.fedoraproject.org/rpms/sayonara/blob/master/f/sayonara.spec
>> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=50177888
>> 
>> How can I solve this ?
> 
> Looks like sayonara doesn't support out-of-src tree builds?
> 
> if so, add to the top:
> 
> %global __cmake_in_source_build 1

Sorry, I misspoke, I meant to say "If not" (instead of "If so")

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: error: configuration file docs/doxygen.cfg not found!

[Rex Dieter]

Martin Gansser wrote:

> Hi,
> 
> when trying to compile sayonara with the recent doxygen-1.8.20 version,
> the built fails with this error:
> 
> /usr/bin/cmake -E cmake_progress_start
> /builddir/build/BUILD/sayonara-player-1.6.0-beta6/x86_64-redhat-linux-
gnu/CMakeFiles
> 0 + doxygen -u docs/doxygen.cfg error: configuration file docs/doxygen.cfg
> not found! Doxygen version 1.8.20
> Copyright Dimitri van Heesch 1997-2019
> 
> 
> [1]
> [https://src.fedoraproject.org/rpms/sayonara/blob/master/f/sayonara.spec
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=50177888
> 
> How can I solve this ?

Looks like sayonara doesn't support out-of-src tree builds?

if so, add to the top:

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

SwapOnZRAM and how it affects earlyoom thresholds

[Rex Dieter]

part of some irc discussions on
https://fedoraproject.org/wiki/Changes/KDEEarlyOOM

raised my attention to related item,
https://fedoraproject.org/wiki/Changes/SwapOnZRAM

As it stands currently with earlyoom, it's default thresholds are 4% ram and 
10% swap before it acts.  That's fine and dandy.

Upon reading the SwapOnZRAM feature proposal, I see it is advocating 
allocating 50% of ram for swap.  I'd like folks to consider and evaluate how 
this impacts earlyoom.  It effectively makes the earlyoom memory threshold 
double (right?).  If so, at least think about lowering 4 to (2 or 3), since 
that will make earlyoom's behavior closer to before swaponzram was 
introduced.

Thoughts?

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Rex Dieter]

John M. Harris Jr wrote:

> On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote:
>> John M. Harris Jr wrote:
>> 
>> 
>> > That's not what this discussion results from. This discussion results
>> > from
>> > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM
>> > killing our applications at random, and ruining our desktop experience.
>> 
>> 
>> This is full of inaccurate statements
>> 
>> 1.  The KDE SIG (at least some) was made aware of this feature and were
>> ok
>> with it.  It wasn't someone outside deciding anything.
> 
> What's the KDE SIG's rationale behind supporting this? This actively
> limits the amount of RAM that end users are able to make use of. The more
> RAM the end user has, the more RAM is not available for use, because
> EarlyOOM will kill software long before it's able to be used. For example,
> on my system, with 6 GiB of RAM, this will send SIGTERM while I still have
> over half of a gigabyte of RAM, and SIGKILL while I still have over a
> quarter of a gigabyte of RAM. There's absolutely no justification for
> this, as I see it.
> 

You're welcome to your opinion, so far I do not share it.  One example: I've 
hit several times in the past where compiling something killed my box and 
made it unresponsive.  I would have loved it for something to have bailed me 
out of those situations.

I've been testing it on a laptop with only 4gb ram, and it's been working 
well for me so far.  Though I honestly think I've not yet hit any thresholds 
, primarily only doing local package builds and web browsing.  

Also, you might want to double-check your math and the configuration values 
in account here, my default earlyoom config is set with -m 4 value, and your 
comment does not take into account swap (default is threshold of 10% free).

-- Rex


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Rex Dieter]

John M. Harris Jr wrote:

> That's not what this discussion results from. This discussion results from
> somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing
> our applications at random, and ruining our desktop experience.

This is full of inaccurate statements

1.  The KDE SIG (at least some) was made aware of this feature and were ok 
with it.  It wasn't someone outside deciding anything.

2.  It's clear you don't like this feature, but characterizing it as random 
and ruining things is going a bit far (to put it mildly).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

[Rex Dieter]

Jakub Jelinek wrote:

> On Sat, May 02, 2020 at 12:36:29PM +0200, Sandro Mani wrote:
>> Hi
>> 
>> I'm stuck on the following build failure of the aarch64 build here [1]
>> 
>> /usr/bin/ld: .libs/geod: hidden symbol `__aarch64_ldadd4_acq_rel' in
>> /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced
>> by DSO
>> /usr/bin/ld: final link failed: bad value
>> collect2: error: ld returned 1 exit status
>> 
>> Never seen anything like this, any ideas?
> 
> #1830472

wouldn't it have been better to untag the broken build asap so folks can 
continue working?  (Sorry if there was discussion about that possibility, 
but I didn't see anything)

As-is, everyone is blocking on waiting for the new gcc build to complete 
(that koji estimates is another ~6 hours away).

Personally, this morning was my primary chance to get a significant amount 
of work done for the coming week... lost.  :(

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days

[Rex Dieter]

Richard W.M. Jones wrote:

> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> 
> This one is a Rawhide update from a side tag, submitted on Sunday
> morning which has been in pending for 2 days.  (As it's Rawhide it's
> supposed to spend 0 days in testing.)  Is there any problem with it,
> or do we just have to wait longer?  It is blocking builds of other
> packages.

I saw the same thing, and submitted a infra ticket about it,
https://pagure.io/fedora-infrastructure/issue/8819

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> On Mon, Apr 6, 2020 at 11:13 PM Rex Dieter  wrote:
> 
>> Rex Dieter wrote:
>>
>> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> work-in-
>> > progress being done in side tag f33-build-side-21031
>> >
>> > I figure it'll take at least a few days to get the core bits and all
>> > dependencies rebuilt.  Will provide status updates as warranted.
>>
>> Fist batch of builds completed, bodhi update:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c
> 
> 
> Ahh, wish I had known, I would have built python-PySide2 into the side
> tag. I suppose I still can but it wouldn't be in the update.

You still can, the side tag still exists... or just wait until it gets 
pushed.

If python-PySide2 uses Qt private api's so that it requires rebuilding for 
every Qt5 point release, make sure that it includes:
BuildRequires: qt5-qtbase-private-devel
that's the set of packages I always include in these sort of Qt mass 
updates.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Rex Dieter wrote:

> FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> progress being done in side tag f33-build-side-21031
> 
> I figure it'll take at least a few days to get the core bits and all
> dependencies rebuilt.  Will provide status updates as warranted.

Fist batch of builds completed, bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c

Hope I did that right, with:
bodhi updates new --from-tag ...
according to https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/

There were a handful of failures, largely in 2 classes:
* FTBFS for reasons other than Qt itself
* a couple due to what I think are Qt 5.14.2 configuration issues (e.g. 
mscore), there's some issue with either translations or datadir in general 
where some full paths that should be /usr/share/... end up referenced as 
what appears to be a broken partial relative path looking like /../share/...

I'll be digging into both more in depth starting tomorrow.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: PSA: please do not BuildRequires: qt5-devel

[Rex Dieter]

Iñaki Ucar wrote:

> On Mon, 6 Apr 2020 at 18:08, Rex Dieter  wrote:
>>
>> The qt5, qt5-devel metapackages were introduced a few releases ago as
>> merely a convenience for end-users, not intended to be used in official
>> fedora packages, but seems these have seen some non-trivial adoption
>> anyway.
>>
>> Personally, I objected to metapackage introduction at the fearing this
>> would
>> happen, and it has.  Appended is a current list of offenders.
> 
> So, is it fine if I just remove this line?
> 
> https://src.fedoraproject.org/rpms/rstudio/blob/master/f/rstudio.spec#_59

Probably, rstudio already has build dependencies on a bunch of other Qt5 
stuff.

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

PSA: please do not BuildRequires: qt5-devel

[Rex Dieter]

The qt5, qt5-devel metapackages were introduced a few releases ago as merely 
a convenience for end-users, not intended to be used in official fedora 
packages, but seems these have seen some non-trivial adoption anyway.

Personally, I objected to metapackage introduction at the fearing this would 
happen, and it has.  Appended is a current list of offenders.

Starting now as a preventative measure, I'm dropping the creation of these 
metapackages on f32+.  Maintainers of the packages below will need to adjust 
things appropriately.  In the *least*, replacing:
BuildRequires: qt5-devel
with
BuildRequires: qt5-qtbase-devel



# dnf repoquery --repoid=rawhide-source --arch=src --whatrequires qt5-devel
...
Panini-0:0.73.0-4.fc32.src
Pencil2D-0:0.6.4-3.fc32.src
ampache_browser-0:1.0.2-5.fc32.src
arc-gui-clients-0:0.4.6-21.fc32.src
cool-retro-term-0:1.1.1-4.fc32.src
cppcheck-0:1.90-5.fc32.src
cutecom-0:0.51.0-4.fc32.src
danmaq-0:0.2.3.1-8.fc32.src
dolphin-emu-0:5.0.11819-1.fc33.src
edb-0:0.9.21-5.fc32.src
fips-0:3.3.1-5.fc32.src
fmit-0:1.2.13-2.fc32.src
focuswriter-0:1.7.5-1.fc33.src
gcin-0:2.8.9-3.fc33.src
heimdall-0:1.4.2-9.fc32.src
icemon-0:3.3-2.fc32.src
jalv-0:1.6.4-2.fc32.src
klog-0:1.0-2.fc33.src
mozc-0:2.23.2815.102-9.fc32.src
mumble-0:1.3.0-1.fc33.src
musique-0:1.5-4.fc31.src
notepadqq-0:1.4.8-10.fc32.src
openal-soft-0:1.19.1-5.fc33.src
openscad-0:2019.05-9.fc33.src
ophcrack-0:3.8.0-4.fc32.src
plplot-0:5.15.0-9.fc33.src
prestopalette-0:0.1.31-7.fc32.src
pulseview-0:0.4.2-1.fc33.src
qgis-0:3.12.1-1.fc33.src
qtiocompressor-0:2.3.1-20.fc32.src
recorder-0:1.0.8-3.fc32.src
root-0:6.20.02-1.fc33.src
rstudio-0:1.2.5033-12.fc33.src
scap-workbench-0:1.2.1-2.fc32.src
scribus-0:1.5.6-0.6.fc33.src
speedcrunch-0:0.12-7.fc32.src
subversion-0:1.12.2-7.fc33.src
suil-0:0.10.6-2.fc32.src
unixODBC-gui-qt-0:0-0.22.20190111svn132.fc32.src
wt-0:4.3.0-1.fc33.src
xca-0:2.2.1-1.fc32.src
xpdf-1:4.02-3.fc32.src
zhu3d-0:4.2.6-17.fc32.src



-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> On Sat, Apr 4, 2020 at 6:50 PM Rex Dieter  wrote:
> 
>> Richard Shaw wrote:
>>
>> > On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:
>> >
>> >> FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> >> work-in- progress being done in side tag f33-build-side-21031
>> >>
>> >> I figure it'll take at least a few days to get the core bits and all
>> >> dependencies rebuilt.  Will provide status updates as warranted.
>>
>> > Looking at the changelog, do I need to drop python-pyside2's BR
>> > on qt5-qtwebkit-devel?
>>
>> I don't know much about pyside, sorry.  I don't know.
>>
> 
> Sorry, I should have been more specific, I was referring to this:
> 
> * Sat Apr 04 2020 Rex Dieter  - 5.14.2-1 -
> 5.14.2
> - drop qt5-qtwebkit from metapackage (hasn't been a core qt5 pkg for
> awhile)

That only affects the 'qt5' and 'qt5-devel' metapackages, which no real 
package in fedora should be using anyway.  Not relevant to anything else 
(including pyside).

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:
> 
>> FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> work-in- progress being done in side tag f33-build-side-21031
>>
>> I figure it'll take at least a few days to get the core bits and all
>> dependencies rebuilt.  Will provide status updates as warranted.

> Looking at the changelog, do I need to drop python-pyside2's BR
> on qt5-qtwebkit-devel?

I don't know much about pyside, sorry.  I don't know.

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

Qt 5.14.2 coming to rawhide

[Rex Dieter]

FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
progress being done in side tag f33-build-side-21031

I figure it'll take at least a few days to get the core bits and all 
dependencies rebuilt.  Will provide status updates as warranted.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: qtwebengine FTBFS, gcc internal compiler error

[Rex Dieter]

Jakub Jelinek wrote:

> On Thu, Mar 26, 2020 at 07:52:37AM -0500, Rex Dieter wrote:
>> Heads up in case anyone else hits this since apparently new gcc landed in
>> rawhide last night (gcc-10.0.1-0.10.fc33)
...
>> Will file a bug later when I get a chance.
> 
> Are you using -g1 ?  Might be https://gcc.gnu.org/PR94273

Yes, -g1 is in effect here (otherwise -debuginfo size blows up to 
astronomical sizes in this case).

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

qtwebengine FTBFS, gcc internal compiler error

[Rex Dieter]

Heads up in case anyone else hits this since apparently new gcc landed in 
rawhide last night (gcc-10.0.1-0.10.fc33)

Been working on/off for almost 2 weeks to get latest qtwebengine to build 
(and finally got all scratch builds to succeed last night), only to see this 
new failure this morning when doing a real build finally:

../../3rdparty/chromium/third_party/skia/src/core/SkOpts.cpp -o 
obj/skia/skia_core_and_effects/SkOpts.o
../../3rdparty/chromium/third_party/skia/src/core/SkOpts.cpp:142:1: internal 
compiler error: in splice_child_die, at dwarf2out.c:5657
  142 | }  // namespace SkOpts
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccVRVFG8.out file, please attach this 
to your bugreport.

Will file a bug later when I get a chance.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Change proposal discussion - Optimize SquashFS Size

[Rex Dieter]

John M. Harris Jr wrote:

> On Monday, February 10, 2020 10:53:45 AM MST Jared K. Smith wrote:
>> On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr 
>> 
>> wrote:
>> > As for the software available, that's called choice. I know
>> > it's a relative unknown in the GNOME world, as one option is shoved
>> > down everyones' throat, but it's a key part of the KDE ideology, as
>> > well as GNU/Linux itself.

>> John, it's obvious from your posts in this list that you're not a fan of
>> GNOME.  I'd kindly ask you to please refrain from attacking GNOME,
>> especially when the discussion at hand isn't about GNOME itself.  It's
>> not in keeping with the "be excellent to each other" spirit that Fedora
>> likes to keep in its mailing lists.

> An observation is not an attack. What I said about GNOME is simply true,
...

John,
It's the "is shoved down everyone's throat" comment that could be construed 
as hostile and non-constructive in this context.  (I certainly took it that 
way). 

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Rex Dieter wrote:

> Damian Ivanov wrote:
> 
>>>Bumping Qt versions is... a fairly difficult process in fedora,
>>>unfortunately.
>> 
>> Introducing a new Qt version could be very simple I think:
>> 1) Branch all Qt related packages (it should be with a one line
>> command or using a web interface)
>> 2) Edit package version number (with a per project (like Qt:5.14.1
>> project) macro - 1 digit changed/or two)
>> 3) Wait for packages to be published into repo (and that repo contains
>> all packages - without spec change - that use Qt priv headers).
>> 4) Fix eventual build failures due to re based patches etc.
>> 5) optional: Press push to start a request to get this merged into main
>> repo.
> 
> Building the core Qt packages is the easy part.  We have that largely
> scripted and semi-automated.
> 
> The (much) harder part is coordinating rebuilds of all the other packages
> that depend on private Qt5 api's  (I wish there weren't so many).

I suppose I could just make it easier on myself and just use rpmdev-bumpspec 
tool on dependencies too.  Historically, I've tried to make an effort to 
keep branches merged, at least for those packages/maintainers that prefer to 
do it that way.

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Damian Ivanov wrote:

>>Bumping Qt versions is... a fairly difficult process in fedora,
>>unfortunately.
> 
> Introducing a new Qt version could be very simple I think:
> 1) Branch all Qt related packages (it should be with a one line
> command or using a web interface)
> 2) Edit package version number (with a per project (like Qt:5.14.1
> project) macro - 1 digit changed/or two)
> 3) Wait for packages to be published into repo (and that repo contains
> all packages - without spec change - that use Qt priv headers).
> 4) Fix eventual build failures due to re based patches etc.
> 5) optional: Press push to start a request to get this merged into main
> repo.

Building the core Qt packages is the easy part.  We have that largely 
scripted and semi-automated.

The (much) harder part is coordinating rebuilds of all the other packages 
that depend on private Qt5 api's  (I wish there weren't so many).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Damian Ivanov wrote:

> But it's not the only CVE fixed with Qt 5.14.1
> The point is that there is other software using Qt which doesn't start
> with K even though K works just fine with 5.14 by the experience of other
> distributions.

Bumping Qt versions is... a fairly difficult process in fedora, 
unfortunately.  The primary reason is that there are many packages that use 
Qt private api's the require rebuilding for every release.  Quick check just 
now in rawhide is that a full Qt5 version update requires (re)building at 
least 78 packages.

So, we (kde-sign, Qt maintainers) generally update strategically where it 
makes sense to warrant the time investment in doing so.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Kevin Kofler wrote:

> Rex Dieter wrote:
>> Latest CVE there has a backported fix applied to fedora's packaging, and
>> is currently in bodhi updates-testing,
>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469
>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4
> 
> But that's only QtBase. QtWebEngine has dozens of security fixes again in
> 5.14.0 and 5.14.1 and our package is stuck on 5.13.2. (5.14.0 adds the
> fixes from Chrom* 78, 5.14.1 the ones from Chrom* 79. 5.13.2 only has
> security fixes up to Chrom* 77.)

QtBase was the primary CVE mentioned in the original link.

QtWebengine packaging is less restricted as far as updates and pretty sure 
that wasn't the point of the original post.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Latest CVE there has a backported fix applied to fedora's packaging, and is 
currently in bodhi updates-testing,
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469
https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 to handle circular build dependencies?

[Rex Dieter]

Markku Korkeala wrote:

> Hi,
> 
> sorry if this a newbie question, I tried to search this
> but did not find good documentation on this problem.
> 
> I'm in the process of upgrading the clojure package to
> next version, which has new dependencies. These dependencies
> require certain clojure version themselves, so it makes a
> chicken-and-egg kind of problem. Are there good ways to handle
> these kind of circular dependencies?

See if this helps,
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.14 rawhide

[Rex Dieter]

Damian Ivanov wrote:

> Qt 5.14 is out since November.

According to:
https://wiki.qt.io/Qt_5.14_Release

final release was not until Dec 12.  

Patience grasshopper.

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Rex Dieter]

Ben Cotton wrote:

> https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer

Maybe it should be obvious, but the feature page doesn't include details on 
how to manually enable(opt-in) or disable(opt-out) of the feature.  Please 
add that.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Development Tools problems for build from source Krita.

[Rex Dieter]

Cătălin George Feștilă wrote:

> I install 'Development Tools', but some tools are not in this group and
> PythonLibrary is not set. Any idea how to fix it? dnf group install

See below, the biggest missing piece is ECM, I'd suggest you do:

sudo dnf builddep krita

then you'll get everything that fedora's packaged krita builds against.

If you're missing ECM, you're likely missing a lot of other stuff too.

-- Rex

> -- Krita version: 4.2.8-beta1
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.5",
> minimum required is "3.0") -- Python system site-packages directory:
> /usr/lib64/python3.7/site-packages -- Could NOT find PythonLibrary
> (missing: PYTHON_LIBRARY) (Required is at least version "3.0") CMake Error
> at CMakeLists.txt:253 (find_package):
>   By not providing "FindECM.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "ECM", but
>   CMake did not find one.
> 
>   Could not find a package configuration file provided by "ECM" (requested
>   version 5.22) with any of the following names:
> 
> ECMConfig.cmake
> ecm-config.cmake
> 
>   Add the installation prefix of "ECM" to CMAKE_PREFIX_PATH or set
>   "ECM_DIR"
>   to a directory containing one of the above files.  If "ECM" provides a
>   separate development package or SDK, be sure it has been installed.
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/home/mythcat/krita-4.2.8-beta1/CMakeFiles/CMakeOutput.log".
> See also "/home/mythcat/krita-4.2.8-beta1/CMakeFiles/CMakeError.log".
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Python 2 exodus is happening now

[Rex Dieter]

Rex Dieter wrote:

> Miro Hrončok wrote:
> 
>> Dear maintainers,
>> here is an updated list of packages that (transitively, at build or run
>> time) require Python 2 and have not yet requested a FESCo exception to do
>> so. Packages with open exception requests have been excluded for now to
>> be able to finish the conversation with FESCo.
>> If you were bcced on this e-mail, it affects one or more of your
>> packages.
>> 
>> We are removing the packages from rawhide **now**.
> 
> python-qt5
> qscintilla
> sip
> 
> I'll take care of removing python2 subpackages for these now, I'd waited
> in case anything that depended on them had requested exceptions.

Sorry, forgot to include this too:
PyQt4

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Python 2 exodus is happening now

[Rex Dieter]

Rex Dieter wrote:

> Miro Hrončok wrote:
> 
>> Dear maintainers,
>> here is an updated list of packages that (transitively, at build or run
>> time) require Python 2 and have not yet requested a FESCo exception to do
>> so. Packages with open exception requests have been excluded for now to
>> be able to finish the conversation with FESCo.
>> If you were bcced on this e-mail, it affects one or more of your
>> packages.
>> 
>> We are removing the packages from rawhide **now**.
> 
> python-qt5
> qscintilla
> sip
> 
> I'll take care of removing python2 subpackages for these now, I'd waited
> in case anything that depended on them had requested exceptions.

ah, here's why,
hgview
https://bugzilla.redhat.com/show_bug.cgi?id=1738953

But that one hasn't asked for any exceptions yet as far as I'm aware of 
(someone holler if I missed anything).

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Python 2 exodus is happening now

[Rex Dieter]

Miro Hrončok wrote:

> Dear maintainers,
> here is an updated list of packages that (transitively, at build or run
> time) require Python 2 and have not yet requested a FESCo exception to do
> so. Packages with open exception requests have been excluded for now to be
> able to finish the conversation with FESCo.
> If you were bcced on this e-mail, it affects one or more of your packages.
> 
> We are removing the packages from rawhide **now**.

python-qt5
qscintilla
sip

I'll take care of removing python2 subpackages for these now, I'd waited in 
case anything that depended on them had requested exceptions.

-- Rex 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: calibre and hedgewars missed in qt5 5.12.5 update

[Rex Dieter]

Mattia Verga via devel wrote:

> Il 13/10/19 03:26, Kevin Fenzi ha scritto:
> 
>> On Sat, Oct 12, 2019 at 05:49:15PM -0700, Kevin Fenzi wrote:
>>
>> Except sadly, it doesn't build:
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=38248022
>> ...
>> * Running build
>> *
>> Fatal Python error: PyQt5.QtCore: Unable to embed qt.conf
>> /var/tmp/rpm-tmp.vEjk0u: line 31:  9198 Aborted (core
>> dumped) OVERRIDE_CFLAGS="-O2 -g -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
>> -fstack-protector-strong -grecord-gcc-switches
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a
>> -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux
>> -mfloat-abi=hard" /usr/bin/python2 setup.py build error: Bad exit status
>> from /var/tmp/rpm-tmp.vEjk0u (%build) ...
>>
>> kevin
>> ___
> 
> + /usr/bin/python2 setup.py build
> *
> * Running build
> *
> 
> Fatal Python error: PyQt5.QtCore: Unable to embed qt.conf
> 
> Hardcoded Python2 command in sources?

This should be fixed with
python-qt5-5.13.1-1.fc30
which is in bodhi and in f30-override tag now.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: calibre and hedgewars missed in qt5 5.12.5 update

[Rex Dieter]

Richard Shaw wrote:

> Just can fyi but at least two packages were missed in the updates:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a4f82aa58
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-80800c5c83
> 
> I can rebuild both (I maintain hedgewars) but can someone rebuild and push
> them directly in?

They (and newer sip/python-qt5) were built in f30-kde side tag, but I didn't 
communicate that well to my collaborator on the Qt 5.12.5 update (jgrulich), 
so they never got submitted to bodhi (at the time).

In the meantime, I submitted

python-qt5,sip :
 https://bodhi.fedoraproject.org/updates/FEDORA-2019-723f2b467f

but couldn't bundle calibre as someone had already submitted it seperately 
to bodhi,
https://bodhi.fedoraproject.org/updates/FEDORA-2019-a4aa28b798

I see a newer hedgewars already submitted, so that should be covered now 
too,
https://bodhi.fedoraproject.org/updates/FEDORA-2019-8c57e47e5e

sorry for the mess and confusion.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New updates straight to obsolete after Epoch bump?!?

[Rex Dieter]

Rex Dieter wrote:

> Appears to be a bodhi one

make that bodhi *bug*

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New updates straight to obsolete after Epoch bump?!?

[Rex Dieter]

Richard Shaw wrote:

> I messed up and build PySide2 5.13.x before I relealized that I should
> have built the latest 5.12.x as the MAJOR.MINOR has to match the version
> of Qt and we have not updated to 5.13 yet.
> 
> So I bumped the Epoch in the spec file and built 5.12.5 but when I
> submitted updates for f31 and 30 they pretty much went straight to
> obsolete. The auto-update for rawhide worked fine.
> 
> f31: https://bodhi.fedoraproject.org/updates/FEDORA-2019-51f88396ca
> f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-005d5f20fb
> 
> What's going on here?

Appears to be a bodhi one, one that folks are aware of and working ... where 
it allows an multiple updates for the same build, or zero builds.

See
https://bodhi.fedoraproject.org/updates/FEDORA-2019-521db81bfa

the one that's obsoleting things has no builds associated with it.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: packaging: upgrade a library to a header-only library

[Rex Dieter]

Miro Hrončok wrote:
> - cmake files usually go into %{_libdir} and such packages cannot be
> noarch as well

smart cmake noarch projects can use %{_datadir}/cmake instead

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Licensing of the bundled libraries

[Rex Dieter]

Michal Schorm wrote:

> Hello,
> 
> Q:
> Is it needed to explicitly list (or pack) license (files) of a library
> that a package bundles? [1]
> And if yes, what's the right way to do so?
> 
> The built package only contain 1 binary (and it's manpage and license
> file). In this case - when no sources are packed - I'd understand that
> it is sufficient to list and pack only the single license of the
> resulting project.
> Is that correct?

I think this faq should cover it:
https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F

In short, you have the option of either tracking the single 
aggregate/combined-work (effective) license, or listing licenses of 
individual components.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedora package in EPEL

[Rex Dieter]

Muneendra Kumar M via devel wrote:

> Hi All,
> 
> 
> 
> I want to have the fctxpd fedora package into the EPEL.
> 
> Iam the maintainer of this fctxpd package in fedora.
> 
> Can anyone help me how can I have the same package in EPEL also.

https://fedoraproject.org/wiki/EPEL/FAQ#How_do_I_get_my_packages_into_EPEL.3F

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Any plans for Qt 5.13.x?

[Rex Dieter]

Richard Shaw wrote:

> So I accidentally built PySide2 5.13.1 for Fedora and the MAJOR.MINOR
> parts are supposed to match with the version of Qt. So unless someone is
> planning to update Qt from 5.12.x to 5.13.x in the near future I'm going
> to have to bump the Epoch and downgrade to 5.12.5.

Plans... yes.  No immediate eta though

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: aarch64 toolchain regression?

[Rex Dieter]

Peter Robinson wrote:

>> > On Tue, Sep 3, 2019 at 8:27 AM Rex Dieter  wrote:
>> >> Builds that were previously succeeding (e.g. pulseaudio) are now
>> >> failing on aarch64 with errors like:
>> >> BUILDSTDERR: annobin: modules/module-loopback.c: ICE: Should be 64-bit
>> >> target
>> >
>> > See also:
>> >
>> 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UPERXTHFV5GOTPGD7H3JZ7UCHKWSEXQZ/
>> >
>> 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S5KHR5FDRHRA5RCSUU6KE56TWH22HFDB/
>> >
>>
>> Thanks, any bug(s) filed yet?  (If not, I'll do so today).
> 
> I'm not aware of a bug yet but please publish it here, I've asked the
> toolchain team @ Arm to take a look and apparently they already have a
> reproduccer.

Bug filed,

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

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: aarch64 toolchain regression?

[Rex Dieter]

Jerry James wrote:

> On Tue, Sep 3, 2019 at 8:27 AM Rex Dieter  wrote:
>> Builds that were previously succeeding (e.g. pulseaudio) are now failing
>> on aarch64 with errors like:
>> BUILDSTDERR: annobin: modules/module-loopback.c: ICE: Should be 64-bit
>> target
> 
> See also:
> 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UPERXTHFV5GOTPGD7H3JZ7UCHKWSEXQZ/
> 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S5KHR5FDRHRA5RCSUU6KE56TWH22HFDB/
> 

Thanks, any bug(s) filed yet?  (If not, I'll do so today).

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

aarch64 toolchain regression?

[Rex Dieter]

Builds that were previously succeeding (e.g. pulseaudio) are now failing on 
aarch64 with errors like:
BUILDSTDERR: annobin: modules/module-loopback.c: ICE: Should be 64-bit 
target


Failed scratch build:
https://userbase.kde.org/Konversation/Configuring_SASL_authentication

Prior successful build,
https://koji.fedoraproject.org/koji/buildinfo?buildID=1348793
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel

[Rex Dieter]

Rex Dieter wrote:

> Rex Dieter wrote:
> 
>> Miro Hrončok wrote:
>> 
>>> I'm hit by the above error in rawhide.
>>> 
>>> Is this expected or unexpected failure?
>> 
>> Since all qtbase really needs is the egl headers (and not pkgconfig
>> specifically), I went ahead and changed the dependency from
>> pkgconfig(egl)
>> to
>> libEGL-devel
>> instead.
> 
> And, now hitting *just* the libepoxy dep issue, filed related,
> https://bugzilla.redhat.com/show_bug.cgi?id=1744320
> against libepoxy, where they could consider workaround by adjusting away
> from pkgconfig dep to explicit libEGL-devel

I went ahead and made that change as threatened, 
https://bugzilla.redhat.com/show_bug.cgi?id=1744320#c3

and libepoxy/qt5-qtbase related builds should be unblocked for the moment

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel

[Rex Dieter]

Rex Dieter wrote:

> Miro Hrončok wrote:
> 
>> I'm hit by the above error in rawhide.
>> 
>> Is this expected or unexpected failure?
> 
> Since all qtbase really needs is the egl headers (and not pkgconfig
> specifically), I went ahead and changed the dependency from
> pkgconfig(egl)
> to
> libEGL-devel
> instead.

And, now hitting *just* the libepoxy dep issue, filed related,
https://bugzilla.redhat.com/show_bug.cgi?id=1744320
against libepoxy, where they could consider workaround by adjusting away 
from pkgconfig dep to explicit libEGL-devel

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: nothing provides pkgconfig(egl) needed by qt5-qtbase-devel

[Rex Dieter]

Miro Hrončok wrote:

> I'm hit by the above error in rawhide.
> 
> Is this expected or unexpected failure?

Since all qtbase really needs is the egl headers (and not pkgconfig 
specifically), I went ahead and changed the dependency from 
pkgconfig(egl) 
to
libEGL-devel
instead.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Pidgin on EPEL8

[Rex Dieter]

Vitaly Zaitsev via devel wrote:

> Hello all.
> 
> While building my Fedora packages for EPEL8, got a very strange error on
> aarch64 and s390x architectures:
> 
> No matching package to install: 'pkgconfig(pidgin)'
> 
> But it builds fine with the same SPEC on x86_64 and ppc64le.

Most obvious answer is that pidgin is simply not available for those archs 
(aarch64, s390x).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dropping -devel subpackage

[Rex Dieter]

Iñaki Ucar wrote:

> On Sun, 4 Aug 2019 at 15:01, Rex Dieter  wrote:
>>
>> Iñaki Ucar wrote:
>>
>> > On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
>> >>
>> >> > So the question is: should I add "Obsoletes: pkg-devel <
>> >> > $new_version" to pkg's SPEC? Is this a proper use of "Obsoletes"?
>> >>
>> >> Yes. Exactly a right thing to do.
>> >
>> > Thanks, Miro. Then, I suggest to add this particular case to the
>> > documentation. Not sure where though, but FWIW, my first search was
>> > "drop subpackage" and *not* the "Obsoletes" subsection.
>>
>> That case should already be covered by the "replace" part of:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
> 
> That's not clear to me. I read that in the first place, and I didn't
> identify this case either as a rename nor a replacement. A replacement
> is like bar that obsoletes foo. But here we have foo and
> foo-something, and at some point the latter is dropped (and not
> provided in foo).

Originally I'd considered that the *main* package was effectively replacing 
-devel, though on second thought it's not a full replacement (ie, only 
Obsoletes without Provides).

-- Rex

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dropping -devel subpackage

[Rex Dieter]

Iñaki Ucar wrote:

> On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
>>
>> > So the question is: should I add "Obsoletes: pkg-devel < $new_version"
>> > to pkg's SPEC? Is this a proper use of "Obsoletes"?
>>
>> Yes. Exactly a right thing to do.
> 
> Thanks, Miro. Then, I suggest to add this particular case to the
> documentation. Not sure where though, but FWIW, my first search was
> "drop subpackage" and *not* the "Obsoletes" subsection.

That case should already be covered by the "replace" part of:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: update hung in "pending" status

[Rex Dieter]

Mátyás Selmeci wrote:

> Hi,
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been
> stuck in "pending" status for several hours now.  Can someone kick them so
> they get into testing?

Updates generally get pushed to -testing at most once a day, nothing to 
kick... yet.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rolling out Phase I of rawhide package gating

[Rex Dieter]

Kevin Fenzi wrote:

> On 7/27/19 8:26 AM, Richard W.M. Jones wrote:
>> On Fri, Jul 26, 2019 at 04:08:40PM +0200, Pierre-Yves Chibon wrote:
>>> Yes and no, robosignatory is swamped signing the builds from the
>>> mass-rebuild, which means they aren't landing in the buildroot :(
>> 
>> This is still taking a really long time.  I built one package early
>> this morning which still hasn't gone into Rawhide probably 6+ hours
>> later.
> 
> Yeah, the mass rebuild finished yesterday, but signing didn't catch all
> the way up until last night. :(
> 
> In any case it should be all back to normal now.

I'm still seeing these in f31-updates-candidate, been there for over 24 
hours now:

f5-attica-5.60.0-2.fc31
kf5-bluez-qt-5.60.0-2.fc31
kf5-karchive-5.60.0-1.fc31
kf5-kcodecs-5.60.0-2.fc31
kf5-kcoreaddons-5.60.0-2.fc31
kf5-kguiaddons-5.60.0-2.fc31
kf5-kidletime-5.60.0-2.fc31
kf5-kitemmodels-5.60.0-2.fc31
kf5-kwayland-5.60.0-2.fc31
kf5-kwindowsystem-5.60.0-2.fc31
kf5-modemmanager-qt-5.60.0-2.fc31
kf5-networkmanager-qt-5.60.0-2.fc31
kf5-prison-5.60.0-2.fc31
kf5-solid-5.60.0-2.fc31
kf5-sonnet-5.60.0-2.fc31
kf5-syntax-highlighting-5.60.0-2.fc31

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: true or false: pkgconfig(foo) vs foo-devel

[Rex Dieter]

Remi Collet wrote:

> Le 18/07/2019 à 18:26, Nicolas Chauvet a écrit :
>>> "Build dependencies on Fedora packages which provide pkg-config files
>>> SHOULD be expressed
>>>  as pkgconfig(foo) and not foo-devel, whether the dependent package uses
>>>  pkg-config or not."
>> 
>> This is true for the fast majority of cases. Specially where there is
>> only one provider of pkgconfig(foo).
>> 
>> But sometime there is a need for a compat library and then I don't
>> know if my package may uses the main library of the compat one.
>> pkgconfig(foo) will pick one or the other, but using the package name
>> is more deterministic to me.
>> 
> 
> Indeed, pkgconfig(foo) start to raise issues when multiple providers
> exists.

I'd argue that should be a relatively (very?!?) rare case, and relying on 
pkgconfig(foo) is still generally the more simple and safe approach.

Of course exceptions exist where you have "reasons(tm)" to do otherwise.

In short, IMO, the guidelines to recommend use of pkgconfig provides are 
still good and valid.  Exceptional cases are simply that: exceptions, which 
can do otherwise provided they document the rationale in the .spec file.

-- Rex

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Lines disordered in mock's build.log

[Rex Dieter]

Miro Hrončok wrote:

> Hello,
> 
> I've noticed that last couple of weeks, I see disordered lines in mock's
> build.log. This happens constantly in local mock, copr and Koji. Example:

Are you using %make_build or at least 'make -O' ?

just 'make %{?_smp_mflags}' does have chances of getting ordering wrong 
without -O flag

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: CMake Error: file INSTALL cannot find

[Rex Dieter]

Martin Gansser wrote:

> Hi,
> 
> when compiling olive [1] on F30, i get this error message:
> 
> Install the project...
> /usr/bin/cmake -P cmake_install.cmake
> -- Install configuration: ""
> -- Installing:

Has it ever built successfully (on fedora)?

If not, this is a better question for your (olive) upstream.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedora 31 System-Wide Change proposal: Python means Python3

[Rex Dieter]

Rex Dieter wrote:

> Stephen John Smoogen wrote:
> 
>> Actually I think it makes more sense that F31 provides no
>> /usr/bin/python. Then a lot of things which depend on it can be found and
>> fixed since they have not adapted to the Future any other way.
> 
> I agree.

Apologies for not fully reading the proposal to realize this is a new 
upstream recommendation.  I withdraw any objection.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedora 31 System-Wide Change proposal: Python means Python3

[Rex Dieter]

Stephen John Smoogen wrote:

> Actually I think it makes more sense that F31 provides no /usr/bin/python.
> Then a lot of things which depend on it can be found and fixed since they
> have not adapted to the Future any other way.

I agree.

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [HEADS UP] Unannounced soname bump of qrencode

[Rex Dieter]

mcatanz...@gnome.org wrote:

> 
> Let's ensure this at least doesn't happen for the same library again
> and again.
> 
> In [1], change SHOULD NOT -> MUST NOT.
> 
> Require maintainers (or provenpackagers) to fix violations like [2]
> when unannounced soname bumps occur.

Then may be worth mentioning this is intended for libraries providing a 
public api, ie, private libraries are generally exempted.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Qt 5.12.3 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> I went ahead and kicked off a new build for 5.12.3.
> 
> On a side note, shouldn't we update f30 to 5.12.3? looking at the
> changelogs between 5.12.2 and 5.12.3 there's about 450 bugs fixed.
> 
> I recommend we do it in a side tag this time though :)

5.12.4 is coming soon, and will be done in a side tag for f30/f31, yes.

-- Rex
___
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: Qt 5.12.3 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> On Tue, Jun 4, 2019 at 6:30 AM Jan Grulich  wrote:
> 
>> Hi,
>>
>> I started update process in rawhide to update all Qt modules to 5.12.3
>> and later I will rebuild all packages depending on Qt private stuff. You
>> may experience build failures until the whole update process is done,
>> which should
>> be hopefully tomorrow.
>>
> 
> What's the current status of the rebuild? I just got PySide2 approved
> (still waiting on repo generation) and will need to update from 5.12.1 to
> 5.12.3.

should be complete now

-- Rex
___
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: Licence tag in spec files for final binaries or initial source code?

[Rex Dieter]

Nico Kadel-Garcia wrote:

>> > "The License: field refers to the licenses of the contents of the
>> > *binary* rpm."
>>
>> Thank you - somehow I missed that part.
>>
>> Felix
> 
> Shouldn't that depend on the license? The source code is normally
> contained in the SRPM. Would it make sense to segregate that source
> code into a different package with a distinct license, if possible?

No (imo, that would over-complicate things for little to no gain).

-- Rex
___
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: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

[Rex Dieter]

Miro Hrončok wrote:

>> So long as EPEL (and Rawhide, tbh) are under the aegis of Fedora, it
>> would be nice at least /some/ effort was made not to toss over
>> incompatible changes, or a broad need for dist conditionals, across the
>> package ecosystem with such cavilerity.
> 
> It's called branches.

And that's fine, being able to easily share .spec's between branches is 
still nice-to-have.

I still personally use and rely on synchronized .spec's (in most branches) a 
*lot*, and will likely continue to do so at leaste until I fully grok and 
embrace modules.

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

orphan compat-openssl10-pkcs11-helper

[Rex Dieter]

Once upon a time, qca needed this, but hasn't for quite awhile, so I'm no 
longer interested in maintaining compat-opensl10-pkcs11-helper

According to repoquery, one item (still) depends on it:
gnupg-pkcs11-scd

-- Rex
___
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: Orphaned packages need new maintainers (lot of nodejs deps will be retired next week)

[Rex Dieter]

Miro Hrončok wrote:

> The following packages are orphaned and will be retired when they
...
> Request package ownership via releng ticket:
> https://pagure.io/releng/issues

> lightdm-gtk   cwickert, dbenoit, orphan,   3 weeks

https://pagure.io/releng/issue/8315

-- Rex
___
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: dropping autogenerated dependency on pkg-config

[Rex Dieter]

Zbigniew Jędrzejewski-Szmek wrote:


> Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config
> (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
> 
> Note: autogenerated Provides/Requires like pkgconfig(foo) are not
> part of this proposal.
> 
> Advantages:
> - less entries in the dependency graph
> - removal of illogical dependency
> - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
> libpkgconf)
>   (Those packages are small, maybe 200k together so this isn't a strong
>reason.)
> 
> Disadvantages:
> - stuff that uses pkg-config or pkgconf will need to grow a dependency
>   (e.g. meson which invokes /usr/bin/pkg-config internally).
>   so there will be some churn.

The work required to fix packages affected by this disadvantage 
(potentially) far outweighs any advantage

Now, if the proposal includes offering to help do a some/most of the work to 
fix all these, then I withdraw the objection. 

-- Rex
___
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: update-desktop-database in %post snippet

[Rex Dieter]

Petr Mensik wrote:

> Is it still valid request to add update-desktop-database into %post,
> like mentioned by fedora-review tool [1]? Almost at the end of the
> comment. I were not able to find any information about it in Package
> Guidelines. 

Here's a link to relevant guideline,
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

(spoiler alert: no, update-desktop-database is no longer needed)

-- Rex
___
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: No rule to make target 'QtWebKit/QWebView', needed by ... ui_browser.h'

[Rex Dieter]

Martin Gansser wrote:

> webvfx [1] no longer compiles on F30 [2], F29 is ok.
> 
> /redhat/redhat-hardened-ld' 'QMAKE_LFLAGS_RELEASE=-Wl,-z,relro
> -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
> QMAKE_STRIP= PREFIX=/usr LIB_SUFFIX=lib64 ) && /usr/bin/make -f Makefile
> /usr/bin/make -f Makefile.Release
> BUILDSTDERR: make[2]: *** No rule to make target 'QtWebKit/QWebView',
> needed by
> 
'/builddir/build/BUILD/webvfx-1.0.0/build/release/.ui/browser/ui_browser.h'.
>  Stop. BUILDSTDERR: make[1]: *** [Makefile:42: release] Error 2
> 
> [1] https://src.fedoraproject.org/rpms/webvfx/blob/master/f/webvfx.spec
> [2] https://kojipkgs.fedoraproject.org//work/tasks/2551/34422551/build.log
> 
> How can i solve this ?

Pull in upstream fix for Qt 5.12 :

https://github.com/mltframework/webvfx/commit/87678ae90a297748ba6366febc524e78b873d43f

-- Rex
___
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: Policy regarding redundant dependencies

[Rex Dieter]

Georg Sauthoff wrote:

> Hello,
> 
> when packaging a C/C++ program, the rpm automatic dependency feature
> usually works well for shared libraries.
> 
> That mean when program 'bar' needs libfoo-devel at build time it's
> sufficient to add
> 
> BuildRequires: libfoo-devel
> 
> and I can omit
> 
> Requires: libfoo
> 
> because rpm automatically adds something like:
> 
> libfoo.so.1()(64bit)
> 
> Of course, I could still add a superfluous
> 
> Requires: libfoo
> 
> and then the resulting binary package would contain a redundant
> dependency like this:
> 
> libfoo
> libfoo.so.1()(64bit)
> 
> Has Fedora a policy against such redundant dependencies?

Yes, see
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_requires

-- Rex
___
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: /etc/yum.repos.d -> /etc/distro.repos.d

[Rex Dieter]

Dridi Boukelmoune wrote:

> Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d?

Please no, that will introduce it's own set of problems as well.

-- Rex
___
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: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)

[Rex Dieter]

Miro Hrončok wrote:

> Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be removing
> python2-sphinx and other related packages on Monday (2019-03-11).
...
> extra-cmake-modules  cicku dvratil heliocastro lkundrak rdieter

fixed extra-cmake-modules to use python3-sphinx, but ran into a bug where 
it fails, filed
https://bugzilla.redhat.com/show_bug.cgi?id=1687572

Disabling doc building on f31+ until that can be fixed.

-- Rex
___
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: Packaging Question - Building the Binaries of my package

[Rex Dieter]

Michael Zhang wrote:

> Recently, someone advised me that I have to build the binaries from the
> source code in the %install phase. That is to say that I have to make it
> transparent how the binaries (ex. jar) are built.

See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

-- Rex
___
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: Qt 5.12 coming to rawhide

[Rex Dieter]

Rex Dieter wrote:

> Continuing work in master branch (aka fc31)

The bulk of this work is now complete, sans a handful of leaf packages.  
Feel free to poke me if additional help is needed for those.

work in f30-kde koji target will continue 

-- Rex
___
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: Qt 5.12 coming to rawhide

[Rex Dieter]

Richard Shaw wrote:

> Was qt 5.12.x supposed to be done in a side tag

That was the original plan, but I gave up on that with the beta freeze 
quickly approaching.  My apologies.

-- Rex
___
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: Qt 5.12 coming to rawhide

[Rex Dieter]

Sérgio Basto wrote:

> On Fri, 2019-03-01 at 14:04 +0000, Rex Dieter wrote:
>> Continuing work in master branch (aka fc31), pending
> 
> I didn't understood , when or how can I test builds against  Qt 5.12 ?

You can't ... yet.  The work I'm doing is to import into rawhide (master 
branch).  Once that is complete, *then* you can build against it.

-- Rex
___
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: Qt 5.12 coming to rawhide

[Rex Dieter]

Vascom wrote:

> Will it be in F29?

Undecided, we'll see how smoothly the upgrade goes in f30 first.

Ideally, yes.

-- Rex

> пт, 1 мар. 2019 г. в 17:05, Rex Dieter :
>>
>> Continuing work in master branch (aka fc31), pending
>>
>> fc30 work will continue when
>> https://pagure.io/releng/issue/7966
>> is processed for a f30-kde koji target.  (Hopefully with enough time
>> prior to beta freeze)
>>
>> -- Rex
>> ___
>> 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
> ___
> 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

___
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: Qt 5.12 coming to rawhide

[Rex Dieter]

Continuing work in master branch (aka fc31), pending 

fc30 work will continue when
https://pagure.io/releng/issue/7966
is processed for a f30-kde koji target.  (Hopefully with enough time prior to 
beta freeze)

-- Rex
___
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: qt4 rebuild

[Rex Dieter]

Richard Shaw wrote:

> So I'm pretty much out of my league at this point. I can commit the
> Q_FOREACH patch if needed.

please do commit (or at least submit pull request).

-- Rex
___
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: qt4 rebuild

[Rex Dieter]

Richard Shaw wrote:

> I'm troubleshooting why apiextractor tests segfault during package
> building. I have not been able to attribute it to any change in build
> flags so I started looking at qt4 which appears to still be FTBFS for F30
> rebuild.
> 
> There's a check in the spec file which fails:
> 
> + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
> #define QT_BUILD_KEY "x86_64 linux g++-9 full-config"
> BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
> BUILDSTDERR: ++ cut '-d ' -f5
> QT_BUILD_KEY_COMPILER failure
> + QT_BUILD_KEY_COMPILER=g++-9
> + '[' g++-9 '!=' g++-4 ']'
> + echo 'QT_BUILD_KEY_COMPILER failure'
> + exit 1
> 
> It looks like after configuration that the "KEY" changed from g++4 to
> g++9.
> 
> Is this check appropriate?

The check is legit'ish.  In particular, afaik, the key should not have 
changed, so that should be fixed in qt4

-- Rex

___
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: Problem with cmake's PythonInterp in F29 and F28

[Rex Dieter]

Artur Iwicki wrote:

> I've got a package (colobot) which has a build-time dependency on Python3.
> The program had a new upstream release today, so I updated the spec file
> and fired up the builds.
> 
> Everything went smooth on rawhide and F30, whereas the F29 and F28 builds
> failed with a rather amusing error message:
>>BUILDSTDERR: CMake Error at
>>/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137
>>(message):
>>BUILDSTDERR:   Could NOT find PythonInterp: Found unsuitable version
>>"1.4", but required
>>BUILDSTDERR:   is at least "2.7" (found
>>BUILDSTDERR:  
>>/builddir/build/BUILD/colobot-colobot-gold-0.1.12-
alpha/build/%{__python3})
>>BUILDSTDERR: Call Stack (most recent call first):
>>BUILDSTDERR:  
>>/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376
>>(_FPHSA_FAILURE_MESSAGE)
>>BUILDSTDERR:   /usr/share/cmake/Modules/FindPythonInterp.cmake:159
>>(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>BUILDSTDERR:   data/CMakeLists.txt:6 (find_package)
>>-- Configuring incomplete, errors occurred!
> 
> So, uh, is this in issue with cmake, python3, the project's CMakeLists, or
> something totally different?

I'll take a look, but as an aside, I think something may be amiss with the 
colobot git repo... I'm trying to do a checkout, and it's taking ages for 
being so large.  It's at 35mb and only about 50% done so far.  Did you 
accidentally add sources to the git repo instead of lookaside source cache?

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

Qt 5.12 coming to rawhide

[Rex Dieter]

I will be working to import Qt 5.12.1 into rawhide soon, progress and blockers 
to be tracked at:
https://bugzilla.redhat.com/show_bug.cgi?id=1661849

A good an important thing, as not only is 5.12.x the latest, but also an LTS 
release as well.  Bonus points for (hopefully) fixing a FTBFS issue or 2 (e.g., 
qt5-qtbase-5.11.3 FTBFS currently).

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