Orion Poplawski wrote:
> With current koji buildroot I end up with:
>
> + ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd
> --w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld
> -rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd
> -rwxr-xr-x. 1 root root 3814880 Feb
With current koji buildroot I end up with:
+ ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd
--w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld
-rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd
-rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/ld.gold
The following Fedora EPEL 7 Security updates need testing:
Age URL
196 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
condor-8.6.11-1.el7
67 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b43fdd19c3
vcftools-0.1.16-1.el7
26
https://bugzilla.redhat.com/show_bug.cgi?id=1678345
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-App-FatPacker-0.010008 |perl-App-FatPacker-0.010008
On Wed, Feb 27, 2019 at 2:42 AM absolutezero wrote:
>
> Hello everyone!
>
> My name is Chilly. I am looking to bring back Snort IDS into the Fedora
> Project and maintain it for at least several years. I am relatively new to
> packaging but have been using Fedora for many years now as my daily
https://pagure.io/389-ds-base/pull-request/50248
https://pagure.io/389-ds-base/issue/50230
--
Sincerely,
William
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> On 27 Feb 2019, at 10:34, William Brown wrote:
>
> I did a merge for a PR, and now everything on pagure seems to have locked up?
Pagure reset, and when I tried again it froze again.
https://pagure.io/389-ds-base/pull-request/50244 is the PR I’m trying to merge.
I may just cherry-pick to
On Tue, 2019-02-26 at 22:44 +0100, Florian Weimer wrote:
> * Sérgio Basto:
>
> > stdio.h defines EOF as -1 , so if we want work with files
> > and use EOF character, we need use signed chars, though .
>
> No, this is not how it works.
>
> Most C interfaces (hopefully all of them, but I
https://bugzilla.redhat.com/show_bug.cgi?id=1678345
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
On Tue, 2019-02-26 at 16:09 -0800, Kevin Fenzi wrote:
> On 2/26/19 11:11 AM, Sérgio Basto wrote:
> > On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote:
> > > According to the Fedora 30 schedule[1], the 100% code complete
> > > deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3]
> > >
On 2/26/19 4:26 PM, William Brown wrote:
On 26 Feb 2019, at 18:32, Ludwig Krispenz wrote:
Hi, I need a bit of time to read the docs and clear my thoughts, but one
comment below
On 02/25/2019 01:49 AM, William Brown wrote:
On 23 Feb 2019, at 02:46, Mark Reynolds wrote:
I want to start a
On 2/26/19 11:11 AM, Sérgio Basto wrote:
> On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote:
>> According to the Fedora 30 schedule[1], the 100% code complete
>> deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3]
>> takes effect on this date as well. All Changes should be in
On 26. 02. 19 18:37, Ken Dreyer wrote:
On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote:
With that, I'm looking for co-maintainers for python-cherrypy. The
package is severely outdated and it seems there hasn't been any
significant contribution to this over the past 4 years. I may have
> On 26 Feb 2019, at 18:32, Ludwig Krispenz wrote:
>
> Hi, I need a bit of time to read the docs and clear my thoughts, but one
> comment below
> On 02/25/2019 01:49 AM, William Brown wrote:
>>
>>> On 23 Feb 2019, at 02:46, Mark Reynolds wrote:
>>>
>>> I want to start a brief discussion
There is already features in lib389 for managing aci, but due to the design of
aci in DS they are *super hard* to represent correctly in DSLdapObjects. I
think the existing lib389 aci code could be adapted to extend dsldapobject to
have some aci tranform capabilities, but they wouldn’t be
On Mon, Feb 25, 2019 at 9:51 PM Miro Hrončok wrote:
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
>
* Sérgio Basto:
> stdio.h defines EOF as -1 , so if we want work with files
> and use EOF character, we need use signed chars, though .
No, this is not how it works.
Most C interfaces (hopefully all of them, but I wouldn't be sure) that
use in-band signaling for EOF return ints. EOF is
* Tom Hughes:
> On 26/02/2019 19:42, Sérgio Basto wrote:
>
>> Is stdio.h that defines EOF as -1 , so if we what work with files and
>> use EOF character, we need use signed chars, though .
>
> No, you need to use int. The EOF value is deliberately outside the
> range of character values so that
On 2/11/19 10:03 AM, Mark Reynolds wrote:
https://pagure.io/389-ds-base/pull-request/50216
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Tue, 2019-02-26 at 20:52 +, Jonathan Wakely wrote:
> On 26/02/19 19:42 +, Sérgio Basto wrote:
> > On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote:
> > > On 26/02/19 13:28 +0100, Florian Weimer wrote:
> > > > * Sérgio Basto:
> > > >
> > > > > The key was "can't represent -1
On Tue, Feb 26, 2019 at 1:29 PM Jakub Jelinek wrote:
> No, see my other mail on what should be done.
>
Since the scratch build shows that the tests pass I'm tempted to disable
%check for now just to fix the FTBFS issue and re-enable when qt is fixed.
Thanks,
Richard
Richard Shaw wrote:
> Ok, I updated the patch the COMPILER_VERSION issue (committed) and have
> a local patch for the Q_FOREACH problem based on a qt 5 commit:
>
> https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b
>
> With both of those problems fixed the build still
Ok, I updated the patch the COMPILER_VERSION issue (committed) and have a
local patch for the Q_FOREACH problem based on a qt 5 commit:
https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b
With both of those problems fixed the build still fails probably due to gcc
9 being
On 26/02/19 19:42 +, Sérgio Basto wrote:
On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote:
On 26/02/19 13:28 +0100, Florian Weimer wrote:
> * Sérgio Basto:
>
> > The key was "can't represent -1 with an unsigned number" , I add
> > some sign char to the code [1] and it fix the FTBFS
On 26/02/2019 19:42, Sérgio Basto wrote:
Is stdio.h that defines EOF as -1 , so if we what work with files and
use EOF character, we need use signed chars, though .
No, you need to use int. The EOF value is deliberately outside the
range of character values so that EOF is not a valid
On Tue, Feb 26, 2019 at 11:38 AM Jakub Jelinek wrote:
> On Wed, Feb 27, 2019 at 02:29:32AM +0900, Mamoru TASAKA wrote:
> > Richard Shaw wrote on 2019/02/27 2:23:
> > > On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA <
> mtas...@fedoraproject.org>
> > > wrote:
> > >
> > > > So... I guess Qt
On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote:
> On 26/02/19 13:28 +0100, Florian Weimer wrote:
> > * Sérgio Basto:
> >
> > > The key was "can't represent -1 with an unsigned number" , I add
> > > some sign char to the code [1] and it fix the FTBFS
> > >
> > > Thanks ,
> > >
> > >
On Tue, 2019-02-26 at 06:22 +, Sérgio Basto wrote:
> On Fri, 2019-02-01 at 11:23 -0500, Neal Gompa wrote:
> > RepoView just needs a patch to switch from rpmUtils and yum.comps
> > to
> > rpm and libcomps Python bindings, which I think I already wrote and
> > put somewhere. I'll have to dig it
On Tue, Feb 26, 2019 at 01:25:54PM -0600, Richard Shaw wrote:
> > What I did is:
> >
> > LANG=C grep -rl 'foreach.*,' . | \
> > xargs sed -i -e '\@foreach.*,@s|foreach\(.*\),|for\1:|'
> >
> > So now I appreciate it if someone would investigate Q_FOREACH macro.
> >
>
> Thanks Mamoru! As
On Tue, Feb 26, 2019 at 11:39 AM Mamoru TASAKA
wrote:
> Mamoru TASAKA wrote on 2019/02/27 2:29:
> > Richard Shaw wrote on 2019/02/27 2:23:
> >> On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA <
> mtas...@fedoraproject.org>
> >> wrote:
> >>
> >>> So... I guess Qt "foreach" behavior changed with
On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote:
> According to the Fedora 30 schedule[1], the 100% code complete
> deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3]
> takes effect on this date as well. All Changes should be in "ON_QA"
> state by then.
I still haven't any
Hello everyone!
My name is Chilly. I am looking to bring back Snort IDS into the Fedora Project
and maintain it for at least several years. I am relatively new to packaging
but have been using Fedora for many years now as my daily driver. Doing my best
to follow to guide according to
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2019-02-27 from 18:00:00 to 19:00:00 GMT
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the
On Tue, Feb 26, 2019 at 10:27 AM Rex Dieter wrote:
> 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
Mamoru TASAKA wrote on 2019/02/27 2:29:
Richard Shaw wrote on 2019/02/27 2:23:
On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA
wrote:
So... I guess Qt "foreach" behavior changed with gcc9..
Is there any chance this will change or magically get fixed if qt is
rebuilt with gcc 9?
Thanks,
On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote:
> With that, I'm looking for co-maintainers for python-cherrypy. The
> package is severely outdated and it seems there hasn't been any
> significant contribution to this over the past 4 years. I may have been
> too optimistic with my available
On Wed, Feb 27, 2019 at 02:29:32AM +0900, Mamoru TASAKA wrote:
> Richard Shaw wrote on 2019/02/27 2:23:
> > On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA
> > wrote:
> >
> > > So... I guess Qt "foreach" behavior changed with gcc9..
> > >
> >
> > Is there any chance this will change or
Richard Shaw wrote on 2019/02/27 2:23:
On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA
wrote:
So... I guess Qt "foreach" behavior changed with gcc9..
Is there any chance this will change or magically get fixed if qt is
rebuilt with gcc 9?
Thanks,
Richard
Well, foreach or Q_FOREACH is
On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA
wrote:
> So... I guess Qt "foreach" behavior changed with gcc9..
>
Is there any chance this will change or magically get fixed if qt is
rebuilt with gcc 9?
Thanks,
Richard
___
devel mailing list --
John Reiser wrote on 2019/02/26 13:18:
That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on
Fedora 28 and Fedora 29.
Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure it's
the culprit).
The traceback says:
> 41
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
https://bugzilla.redhat.com/show_bug.cgi?id=1683336
Tom "spot" Callaway changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore
-lQtXmlPatterns -lQtXml)
plus an explicit libapiextractor.so.0.10.1. Did you run nine tests,
replacing the pieces
one-by-one with their Fedora 29 versions?
I'm not sure how to do that in a mock chroot...
On Tue, Feb 26, 2019 at 9:52 AM John Reiser wrote:
> > Is it definitely the linking? Or should I check the compiler arguments
> as well?
>
> There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore
> -lQtXmlPatterns -lQtXml)
> plus an explicit libapiextractor.so.0.10.1. Did you
@Matus Honek
Yes, I agree.
Perhaps we should open one ticket in pagur to track this issue ?
Regards
Anuj Borah
On Tue, Feb 26, 2019 at 9:12 PM Matus Honek wrote:
> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific
https://bugzilla.redhat.com/show_bug.cgi?id=1683336
Bug ID: 1683336
Summary: Upgrade perl-Text-Template to 1.55
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Text-Template
Assignee: tcall...@redhat.com
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
Is it definitely the linking? Or should I check the compiler arguments as well?
There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore
-lQtXmlPatterns -lQtXml)
plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, replacing
the pieces
one-by-one with their
On 20. 02. 19 23:24, Tomas Tomecek wrote:
Hello,
at DevConf.cz, we have introduced a new project: packit [1] [2].
[1] https://www.youtube.com/watch?v=KpF27v6K4Oc
[2] https://github.com/packit-service/packit
From the ticket:
>> FESCo is concerned that the presented idea of how this automation
This kinda leads me to thinking we should implement ACIs management
within the DSLdapObjects like this (probably specific to a particular
subclass, to a degree). One that would take care of this added
requirement for objectclass ACIs because of hidden .filter's behavour.
Because that is currently
According to the Fedora 30 schedule[1], the 100% code complete
deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3]
takes effect on this date as well. All Changes should be in "ON_QA"
state by then.
[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2]
According to the Fedora 30 schedule[1], the 100% code complete
deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3]
takes effect on this date as well. All Changes should be in "ON_QA"
state by then.
[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1683308
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
#fedora-meeting-3: Weekly Meeting of the Modularity Team
Meeting started by nils at 15:00:00 UTC.
Minutes:
On Tue, Feb 26, 2019 at 8:44 AM John Reiser wrote:
> > 'addedFunc' itself is 0 (NULL).
> > Substituting testvoidarg.cpp.o as compiled by
> gcc-8.2.1-6.fc28.x86_64 (from the same source)
> > gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is
> no longer a suspect.
> >
https://bugzilla.redhat.com/show_bug.cgi?id=1683308
Bug ID: 1683308
Summary: perl-Devel-PatchPerl-1.56 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Devel-PatchPerl
Keywords: FutureFeature,
On 26/02/19 13:28 +0100, Florian Weimer wrote:
* Sérgio Basto:
The key was "can't represent -1 with an unsigned number" , I add some sign char
to the code [1] and it fix the FTBFS
Thanks ,
[1]
https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch
'addedFunc' itself is 0 (NULL).
Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from
the same source)
gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no
longer a suspect.
I just performed a mockbuild for Fedora 29 and all tests passed...
On 26. 02. 19 15:07, Petr Šabata wrote:
On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote:
From:
https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
When you try to run:
mock -r fedora-rawhide-x86_64 shell
You will get:
Problem 1: conflicting requests
- nothing
On Tue, Feb 26, 2019 at 9:12 AM Miro Hrončok wrote:
>
> Long story short:
>
> - we've updated pycodestyle and broke flake8
> - we need to update flake8
> - we cannot update on python2
>
> Hence, I'd like to get rid of python2-flake8.
>
>
On 26/02/2019 14:08, Petr Šabata wrote:
I always wonder why people disable the repo -- it's part of
Fedora. What's your motivation?
I'm not using it and it's extra metadata to fetch, parse
and store that slows down updating?
That and on work machines we're not currently mirroring
modules to
Long story short:
- we've updated pycodestyle and broke flake8
- we need to update flake8
- we cannot update on python2
Hence, I'd like to get rid of python2-flake8.
https://src.fedoraproject.org/rpms/python-flake8/pull-request/4
We will probably just do it and deal with the breakage later.
On Mon, Feb 25, 2019 at 10:19 PM John Reiser wrote:
> > That test 'testvoidarg' succeeds for me (normal termination, no
> SIGSEGV) on Fedora 28 and Fedora 29.
> >
> >
> > Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure
> it's the culprit).
> >
> >
> > The
On Tue, Feb 26, 2019 at 02:41:56PM +0100, Fabio Valentini wrote:
> On Tue, Feb 26, 2019, 14:24 Miroslav Suchý wrote:
>
> > From:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
> >
> > When you try to run:
> > mock -r fedora-rawhide-x86_64 shell
> >
> > You will get:
> > Problem
On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote:
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
>
> When you try to run:
> mock -r fedora-rawhide-x86_64 shell
>
> You will get:
> Problem 1: conflicting requests
> - nothing provides module(platform:f30)
On Tue, Feb 26, 2019, 14:24 Miroslav Suchý wrote:
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
>
> When you try to run:
> mock -r fedora-rawhide-x86_64 shell
>
> You will get:
> Problem 1: conflicting requests
> - nothing provides module(platform:f30) needed by module
From:
https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
When you try to run:
mock -r fedora-rawhide-x86_64 shell
You will get:
Problem 1: conflicting requests
- nothing provides module(platform:f30) needed by module
stratis:1:20181215204600:a5b0195c-0.x86_64
Problem 2: conflicting
* Sérgio Basto:
> The key was "can't represent -1 with an unsigned number" , I add some sign
> char to the code [1] and it fix the FTBFS
>
> Thanks ,
>
> [1]
> https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch
Please note that this patch changes
On Mon, 2019-02-25 at 21:49 +0100, Miro Hrončok wrote:
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package
> or
> retire your depending package to avoid broken dependencies, otherwise your
https://bugzilla.redhat.com/show_bug.cgi?id=1683158
Bug ID: 1683158
Summary: stompclt-1.6 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: stompclt
Keywords: FutureFeature, Triaged
Assignee:
On 2/26/19 9:37 AM, Mosaab Alzoubi wrote:
Due to like-dead upstream and security issue, I orphan these packages:
apt
synaptic
fedora-package-config-apt
Thank you!
- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Tue, Feb 26, 2019 at 2:37 AM Mosaab Alzoubi wrote:
>
> Due to like-dead upstream and security issue, I orphan these packages:
>
> apt
I'll take this. Then it can be updated to latest apt-dpkg instead and
used for other things.
--
真実はいつも一つ！/ Always, there's only one truth!
Hi all.
I am plan to retire package kchildlock from Fedora.
It is KDE4 application long time unsupported and FTBFS on rawhide and F30.
If no one need it I will retire package in one week.
https://src.fedoraproject.org/rpms/kchildlock
https://store.kde.org/p/1127875/
Hi all.
I abandoned qblade packaging because upstream is unresponsive (as always).
Currently, qblade does not compile with gcc9.
Upstream project: https://sourceforge.net/projects/qblade/
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key:
Hi, I need a bit of time to read the docs and clear my thoughts, but one
comment below
On 02/25/2019 01:49 AM, William Brown wrote:
On 23 Feb 2019, at 02:46, Mark Reynolds wrote:
I want to start a brief discussion about a major problem we have backend
transaction plugins and the entry
Dne 20. 02. 19 v 10:02 Till Maas napsal(a):
> On Fri, Feb 15, 2019 at 04:28:17PM +0100, Vít Ondruch wrote:
>> Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a):
>>> * Hans de Goede [15/02/2019 12:09] :
And automatic scripts really just should hand it over to the first
co-maintainer
76 matches
Mail list logo
