e 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
>
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 include
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 libtoo
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
> > --s
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,
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 th
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 s
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
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++
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
&g
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 fi
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-
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
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.fedorapro
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
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):
>
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 need
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
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 ses
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:
>>>
>>
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-
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
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:
gstrea
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 dolph
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/sayona
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/doxy
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.
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
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 SI
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
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
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
>> >
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
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 see
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
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
>> >
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 fe
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
___
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
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 whe
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 shove
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 on
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 nu
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 fedor
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.or
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 mailin
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 vers
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
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
___
d
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
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
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
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 conversati
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 erro
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 p
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:
ht
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 u
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
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 sourc
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_p
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.
Pl
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
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
>> tar
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
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
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 dependen
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
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 ans
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 <
>&g
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 parti
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 ge
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
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
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 orderi
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 (
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 a
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
___
de
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 mentioni
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,
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 proces
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 segre
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 branc
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@lis
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
__
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:
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.fe
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
>
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
>
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 deve
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
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-
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
--
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 unsubscr
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 r
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 whe
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@lis
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 sen
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:
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 rath
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
1 - 100 of 702 matches
Mail list logo
