[Bug 1548611] New: perl-Net-GitHub-0.94 is available

[bugzilla]

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

Bug ID: 1548611
   Summary: perl-Net-GitHub-0.94 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-GitHub
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jpazdzi...@redhat.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.94
Current version/release in rawhide: 0.93-2.fc28
URL: http://search.cpan.org/dist/Net-GitHub/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3150/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548609] New: perl-Mojolicious-7.68 is available

[bugzilla]

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

Bug ID: 1548609
   Summary: perl-Mojolicious-7.68 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com



Latest upstream release: 7.68
Current version/release in rawhide: 7.67-1.fc29
URL: http://mojolicio.us/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5966/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548600] New: perl-DBIx-RunSQL-0.17 is available

[bugzilla]

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

Bug ID: 1548600
   Summary: perl-DBIx-RunSQL-0.17 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBIx-RunSQL
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.17
Current version/release in rawhide: 0.16-4.fc28
URL: http://search.cpan.org/dist/DBIx-RunSQL/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6560/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548597] New: perl-Class-C3-Componentised-1.001002 is available

[bugzilla]

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

Bug ID: 1548597
   Summary: perl-Class-C3-Componentised-1.001002 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Class-C3-Componentised
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest upstream release: 1.001002
Current version/release in rawhide: 1.001000-18.fc28
URL: http://search.cpan.org/dist/Class-C3-Componentised/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6739/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

23.02.2018 13:58 Jonathan Wakely  wrote:
>
>
> On 22/02/18 16:47 +0100, Rafal Luzynski wrote:
> >15.02.2018 12:02 Rafal Luzynski  wrote:
> >>
> >>
> >> 9.02.2018 11:34 Rafal Luzynski  wrote:
> >> > [...]
> >> > Please:
> >> > - backport the solution to F26 and F27 as well, this should be much
> >> > easier than in F28 (my pull requests may be helpful),
> >> > - mark my pull requests as merged/obsolete/whatever is appropriate,
> >> > - mark the bugzilla tickets as fixed (hopefully this is automatic).
> >>
> >> PING
> >>
> >> Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
> >> have been waiting for about 1.5 months now.
> >
> >PING^2
>
> Updates submitted for f26 and f27 now.

Indeed. Thank you Jakub, I have not noticed. And thank you Jonathan
for pushing it to bodhi, that made me notice the change.

> You might have noticed the GCC maintainer is a bit busy with rawhide,
> and compat-gcc-34 is not a high priority :-)

True, I've noticed and that's why I have prepared the patches and asked
in public anyone with sufficient privileges to accept them.

Thank you everybody for your participation and I hope it is correct now.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

I'm sorry, for the first time in decades I actually hit the send
key sequence (Ctrl-C Ctrl-C) accidentally.

> "JJ" == Jakub Jelinek  writes:

JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.

That's absolutely bizarre.

JJ> I can now get the coredumps, but I'm afraid I really need a way to
JJ> reproduce it under gdb, from the core dump there isn't sufficient
JJ> information available.

I just now found a way.  See below.

JJ> So, what is this squatter process about, with what command line
JJ> options is it invoked, how does it interact with other processes, is
JJ> it single-threaded?

It creates various search indices for the IMAP server (which is why it
wraps Xapian).  The manpage is available from
https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html
Technically the test suite simply creates the conditions for it to do
its work (in a randomly named directory) and then calls squatter
directly.  You should be able to see the arguments in the test suite's
output.

You can get down into the mock chroot and run tests manually:

mock -r fedora-rawhide-x86_64 --shell

and then enter:

su - mockbuild
cd /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane
export CYRUS_USER=$USER
export 
LD_LIBRARY_PATH=/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc29.x86_64/usr/lib64
rm -rf work; mkdir work
./testrunner.pl -vvv -f pretty SearchFuzzy.xapianv2

(You may have to adjust LD_LIBRARY_PATH there; using a glob fails to
work for me for reasons I don't understand.)

That will run just one test.  Down in the log you'll see something like:

=> Instance[1506] Running: 
"/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter" 
"-C" 
"/builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2322151/conf/imapd.conf"

A bit further you see the output from that process:

2322151/squatter[50141]: SQL backend defaulting to engine 'pgsql'
2322151/squatter[50141]: indexing mailboxes
2322151/squatter[50141]: indexing mailbox user.cassandane...

and at that point it segfaults.

If at this point you "rm -rf work/224058I1/search" (to clear out the
partially created search database) and then run:

/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C 
work/2322151/conf/imapd.conf

you should see the same segfault.  For me it does still segfault when
run under gdb, though you will have to delete that "search" directory
each time or the process won't fail.

JJ> What I can see is that the exc passed to _Unwind_Resume points to
JJ> some memory inside of the xapian_dbw_open C++ function's stack frame
JJ> which indeed contains multiple try/catch blocks, even nested ones;

That's about as far as I have been able to comprehend.

Just to be sure, I have done builds with fedora-rpm-macros and glibc
rolled back to the versions January 21 (the last successful koschei
build) and sadly things still fail in the same way.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Jared K. Smith]

On Fri, Feb 23, 2018 at 12:32 PM, Jeff Law  wrote:

> The fact that the 389-ds code works on other architectures does not
> allow us to draw any conclusions at this point.
>

Can you give any more details on 32-bit ARM in particular -- is it just
i686 that is experiencing issues, or have you seen similar memory
corruption issues on 32-bit ARM as well?

--
Jared Smith
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

I'm sorry, for the first time in decades I actually hit the send
key sequence (Ctrl-C Ctrl-C) accidentally.

> "JJ" == Jakub Jelinek  writes:

JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.

That's absolutely bizarre.

JJ> I can now get the coredumps, but I'm afraid I really need a way to
JJ> reproduce it under gdb, from the core dump there isn't sufficient
JJ> information available.

I just now found a way.  See below.

JJ> So, what is this squatter process about, with what command line
JJ> options is it invoked, how does it interact with other processes, is
JJ> it single-threaded?

It creates various search indices for the IMAP server (which is why it
wraps Xapian).  The manpage is available from
https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html
Technically the test suite simply creates the conditions for it to do
its work (in a randomly named directory) and then calls squatter
directly.  You should be able to see the arguments in the test suite's
output.

You can get down into the mock chroot and run tests manually:

mock -r fedora-rawhide-x86_64 --shell

and then enter:

su - mockbuild
cd /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane
export CYRUS_USER=$USER
export 
LD_LIBRARY_PATH=/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc29.x86_64/usr/lib64
rm -rf work; mkdir work
./testrunner.pl -vvv -f pretty SearchFuzzy.xapianv2

(You may have to adjust LD_LIBRARY_PATH there; using a glob fails to
work for me for reasons I don't understand.)

That will run just one test.  Down in the log you'll see something like:

=> Instance[1506] Running: 
"/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter" 
"-C" 
"/builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2322151/conf/imapd.conf"

A bit further you see the output from that process:

2322151/squatter[50141]: SQL backend defaulting to engine 'pgsql'
2322151/squatter[50141]: indexing mailboxes
2322151/squatter[50141]: indexing mailbox user.cassandane...

and at that point it segfaults.

If at this point you "rm -rf work/224058I1/search" (to clear out the
partially created search database) and then run:

/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C 
work/2322151/conf/imapd.conf

you should see the same segfault.  For me it does still segfault when
run under gdb, though you will have to delete that "search" directory
each time or the process won't fail.

JJ> What I can see is that the exc passed to _Unwind_Resume points to
JJ> some memory inside of the xapian_dbw_open C++ function's stack frame
JJ> which indeed contains multiple try/catch blocks, even nested ones;

That's about as far as I have been able to comprehend.

Just to be sure, I have done builds with fedora-rpm-macros and glibc
rolled back to the versions January 21 (the last successful koschei
build) and sadly things still fail in the same way.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

> "JJ" == Jakub Jelinek  writes:

JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.

That's absolutely bizarre.

JJ> I can now get the coredumps, but I'm afraid I really need a way to
JJ> reproduce it under gdb, from the core dump there isn't sufficient
JJ> information available.

And unfortunately I haven't been able to create one.

So, what is this squatter process about,
JJ> with what command line options is it invoked, how does it interact
JJ> with other processes, is it single-threaded?

JJ> What I can see is that the exc passed to _Unwind_Resume points to
JJ> some memory inside of the xapian_dbw_open C++ function's stack frame
JJ> which indeed contains multiple try/catch blocks, even nested ones;
JJ> but I find it strange that _Unwind_Exception objects would be on the
JJ> stack, they should be in malloced objects (at the end of
JJ> __cxa_exception e.g. for C++ exceptions), or come from the emergency
JJ> pool if malloc would fail (unlikely in this case).  The
JJ> _Unwind_Exception contains completely bogus values not just in one
JJ> field, but in all of them.

JJ> Jakub
JJ> ___ devel mailing list
JJ> -- devel@lists.fedoraproject.org To unsubscribe send an email to
JJ> devel-le...@lists.fedoraproject.org

-- 
 Jason L Tibbitts III - ti...@math.uh.edu - 713/743-3486 - 660PGH
 System Manager:  University of Houston Department of Mathematics 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1380983] Package metadata for perl-Gtk2-Unique lists the wrong URL, and the package itself is apparently deprecated.

