___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/
I am a little beyond the 8-week window for the "no-hassle" unretire, so I need
a new review for the fastbit packagethat I retired a few months ago. It's
already in the Fedora git tree. I have it building cleanly again and would
liketo resurrect it. I have gone over the review items locally,
>> OK, here's one at least. I have had to manually add -DPIC to the spec for
>> aarch64 in order to get
>> that arch to pass. There were no problems with it up until recently.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=37332928
>So I believe this is fixed with the rebuild on an
>> 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
>>You're much better off including a couple of koji tasks/packages
>>showing the issue, it's much easier to get some real context.
>OK, here's one at least. I have had to manually add -DPIC to the spec for
>aarch64 in order to get>that arch to pass. There were no problems with it up
>until r
>On Friday, August 30, 2019, 07:45:19 AM EDT, Peter Robinson
> wrote:
>On Thu, Aug 29, 2019 at 10:21 PM Philip Kovacs via devel
wrote:
>>
>> Several of us are getting errors in our c++ packages related to missing PIC
>> flags in aarch64.
>>
>> Som
Several of us are getting errors in our c++ packages related to missing PIC
flags in aarch64.
Something is amiss there. A small snippet from openmpi:
make[2]: Entering directory
'/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx'
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -DNDEBUG
Thanks Jerry -- what you describe is exactly what I am seeing in the build.log
Phil
On Thursday, August 29, 2019, 04:20:22 PM EDT, Jerry James
wrote:
On Thu, Aug 29, 2019 at 2:05 PM Philip Kovacs via devel
wrote:
> Is there something odd going on with arch aarch64 -- openmpi bui
Is there something odd going on with arch aarch64 -- openmpi builds are
failing on that arch.
On Thursday, August 29, 2019, 04:37:55 AM EDT, Zbigniew Jędrzejewski-Szmek
wrote:
Packages are now built. Update is submitted for F31
[https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f
> But there's not anything actually wrong anymore?\
>I'm not sure what else you would like me to do here...>kevin
Yeah it's all good now -- f30 and f29 are all in testing now. Thanks for
checking.Phil___
devel mailing list -- devel@lists.fedoraproje
encetaking care of this.
On Saturday, August 10, 2019, 04:40:31 PM EDT, Kevin Fenzi
wrote:
On 8/10/19 11:33 AM, Philip Kovacs via devel wrote:
> Just look at the updates pending pages. Here are f30 and f29, resp:
> https://bodhi.fedoraproject.org/updates/?releases=F30&st
On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel
wrote:
Why does it take days sometimes just to start the 7 day timer?
Can we have some examples to track this down? Because without that.. no idea
and no way to fix.
___
devel mailing list
Why does it take days sometimes just to start the 7 day timer? ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/projec
> It does not matter if the config process uses pkgconfig or not.
> Depending on the package name is not a way to state you're not using
> pkgconfig, it's a way to get broken builds when the package you depend
> on gets restructured.
Then the docs should be strengthened to state the case from
A "necessary and sufficient" question on the use of .pc files supplied by
library providers.
1. Package foo-devel installs a pkgconfig .pc file as a convenience to
developers.
2. Package bar requires headers and libraries provided by foo and is both a
build and runtime dependency of foo.3. Pa
It's likely the big endian emulation running on little endian machines which
is killing performance. I also have some time sensitive package tests failing
on s390x. On Thursday, July 11, 2019, 05:30:28 AM EDT, Peter Lemenkov
wrote:
Hello All,
Not sure if it's only me but every time
> On Wednesday, June 26, 2019, 02:42:29 AM EDT, Dan Horák
wrote:>
> what package is it?
fastbit. This evening I retired it in master since no upstream updates have
been issued since 02/2016.
https://src.fedoraproject.org/rpms/fastbit
The build problems are completely recent, nothing "
> On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
> wrote:
> Please quantify: What is the byte size of the .s file?
> First hint: give the virtual machine enough resources!
> Either RAM, or "swap" (paging) space.
The .s got up to about 375M before that particular g++ compile proce
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)files -- so large that any attempt to build them in
memory (e.g. with -pipe) causes memory exhaustion.The only way I have found to
reliably get the build to run to completion is by using -save-te
I use those macros wherever possible, but sometimes I need a raw `make`in
order to specify uncommon targets.
I'll just replace `__make` with `make` for now. No harm there.On
Wednesday, June 19, 2019, 12:06:44 PM EDT, Vitaly Zaitsev via devel
wrote:
Hello, Philip Kovacs via
sday, June 19, 2019, 11:31:24 AM EDT, Christophe de
Dinechin wrote:
> On 19 Jun 2019, at 17:28, Philip Kovacs via devel
> wrote:
>
> I notice I am still using the `__make` macro in my specs. While they still
> work, should we proactively replace them with `make` ?
What’s
I notice I am still using the `__make` macro in my specs. While they still
work, should we proactively replace them with `make` ?
The additional message I am getting here is that the under-under macros might
be subject to removal.
ThanksPhil___
devel m
OK, my builds are back in order having removed those macros and replaced them
with commands.
I expect that many package maintainers will be hit with this.
On Wednesday, June 19, 2019, 12:01:31 AM EDT, Neal Gompa
wrote:
On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
wrote
I'm getting new build failures on the autotools macros that had been working
for years. rpmbuild doesn't likethem anymore in rawhide. The macros are (or
were) in the file `/usr/lib/rpm/macros`. The relevant portion of my spec is
here:
-- spec -- %build%{__aclocal} -I auxdir%{__autoconf}%{__a
24 matches
Mail list logo
