[Bug 1548225] perl-Test-Strict-0.45 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Strict-0.45-1.fc2
   ||9
   ||perl-Test-Strict-0.45-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2018-02-23 02:55:14



-- 
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 1548214] perl-Log-Dispatchouli-2.016 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Dispatchouli-2.016
   ||-1.fc29
   ||perl-Log-Dispatchouli-2.016
   ||-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-23 02:36:53



-- 
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

runroot changing during the course of a rawhide pungi run

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


If I understand correctly there was a new lorax build [1] that completed
at 01:11 UTC (02/23) that then made it into the runroot of a task [2] that 
was part of a pungi compose [3] that started at 14:54 UTC (02/22).

I think this caused problems with the build, but that isn't really
important. The real question is: if our runroot changes during the run then
we could have some tasks (lorax imagebuild etc) that run with some versions
of software and other tasks that run with others. This is probably especially
maddening when trying to debug why one failed when others didn't.

Is my understanding correct?

Dusty

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1048851
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25243479
[3] 
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180222.n.1/
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqPi74ACgkQMwLb1zlS
5nGSwg/9HIHUVvCTZiU/3tNT1zskuJZNUtiuefWFsVQTQfgLulLz+L/Fw8KxtmLO
zVKXKF7Aqs5xHxkAle+VZq6HNmhU6lB6DUpLpxnhXhBw8fBB8TpEbxaHBQtE9mPS
90zrYNTYXB7vMLkM+FnenpELF2XYe80/O6iz34ZUCMqYdavw1G7s8MI6cS36CV0m
ZpOTdYpIRtVFgv4NSy8hFDs91XPXE3hp4jP/ffU0rnA0Aq1tW3r67EyDT26LSRk1
CfKewnLNCXN329PukFAA1xYOjT9JxjZJAswCXsgx+Vr5vjI6AGCq+773Iz2PgX4H
ZPcGWrZDeILtCPARjAqfUx22ldPF38MSfL3v0GHy9NgC683yLaLUqm08Zl7l4Ujh
xg/wPbvvYt/VmwhCY+MQLf1XrYylLvCdVJyI7yrum8QhfWieTzH2OizejyddT6dE
2NEqdNsh1BIrsh/9kw8s7XdE3dZ6UyfxYwwcdMC6XtJT633IlJiXq2HfqtlRLipp
H1rqz+1+Qp7bQAIQqH8sn2FpgW2IBr9csb/vxWq3ZcePeukRe4q/SRFa+xDvg8gF
yuLrBa+Ovkh8KZvVeH34OAyf8AFRCjHCz1YtKThCfELzDWRFwOfzWmbA80+8rKQN
JcapBDyqHJDeL86O/HuTXNE770EtzeglA0YDO+a/G4Of2ngedP4=
=/fUr
-END PGP SIGNATURE-
___
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]

> "JR" == John Reiser  writes:

JR> Those one-line tracebacks, with no source file and no line number,
JR> are a clue that valgrind could find no corresponding degbuginfo.
JR> Please install the debuginfo for libcyrus_imap.so.0.0.0 and
JR> libstdc++.so.6.0.25, then re-run valgrind.  This is very close to
JR> pin-pointing the bug.

All of the debuginfo was installed at that time, and running gdb on the
core did not complain of any missing debug symbols.
libcyrus_imap.so.0.0.0 is a build artifact of this very package.  The
tests are running at the %install section (instead of in %check) so none
of the binaries have been stripped yet.  There is no additional
debuginfo I can think to install.

Just to be sure I repeated the process after wiping my mock cache but
there is no change.  I also built everything with -Og instead of -O2 but
there is also no change (except, interestingly, one repeated argument in
the do_indexer frame is no longer present):

Old:
#8  0x55aff86b4774 in do_indexer (sa=0x7fffbc365370, sa=0x7fffbc365370) at 
imap/squatter.c:352

New:
#8  0x55d7ec2f7364 in do_indexer (sa=0x7ffc51f6d8e0) at imap/squatter.c:352

#0  0x03e70120 in ?? ()
#1  0x7f31ff91c81e in _Unwind_ForcedUnwind_Phase2 (exc=0x7ffc51f6d2e0, 
context=0x7ffc51f6d000, frames_p=0x7ffc51f6cf08) at 
../../../libgcc/unwind.inc:170
#2  0x7f31ff91d105 in _Unwind_Resume () at ../../../libgcc/unwind.inc:243
#3  0x7f3205d03ba8 in stem_version_set (version=, 
database=) at /usr/include/c++/8/bits/char_traits.h:320
#4  xapian_dbw_open (paths=0x55d7edbc7b70, dbwp=0x55d7edbc80e8) at 
imap/xapian_wrap.cpp:327
#5  0x7f3205d7202f in begin_mailbox_update (rx=0x55d7edbc8050, 
mailbox=0x7f3206b57018, flags=0) at imap/search_xapian.c:1535
#6  0x7f3205d542dc in search_update_mailbox (rx=0x55d7edbc8050, 
mailbox=0x7f3206b57018, flags=0) at imap/search_engines.c:211
#7  0x55d7ec2f71fc in index_one (name=0x55d7edbc7b30 "user.cassandane", 
blocking=1) at imap/squatter.c:292
#8  0x55d7ec2f7364 in do_indexer (sa=0x7ffc51f6d8e0) at imap/squatter.c:352
#9  0x55d7ec2f8429 in main (argc=3, argv=0x7ffc51f6da18) at 
imap/squatter.c:1004

I will work up a ticket in bugzilla.redhat.com against gcc now and will
include some instructions for replicating this.