[bugzilla]

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

Andrew Toskin  changed:

   What|Removed |Added

Version|26  |rawhide



--- Comment #2 from Andrew Toskin  ---
perl-Gtk2-Unique and perl-Gtk2-Unique-devel still use the old live.gnome.org
domain.

I wondered briefly if maybe the package should just be removed, if upstream
isn't developing it anymore. From a quick dnf repoquery, it seems only
pacmanager still requires perl-Gtk2-Unique, and nothing seems to require the
-devel package. But I'm not sure whether or how much pacmanager is still used.

At the very least, it would still make sense to update the package URL, as I
noted in my original comment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Pagure - Can't remove yourself from a project if not an admin?

[Richard Shaw]

On Mon, Feb 19, 2018 at 2:35 AM, Pierre-Yves Chibon 
wrote:

>
> Maybe I could help you in the mean time, feel free to ask.


Thanks for the offer but I emailed one of the admins and got myself removed.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

Some more information:

I looked through the Koschei logs for this package and it seemed it
actually started failing before gcc8 went in.  Specifically, the first
failed build was on January 22, and the changes for that run were:

mariadb-devel  3:10.2.12-2.fc28   -> 3:10.2.12-3.fc28
binutils   2.29.1-12.fc28 -> 2.29.1-13.fc28
glibc-common   2.26.9000-46.fc28  -> 2.26.9000-48.fc28
perl-DateTime-TimeZone 2.15-1.fc28-> 2.16-1.fc28
libxcrypt  4.0.0-0.203.2018012... -> 4.0.0-0.204.2018012...
glibc  2.26.9000-46.fc28  -> 2.26.9000-48.fc28
netpbm-progs   10.81.00-1.fc28-> 10.81.00-2.fc28
glibc-devel2.26.9000-46.fc28  -> 2.26.9000-48.fc28
libxcrypt-devel4.0.0-0.203.2018012... -> 4.0.0-0.204.2018012...
netpbm 10.81.00-1.fc28-> 10.81.00-2.fc28
ca-certificates2017.2.20-5.fc28   -> 2017.2.20-6.fc28
glibc-headers  2.26.9000-46.fc28  -> 2.26.9000-48.fc28
libnsl 2.26.9000-46.fc28  -> 2.26.9000-48.fc28
glibc-all-langpacks2.26.9000-46.fc28  -> 2.26.9000-48.fc28
perl-IO-Socket-SSL 2.052-1.fc28   -> 2.054-1.fc28
redhat-rpm-config  79-1.fc28  -> 84-1.fc28


The glibc and redhat-rpm-config updates are most interesting as the
latter changed the default compiler flags.  Unfortunately the log is no
longer available, nor is any log from any koschei run previous to gcc8
landing.

So I have more to investigate, including trying to roll back the
redhat-rpm-config changes.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 02:17:34PM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek  writes:
> 
> JJ> Well, I'm seeing
> [...]
> 
> So that's the first of the two test suites, which I've seen fail before
> but I haven't invested any time into debugging it.  It's completely
> unrelated to any of the failures I'm talking about.
> 
> You can just remove or comment the line "make check || exit 1" in the
> spec to skip that test suite and get down to the one that crashes.
> 
> JJ> Does it need networking outside of the mock (i.e. shall I retry with
> JJ> --enable-networking)?
> 
> There should be no need; it certainly doesn't need networking.  That's
> just a cunit-based test suite and outside of a couple of cases where I
> was randomly trying things to get better debugging for the unwinder
> segfault at hand, I've not had any real problems with it.

Strangely, --enable-network to mock was really needed so that the first 
testsuite
passes.

I can now get the coredumps, but I'm afraid I really need a way to reproduce
it under gdb, from the core dump there isn't sufficient information
available.  So, what is this squatter process about, with what command line
options is it invoked, how does it interact with other processes, is it
single-threaded?

What I can see is that the exc passed to _Unwind_Resume points to some
memory inside of the xapian_dbw_open C++ function's stack frame which
indeed contains multiple try/catch blocks, even nested ones; but I find
it strange that _Unwind_Exception objects would be on the stack, they should
be in malloced objects (at the end of __cxa_exception e.g. for C++
exceptions), or come from the emergency pool if malloc would fail (unlikely
in this case).  The _Unwind_Exception contains completely bogus values not
just in one field, but in all of them.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

> "JJ" == Jakub Jelinek  writes:

JJ> Well, I'm seeing
[...]

So that's the first of the two test suites, which I've seen fail before
but I haven't invested any time into debugging it.  It's completely
unrelated to any of the failures I'm talking about.

You can just remove or comment the line "make check || exit 1" in the
spec to skip that test suite and get down to the one that crashes.

JJ> Does it need networking outside of the mock (i.e. shall I retry with
JJ> --enable-networking)?

There should be no need; it certainly doesn't need networking.  That's
just a cunit-based test suite and outside of a couple of cases where I
was randomly trying things to get better debugging for the unwinder
segfault at hand, I've not had any real problems with it.

Thanks to tmz on IRC I have some independent verification of this (he
gets the same failures) and have a way to reproduce this inside mock
inside a docker container.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Enable dbus-broker

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote:
> Proposed System Wide Change: Enable dbus-broker
> https://fedoraproject.org/wiki/Changes/EnableDbusBroker

What about renaming this to DbusBrokerAsTheDefaultDbusImplementation?

"Enable" correctly describes the technical operation (systemctl invocation),
but it isn't obvious just from the title that this is about replacing
normal dbus daemon.

> == Scope ==
> * Proposal owners:
> ** Fix regressions.
> ** Enabledbus-broker.service in system and user-global context of
> systemd (via systemd presets).

> ** Pull in dbus-broker package from dbus package.
I'm not sure if this is the correct way to do this. People might want
to install systems with just normal dbus (e.g. in containers or minimal
installations). It'd be better to update comps [1] to pull in dbus-broker
instead of dbus into @Standard.

[Based on our preeliminary discussions]
This replaces the system wide bus and user busses.
What about the at-spi2 private dbus instance? Would dbus-broker be fast
enough to change gdm to use the user bus? Do you have plans to replace
this last use too?

If dbus-broker becomes the default like described in the Change page,
what other dependencies on dbus will remain?

Since this is already testable [2], what about asking for testing on
devel-announce@ and test-announce@ ? This is a pretty big change, and
I don't we can make the decision to use this by default without
widespread testing.

[1] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in
[2] https://fedoraproject.org/wiki/Changes/EnableDbusBroker#How_To_Test

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 11:54:28AM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek  writes:
> 
> JJ> Haven't managed to reproduce it, while there are some testsuite
> JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any
> JJ> segvs nor traps.
> 
> Of course I can reproduce this easily and it also happens in the
> buildsystem.  The first failure after the gcc update is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25054443 Note that
> it fails on all architectures except for s390x, and that succeeds only
> because the test suite is disabled there.

Well, I'm seeing
Suite: backend
  Test: badhost ...FAILED
1. cunit/unit.c:133  - CU_FAIL_FATAL("Code under test timed out")
  Test: badservice ...
unit: code under test 
(/builddir/build/BUILD/cyrus-imapd-3.0.5/cunit/backend.testc:test_badhost) 
timed out
passed
  Test: sasl_plain ...FAILED
1. cunit/unit.c:133  - CU_FAIL_FATAL("Code under test timed out")
  Test: sasl_digestmd5 ...
unit: code under test 
(/builddir/build/BUILD/cyrus-imapd-3.0.5/cunit/backend.testc:test_sasl_plain) 
timed out
FAILED
and many others, supposedly the issue you have is after this make check
and thus my mock build doesn't even reach there.
Does it need networking outside of the mock (i.e. shall I retry with
--enable-networking)?

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

