There already is a fedora_active_user script of sorts
https://github.com/pypingou/fedora-active-user.
I would not be in favor of any respond or die automation. We volunteer our
time and effort to be packagersand the job is often thankless enough as it is.
Having some additional automation or
ant to find a way to automate notification that a maintainer is
unresponsive after a reasonably period, fine. Obsoleting their packages is
just wrong however. On Sunday, November 18, 2018, 4:45:00 AM EST, Mattia
Verga wrote:
Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
You wa
I am opposed to allowing PP unfettered access to projects in which the
maintainer(s) are responsive. It's common for developers to have artistic
(volatile) temperaments , like a painter who paints on canvas owned by someone
else. Does the owner have the right to change the color jars? Perhaps
s/do want/do NOT want
On Saturday, December 9, 2017 1:21 PM, Philip Kovacs
wrote:
I am opposed to allowing PP unfettered access to projects in which the
maintainer(s) are responsive. It's common for developers to have artistic
(volatile) temperaments , like a painter who pain
ber 9, 2017 2:13 PM, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want
>
> On Saturday, December 9, 2017 1:21 PM, Philip Kovacs
>wrote:
>
>
> I am opposed to allowing PP unfettered access to pro
at the maintainer is demonstrating "unchecked abusive
behavior."
For Pete's sake.
On Tuesday, December 12, 2017 7:09 AM, Graham Leggett
wrote:
On 09 Dec 2017, at 8:21 PM, Philip Kovacs wrote:
I am opposed to allowing PP unfettered access to projects in which the
Can we remove the gtk-update-icon-cache entries from our packages now,
manually, in advance of the mass update?
On Wednesday, January 3, 2018 11:10 AM, Charalampos Stratakis
wrote:
- Original Message -
> From: "Tomasz Kłoczko"
> To: "Development discussions related to Fedora
Any word on the performance hit before you push to stable? Is it discernible?
On Wednesday, January 3, 2018 8:15 PM, stan
wrote:
On Wed, 03 Jan 2018 15:02:11 -0800
Adam Williamson wrote:
> * We know that the fix can lead to reduced performance in some cases
> (this affects synthetic
Can someone please elaborate on how I can control the abi tests directly?Where
exactly can I access these and refine them on a per-package basis?
How to fix the tests?
The tests are all in your hand, you can fix the dist.depcheck and dist.abicheck
by adjusting the update or the build and you can
On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote:
>> Can someone please elaborate on how I can control the abi tests
>> directly?Where exactly can I access these and refine them on a per-
>> package basis?
>That text isn't talking about "fixing the tests&quo
I'm getting:
configure: error: C compiler cannot create executables
On Friday, January 26, 2018 1:53 AM, Ralf Corsepius
wrote:
Hi,
ATM all rawhide builds are failing for me, because autoconf's tests for
CC are failing.
Digging into details led me to this error:
...
cc1: error: fail t
Is Koschei eventually going to rebuild with the corrected gcc? I see
dependency changes after the last failed build, but Koschei hasn't rebuilt yet.
On Saturday, January 27, 2018 4:01 AM, Peter Robinson
wrote:
ATM all rawhide builds are failing for me, because autoconf's tests fo
False positive on project pmix. I checked my rawhide build logs for all six
arches and there is no `checking for c++`, as you report, in the autotools
configure output. The project is a C project and the spec properly lists
BuildRequires: gcc`. There is nothing wrong and nothing to do.
O
Ok, my configure.ac initializes libtool with both c and c++ :
LT_INIT()LT_LANG([C])LT_LANG([C++])
where only C is needed. There are no ill-effects other than producing some
noise in the configureoutput, but I will patch out the LT_LANG([C++]) line to
trim the noise.
On Sunday, February 18
The bind now issue is a real problem for some packages. I have interacted with
upstream countlesstimes on it and simply lost the fight. Please, whatever you
do, leave some route to disable bind now.
On Friday, February 23, 2018 10:55 AM, Florian Weimer
wrote:
I've seen a fair amount
My particular concern is not "missing" bind now flags in the elf objects. I am
concerned aboutmaking sure bind now is omitted because the package cannot
operate with that flag.
On Friday, February 23, 2018 11:35 AM, Florian Weimer
wrote:
On 02/23/2018 05:16 PM, Philip Ko
d, thousands or more nodes).
On Friday, February 23, 2018 12:26 PM, John Reiser
wrote:
Philip Kovacs wrote:
> My particular concern is not "missing" bind now flags in the elf objects. I
> am concerned about
> making sure bind now is omitted because the package ca
ents (from redhat-rpm-config).
>>
>> This will happen both in rawhide and Fedora 28.
>
> Are you also implementing a way to disable it, as Philip Kovacs asked
> for yesterday?
It's still for hardened builds only. Sorry, I should have mentioned
that. It's next to -
I would settle for knowledge of where the f29/rawhide gpg keys are hidden so I
import them.
The "To Rawhide" instructions below are outdated as they direct you to a page
where the f29/rawhideare not presented.
Upgrading Fedora using package manager - Fedora Project Wiki
|
| |
Upgrading
Yeah I'm living in the chaos of going from f28 rawhide to f29 rawhide.
Thanks for the tips.
On Saturday, March 3, 2018 5:26 PM, stan
wrote:
On Sat, 3 Mar 2018 21:15:22 + (UTC)
Philip Kovacs wrote:
> I would settle for knowledge of where the f29/rawhide gpg keys are
Alright I got around the catch-22 of dnf needing the f29 keys in order to
install the f29 keys with:
dnf install --nogpgcheck fedora-gpg-keys-29-0.1
That cleared the road for me.
On Saturday, March 3, 2018 5:41 PM, Philip Kovacs wrote:
Yeah I'm living in the chaos of going fro
Hello all. My name is Philip Kovacs and I would like to introduce myself.
I'm in the US and I've been in software development for more than 25 years. My
interests are in parallel and distributed computing, cloud, networking,
virtualization, container technology, performance monitor
Or use Fedora Copr to create personal repos for your projects. There is a lot
of utility in doing that,esp. when you start dealing with multiple boxes or
vms. Doing local installs directly from rpms doesnot scale and becomes tedious
very quickly. If you're writing or modifying the spec yours
One concern is that -Wl,--as-needed requires greater accuracy with the ordering
of objects and
libraries as you link. Also, if a package uses a library indirectly, i.e. A
uses C via B: A -> B -> C,--as-needed will peel away C and break A unless A
explicitly mentions its need for C. Of course
If I have version 1 of package foo, containing items bar, xxx, yyy, zzz, i.e.
foo-1-barxxxyyyzzz
and, for version 2, bar is split off to its own sub-package, foo-bar, so that
the desired packaging becomes:
foo-2 foo-bar-2- -xxx baryyyzzz
with foo-bar perma
PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 2017-12-02 at 10:25 +0100, Igor Gnatenko wrote:
> On Sat, 2017-12-02 at 09:24 +0100, Mattia Verga wrote:
> > Il 01/12/2017 20:20, Philip Kovacs ha scritto:
> > > If I have version 1 of package foo, containing items bar, xxx, yyy,
Is there a workaround or fix forthcoming for fedpkg?
$ fedpkg --helpTraceback (most recent call last): File "/usr/bin/fedpkg", line
6, in from pkg_resources import load_entry_point File
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3088, in
@_call_aside File
"/
/19/2018 03:21 PM, Philip Kovacs wrote:
> Is there a workaround or fix forthcoming for fedpkg?
>
>
> $ fedpkg --helpTraceback (most recent call last): File "/usr/bin/fedpkg",
> line 6, in from pkg_resources import load_entry_point File
> "/usr/lib/pyth
I got hit with this too on F28 using negativo17's nvidia driver
packages.Downgrading selinux-policy-3.14.1-25 /
selinux-policy-targeted-3.14.1-25 clears it up.There's a fedora update to
-3.14.1-29 pending:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
Too bad dnf doesn't allow
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 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
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
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
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
> 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
Unfortunately mpich now failed,
> so there'll be some delay. I'll submit one big update for F31 at the
> end.
>
> Zbyszek
>
>
> On Wed, Aug 28, 2019 at 06:19:36AM +, Philip Kovacs wrote:
> >
> > Are you going to submit f31 bodhi updates for these
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
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
>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
>>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
>> 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
>> 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
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,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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'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
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 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
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 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
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
> 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
> 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 "
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
53 matches
Mail list logo