The only other interesting thing I've found so far (which I'm sure was
already obvious) is that this does appear to happen within a catch block
(the one in xapian_dbw_open, source here:
https://github.com/cyrusimap/cyrus-imapd/blob/cyrus-imapd-3.0/imap/xapian_wrap.cpp#L305).

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

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

[Jason L Tibbitts III]

> "SJS" == Stephen John Smoogen  writes:

SJS> OK this is a problem on my part. I have taken sections which have
SJS> MUST/WILL/SHOULD in them to be done and I have taken ones without
SJS> that as general guidance.

Unfortunately the guidelines simply do not consistently capitalize
SHOULD/MUST (and MAY, in the few places where it appears).  New things
should have the yelling legalese but older sections probably won't.  I
fix them when I come across them but it's sadly not as simple as running
sed across the whole thing.

I did fix up the specific example mentioned here.

 - 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

[John Reiser]

Jason L Tibbitts III wrote:

"JR" == John Reiser  writes:


JR> Please create a bugzilla report, or other well-known tracking
JR> instance.

But where?  I don't even know whose problem this is.  It's taken me days
of what little free time I have just to figure out how to get the
backtrace I was able to provide.


For any SIGSEGV, file bugzilla against the package that contains the
program counter at the time of the fault.  In this case, libgcc
(which bugzilla might say, "libgcc is part of gcc, so use gcc.")
Then post here the URL of the bugzilla report.



I am certainly conditioned to assume that the compiler is working as
designed and problems like this are due to upstream code issues which
simply weren't exposed with previous versions of the compiler.  And
while tracking this all down, I did find at least one real live bug in
the upstream code.

JR> Non-repeatability due to unspecified or mismatched versions is
JR> frustrating.

Well, sure it is.  I just don't have enough information to do anything
other than spew random things.  I'm still trying to understand what's
gone wrong where, and what information is relevant.


Include the versions of the packages for these pieces, please:
   cyrus-imapd and any package that it BuildRequires or Requires
   gcc, libgcc
   gcc-c++, libstdc++
   glibc
   binutils (for /usr/bin/ld)
   mock
   kernel
The idea is: I want to run _exactly_ "the same thing" as you did.


valgrind --track-origins=yes --trace-children=yes ./testrunner.pl -v -f
pretty SearchFuzzy.xapianv2


This is good progress!
> ==22846==  Uninitialised value was created by a stack allocation
> ==22846==at 0x5837ED0: ??? (in 
/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/lib64/libcyrus_imap.so.0.0.0)

> ==22846==by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)

Those one-line tracebacks, with no source file and no line number,
are a clue that valgrind could find no corresponding degbuginfo.
Please install the debuginfo for libcyrus_imap.so.0.0.0 and libstdc++.so.6.0.25,
then re-run valgrind.  This is very close to pin-pointing the bug.


JR> The reported behavior is consistent with use of an uninitialized
JR> value.

In whose code?  It sounds like you're saying that the upstream code is
broken, which of course would be something I could understand, but


In the unwind code, which is used by exception handling.



JR> Looking at the code: = gcc/libgcc/unwind.inc

... here you're talking about gcc code.


libgcc.



JR> This is a giant red flag for unreliable code.

And I'm still confused about whose code is unreliable.


libgcc, because it does not check its input (the unwind tables) enough.
Perhaps gcc generated incorrect data into the tables,
but it is the fault of libgcc for not avoiding SIGSEGV.
SIGSEGV is *ALWAYS* the fault of the package that contains $pc
until that package proves otherwise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] fedora/linux/modular 404

[Langdon White]

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

Schedule for Friday's FESCo Meeting (2018-02-23)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

Note that this is a change in time from the previous FESCo meeting time.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-02-22 15:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda


= Followups =

#topic #1714 Fedora 26 spins process was missed
.fesco 1714
https://pagure.io/fesco/issue/1714

= New business =

#topic #1845 389-ds-base and freeipa on 32 bit arches
.fesco 1845
https://pagure.io/fesco/issue/1845

#topic #1846 F28 approved Changes not in MODIFIED status (considered as
not testable)
.fesco 1846
https://pagure.io/fesco/issue/1846

#topic #1847 Request Permission to Retire w/o Responsive Maintainer
.fesco 1847
https://pagure.io/fesco/issue/1847

#topic #1848 Request to Authorize Removal of Blender Source Tarballs
from Incorrect Place in Repository
.fesco 1848
https://pagure.io/fesco/issue/1848

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.



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 1548225] New: perl-Test-Strict-0.45 is available

[bugzilla]

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

Bug ID: 1548225
   Summary: perl-Test-Strict-0.45 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Strict
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.45
Current version/release in rawhide: 0.43-1.fc29
URL: http://search.cpan.org/dist/Test-Strict/

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/3419/

-- 
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

[389-devel] Please review: 49447 Pbkdf2 missing on upgrade

[William Brown]

https://pagure.io/389-ds-base/issue/49447

https://pagure.io/389-ds-base/pull-request/49577

-- 
Thanks,

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

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

[Jason L Tibbitts III]

> "JR" == John Reiser  writes:

JR> Please create a bugzilla report, or other well-known tracking
JR> instance.

But where?  I don't even know whose problem this is.  It's taken me days
of what little free time I have just to figure out how to get the
backtrace I was able to provide.

I am certainly conditioned to assume that the compiler is working as
designed and problems like this are due to upstream code issues which
simply weren't exposed with previous versions of the compiler.  And
while tracking this all down, I did find at least one real live bug in
the upstream code.

JR> Non-repeatability due to unspecified or mismatched versions is
JR> frustrating.