> "JJ" == Jakub Jelinek  writes:

JJ> Haven't managed to reproduce it, while there are some testsuite
JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any
JJ> segvs nor traps.

Of course I can reproduce this easily and it also happens in the
buildsystem.  The first failure after the gcc update is
https://koji.fedoraproject.org/koji/taskinfo?taskID=25054443 Note that
it fails on all architectures except for s390x, and that succeeds only
because the test suite is disabled there.

Of course something could have changed in rawhide between now and when I
did this last night, so I'll rerun everything.  But I did do aw scratch
build (with an abbreviated test suite run) still shows the failures
which can be viewed here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25261672 Not that
it's useful to you unless you can get the cores out of koji.  (The s390x
build fails for different reasons.)

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

The package is slurm and the issue is their plugins.  It's a deep architectural 
problem unfortunately,To summarize the issue briefly:  When designing a plugin 
system, the services a plugin providesought not depend on the environment that 
loads it.  That is not the case for slurm.   Their pluginscontain symbols that 
refer back to the program that loads them. 
Suppose you have a plugin P loaded by programs A and B.   Slurm's plugins often 
contain symbols a in A and b in B.  When program A loads plugin P, the symbols 
b remain unresolved.  When program B loads plugin P, the symbols a remain 
unresolved.
I have spent hours supplying complex patches for them to "harden" and meet the 
bind now requirement,They acknowledge the problem but do not have enough 
customers complaining about it yet.  Slurm issoftware deployed in large HPC 
research centers typically (hundred, 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 cannot operate with that 
> flag.

Please tell us the name of the packages, and some indication of why
the package does not work with BIND_NOW.  Having specific information
might help to identify and understand a more-general situation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Marek Polacek]

On Fri, Feb 23, 2018 at 04:09:26PM +, Richard W.M. Jones wrote:
> On Thu, Feb 22, 2018 at 06:49:02PM +0100, Marek Polacek wrote:
> > libguestfs-1.37.35-2.fc28.src.rpm
> > I'm not sure about these failures, but they don't seem to be GCC bugs.
> 
> Is there a log file?

The one I have says
libvirt: XML-RPC error : Failed to connect socket to 
'/builddir/.cache/libvirt/libvirt-sock': No such file or directory
libguestfs: error: could not connect to libvirt (URI = qemu:///session): Failed 
to connect socket to '/builddir/.cache/libvirt/libvirt-sock': No such file or 
directory [code=38 int1=2]
libguestfs: trace: launch = -1 (error)
libguestfs: trace: close
libguestfs: closing guestfs handle 0x5646f5406a40 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf 
/builddir/build/BUILD/libguestfs-1.37.35/tmp/libguestfsfTNsVu
make: *** [Makefile:2906: quickcheck] Error 1

so it's probably another networking issue in mock.

Marek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Jeff Law]

On 02/23/2018 10:29 AM, Alexander Bokovoy wrote:
> On pe, 23 helmi 2018, Jeff Law wrote:
>> On 02/23/2018 09:58 AM, Randy Barlow wrote:
>>> Greetings gcc maintainers!
>>>
>>> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
>>> freeipa on 32 bit arches for Fedora 28. This was done without a change
>>> request being filed, so FESCo is trying to decide how best to handle it.
>>>
>>> It seems there are some concerns about whether the C tooling correctly
>>> handles some cases for 32-bit arches that led to the decision by the IPA
>>> maintainers to drop support for 32-bit. FESCo would like to ask for the
>>> GCC maintainers' input on the issue.
>>>
>>> Thanks in advance for your feedback!
>> GCC, binutils, etc all support 32-bit arches just fine.  THe current
>> thinking is there are serious concurrency concerns in the freeipa code
>> which are leading to the failures they were seeing on 32 bit platforms
>> (i686 in particular).
> To be clear there are concerns in 389-ds code that lead to data
> corruptions on i686. They aren't seen on other 32-bit platforms Fedora
> supports according to 389-ds developers.
Sorry to mis-characterize the problem.  It's the 389-ds code with the
concurrency concerns, not freeipa.

The fact that the 389-ds code works on other architectures does not
allow us to draw any conclusions at this point.  It really needs to go
through a root cause analysis to determine exactly why it is not working
correctly.  That will in turn tell us if it's the 389-ds code or
something in the compiler (or elsewhere) that is the problem.


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Alexander Bokovoy]

On pe, 23 helmi 2018, Jeff Law wrote:

On 02/23/2018 09:58 AM, Randy Barlow wrote:

Greetings gcc maintainers!

A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
freeipa on 32 bit arches for Fedora 28. This was done without a change
request being filed, so FESCo is trying to decide how best to handle it.

It seems there are some concerns about whether the C tooling correctly
handles some cases for 32-bit arches that led to the decision by the IPA
maintainers to drop support for 32-bit. FESCo would like to ask for the
GCC maintainers' input on the issue.

Thanks in advance for your feedback!

GCC, binutils, etc all support 32-bit arches just fine.  THe current
thinking is there are serious concurrency concerns in the freeipa code
which are leading to the failures they were seeing on 32 bit platforms
(i686 in particular).

To be clear there are concerns in 389-ds code that lead to data
corruptions on i686. They aren't seen on other 32-bit platforms Fedora
supports according to 389-ds developers.

FreeIPA has no choice as 389-ds-base was moved to exclude i686
architecture according to the process defined in Fedora.
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[John Reiser]

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 cannot operate with that 
flag.


Please tell us the name of the packages, and some indication of why
the package does not work with BIND_NOW.  Having specific information
might help to identify and understand a more-general situation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 10:56:47AM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek  writes:
> 
> JJ> Can I get detailed info on how to reproduce this (most importantly,
> JJ> which src.rpm you are trying to build)?
> 
> Sorry, that was all in the original message.
> 
> The package is cyrus-imapd; all you have to do is check it out and do
> fedpkg mockbuild (on the rawhide branch).  The test suite should
> generate 22 core files, each of which should give a mostly identical
> backtrace.  Unfortunately I can't get the crash to happen when running
> outside of mock.  I also can't get it when directly executing the
> crashing program while inside the chroot (via mock --shell); it has to
> be run by the test suite and in mock.  I haven't yet been able to figure
> out why.

Haven't managed to reproduce it, while there are some testsuite failures,
they are due to timeouts and e.g. dmesg doesn't show any segvs nor traps.

This was with mock -r fedora-rawhide-x86_64 ./cyrus-imapd-3.0.5-3.fc28.src.rpm

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Jeff Law]

On 02/23/2018 09:58 AM, Randy Barlow wrote:
> Greetings gcc maintainers!
> 
> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
> freeipa on 32 bit arches for Fedora 28. This was done without a change
> request being filed, so FESCo is trying to decide how best to handle it.
> 
> It seems there are some concerns about whether the C tooling correctly
> handles some cases for 32-bit arches that led to the decision by the IPA
> maintainers to drop support for 32-bit. FESCo would like to ask for the
> GCC maintainers' input on the issue.
> 
> Thanks in advance for your feedback!
GCC, binutils, etc all support 32-bit arches just fine.  THe current
thinking is there are serious concurrency concerns in the freeipa code
which are leading to the failures they were seeing on 32 bit platforms
(i686 in particular).

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

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 Kovacs wrote:
> 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.

Disable it for what?

The vast majority of missing BIND_NOW flags has been caused by 
accidentally dropped LDFLAGS settings.  (That, and firmware files which 
happen to be ELF.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

389-ds-base and freeipa on 32 bit arches

[Randy Barlow]

Greetings gcc maintainers!

A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
freeipa on 32 bit arches for Fedora 28. This was done without a change
request being filed, so FESCo is trying to decide how best to handle it.

It seems there are some concerns about whether the C tooling correctly
handles some cases for 32-bit arches that led to the decision by the IPA
maintainers to drop support for 32-bit. FESCo would like to ask for the
GCC maintainers' input on the issue.

Thanks in advance for your feedback!


[0] https://pagure.io/fesco/issue/1845
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1544386



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc27 has been pushed to the Fedora 27
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ccdb4a06f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

> "JJ" == Jakub Jelinek  writes:

JJ> Can I get detailed info on how to reproduce this (most importantly,
JJ> which src.rpm you are trying to build)?

Sorry, that was all in the original message.

The package is cyrus-imapd; all you have to do is check it out and do
fedpkg mockbuild (on the rawhide branch).  The test suite should
generate 22 core files, each of which should give a mostly identical
backtrace.  Unfortunately I can't get the crash to happen when running
outside of mock.  I also can't get it when directly executing the
crashing program while inside the chroot (via mock --shell); it has to
be run by the test suite and in mock.  I haven't yet been able to figure
out why.

To get the test suite run before rpm strips out all of the debug
information, you can just delete the %check line from the spec before
building.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: unresponsive maintainer procedure for konradm (Conrad Meyer)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 23, 2018 at 08:34:34AM -0800, Conrad Meyer wrote:
> On Fri, Feb 23, 2018 at 8:16 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > If anyone knows how to contact Conrad Meyer / konradm, please do so.
> >
> > Today one package owned by konradm, xchat-ruby, was retired as a result
> > of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks
> > if there is no response.
> >
> > [1] https://pagure.io/fesco/issue/1847
> 
> 
> Hi Zbigniew,
> 
> This is the very first email I've gotten on the subject.  I'm
> definitely still around.  I don't think the @tylerc.org address is
> still active, but I believe I changed my email address in all of the
> relevant project places.  Maybe not?

Hi,

it's great that this got resolved so quickly. Welcome back ;)

Please update your e-mail in FAS:
https://admin.fedoraproject.org/accounts/user/view/konradm.
I see that bugzilla is using a different address, so that's good.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: unresponsive maintainer procedure for konradm (Conrad Meyer)

[Conrad Meyer]

On Fri, Feb 23, 2018 at 8:16 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> If anyone knows how to contact Conrad Meyer / konradm, please do so.
>
> Today one package owned by konradm, xchat-ruby, was retired as a result
> of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks
> if there is no response.
>
> [1] https://pagure.io/fesco/issue/1847


Hi Zbigniew,

This is the very first email I've gotten on the subject.  I'm
definitely still around.  I don't think the @tylerc.org address is
still active, but I believe I changed my email address in all of the
relevant project places.  Maybe not?

Thanks,
Conrad
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Florian Weimer]

On 02/23/2018 05:16 PM, Philip Kovacs wrote:

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.


Disable it for what?

The vast majority of missing BIND_NOW flags has been caused by 
accidentally dropped LDFLAGS settings.  (That, and firmware files which 
happen to be ELF.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1082  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 845  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 427  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 324  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 156  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  93  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  43  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-069884a87f   
p7zip-16.02-10.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-72e5d3ef89   
suricata-4.0.4-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832   
seamonkey-2.49.2-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4   
mbedtls-2.7.0-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3   
knot-resolver-2.1.0-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1   
openjpeg2-2.3.0-6.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

datagrepper-0.9.1-2.el7
freexl-1.0.5-1.el7
lcgdm-1.10.0-5.el7
lynis-2.6.2-1.el7
meson-0.44.1-1.el7
nsd-4.1.20-1.el7
php-cs-fixer-2.2.17-1.el7
python-toml-0.9.4-3.el7
spglib-1.10.3-1.el7

Details about builds:



 datagrepper-0.9.1-2.el7 (FEDORA-EPEL-2018-954236b0e6)
 A webapp to query fedmsg history

Update Information:

Latest upstream.




 freexl-1.0.5-1.el7 (FEDORA-EPEL-2018-9111777f91)
 Library to extract data from within an Excel spreadsheet

Update Information:

Fixes several heap-buffer-overflows, see related Bugzilla tickets!

References:

  [ 1 ] Bug #1547892 - heap-buffer-overflow in freexl.c:3912 
read_mini_biff_next_record of FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547892
  [ 2 ] Bug #1547889 - heap-buffer-overflow in freexl.c:383 
parse_unicode_string of FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547889
  [ 3 ] Bug #1547885 - heap-buffer-overflow in freexl.c:1866 parse_SST of 
FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547885
  [ 4 ] Bug #1547883 - heap-buffer-overflow in freexl.c:1805 parse_SST parse_SST
https://bugzilla.redhat.com/show_bug.cgi?id=1547883
  [ 5 ] Bug #1547879 - heap-buffer-overflow in freexl::destroy_cell of FreeXL 
1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547879




 lcgdm-1.10.0-5.el7 (FEDORA-EPEL-2018-a914bf925b)
 LHC Computing Grid Data Management

Update Information:

* new upstream release    * new upstream release




 lynis-2.6.2-1.el7 (FEDORA-EPEL-2018-d7a6cbf9d8)
 Security and system auditing tool

Update Information:

Update to 2.6.2 (rhbz #1539272)    Update to 2.6.1 (rhbz #1539272)

References:

  [ 1 ] Bug #1539272 - lynis-2.6.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1539272




 meson-0.44.1-1.el7 (FEDORA-EPEL-2018-9e6b270e6f)
 High productivity build system

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 954  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 845  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 816  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 427  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 156  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc1949f307   
p7zip-16.02-10.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be69c94866   
clamav-0.99.3-8.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9   
seamonkey-2.49.2-2.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5   
mbedtls-2.7.0-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6ac908eac8   
openjpeg2-2.3.0-6.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

freexl-1.0.5-1.el6
lcgdm-1.10.0-5.el6
lynis-2.6.2-1.el6
nsd-4.1.20-1.el6

Details about builds:



 freexl-1.0.5-1.el6 (FEDORA-EPEL-2018-2ffe688829)
 Library to extract data from within an Excel spreadsheet

Update Information:

Fixes several heap-buffer-overflows, see related Bugzilla tickets!

References:

  [ 1 ] Bug #1547892 - heap-buffer-overflow in freexl.c:3912 
read_mini_biff_next_record of FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547892
  [ 2 ] Bug #1547889 - heap-buffer-overflow in freexl.c:383 
parse_unicode_string of FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547889
  [ 3 ] Bug #1547885 - heap-buffer-overflow in freexl.c:1866 parse_SST of 
FreeXL 1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547885
  [ 4 ] Bug #1547883 - heap-buffer-overflow in freexl.c:1805 parse_SST parse_SST
https://bugzilla.redhat.com/show_bug.cgi?id=1547883
  [ 5 ] Bug #1547879 - heap-buffer-overflow in freexl::destroy_cell of FreeXL 
1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1547879




 lcgdm-1.10.0-5.el6 (FEDORA-EPEL-2018-6127fa810f)
 LHC Computing Grid Data Management

Update Information:

* new upstream release    * new upstream release




 lynis-2.6.2-1.el6 (FEDORA-EPEL-2018-2d5fccbc12)
 Security and system auditing tool

Update Information:

Update to 2.6.2 (rhbz #1539272)    Update to 2.6.1 (rhbz #1539272)

References:

  [ 1 ] Bug #1539272 - lynis-2.6.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1539272




 nsd-4.1.20-1.el6 (FEDORA-EPEL-2018-4596dd47c4)
 Fast and lean authoritative DNS Name Server

Update Information:

Updated to 4.1.20 (fixup memory leaks)

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc26 has been pushed to the Fedora 26
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5ea674b664

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

unresponsive maintainer procedure for konradm (Conrad Meyer)

[Zbigniew Jędrzejewski-Szmek]

Hi,

If anyone knows how to contact Conrad Meyer / konradm, please do so.

Today one package owned by konradm, xchat-ruby, was retired as a result
of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks
if there is no response.

[1] https://pagure.io/fesco/issue/1847

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

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 of LDFLAGS injection failures related to 
libtool.  For the most part, 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a 
lack of BIND_NOW in the resulting binary.

Is there a way we can fix this in libtool or the auto* tools?  I'm also 
considering moving -Wl,-z,now to the command line from the GCC specs 
file, which might help here, too.  But I'd prefer a direct, unfiltered 
channel from redhat-rpm-config to the linker invocation in case we need 
to inject additional flags.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Richard W.M. Jones]

On Thu, Feb 22, 2018 at 06:49:02PM +0100, Marek Polacek wrote:
> libguestfs-1.37.35-2.fc28.src.rpm
> I'm not sure about these failures, but they don't seem to be GCC bugs.

Is there a log file?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Summary/Minutes for today's FESCo Meeting (2018-02-23)

[Kevin Fenzi]

===
#fedora-meeting: FESCO (2018-02-23)
===


Meeting started by nirik at 15:08:16 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2018-02-23/fesco.2018-02-23-15.08.log.html
.



Meeting summary
---
* init process  (nirik, 15:08:17)

* #1714 Fedora 26 spins process was missed  (nirik, 15:10:25)
  * LINK: https://pagure.io/fesco/issue/1714   (nirik, 15:10:26)
  * LINK: https://fedoraproject.org/wiki/Astronomy_Spin has an owner
section, do the others?  (bowlofeggs, 15:21:15)
  * AGREED: FESco will create the pages and asking on devel and spins
lists to populate it and require testing at beta to stay in.
(+5,0,0)  (nirik, 15:25:58)

* #1845 389-ds-base and freeipa on 32 bit arches  (nirik, 15:26:09)
  * LINK: https://pagure.io/fesco/issue/1845   (nirik, 15:26:09)
  * AGREED: Ask the GCC team to try to help find the source of the
corruption.  Post to the -devel list to let people know the
situation.  Revisit in two weeks. (+5,0,0)  (nirik, 15:34:43)
  * ACTION: bowlofeggs to mail devel and gcc maintainers to make them
aware of the converstation in bugs.  (nirik, 15:40:17)

* #1846 F28 approved Changes not in MODIFIED status (considered as not
  testable)  (nirik, 15:40:42)
  * LINK: https://pagure.io/fesco/issue/1846   (nirik, 15:40:42)
  * AGREED: changes wishing to defer to f29 can do so now, the rest we
revisit next week for response or testable. (+5,0,0)  (nirik,
15:47:01)

* #1847 Request Permission to Retire w/o Responsive Maintainer  (nirik,
  15:47:21)
  * LINK: https://pagure.io/fesco/issue/1847   (nirik, 15:47:21)
  * AGREED: proceed immediately with retiring xchat-ruby, and open the