Well, sure it is.  I just don't have enough information to do anything
other than spew random things.  I'm still trying to understand what's
gone wrong where, and what information is relevant.

I can certainly list the versions of everything in the buildroot, and
everything in the buildroot of the last successful build.  But I don't
think that's going to be particularly useful.  I only know that it
failed to build during the mass rebuild that happened after gcc (and
plenty of other things) was updated.

JR> What does running under memcheck ("valgrind --track-origins=yes
JR> ...") say?

Well, I can run the test suite under valgrind.  It seems to be able to
trace children, too.  I did:

valgrind --track-origins=yes --trace-children=yes ./testrunner.pl -v -f
pretty SearchFuzzy.xapianv2

and got a pile of output.  Narrowing down to just the indexing process
(called squatter) which actually segfaults gives the output I include at
the end of this message.

JR> The reported behavior is consistent with use of an uninitialized
JR> value.

In whose code?  It sounds like you're saying that the upstream code is
broken, which of course would be something I could understand, but

JR> Looking at the code: = gcc/libgcc/unwind.inc

... here you're talking about gcc code.

JR> This is a giant red flag for unreliable code.

And I'm still confused about whose code is unreliable.

 - J<

Output under valgrind for the process which segfaults:

==22846== Memcheck, a memory error detector
==22846== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22846== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==22846== Command: 
/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/2352581/conf/imapd.conf
==22846==
2352581/squatter[22846]: SQL backend defaulting to engine 'pgsql'
2352581/squatter[22846]: indexing mailboxes
2352581/squatter[22846]: indexing mailbox user.cassandane...
==22846== Conditional jump or move depends on uninitialised value(s)
==22846==at 0xBCC2052: _Unwind_Resume (unwind.inc:240)
==22846==by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==by 0x588D58A: search_update_mailbox (search_engines.c:211)
==22846==by 0x10C104: index_one (squatter.c:292)
==22846==by 0x10B773: do_indexer (squatter.c:352)
==22846==by 0x10B773: main (squatter.c:1004)
==22846==  Uninitialised value was created by a stack allocation
==22846==at 0x5837ED0: ??? (in 
/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/lib64/libcyrus_imap.so.0.0.0)
==22846==
==22846== Use of uninitialised value of size 8
==22846==at 0xBCC181B: _Unwind_ForcedUnwind_Phase2 (unwind.inc:170)
==22846==by 0x1FFEFFF76F: ???
==22846==by 0x1FFEFFF6DF: ???
==22846==by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
==22846==by 0xE6F90EF: ???
==22846==by 0x1FFEFFF77F: ???
==22846==by 0xE6F5F6F: ???
==22846==by 0x1FFEFFF74F: ???
==22846==by 0x1FFEFFF76F: ???
==22846==by 0xE6F550F: ???
==22846==by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==  Uninitialised value was created by a stack allocation
==22846==at 0x5837ED0: ??? (in 
/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/lib64/libcyrus_imap.so.0.0.0)
==22846==
==22846== Jump to the invalid address stated on the next line
==22846==at 0x120: ???
==22846==by 0x1FFEFFF6DF: ???
==22846==by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
==22846==by 0xE6F90EF: ???
==22846==by 0x1FFEFFF77F: ???
==22846==by 0xE6F5F6F: ???
==22846==by 0x1FFEFFF74F: ???
==22846==by 0x1FFEFFF76F: ???
==22846==by 0xE6F550F: ???
==22846==by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==by 0x588D58A: search_update_mailbox 

[Bug 1548214] New: perl-Log-Dispatchouli-2.016 is available

[bugzilla]

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

Bug ID: 1548214
   Summary: perl-Log-Dispatchouli-2.016 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Dispatchouli
  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



Latest upstream release: 2.016
Current version/release in rawhide: 2.015-5.fc28
URL: http://search.cpan.org/dist/Log-Dispatchouli

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/7173/

-- 
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] New: perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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

Bug ID: 1548207
   Summary: perl-DateTime-Format-Flexible-0.29 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime-Format-Flexible
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.29
Current version/release in rawhide: 0.28-4.fc28
URL: http://search.cpan.org/dist/DateTime-Format-Flexible/

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/2795/

-- 
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

[Kevin Fenzi]

On 02/22/2018 10:33 AM, milanisko k wrote:
> Folks,
> 
> 
> I've just encountered $Subj today, yesterday the same content URL
> 
> 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.

kevin



signature.asc
Description: OpenPGP digital signature
___
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

[John Reiser]

I could really use some help from the gcc experts.


Please create a bugzilla report, or other well-known tracking instance.
In particular, bugzilla asks about repeatability, version numbers, etc.
Non-repeatability due to unspecified or mismatched versions is frustrating.


A package I maintain, cyrus-imapd, contains two extensive test suites
which we run at package build time.  After the big flag day where we
updated gcc and glibc and such in rawhide, one of the test suites now
shows failures and produces 22 core dumps, but only when run in mock
(not even fedpkg local on a rawhide container).  Even in mock, if I
get into the chroot, duplicate the test environment and run the failing
program by hand (or under strace, or under gdb) then it doesn't
segfault.


What does running under memcheck ("valgrind --track-origins=yes ...") say?
The reported behavior is consistent with use of an uninitialized value.
[gdb changes the environment by adding two pipes when invoking a process.]


After getting cores and all of the debugging stuff into mock
(instructions below) I found that all cores have substantially identical
backtraces:

(gdb) bt
#0  0x0120 in ?? ()
#1  0x7f18a19d281e in _Unwind_ForcedUnwind_Phase2 (exc=0x7fffbc364c70, 
context=0x7fffbc364990, frames_p=0x7fffbc364898) at 
../../../libgcc/unwind.inc:170
#2  0x7f18a19d3105 in _Unwind_Resume () at ../../../libgcc/unwind.inc:243
#3  0x7f18a7dbbb90 in stem_version_set (version=, 
database=) at /usr/include/c++/8/bits/char_traits.h:320
#4  xapian_dbw_open (paths=0x55aff951eb70, dbwp=0x55aff951f0f8) at 
imap/xapian_wrap.cpp:327


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.
Such a check would have avoided the particular SIGSEGV in the traceback above.
Of course this might cause vague or incorrect results, but there could
be strong hints about what to fix, instead of just a bare SIGSEGV.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[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.
>
> I downloaded all Fedora packages on Jan 19, which should give you a sense of
> how long it takes to process all of this.
> There were 20892 packages overall (last year Fedora had 18811 packages).  
> Using
> koji-is-noarch.py I removed all noarch packages from that, so that we only
> build archful packages to save time.  That left me with 9329 packages to 
> build.
> Of that, 8358 built fine with the new GCC (mostly 
> gcc-8.0.1-0.3.fc28.x86_64.rpm
> but I also used a newer version from rawhide).  The packages that failed to
> build with GCC 8 I rebuilt with GCC 7; if they failed with GCC 7, I took them
> off the list.  The rest had to be analyzed; it was around 300 packages this
> time.  (Last year it was ~198 packages.  So more work this year.)
>
> I found several GCC bugs, most of which have already been fixed (actually all
> but PR84231).  Fortran ABI has changed in GCC 8 (as it did in GCC 7).  A nasty
> bug has been discovered in the new empty classes ABI code: we will need 
> another
> mass rebuild to find out which package are affected.  There have been a few
> bugs in code that deals with optimizing strlen; hopefully we won't find more 
> of
> them.
>
> A lot of churn has been caused due to changes in the C++ compiler.  Previously
> GCC was fairly forgiving about broken template code and would check almost
> nothing until the template was instantiated.  In more recent releases parts of
> the template which don't depend on the template arguments get checked earlier.
> The standard says such code is ill-formed, but that no diagnostic is required
> i.e.  the compiler is allowed to diagnose the problem, but not required to
> (because it could be expensive or difficult to check for some compilers).  So
> the code was always broken, but now GCC tells you about it.  I encourage the
> packagers to fix these bugs.
>
> With every release GCC gains new warnings which cause build failures in
> packages that use -Werror (not going to start a flame war about this here).
> This year the main offender was probably -Wformat-truncation.  Due to time
> constrains I wasn't able to check every warning and decide if it's warranted
> or a false positive.
>
> As usual, there will be a "porting to" document to ease the transition to the
> new GCC.  We already have https://gcc.gnu.org/gcc-8/porting_to.html, even 
> though
> this document is still in flux.
>
> What follows is my analysis of what went wrong for the people who want to get
> an overview of the details.  Note that my understanding of packages other than
> gcc is very limited, so it's entirely possible that I miscategorized some
> problems.  Since during the time I was analyzing failures GCC 8 made it to the
> buildroots, it was no longer possible to use buildroots only different from
> each other by the GCC version, so some of the failures are caused by a new
> version of boost, glibc, etc.
>
> Thanks Jakub Jelinek for promply fixing bugs I reported (or caused :)) and
> Jonathan Wakely for his great help with anything related to C++.

Thanks for both the detailed summary and the overall great amount of
work your team does to help ensure we continue to be "first" when it
comes to toolchain in Fedora.  I know this isn't easy by any means,
but reducing and analyzing the failures to a relatively small number
really reduces the burden on the overall Fedora packager community.
Keep up the excellent work!

josh

>
> Let's get down to the nitty-gritty:
>
>
>
> apr-1.6.3-1.fc28.src.rpm
> undefined behavior -- signed overflow:
> 310 for (off = 1; off < LONG_MAX && off > 0; off *= 2) {
> 311 apr_strfsize(off, buf);
> 312 apr_strfsize(off + 1, buf);
> 313 apr_strfsize(off - 1, buf);
> 314 }
> where off is of type long int.
>
> mozjs38-38.8.0-8.fc28.src.rpm
> undefined behavior; building with -fsanitize=undefined:
>
> # cd /builddir/build/BUILD/mozilla-esr38/js/src/tests && 
> /builddir/build/BUILD/mozilla-esr38/js/src/js/src/shell/js -f shell.js -f 
> js1_5/shell.js -f js1_5/Regress/shell.js -f 
> js1_5/Regress/regress-360969-06.js; cd -
> BUGNUMBER: 360969
> STATUS: 2^17: global function
> /builddir/build/BUILD/mozilla-esr38/js/src/gc/Marking.cpp:669:10: runtime 
> error: load of misaligned address 0x7f8be8070c9a for type 'void *', which 
> requires 8 byte alignment
> 0x7f8be8070c9a: note: pointer points here
> 00 00  48 b9 30 d8 e5 e2 8b 7f  00 00 48 8b 49 

Help needed with new segfaults in frame unwinding under gcc8

[Jason L Tibbitts III]

I could really use some help from the gcc experts.

A package I maintain, cyrus-imapd, contains two extensive test suites
which we run at package build time.  After the big flag day where we
updated gcc and glibc and such in rawhide, one of the test suites now
shows failures and produces 22 core dumps, but only when run in mock
(not even fedpkg local on a rawhide container).  Even in mock, if I
get into the chroot, duplicate the test environment and run the failing
program by hand (or under strace, or under gdb) then it doesn't
segfault.