procedure on fedora-devel for nonresponisve maintainer (+5,0,0)
(nirik, 15:50:27)
  * ACTION: zbyszek to retire xchat-ruby and start non responsive
process for developer.  (nirik, 15:52:58)

* #1848 Request to Authorize Removal of Blender Source Tarballs from
  Incorrect Place in Repository  (nirik, 15:53:05)
  * LINK: https://pagure.io/fesco/issue/1848   (nirik, 15:53:05)
  * AGREED: defer this another week for more discussion. (+5,0,0)
(nirik, 15:57:17)

* next weeks chair  (nirik, 15:57:22)
  * zbyszek to chair next week  (nirik, 15:59:30)

* Open Floor  (nirik, 15:59:34)

Meeting ended at 16:04:50 UTC.




Action Items

* bowlofeggs to mail devel and gcc maintainers to make them aware of the
  converstation in bugs.
* zbyszek to retire xchat-ruby and start non responsive process for
  developer.




Action Items, by person
---
* bowlofeggs
  * bowlofeggs to mail devel and gcc maintainers to make them aware of
the converstation in bugs.
* zbyszek
  * zbyszek to retire xchat-ruby and start non responsive process for
developer.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (86)
* bowlofeggs (40)
* zbyszek (30)
* jsmith (26)
* jwb (22)
* zodbot (13)
* tyll (0)
* sgallagh (0)
* maxamillion (0)
* dgilmore (0)
--
15:08:16  #startmeeting FESCO (2018-02-23)
15:08:17  #meetingname fesco
15:08:17  #chair maxamillion dgilmore nirik  jsmith sgallagh
bowlofeggs tyll jwb zbyszek
15:08:17  #topic init process
15:08:17  Meeting started Fri Feb 23 15:08:16 2018 UTC.  The
chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:17  Useful Commands: #action #agreed #halp #info #idea
#link #topic.
15:08:17  The meeting name has been set to 'fesco_(2018-02-23)'
15:08:17  The meeting name has been set to 'fesco'
15:08:17  Current chairs: bowlofeggs dgilmore jsmith jwb
maxamillion nirik sgallagh tyll zbyszek
15:08:21  who all is around?
15:08:26  .hello2
15:08:27  jsmith: jsmith 'Jared Smith' 
15:08:27  hello (again)
15:08:43  .hello2
15:08:44  zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek'

15:09:39  we need 1 more I guess for quorum... bowlofeggs ?
15:10:02  .hello2
15:10:02  bowlofeggs: bowlofeggs 'Randy Barlow' 
15:10:15  cool. Lets go ahead and start then.
15:10:25  #topic #1714 Fedora 26 spins process was missed
15:10:26  .fesco 1714
15:10:26  https://pagure.io/fesco/issue/1714
15:10:28  nirik: Issue #1714: Fedora 26 spins process was missed
- fesco - Pagure - https://pagure.io/fesco/issue/1714
15:10:53  maxamillion was going to make these pages... but seems not.
15:10:58  Isn't this just a question of manpower? I.e.
everybody thinks this page should exist, but nobody is volunteering?
15:11:09  I can just do so... but that brings up the question if
we want to change the process any
15:11:31  zbyszek: that and the "process" is pretty poorly
documented/understood I think...
15:11:52  right now I guess fesco is supposed to make the page...
but that doesn't give a clear action to one person who will do it.
15:12:31  we could do a divide and conquer, unless that
would cause inconsistency
15:13:24  i'd do 

libtool and LDFLAGS build flags injection

[Florian Weimer]

I've seen a fair amount of LDFLAGS injection failures related to 
libtool.  For the most part, 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a 
lack of BIND_NOW in the resulting binary.


Is there a way we can fix this in libtool or the auto* tools?  I'm also 
considering moving -Wl,-z,now to the command line from the GCC specs 
file, which might help here, too.  But I'd prefer a direct, unfiltered 
channel from redhat-rpm-config to the linker invocation in case we need 
to inject additional flags.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Todd Zullinger]

Tom Hughes wrote:
> On 23/02/18 14:33, Paul Howarth wrote:
>> On Thu, 22 Feb 2018 18:49:02 +0100
>> Marek Polacek  wrote:
>>>  proftpd: timeouts in tests, but in koji it's fine
>> 
>> I get this too. If I build with mock --old-chroot then it works fine.
> 
> So the obvious difference is that mock with --old-chroot has networking
> enabled while the default (ie --new-chroot) does not.
> 
> Does --enable-network also make it work?
> 
> That doesn't explain koji though, as that has networking disabled.

I don't know if this is the same issue, but I noticed that
in local mock builds of git, some tests were very slow.  The
tests that were slow were suffering from socket timeouts
while making calls to getaddrinfo (to get the local
hostname, for determining the default git user identity).

I added --private-network to the nspawn_args in the mock
config which eliminated the 5 second timeouts for each of
these calls.

I made a comment to remind myself about it later:

# NOTE (tmz): This should still be the default, I think.  Without it, network
# calls timeout rather than fail quickly.  The typical default socket timeout is
# 5 seconds.  A simple call like 'git var GIT_AUTHOR_IDENT' saw 4 socket
# timeouts and takes 20 seconds to return.  With this option, it takes
# milliseconds.
#
# See https://github.com/rpm-software-management/mock/issues/113 where this was
# partially dealt with.  Unfortunately, the solution there sets a default route
# to 127.0.0.1 but copies /etc/resolv.conf from the host system -- regardless of
# the use_host_resolv setting because systemd-nspawn overrides mock and copies
# the system /etc/resolf.conf to the container.  There seems to be no option
# other than --private-network to avoid this.

I haven't had time to look at it further to see if there are
any patches worth submitting to improve the situation (in
mock and/or systemd-nspawn).

-- 
Todd
~~
Men have become the tools of their tools.
-- Henry David Thoreau (1817-1862)



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Tom Hughes]

On 23/02/18 14:33, Paul Howarth wrote:

On Thu, 22 Feb 2018 18:49:02 +0100
Marek Polacek  wrote:

 proftpd: timeouts in tests, but in koji it's fine


I get this too. If I build with mock --old-chroot then it works fine.


So the obvious difference is that mock with --old-chroot has networking
enabled while the default (ie --new-chroot) does not.

Does --enable-network also make it work?

That doesn't explain koji though, as that has networking disabled.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1547327] perl-Scalar-List-Utils-1.50 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-02-23 10:02:45



--- Comment #1 from Jan Pazdziora  ---
Built to rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=25258320.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

cfitsio update to 3.420 with so version bump

[Christian Dersch]

Hi folks,

I'm going to update cfitsio to new version 3.420 this weekend on F28+, this 
includes a library version bump to 5. As there were no API changes, everything 
should rebuild fine, I made some test builds so far. I'll take care of the 
required rebuilds.

Affected packages (many of these my own ones):
* CCfits
* astrometry
* bes
* cpl
* healpix
* gdal
* indi-apogee
* indi-gphoto
* indi-sx
* kst
* kstars
* libindi
* luminance-hdr
* nightview
* perl-Astro-FITS-CFITSIO
* phd2
* python-astropy
* python-fitsio
* python-pyfits
* root
* siril
* skyviewer
* ufraw
* vips
* wcslib

Greetings,
Christian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Paul Howarth]

On Thu, 22 Feb 2018 18:49:02 +0100
Marek Polacek  wrote:
> proftpd: timeouts in tests, but in koji it's fine

I get this too. If I build with mock --old-chroot then it works fine.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Tom Hughes]

On 23/02/18 13:16, Jakub Jelinek wrote:

On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:

Looking at the code:
= gcc/libgcc/unwind.inc
  _Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
   struct _Unwind_Context *context,
   unsigned long *frames_p)
  {
_Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc->private_1;
  <>
stop_code = (*stop) (1, action, exc->exception_class, exc,
 context, stop_argument);
=
we see that function pointer 'stop' is cast from an untyped word 'private_1'
with no checking at all, not even for NULL or < PAGE_SIZE, etc.
This is a giant red flag for unreliable code.


Wrong.  Just look at what the callers do:
   if (exc->private_1 == 0)
 code = _Unwind_RaiseException_Phase2 (exc, _context, );
   else
 code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
and
   if (exc->private_1 == 0)
 return _Unwind_RaiseException (exc);

   uw_init_context (_context);
   cur_context = this_context;

   code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
So, _Unwind_ForcedUnwind_Phase2 is not called if private_1 is NULL.


Judging by the valgrind report it is undefined, and likely has the
value 0x120 or something close to that, which is clearly bogus but
good enough to get past the null check ;-)


Can I get detailed info on how to reproduce this (most importantly, which
src.rpm you are trying to build)?


I believe it's cyrus-imapd.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Adapting Perl packages to GCC removal from Fedora 29 build root

[Petr Pisar]

On Fri, Feb 23, 2018 at 02:22:38PM +0100, Robert-André Mauchin wrote:
> What about packages that use perl(XSLoader) but not perl(Module::Build)? 
> Shouldn't they require gcc too?
> 
If you mean build-requiring gcc because your package run-requires XSLoader
because it packages an XS code the is compiled when building the package. Then
yes, you should have to build-require gcc. Otherwise the package won't build.

For example if you package uses ExtUtils::MakerMaker, then if Makefile.PL
detects XS files in the sources, it will generate Makefile that executes gcc
directly.

Because there is no intermediate module that would mandate dependency on gcc
there is no other way then to adding BuildRequires: gcc into the spec file. We
cannot add gcc dependency to perl-ExtUtils-MakeMaker because again majority of
Perl source packages do not need gcc.

If you mean run-requiring gcc, then no. There is no reason to run-require gcc
just only because the package loads an shared library with XSLoader.

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

How to package a gnome-shell-extension default on?

[Christopher]

Is it possible, and if so, how do I package a gnome-shell-extension that is
defaulted to on for all users?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Adapting Perl packages to GCC removal from Fedora 29 build root

[Paul Howarth]

On Fri, 23 Feb 2018 13:56:58 +0100
Petr Pisar  wrote:

> It's a long time I sent a message here. And because your read my new
> message, it means something is wrong. Here it is:
> 
> GCC won't be in the minimal build root
> 
> since Fedora 29. That affects Perl packages that executes gcc at
> build time
> .
> 
> Many of them use ExtUtils::CBuilder
>  and thus
> Paul proposed adding dependency on gcc to perl-ExtUtils-CBuilder
>  instead of
> adding it to each of the affected spec file as C guidelines recommends
> .
> 
> It's true that the only reason for ExtUils::CBuilder existence is to
> build C code. Thus it is reasonable to require gcc from this package.
> 
> (ExtUils::CBuilder also supports C++ and I think it makes sense to
> require both gcc and gcc-c++.)
> 
> But if perl-ExtUtils-CBuilder will require gcc, then all
> Module::Build driven packages (403) will pull in gcc because current
> perl-Module-Build requires it. In reality there is only 59
> architecture specific packages that uses Module::Build.
> 
> So it's tempting to remove the ExtUtils::CBuilder dependency from
> perl-Module-Build. Can we do it?
> 
> "XS Extensions" section in Module::Build::Authoring reads:
> 
> Modules which need to compile XS code should list
> "ExtUtils::CBuilder" as a "build_requires" element.
> 
> Contrary to that Module-Build requires ExtUtils::CBuilder in it's
> META data. Thus I don't believe CPAN distribution authors or Fedora
> packagers do that. And indeed Fedora has 36 Module::Build packages
> that are missing ExtUtils::CBuilder build-dependency:
> 
> perl-Alien-ROOT
> perl-Alien-wxWidgets
> perl-Authen-DecHpwd
> perl-Boost-Geometry-Utils
> perl-Config-Augeas
> perl-Crypt-MySQL
> perl-Crypt-ScryptKDF
> perl-Data-Pond
> perl-Devel-GoFaster
> perl-File-Map
> perl-Hash-FieldHash
> perl-HTML-Escape
> perl-IO-Interface
> perl-JavaScript-Minifier-XS
> perl-Judy
> perl-KinoSearch1
> perl-Lexical-SealRequireHints
> perl-Lexical-Var
> perl-Lchown
> perl-Lingua-Stem-Snowball
> perl-Net-IDN-Encode
> perl-Net-LibIDN2
> perl-Params-Classify
> perl-Params-Validate
> perl-Parse-DMIDecode
> perl-PerlIO-buffersize
> perl-PerlIO-Layers
> perl-RPM2
> perl-Scalar-String
> perl-SDL
> perl-Socket-Netlink
> perl-Text-Xslate
> perl-Thread-SigMask
> perl-Time-timegm
> perl-Unicode-CaseFold
> remctl
> 
> I think it makes sense to implement this change:
> 
> (1) Add gcc and gcc-c++ dependency to perl-ExtUtils-CBuilder.
> (2) Replace ExtUtils::CBuilder hard dependency with a weak dependency
> at Recommends level in perl-Module-Build.
> (3) Add ExtUtils::CBuilder build-time dependency to those 36 packages.
> (4) Add gcc weak dependency at Recommends level to
> perl-ExtUtils-MakeMaker. (4) Add gcc build dependency to rest (mostly
> ExtUtils::MakeMaker-driven) spec files where it is missing.
> 
> Do you agree? Do you have a different opinion? Do you have a better
> plan?

That looks very reasonable to me.

Paul.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Jan Pazdziora]

On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> 
> List of packages and respective maintainers:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
> 
> adeltonmod_auth_openidc mod_authnz_pam mod_intercept_form_submit 
> mod_lookup_identity perl-Cache-Mmap perl-Crypt-DES perl-Sys-CPU

I've updated and built

mod_authnz_pam
mod_intercept_form_submit
mod_lookup_identity
perl-Cache-Mmap
perl-Crypt-DES

I'm leaving mod_auth_openidc to John and perl-Sys-CPU to Emmanuel,
as I don't want to step on their toes.

-- 
Jan Pazdziora
Senior Principal Software Engineer, OpenShift Security Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Adapting Perl packages to GCC removal from Fedora 29 build root

[Robert-André Mauchin]

On vendredi 23 février 2018 13:56:58 CET Petr Pisar wrote:
> It's a long time I sent a message here. And because your read my new
> message, it means something is wrong. Here it is:
> 
> GCC won't be in the minimal build root
>  since
> Fedora 29. That affects Perl packages that executes gcc at build time
> .
> 
> Many of them use ExtUtils::CBuilder
>  and thus Paul
> proposed adding dependency on gcc to perl-ExtUtils-CBuilder
>  instead of adding it
> to each of the affected spec file as C guidelines recommends
>  quires>.
> 
> It's true that the only reason for ExtUils::CBuilder existence is to build
> C code. Thus it is reasonable to require gcc from this package.
> 
> (ExtUils::CBuilder also supports C++ and I think it makes sense to require
> both gcc and gcc-c++.)
> 
> But if perl-ExtUtils-CBuilder will require gcc, then all Module::Build
> driven packages (403) will pull in gcc because current perl-Module-Build
> requires it. In reality there is only 59 architecture specific packages
> that uses Module::Build.
> 
> So it's tempting to remove the ExtUtils::CBuilder dependency from
> perl-Module-Build. Can we do it?
> 
> "XS Extensions" section in Module::Build::Authoring reads:
> 
> Modules which need to compile XS code should list "ExtUtils::CBuilder"
> as a "build_requires" element.
> 
> Contrary to that Module-Build requires ExtUtils::CBuilder in it's META data.
> Thus I don't believe CPAN distribution authors or Fedora packagers do that.
> And indeed Fedora has 36 Module::Build packages that are missing
> ExtUtils::CBuilder build-dependency:
> 