After getting cores and all of the debugging stuff into mock
(instructions below) I found that all cores have substantially identical
backtraces:

(gdb) bt
#0  0x0120 in ?? ()
#1  0x7f18a19d281e in _Unwind_ForcedUnwind_Phase2 (exc=0x7fffbc364c70, 
context=0x7fffbc364990, frames_p=0x7fffbc364898) at 
../../../libgcc/unwind.inc:170
#2  0x7f18a19d3105 in _Unwind_Resume () at ../../../libgcc/unwind.inc:243
#3  0x7f18a7dbbb90 in stem_version_set (version=, 
database=) at /usr/include/c++/8/bits/char_traits.h:320
#4  xapian_dbw_open (paths=0x55aff951eb70, dbwp=0x55aff951f0f8) at 
imap/xapian_wrap.cpp:327
#5  0x7f18a7e2e2ef in begin_mailbox_update (rx=0x55aff951f060, 
mailbox=0x7f18a8c12018, flags=0) at imap/search_xapian.c:1535
#6  0x7f18a7e0f58b in search_update_mailbox (rx=0x55aff951f060, 
mailbox=0x7f18a8c12018, flags=0) at imap/search_engines.c:211
#7  0x55aff86b5105 in index_one (name=0x55aff951eb30 "user.cassandane", 
blocking=1) at imap/squatter.c:292
#8  0x55aff86b4774 in do_indexer (sa=0x7fffbc365370, sa=0x7fffbc365370) at 
imap/squatter.c:352
#9  main (argc=3, argv=0x7fffbc3654c8) at imap/squatter.c:1004

Which as far as I've been able to gather from talking to folks on IRC,
its segfaulting in the stack unwinder trying to handle a C++ exception.
(The only C++ in the program is a wrapper for the Xapian search engine.)

I have done testing with older versions of Xapian (known to build the
package successfully) without any change in behavior, but I'm not sure I
have a reasonable way to roll back the gcc update.

The source is available from
https://github.com/cyrusimap/cyrus-imapd/tree/cyrus-imapd-3.0; the
specific function involved (stem_version_set) is
https://github.com/cyrusimap/cyrus-imapd/blob/cyrus-imapd-3.0/imap/xapian_wrap.cpp#L262
but it's only three lines.

I would appreciate any help from folks who can comprehend what's going
wrong here.  Upstream is can't really offer much in the way of help;
given that the actual failure seems to happen in the libgcc code and
that this can't (so far) be reproduced outside of our buildsystem,
they're not sure what they can do.


Getting useful backtraces from a mock chroot:

If you turn off systemd coredump catching on the machine running mock
(sysctl -w 'kernel.core_pattern=core.%p') and delete the "%check" line
from the spec before building (so that the tests run as part of
%install), you can get the cores left in the mock chroot with the
complete debug information left unstripped.  Then you can manually
install gdb and all of the debugfinfo packages:

mock -r fedora-rawhide-x86_64 --enablerepo fedora-debuginfo -i gdb
cyrus-sasl-lib-debuginfo glibc-debuginfo jansson-debuginfo
keyutils-libs-debuginfo krb5-libs-debuginfo libcom_err-debuginfo
libgcc-debuginfo libical-debuginfo libicu-debuginfo libnghttp2-debuginfo
libselinux-debuginfo libstdc++-debuginfo libuuid-debuginfo
libxcrypt-debuginfo libxml2-debuginfo nspr-debuginfo nss-debuginfo
nss-util-debuginfo openldap-debuginfo openssl-libs-debuginfo
pcre-debuginfo pcre2-debuginfo postgresql-libs-debuginfo
shapelib-debuginfo sqlite-libs-debuginfo xapian-core-libs-debuginfo
xz-libs-debuginfo zlib-debuginfo

Then run:

mock -r fedora-rawhide-x86_64 --shell
su - mockbuild
find . -name core.\*

and gdb as usual.

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

[modularity] fedora/linux/modular 404

[milanisko k]

Folks,


I've just encountered $Subj today, yesterday the same content URL

worked just OK. Is this expected or rather an exception? In the former
case, where can I get the modular content?


Thanks!

milan


PS: I'm figuring out https://pulpproject.org support for modular content
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

"libcryptopp update to 6.1.0 with ABI change"

[Nicolas Chauvet]

Hi,

I plan to update cryptopp to 6.1.0 release for f28+ later today.
This will not change the ABI number, because our package was
previously patched with a forged SONAME to only use the one number
convention (aka libcryptopp.so.6 instead of libcryptopp.so.6.0).

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
tegrarcm (I will handle this one)


Thx


-- 
-

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

Fedora mass rebuild 2018

[Marek Polacek]

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.

I downloaded all Fedora packages on Jan 19, which should give you a sense of
how long it takes to process all of this.
There were 20892 packages overall (last year Fedora had 18811 packages).  Using
koji-is-noarch.py I removed all noarch packages from that, so that we only
build archful packages to save time.  That left me with 9329 packages to build.
Of that, 8358 built fine with the new GCC (mostly gcc-8.0.1-0.3.fc28.x86_64.rpm
but I also used a newer version from rawhide).  The packages that failed to
build with GCC 8 I rebuilt with GCC 7; if they failed with GCC 7, I took them
off the list.  The rest had to be analyzed; it was around 300 packages this
time.  (Last year it was ~198 packages.  So more work this year.)