What about packages that use perl(XSLoader) but not perl(Module::Build)? 
Shouldn't they require gcc too?

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Florian Weimer]

On 02/18/2018 06:09 PM, Igor Gnatenko wrote:

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt


fbset should be taken care of because I had to touch the package anyway, 
and it has seen few actual changes over the years.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help needed with new segfaults in frame unwinding under gcc8

[Jakub Jelinek]

On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:
> Looking at the code:
> = gcc/libgcc/unwind.inc
>  _Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
>   struct _Unwind_Context *context,
>   unsigned long *frames_p)
>  {
>_Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc->private_1;
>  <>
>stop_code = (*stop) (1, action, exc->exception_class, exc,
> context, stop_argument);
> =
> we see that function pointer 'stop' is cast from an untyped word 'private_1'
> with no checking at all, not even for NULL or < PAGE_SIZE, etc.
> This is a giant red flag for unreliable code.

Wrong.  Just look at what the callers do:
  if (exc->private_1 == 0)
code = _Unwind_RaiseException_Phase2 (exc, _context, );
  else
code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
and
  if (exc->private_1 == 0)
return _Unwind_RaiseException (exc);

  uw_init_context (_context);
  cur_context = this_context;

  code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
So, _Unwind_ForcedUnwind_Phase2 is not called if private_1 is NULL.

Can I get detailed info on how to reproduce this (most importantly, which
src.rpm you are trying to build)?

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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



--- Comment #8 from Petr Pisar  ---
The perl-devel message
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Jonathan Wakely]

On 22/02/18 16:47 +0100, Rafal Luzynski wrote:

15.02.2018 12:02 Rafal Luzynski  wrote:



9.02.2018 11:34 Rafal Luzynski  wrote:
> [...]
> Please:
> - backport the solution to F26 and F27 as well, this should be much
> easier than in F28 (my pull requests may be helpful),
> - mark my pull requests as merged/obsolete/whatever is appropriate,
> - mark the bugzilla tickets as fixed (hopefully this is automatic).

PING

Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
have been waiting for about 1.5 months now.


PING^2


Updates submitted for f26 and f27 now.

You might have noticed the GCC maintainer is a bit busy with rawhide,
and compat-gcc-34 is not a high priority :-)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Adapting Perl packages to GCC removal from Fedora 29 build root

[Petr Pisar]

It's a long time I sent a message here. And because your read my new message,
it means something is wrong. Here it is:

GCC won't be in the minimal build root
 since
Fedora 29. That affects Perl packages that executes gcc at build time
.

Many of them use ExtUtils::CBuilder
 and thus Paul
proposed adding dependency on gcc to perl-ExtUtils-CBuilder
 instead of adding it to
each of the affected spec file as C guidelines recommends
.

It's true that the only reason for ExtUils::CBuilder existence is to build
C code. Thus it is reasonable to require gcc from this package.

(ExtUils::CBuilder also supports C++ and I think it makes sense to require
both gcc and gcc-c++.)

But if perl-ExtUtils-CBuilder will require gcc, then all Module::Build driven
packages (403) will pull in gcc because current perl-Module-Build requires
it. In reality there is only 59 architecture specific packages that uses
Module::Build.

So it's tempting to remove the ExtUtils::CBuilder dependency from
perl-Module-Build. Can we do it?

"XS Extensions" section in Module::Build::Authoring reads:

Modules which need to compile XS code should list "ExtUtils::CBuilder"
as a "build_requires" element.

Contrary to that Module-Build requires ExtUtils::CBuilder in it's META data.
Thus I don't believe CPAN distribution authors or Fedora packagers do that.
And indeed Fedora has 36 Module::Build packages that are missing
ExtUtils::CBuilder build-dependency:

perl-Alien-ROOT
perl-Alien-wxWidgets
perl-Authen-DecHpwd
perl-Boost-Geometry-Utils
perl-Config-Augeas
perl-Crypt-MySQL
perl-Crypt-ScryptKDF
perl-Data-Pond
perl-Devel-GoFaster
perl-File-Map
perl-Hash-FieldHash
perl-HTML-Escape
perl-IO-Interface
perl-JavaScript-Minifier-XS
perl-Judy
perl-KinoSearch1
perl-Lexical-SealRequireHints
perl-Lexical-Var
perl-Lchown
perl-Lingua-Stem-Snowball
perl-Net-IDN-Encode
perl-Net-LibIDN2
perl-Params-Classify
perl-Params-Validate
perl-Parse-DMIDecode
perl-PerlIO-buffersize
perl-PerlIO-Layers
perl-RPM2
perl-Scalar-String
perl-SDL
perl-Socket-Netlink
perl-Text-Xslate
perl-Thread-SigMask
perl-Time-timegm
perl-Unicode-CaseFold
remctl

I think it makes sense to implement this change:

(1) Add gcc and gcc-c++ dependency to perl-ExtUtils-CBuilder.
(2) Replace ExtUtils::CBuilder hard dependency with a weak dependency at
Recommends level in perl-Module-Build.
(3) Add ExtUtils::CBuilder build-time dependency to those 36 packages.
(4) Add gcc weak dependency at Recommends level to perl-ExtUtils-MakeMaker.
(4) Add gcc build dependency to rest (mostly ExtUtils::MakeMaker-driven) spec
files where it is missing.

Do you agree? Do you have a different opinion? Do you have a better plan?

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: "libcryptopp update to 6.1.0 with ABI change"

[Rex Dieter]

Nicolas Chauvet wrote:

> Hi,
> 
> I plan to update cryptopp to 6.1.0 release for f28+ later today.
...
> The good news, is that upstream accepted my patch to freeze the ABI
> with .6, with this lts version. So for more safety, there is a need to
> rebuild the few packages using this library:
> 
> clementine
> libndn-cxx
> pycryptopp

New builds underway.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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



--- Comment #7 from Petr Pisar  ---
I did some tests and if we want perl-ExtUtils-CBuilder to require gcc, we need
to remove dependency on ExtUtils::CBuilder from perl-Module-Build. That will
break 36 packages in Fedora.

Module-Build requires ExtUtils::CBuilder in META data, but at the same time
documents that Module::Build users should require ExtUtils::CBuilder
explicitly.

I'm keen to go this way and fix the 36 packages. I will send an e-mail to
perl-devel list the attract more attention and more ideas.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [modularity] fedora/linux/modular 404

[milanisko k]

Kevin, Langdon,

thanks guys! I'll keep an eye on this so we won't miss this feature.

Cheers,
milan


pá 23. 2. 2018 v 2:21 odesílatel Langdon White  napsal:

> On Thu, Feb 22, 2018 at 4:51 PM Kevin Fenzi  wrote:
>
>> On 02/22/2018 10:33 AM, milanisko k wrote:
>> > Folks,
>> >
>> >
>> > I've just encountered $Subj today, yesterday the same content URL
>> > <
>> http://dl.fedoraproject.org/pub/fedora/linux/modular/updates/testing/27/Server/x86_64/
>> >
>> > worked just OK. Is this expected or rather an exception? In the former
>> > case, where can I get the modular content?
>>
>> Yeah, we never actually released the modular server for f27. A different
>> approach was taken for f28:
>>
>>
>> https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/
>>
>> Since we never released it (except as a beta) and never shipped any
>> updates for it (except test ones) we removed those repos.
>>
>> > Thanks!
>> >
>> > milan
>> >
>> >
>> > PS: I'm figuring out https://pulpproject.org support for modular
>> content
>>
>> Cool. I'm not fully sure how this will look for f28, but likely you
>> could ask the releng list or modulariy workgroup.
>>
>>
> If you would like to track progress, we have a ticket open here:
> https://pagure.io/releng/issue/7227
>
> langdon
>
>
>> kevin
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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



--- Comment #6 from Petr Pisar  ---
Compare to cmake bug #923024. cmake does not run-require any compiler although
it defaults to C++ and dies if it cannot find g++.

I will probably add both compilers as a hard dependency.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc26 has been submitted as an update to
Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5ea674b664

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc27 has been submitted as an update to
Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ccdb4a06f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-DateTime-Format-Flexib
   ||le-0.29-1.fc29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: New "tests" namespace to share test code

[Pavel Raiskup]

On Thursday, February 22, 2018 3:50:38 PM CET Pierre-Yves Chibon wrote:
> On Wed, Feb 14, 2018 at 05:28:20PM +0100, Petr Šplíchal wrote:
> > When, for a particular package, it is the most efficient way to
> > maintain tests in a separate repo why should we discourage from
> > this approach? There are packages where it makes more sense to
> > store test code directly in dist-git. And it is still an option.
> > But why should we enforce this for all?
> 
> My worries are basically that this mechanism is hiding the tests from
> the package maintainers. It splits the concerns between people
> maintaining the artifacts and people maintaining the tests, which is
> exactly what the original plan to bring CI was *not* about.

Since we'll have to "hook" the remote repo into dist-git code, I must be
missing something.  Where do you see the hidden magic?

> The idea has always been to bring the tests where the code lives, so
> that both can be worked on as one, to make tests be a concern of the
> package maintainer very much like updating the artifact (rpms, image..)
> is, while getting support from QE for them (the tests).

If the tests live in separate repo, they still can "work as one".

> In addition, this is what I fear most:
> The tests for the package are stored elsewhere, we're not sure where (the 
> tests
> namespace, a random git repo on the internet...), the packager update package
> and the tests fail.
> What do you think will happen?
> a) the packager will look for $random_place_of_the_internet where tests are 
> and
>spend time trying to fix them.

Yes, please don't force us to use random_place_of_the_internet, but rather
allow maintainers to use standardized place.

Then e.g. 'rpmtests/' repo can automatically grant commit access
to package maintainers of 'rpms/' to not overcomplicate things,
but still, we can grant non-packagers access to 'rpmtests/'.

What about proventesters, could we grant them access to all tests, or could we
create new role?

> b) the packager will turn off the tests because they get in the way

Polemics (even below) about turning-off the tests is FUD.  Since tests are
opt-in feature, why would anyone thought this way?

> If the packager wants to turn off the tests, they will have to go through
> dist-git to do it, they may very well end up turning the tests off anyway, but
> if the tests are right there, they may as well have a quick look at them to 
> see
> if they can fix them quickly before deciding.
> 
> In addition, if the packager turn the tests off and the people maintaining the
> tests do not realize that, they will end up spending time maintaining
> $somewhere_else tests that aren't being used.
> Having them interact directly with the dist-git repo will increase the
> chances
> that they see/realize when something is turned off.
>
> If that means we have less tests in dist-git because the maintainers do
> not want them, I'd say so be it.  In the long term this is their loss,
> they are the ones who will get the bug reports and will have to deal
> with them, they are the ones who will have to dive into old code rather
> than going back into something that is still fresh in their mind.

There's no loss, no.  Everything is as transparent as with in-dist-git
testing, except it gives us more flexibility
- to allow more people to contribute.
- keep the package's git smaller and concentrated on packaging

> As long as, it is clear that they have been approached and that it is their
> choice to not merge pull-requests adding tests, I think the people offering to
> help should not be the ones blamed.

The help here is very much welcome, I wouldn't blame anyone though (I for
one only wait for a bit more flexible form of CI).

Btw., the far more important problem is that we can not setup CI for
non-atomic host packages, and that we can not use the CI for Rawhide
gating.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New "tests" namespace to share test code

[Petr Šplíchal]

On 22 February 2018 at 15:50, Pierre-Yves Chibon  wrote:
> On Wed, Feb 14, 2018 at 05:28:20PM +0100, Petr Šplíchal wrote:
>> Hi!
>>
>> During the last days there have been concerns raised regarding
>> what is an appropriate content for the tests namespace. [1] My
>> original idea was to enable sharing tests even across branches of
>> the same component, not only for tests to be used by completely
>> different packages. The initial examples might have been a bit
>> misleading in this respect. One of the main points still holds:
>>
>> >  * Tests might follow a different branching pattern than the
>> >dist-git repo, leading to code duplication
>>
>> From the feedback from developers I feel they always keep on mind
>> and care a lot about the maintenance costs. So it perfectly makes
>> sense to me if they want to keep and maintain tests in a separate
>> repo instead of merging/cherry-picking between dist-git branches.
>>
>> When, for a particular package, it is the most efficient way to
>> maintain tests in a separate repo why should we discourage from
>> this approach? There are packages where it makes more sense to
>> store test code directly in dist-git. And it is still an option.
>> But why should we enforce this for all?

Thanks for sharing your thoughts, Pierre.

> My worries are basically that this mechanism is hiding the tests
> from the package maintainers. It splits the concerns between
> people maintaining the artifacts and people maintaining the
> tests, which is exactly what the original plan to bring CI was
> *not* about.

I do not see a split here but rather potential for enhanced or
extended collaboration. Repositories in the tests namespace can be
set up with more open access than rpms git. In this way devel can
invite qe for direct collaboration on tests. That's one of the
reasons why we should try to fix the non-packager access as soon
as possible.

https://pagure.io/fedora-infrastructure/issue/6361

> The idea has always been to bring the tests where the code
> lives, so that both can be worked on as one, to make tests be a
> concern of the package maintainer very much like updating the
> artifact (rpms, image..) is, while getting support from QE for
> them (the tests).

I see the benefits of having code with tests at the very same
place, I find this very useful especially for unit tests in the
project upstream. However, the situation here is a bit different
in two respects:

1) The rpms dist git does not include package code itself but
rather build metadata only (mainly spec files describing how to
build the package) so it makes very good sense to host at this
place testing metadata only (how to test the package). This is
quite nicely consistent approach.

2) As far as I can see, within the Always Ready Operating System
effort we are not looking to cover every and each feature in all
packages but rather ensuring the OS works as a whole. Thus basic
functionality and integration tests which guard the stability of
the packages are more appropriate for testing. These do not need
to be kept so close to the package code.

I believe we don't want to duplicate upstream unit testing here.
We should probably clarify more which test types are appropriate
or expected in the Fedora CI. As part of the docs consolidation I
added a brief section about test types to the main CI portal:

https://fedoraproject.org/wiki/CI#Test_Types

Does it decribe well what we are looking for? Shall we extend it?

> In addition, this is what I fear most:
> The tests for the package are stored elsewhere, we're not sure
> where (the tests namespace, a random git repo on the
> internet...), the packager update package and the tests fail.

I see no hiding of tests from maintainers: Tests are clearly
referenced and discoverable from the rpms dist git as defined by
the Standard Test Interface and devels have access, see:

https://fedoraproject.org/wiki/CI/Share_Test_Code#Examples

Devel decides which tests are good for testing, it does not matter
where the test code lives. However there needs to be trust to the
referenced repo. But this is the same as with any other open
source project.

> What do you think will happen?
> a) the packager will look for $random_place_of_the_internet
> where tests are and spend time trying to fix them.
> b) the packager will turn off the tests because they get in the way
>
> If the packager wants to turn off the tests, they will have to
> go through dist-git to do it, they may very well end up turning
> the tests off anyway, but if the tests are right there, they may
> as well have a quick look at them to see if they can fix them
> quickly before deciding.

It's not random_place_of_the_internet, it's well selected and
trusted source where devel can (usually) directly contribute. I
meet devels around who see benefit in having tests enabled. So
I don't share your concern about turning the test off so easily.

> In addition, if the packager turn the tests off and the 

Re: Fedora mass rebuild 2018

[Guido Aulisi]

2018-02-22 21:47 GMT+01:00 Josh Boyer :
> On Thu, Feb 22, 2018 at 12:49 PM, Marek Polacek  wrote:
>> As many of you know, every year we (the GCC team) rebuild all the Fedora
>> packages with the upcoming GCC, so as to reveal as many bugs as possible 
>> before
>> we release the new version.  As in the previous years, it is only performed 
>> on
>> x86_64 only; we unfortunately lack the resources to deal with other arches.
>> Ideally we'd conclude this mass rebuild *before* the new GCC has gotten into
>> the buildroots; alas, this wasn't the case this year.

Thank you for your great job.

>
> josh
>
>>
>> Let's get down to the nitty-gritty:
...
>> jalv-1.6.0-3.fc27.src.rpm
I tried a mockbuild in current rawhide (jalv-1.6.0-4.fc28.src.rpm) and
it was successful.
...
>> lv2-x42-plugins-0.3.0-0.3.20170428.fc27.src.rpm
I've patched this package
(lv2-x42-plugins-0.3.0-0.5.20170428.fc29.src.rpm) and I've sent PRs
upstream

Ciao
Guido
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org