I found several GCC bugs, most of which have already been fixed (actually all
but PR84231).  Fortran ABI has changed in GCC 8 (as it did in GCC 7).  A nasty
bug has been discovered in the new empty classes ABI code: we will need another
mass rebuild to find out which package are affected.  There have been a few
bugs in code that deals with optimizing strlen; hopefully we won't find more of
them.

A lot of churn has been caused due to changes in the C++ compiler.  Previously
GCC was fairly forgiving about broken template code and would check almost
nothing until the template was instantiated.  In more recent releases parts of
the template which don't depend on the template arguments get checked earlier.
The standard says such code is ill-formed, but that no diagnostic is required
i.e.  the compiler is allowed to diagnose the problem, but not required to
(because it could be expensive or difficult to check for some compilers).  So
the code was always broken, but now GCC tells you about it.  I encourage the
packagers to fix these bugs.

With every release GCC gains new warnings which cause build failures in
packages that use -Werror (not going to start a flame war about this here).
This year the main offender was probably -Wformat-truncation.  Due to time
constrains I wasn't able to check every warning and decide if it's warranted
or a false positive.

As usual, there will be a "porting to" document to ease the transition to the
new GCC.  We already have https://gcc.gnu.org/gcc-8/porting_to.html, even though
this document is still in flux.

What follows is my analysis of what went wrong for the people who want to get
an overview of the details.  Note that my understanding of packages other than
gcc is very limited, so it's entirely possible that I miscategorized some
problems.  Since during the time I was analyzing failures GCC 8 made it to the
buildroots, it was no longer possible to use buildroots only different from
each other by the GCC version, so some of the failures are caused by a new
version of boost, glibc, etc.

Thanks Jakub Jelinek for promply fixing bugs I reported (or caused :)) and
Jonathan Wakely for his great help with anything related to C++.

Let's get down to the nitty-gritty:



apr-1.6.3-1.fc28.src.rpm
undefined behavior -- signed overflow:
310 for (off = 1; off < LONG_MAX && off > 0; off *= 2) {
311 apr_strfsize(off, buf);
312 apr_strfsize(off + 1, buf);
313 apr_strfsize(off - 1, buf);
314 }
where off is of type long int.

mozjs38-38.8.0-8.fc28.src.rpm
undefined behavior; building with -fsanitize=undefined:

# cd /builddir/build/BUILD/mozilla-esr38/js/src/tests && 
/builddir/build/BUILD/mozilla-esr38/js/src/js/src/shell/js -f shell.js -f 
js1_5/shell.js -f js1_5/Regress/shell.js -f 
js1_5/Regress/regress-360969-06.js; cd -
BUGNUMBER: 360969
STATUS: 2^17: global function
/builddir/build/BUILD/mozilla-esr38/js/src/gc/Marking.cpp:669:10: runtime 
error: load of misaligned address 0x7f8be8070c9a for type 'void *', which 
requires 8 byte alignment
0x7f8be8070c9a: note: pointer points here
00 00  48 b9 30 d8 e5 e2 8b 7f  00 00 48 8b 49 70 48 8d  49 68 41 52 41 51 
41 50  57 56 52 51 50 48
  ^
/builddir/build/BUILD/mozilla-esr38/js/src/gc/Marking.cpp:671:13: runtime 
error: load of misaligned address 0x7f8be8070c9a for type 'void *', which 
requires 8 byte alignment
0x7f8be8070c9a: note: pointer points here
00 00  48 b9 30 d8 e5 e2 8b 7f  00 00 48 8b 49 70 48 8d  49 68 41 52 41 51 
41 50  57 56 52 51 50 48
  ^
...and so on.
This changed with https://gcc.gnu.org/r255387.
With -fno-delete-null-poiner-checks this passes.

libomxil-bellagio-0.9.3-15.fc27.src.rpm
libX11-1.6.5-5.fc28.src.rpm
error: 

[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
 844  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 815  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 426  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 155  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  74  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc1949f307   
p7zip-16.02-10.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be69c94866   
clamav-0.99.3-8.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9   
seamonkey-2.49.2-2.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5   
mbedtls-2.7.0-1.el6
   1  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

lynis-2.6.1-1.el6
nova-agent-2.1.12-1.el6

Details about builds:



 lynis-2.6.1-1.el6 (FEDORA-EPEL-2018-0806864ce2)
 Security and system auditing tool

Update Information:

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




 nova-agent-2.1.12-1.el6 (FEDORA-EPEL-2018-c688297120)
 Agent for setting up clean servers on Xen

Update Information:

- Latest upstream

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

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

[bugzilla]

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



--- Comment #5 from Igor Gnatenko  ---
I would add both dependencies.

-- 
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: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Stephen John Smoogen]

On 22 February 2018 at 10:47, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Feb 22, 2018 at 09:53:25AM -0500, Stephen John Smoogen wrote:
>> I am trying to figure out the special cases here. Why are some
>> packages more equal than others.
>>
>> In the end, I am just trying to figure out what the new "Fedora
>> Project Packagers License" is. Something like:
>>
>> A packager MUST know every build requirement that their package uses
>> to build itself. A packager MUST list each of these as a
>> BuildRequires. A packager MUST not depend on dependencies to pull in
>> those packages.
>
> "It is important that your package list all necessary build
> dependencies using the BuildRequires: tag. You may assume that enough
> of an environment exists for RPM to function, to build packages and
> execute basic shell scripts, but you should not assume any other
> packages are present as RPM dependencies and anything brought into the
> buildroot by the build system may change over time." [1]
>
> This is not _too_ precise, but I think that's OK. It's pretty clear
> that a compiler is not necessary "for RPM to function, to build packages
> and execute basic shell scripts".
>

OK this is a problem on my part. I have taken sections which have
MUST/WILL/SHOULD in them to be done and I have taken ones without that
as general guidance. To me that section said it was ok to not list
gcc-cc if you knew it had to be there gcc-c++ would have to pull it
in. It is a should not a SHOULD and not a must or MUST. I will correct
my reading of this from now on.


> [1] 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Build-Time_Dependencies_.28BuildRequires.29
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

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

[Paul Howarth]

On Sun, 18 Feb 2018 18:09:40 +0100
Igor Gnatenko  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Over this weekend I've performed scratch-mass-rebuild without having
> gcc and gcc-c++ in buildroot of all Fedora packages, many of which
> failed due to random reasons and I grepped all logs for some common
> errors found by analyzing hundreds of build logs.
> 
> Guidelines:
> https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
> s_and_Requies
> 
> The grep output is located here:
> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> 
> Some packages might be missed due to short koji outage, broken
> dependencies and so on, but majority of real failures is below.
> 
> If you fixed package(s), found false positive, found missing packages
> in list or anything else -- please let me know.

Fixed:
curl gtkwave gtorrentviewer mod_fcgid perl-B-Hooks-OP-Check
perl-Crypt-IDEA perl-Date-Simple perl-Digest-MD4 perl-JSON-XS
perl-MooseX-Role-WithOverloading perl-Readonly-XS 
perl-Variable-Magic perl-perl5i perl-true

Won't need fixing if perl-ExtUtils-CBuilder grows a dependency on gcc
(https://bugzilla.redhat.com/show_bug.cgi?id=1547165):
perl-ExtUtils-CChecker perl-File-LibMagic perl-Hash-StoredIterator
perl-Module-Build-XSUtil perl-Time-y2038

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

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 22, 2018 at 09:53:25AM -0500, Stephen John Smoogen wrote:
> I am trying to figure out the special cases here. Why are some
> packages more equal than others.
> 
> In the end, I am just trying to figure out what the new "Fedora
> Project Packagers License" is. Something like:
> 
> A packager MUST know every build requirement that their package uses
> to build itself. A packager MUST list each of these as a
> BuildRequires. A packager MUST not depend on dependencies to pull in
> those packages.

"It is important that your package list all necessary build
dependencies using the BuildRequires: tag. You may assume that enough
of an environment exists for RPM to function, to build packages and
execute basic shell scripts, but you should not assume any other
packages are present as RPM dependencies and anything brought into the
buildroot by the build system may change over time." [1]

This is not _too_ precise, but I think that's OK. It's pretty clear
that a compiler is not necessary "for RPM to function, to build packages
and execute basic shell scripts".

[1] 
https://fedoraproject.org/wiki/Packaging:Guidelines#Build-Time_Dependencies_.28BuildRequires.29

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

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

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

Regards,

Rafal
___
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
 1081  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 843  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 426  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 323  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 155  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  92  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-069884a87f   
p7zip-16.02-10.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-72e5d3ef89   
suricata-4.0.4-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832   
seamonkey-2.49.2-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4   
mbedtls-2.7.0-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3   
knot-resolver-2.1.0-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1   
openjpeg2-2.3.0-6.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7


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

GMT-5.4.3-1.el7
argparse-manpage-1.0.0-1.el7
cargo-0.25.0-1.el7
fldigi-4.0.16-1.el7.1
freedv-1.2.2-1.el7.1
getdns-1.4.0-1.el7
hamlib-3.1-11.el7
ima-evm-utils-1.1-1.el7
llvm5.0-5.0.1-5.el7
lynis-2.6.1-1.el7
mingw-wavpack-5.1.0-4.el7
nova-agent-2.1.12-1.el7
perl-HTTP-Lite-2.44-12.el7
python-certbot-dns-cloudflare-0.21.1-1.el7
python-certbot-dns-cloudxns-0.21.1-1.el7
python-certbot-dns-luadns-0.21.1-1.el7
qsstv-9.2.6-1.el7.1
rust-1.24.0-2.el7

Details about builds:



 GMT-5.4.3-1.el7 (FEDORA-EPEL-2018-0c8e266959)
 Generic Mapping Tools

Update Information:

  -  Update to 5.4.3  -   Fix GSHHG_ROOT (bug #1545256)

References:

  [ 1 ] Bug #1545256 - gmt   cannot find  gshhg files
https://bugzilla.redhat.com/show_bug.cgi?id=1545256
  [ 2 ] Bug #1449426 - GMT-5.4.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1449426




 argparse-manpage-1.0.0-1.el7 (FEDORA-EPEL-2018-d274033e1d)
 Build manual page from Python ArgumentParser object

Update Information:

build man page from python ArgParse object

References:

  [ 1 ] Bug #1546801 - Review Request: argparse-manpage - Build manual page 
from Python ArgumentParser object
https://bugzilla.redhat.com/show_bug.cgi?id=1546801




 cargo-0.25.0-1.el7 (FEDORA-EPEL-2018-592dd11f3d)
 Rust's package manager and build tool

Update Information:

New versions of Rust and Cargo -- see the release notes for [1.24](https://blog
.rust-lang.org/2018/02/15/Rust-1.24.html).




 fldigi-4.0.16-1.el7.1 (FEDORA-EPEL-2018-cf02b4f677)
 Digital modem program for Linux

Update Information:

Updating hamlib to 3.1 as it is required for wsjtx.    * Changed the .pro
file for autodetecing correct libopenjpg2 (DL1JBE -Tom) * ftp transfer -
initialize bug fix (VK6MN- Mike) * Help manual -> path correction and corrected
some typo's (DJ0MBA- Marinus) * SSTV initialize bug fix (Adrian) * Camera
support for Raspberry PI Cam * fixed audio loopback use * fixed transmission
after stop, image was not restarted at top    Version 4.0.16 - Maintenance
releasewo seg fault * fix seg fault in waterfall only mode8psk
lockup problem * correct lockup associated with S/N and 

[Bug 1546268] Please provide a package for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-HTTP-Lite-2.44-12.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2018-2b6a247182

-- 
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 1544065] perl-Net-DNS-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Net-DNS-1.15-1.fc27
 Resolution|--- |ERRATA
Last Closed||2018-02-22 09:54:05



--- Comment #5 from Fedora Update System  ---
perl-Net-DNS-1.15-1.fc27 has been pushed to the Fedora 27 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
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: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Stephen John Smoogen]

On 22 February 2018 at 02:41, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, 2018-02-21 at 10:51 -0500, Stephen John Smoogen wrote:
>> On 21 February 2018 at 09:53, Reindl Harald 
>> wrote:
>> >
>> >
>> > it's pretty easy:
>> >
>> > when you don't list your BuildRequires properly you depend on luck
>> > that they
>> > are pulled by something else in the buildroot
>> >
>>
>> OK I understand that, but where is the cutoff. Where as a packager
>> should I stop adding things and expect that libsolv is going to do
>> its
>> job?  Do I need to put in
>>
>> BuildRequires: kernel
>> BuildRequires: systemd
>> BuildRequires: bash
>> BuildRequires: glibc
>> ...
>>
>> I am depending on luck to get all of those in the environment in a
>> working variant. I can understand where defining all that would be
>> useful. I just don't want to spend the next year doing this one by
>> one
>> like a death by a thousand papercuts. It would also be a better use
>> of
>> the time to have a tool which generated all N dozen items.
>
> No, you don't need kernel/systemd/glibc for build. You do need bash,
> but this is special case without which RPM wouldn't work. So you are
> not expected to list those in any case.

I am trying to figure out the special cases here. Why are some
packages more equal than others.

In the end, I am just trying to figure out what the new "Fedora
Project Packagers License" is. Something like:

A packager MUST know every build requirement that their package uses
to build itself. A packager MUST list each of these as a
BuildRequires. A packager MUST not depend on dependencies to pull in
those packages.

That would have made this a lot clearer to me earlier on.


-- 
Stephen J Smoogen.
___
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

[Pierre-Yves Chibon]

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?

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.
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).

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.
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.

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.
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.


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

Re: Fwd: Broken dependencies: rust-chan

[Florian Weimer]

On 02/22/2018 02:24 PM, Randy Barlow wrote:

I've been receiving e-mails that say that one of my packages has broken
dependencies, but I believe the dependencies are satisfied. Is the
system that generates these e-mails unaware of rich rpm dependencies,
perhaps?


Yes: https://pagure.io/releng/issue/6365

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

Fwd: Broken dependencies: rust-chan

[Randy Barlow]

I've been receiving e-mails that say that one of my packages has broken
dependencies, but I believe the dependencies are satisfied. Is the
system that generates these e-mails unaware of rich rpm dependencies,
perhaps?


 Forwarded Message 
Subject: Broken dependencies: rust-chan
Date: Wed, 21 Feb 2018 23:09:08 + (UTC)
From: build...@fedoraproject.org
To: rust-chan-ow...@fedoraproject.org



rust-chan has broken dependencies in the F-28 tree:
On x86_64:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On armhfp:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On ppc64le:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On aarch64:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On ppc64:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On s390x:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
On i386:
rust-chan-devel-0.1.21-2.fc28.noarch requires (crate(rand) >= 0.4.0
with crate(rand) < 0.5.0)
Please resolve this as soon as possible.





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

Re: Package stops supporting python 2.7 in latest version, what to do now

[Miro Hrončok]

On 21.2.2018 22:18, Sergio Pascual wrote:

Hello all,

python package astropy as ceased to support python 2.7 in its latest 
version, 3.0.

It still provides a LTS version that supports both python 2 and 3.

As astropy packagers, we seek advice on how to manage this situation.

So the posibilities are:

1) package the version with support of python 3 and forget about python 2
2) package the LTS version that supports both python 2 and 3
3) package the LTS version for python 2 and the new version for python 3.



Either do 1 or 3.

In both cases: remove all py2 bits form the package. And if you choose 
to go 3), add python2-astropy as a new package. It has to go trough 
review.  See python2-django1.11 and python2-ipython for examples.


In the third case, wihich consider the best approach, do I need to 
create a new package and go through the review process?


Best regards, Sergio




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



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: qa-ansible - repo for PRs against fedora infra ansible

[Kamil Paral]

On Wed, Feb 21, 2018 at 7:49 PM, Kevin Fenzi  wrote:

> On 02/21/2018 05:54 AM, Kamil Paral wrote:
> > Hello,
> >
> > I've created a new project and cloned all Fedora Infra ansible into it:
> > https://pagure.io/fedora-qa/qa-ansible
> >
> > The idea is to have a repo against which we can create a PR and review it
> > comfortably. Once reviewed, the patch of course needs to go to the real
> > infra ansible repo. But this should help for patches where you want other
> > people to have a look at it before pushing.
> >
> > If you want to use it, I recommend adding this as another remote in your
> > existing infra ansible checkout, that's probably the most comfortable
> > setup, at least for me.
>
> Note that we have plans to make the ansible repo avaiable in public for
> PR's, but have been holding off on this until Patricks git backend is
> finished. That should let us have it multiple places and stay in sync.
>

Great news, thanks. Looking forward to it :)
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org