[Bug 1537217] perl-gettext: Obsoletes work by package name, not by provides

[bugzilla]

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

Igor Gnatenko  changed:

   What|Removed |Added

  Flags||needinfo?(rc040203@freenet.
   ||de)



--- Comment #2 from Igor Gnatenko  ---
ping?

-- 
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 1550748] perl-Date-Manip-6.70 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-03-02 02:45:41



--- Comment #1 from Jan Pazdziora  ---
perl-Date-Manip-6.70-1.fc29 built to rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25410775

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

Kernel marking files in /boot as %ghost

[Samuel Rakitničan]

Dear list,

I've stumbled upon a serious issue that has not been discussed before. 
Somewhere around May 2015 kernel files was moved to 
/usr/lib/modules/, which are then copied to /boot in post scriptlets 
[1]. The issue is that such files are marked with %ghost because they don't 
exist initially and are being copied when installed. Now because of that rpm 
(rpm -qV) can't verify the files attributes correctly and heck even doesn't 
point out if they don't exist at all as it is the case if dnf fails in the 
middle of transaction. Because of that I've opened a bug report [2], but it was 
closed because that was supposedly intended, but looking at mailing list 
archive, I don't see this particular issue being raised and frankly in my 
opinion marking files that are responsible to boot the system as %ghost should 
not happen. %ghost should be used only when there is not any other option left 
in case when files truly doesn't exist and its integrity could not be verified 
in advance.


[1] https://lists.fedoraproject.org/pipermail/kernel/2015-May/005819.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1467450
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Need assistance to build openvdb for both Blender and LuxRender

[Luya Tshimbalanga]

Hello team,

openvdb currently failed for some odd reasons
(https://koji.fedoraproject.org/koji/taskinfo?taskID=25408808) on both
Rawhide and F28 in order to rebuild for boost 1.66.

Looking for tail result from build.log, it seems the mockbuild hit a bug:

https://koji.fedoraproject.org/koji/getfile?taskID=25408809=DEFAULT=build.log=-4000

Can someone investigate the cause? Thanks

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net




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: Add ability to check ABI compliance from fedpkg?

[Sérgio Basto]

On Tue, 2018-02-27 at 12:55 -0600, Richard Shaw wrote:
> I don't have to do it for many of my packages, but I do regularly
> check ABI compliance before performing an update so I know if I need
> to rebuild dependencies or not. 
> Currently my workflow is something like:
> $ cd abicompare/$ mkdir  $ cd 
> (unpack pakage and -devel package)(same for )$ abi-
> compliance-checker -l  -vnum  -dump 
> 
> $ abi-compliance-checker -l  -vnum  -dump 
> 
> 
> 
> 
> $ abi-compliance-checker -l  -old  -new
> 
> $ scp -r 
> :public_html/compatibility_report/
> It would be REALLY nice to automate this to any extent possible PRIOR
> to actually building a package (fedpkg ).
> I'm partial to abi-compliance-checker because I maintain it and I
> know how to interpret the results but any equivalent tool would be
> fine :)

Do you know the existence of fedabipkgdiff [1] and rfabipkgdiff [2].The
funny part (for me) is that both commands aren't in fedpkg or rfpkg 

[1] rpm -qf /usr/bin/fedabipkgdifflibabigail-1.0-1.fc26.x86_64 
[2]rpm -qf /usr/bin/rfabipkgdiff  rpmfusion-packager-0.6.2-
1.fc26.noarch
Cheers, -- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 05:43 PM, Adam Williamson wrote:

On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote:

On 02/27/2018 07:27 PM, Richard Shaw wrote:

On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> wrote:


 Once again, folks, *please* announce your soname bumps, and co-ordinate
 rebuilds. (In fact it looks like Zdenek is the maintainer of both
 packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a
"%global sover " and using it in %files?

If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is not
a release. So SONAME breakages are expected to happen in rawhide and
maintainers supposed to be reacted upon.


This is not true and I have *specifically* pointed you at the policy
page which says it is not true, more than once.


And I have to reiterate my mantra: This plan is a non-realistic 
illusion. It simply does not work and will not work.



https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

For updates to rawhide packages, Maintainers SHOULD:

 Try not to push a clearly broken build (breaks the default
buildroot package set, etc)


Note the "SHOULD" - This is the reflection of what I said above.

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

Fedora 28-20180301.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Atomic raw-xz x86_64

Failed openQA tests: 17/127 (x86_64), 7/24 (i386), 1/2 (arm)

ID: 196470  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/196470
ID: 196483  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196483
ID: 196485  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196485
ID: 196486  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196486
ID: 196496  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196496
ID: 196499  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196499
ID: 196500  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196500
ID: 196501  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196501
ID: 196502  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/196502
ID: 196503  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/196503
ID: 196504  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196504
ID: 196505  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196505
ID: 196506  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196506
ID: 196516  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196516
ID: 196517  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/196517
ID: 196538  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/196538
ID: 196539  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196539
ID: 196544  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196544
ID: 196555  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196555
ID: 196579  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/196579
ID: 196587  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/196587
ID: 196588  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/196588
ID: 196593  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196593
ID: 196599  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/196599
ID: 196606  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/196606

Soft failed openQA tests: 12/127 (x86_64), 3/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 196455  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196455
ID: 196456  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196456
ID: 196478  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196478
ID: 196479  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/196479
ID: 196480  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196480
ID: 196481  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196481
ID: 196482  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196482
ID: 196527  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196527
ID: 196540  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/196540
ID: 196541  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196541
ID: 196550  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196550
ID: 196553  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/196553
ID: 196563  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/196563
ID: 196581  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/196581
ID: 196583  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196583

Passed openQA tests: 76/127 (x86_64), 14/24 (i386)

Skipped openQA tests: 21 of 153
-- 
Mail generated by check-compose:

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Kevin Fenzi wrote:
>> Something needs to be done to make the compose process more robust, e.g.:
>> * running createrepo on a stable release, so that we do not have to be
>> able
>>   to init a chroot of the target system to compose a repository. A broken
>>   dependency, even in systemd or rpm, should NEVER be a reason for the
>>   repository to fail to compose.
>> * publishing individual deliverables one at a time, i.e.:
>>   1. compose the repositories,
>>   2. sync the repositories out to the mirrors,
>>   3. build the images (atomic ostrees, live images etc.) one at a time,
>>   4. sync those images that succeeded out to the mirrors, keep the old
>>  versions of the other ones (the matching SRPMs are in Koji anyway,
>>  so it does not matter if the SRPMs in the tree don't match)
>> etc.
> 
> I disagree entirely with the above. I think the solution is to gate
> packages coming into rawhide and hold or reject those that break the
> compose until they are fixed. I think being proactive is VASTLY better
> than being reactive. Not breaking something in the first place is much
> easier to deal with than trying to fix it later.

And how do you propose doing that? The only reliable way to hold packages 
that break the compose would be to actually try to run the whole compose 
process after every package build. That just does not scale. The composes 
are only daily for a reason. Running a compose for every package build would 
use a lot of resources and would also take very long, delaying the tagging 
of the package into Rawhide for an insane amount of time (at least hours).

If you propose just doing some fast automated tests catching some issues, 
that will never reliably catch all issues breaking the composes, and so my 
proposals to increase the robustness of the compose process will still be 
relevant. The only way to know for sure whether the compose will succeed is 
to run it (and even that will not necessarily catch non-deterministic 
failures).

It is just defensive programming to not fail the whole process on any small 
issue that you cannot avoid (with the resources that are available).

By the way, in the distant past, if some (or even all) live image compose(s) 
failed, the compose would just get published without that/those live 
image(s) (in the worst case, with an empty Live directory). Not ideal (and 
keeping the last successful build of each image as I suggest doing would be 
an improvement on that, Koji should be enough to fulfill the copyleft 
licenses' source distribution requirements), but at least the package repo 
went out a lot more often than nowadays.

>> Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide
>> and Branched trees (which miscompiles the Chromium/QtWebEngine build tool
>> GN on x86_64), the fix (8.0.1-0.16) has already been in the right Koji
>> tags for days, but any third-party repository (RPM Fusion, Copr, etc.)
>> will still get the broken GCC. This is not acceptable.
> 
> I'm sure there's any number of bugs in any number of collections of
> packages.

I am not asking you to ship bug-free composes. (I know that's impossible. 
;-) ) I am just asking you to take less than a week to get a compose with an 
already built critical fix out. :-)

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

Re: Why size of repositories metadata is too high in Fedora?

[stan]

On Thu, 01 Mar 2018 14:29:45 -
"Farhad Mohammadi Majd"  wrote:

> Hello, in Debian (9, stable), size of all the official repositories
> metadata is maximum 10MB, while in Fedora, today I ran "dnf update"
> for first time after installing Fedora 27
> (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two
> official repositories!
> 
> It is really too high, why there is such difference? why don't
> optimize it and fix this problem?

I don't have any intimate knowledge of this.  But you are comparing
apples and oranges.  Apt and dnf.  Either the format of the meta data
must be very different for the two, or apt must send much less meta
data. 

You aren't alone in complaining about this.  Whenever an update occurs,
all the meta data has to be downloaded again.  People on limited
quantity connections find this onerous.  There has been discussion of
making the meta data update an incremental update, but the format of
meta data doesn't lend itself well to doing this.  And the delta files
would put a lot of extra files on repo hosts.

I think you can be assured that if there was a simple optimization that
could take care of this, it would have already been applied.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [RFC] Packages which are not installable (obsoleted by other pacakges)

[Honggang LI]

On Thu, Mar 01, 2018 at 05:46:00PM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I ran some check on latest compose and found that quite a few packages
> in repo can't be installed due to being obsoleted. What do we do about
> those packages? Should I submit bugs for each of them?


> can't install libhfi1-0.5-26.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.i686
> can't install libmlx5-1.0.2-5.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.i686
> can't install libocrdma-1.0.8-6.fc27.i686:
>   package is obsoleted by libibverbs-16.2-3.fc28.i686
> can't install libocrdma-1.0.8-6.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.i686
> can't install libhfi1-0.5-26.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.x86_64
> can't install libmlx5-1.0.2-5.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.x86_64
> can't install libocrdma-1.0.8-6.fc27.i686:
>   package is obsoleted by libibverbs-16.2-3.fc28.x86_64
> can't install libocrdma-1.0.8-6.fc27.x86_64:
>   package is obsoleted by libibverbs-16.2-3.fc28.x86_64


> can't install libhfi1-static-0.5-26.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.i686
> can't install libmlx5-static-1.0.2-5.fc27.i686:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.i686
> can't install libmlx5-static-1.0.2-5.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.i686
> can't install libocrdma-static-1.0.8-6.fc27.i686:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.i686
> can't install libocrdma-static-1.0.8-6.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.i686
> can't install libhfi1-static-0.5-26.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.x86_64
> can't install libmlx5-static-1.0.2-5.fc27.i686:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.x86_64
> can't install libmlx5-static-1.0.2-5.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.x86_64
> can't install libocrdma-static-1.0.8-6.fc27.i686:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.x86_64
> can't install libocrdma-static-1.0.8-6.fc27.x86_64:
>   package is obsoleted by rdma-core-devel-16.2-3.fc28.x86_64


https://bugzilla.redhat.com/show_bug.cgi?id=1404043#c42

The libhfi1, libmlx5, and libocrdma packages shold be retired.
I sent offline to libmlx5 and libocrdma maintainer when I retired
rest of user-space RDMA drives. But they did not retire the packages.

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

[Test-Announce] Fedora 28 Branched 20180301.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 28 Branched 20180301.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/28

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180301.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1550755] New: perl-Mozilla-CA-20180117 is available

[bugzilla]

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

Bug ID: 1550755
   Summary: perl-Mozilla-CA-20180117 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mozilla-CA
  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: 20180117
Current version/release in rawhide: 20160104-7.fc28
URL: http://search.cpan.org/dist/Mozilla-CA/

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

-- 
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 1550752] New: perl-Locale-Codes-3.56 is available

[bugzilla]

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

Bug ID: 1550752
   Summary: perl-Locale-Codes-3.56 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Locale-Codes
  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: 3.56
Current version/release in rawhide: 3.55-2.fc28
URL: http://search.cpan.org/dist/Locale-Codes/

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

-- 
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 1550748] New: perl-Date-Manip-6.70 is available

[bugzilla]

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

Bug ID: 1550748
   Summary: perl-Date-Manip-6.70 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Date-Manip
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: huzai...@redhat.com, jpazdzi...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org



Latest upstream release: 6.70
Current version/release in rawhide: 6.60-2.fc28
URL: http://search.cpan.org/dist/Date-Manip/

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

-- 
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: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Bruno Wolff III]

On Thu, Mar 01, 2018 at 09:19:48 -0600,
 Bruno Wolff III  wrote:


Note that there was a completed compose for March 1st, so you don't 
need this today.


I'm not sure what happened, but it looks like the compose only got copied 
over to the secondary architecure. So i386 has updates from today available 
by rsync, but x86_64 doesn't.

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

[Bug 1550305] perl-Net-FTPSSL-0.40 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-FTPSSL-0.40-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-01 16:39:52



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1052366

-- 
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 1550518] perl-CGI-Application-4.60 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CGI-Application-4.60-1
   ||.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-01 16:38:17



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1052377

-- 
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 1550533] perl-Mojolicious-7.70 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.70-1.fc2
   ||8
 Resolution|--- |NEXTRELEASE
Last Closed||2018-03-01 16:37:06



--- Comment #1 from Emmanuel Seyman  ---
Built for F28 and rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1052381
https://koji.fedoraproject.org/koji/buildinfo?buildID=1052383

-- 
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: Test gating enabled in Bodhi

[Randy Barlow]

On 03/01/2018 11:01 AM, mcatanz...@gnome.org wrote:
> I know Pierre-Yves warned us about the bug that the tests will be
> reported as a failure if the tests are still being run, but there was
> absolutely no indication that there were more tests that were still
> being run. So this could definitely stand to be improved.

I think you may have hit this issue:

https://github.com/fedora-infra/bodhi/issues/2124



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: [RFC] Packages which are not installable (obsoleted by other pacakges)

[Kevin Fenzi]

On 03/01/2018 08:46 AM, Igor Gnatenko wrote:
> I ran some check on latest compose and found that quite a few packages
> in repo can't be installed due to being obsoleted. What do we do about
> those packages? Should I submit bugs for each of them?

I would say so yes. Then after some time just retire the rest.

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: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Kevin Fenzi]

On 03/01/2018 07:19 AM, Bruno Wolff III wrote:
> On Thu, Mar 01, 2018 at 10:31:21 +0100,
>  Vít Ondruch <vondr...@redhat.com> wrote:
>>
>> Actually yes, it would be super useful if I knew where the repos are.
> 
> I use the following to get the rawhide i386 compose repo. I need to
> change the date and sequence number to match the one I want. I use it to
> get update packages and rarely to rollback packages after a bad update.

Note that these repos below only exist for two weeks and then are removed.

> You probably don't want the gpgcheck and sslverify disabled.

Yeah, everything should be signed and you should always use ssl/have
sslverify to true.

> 
> [compose]
> name=Fedora - Compose
> failovermethod=priority
> #baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/$basearch/os/
> 
> #mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=rawhide=$basearch
> 
> #baseurl=http://bruno.wolff.to/fedora/development/rawhide/$basearch/os/
> #baseurl=file:///home/fedora/development/rawhide/Everything/$basearch/os/
> baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180301.n.0/compose/Everything/i386/os/
> 
> enabled=1
> gpgcheck=0
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
> sslverify=False
> 
> Note that there was a completed compose for March 1st, so you don't need
> this today.

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: Frequently broken Rawhide/Branched composes

[Kevin Fenzi]

On 02/28/2018 06:19 PM, Kevin Kofler wrote:
> Fabio Valentini wrote:
>> AFAICT, those "broken deps in rawhide" mails are only sent if there is a
>> compose, and during the past weeks, there have been few of those ... so
>> breakage is sometimes allowed to sit unnoticed (and grow increasingly
>> worse) for very long.
> 
> Isn't that the real issue to fix? Failed Rawhide composes used to be a rare 
> event. Now we have both Rawhide and Branched composes broken for days at a 
> time, e.g., currently since February 20. This is just not acceptable.

Some of us have been/are working on fixing it. I agree that its not good
and we should work to fix it.
> 
> Something needs to be done to make the compose process more robust, e.g.:
> * running createrepo on a stable release, so that we do not have to be able
>   to init a chroot of the target system to compose a repository. A broken
>   dependency, even in systemd or rpm, should NEVER be a reason for the
>   repository to fail to compose.
> * publishing individual deliverables one at a time, i.e.:
>   1. compose the repositories,
>   2. sync the repositories out to the mirrors,
>   3. build the images (atomic ostrees, live images etc.) one at a time,
>   4. sync those images that succeeded out to the mirrors, keep the old
>  versions of the other ones (the matching SRPMs are in Koji anyway, so
>  it does not matter if the SRPMs in the tree don't match)
> etc.

I disagree entirely with the above. I think the solution is to gate
packages coming into rawhide and hold or reject those that break the
compose until they are fixed. I think being proactive is VASTLY better
than being reactive. Not breaking something in the first place is much
easier to deal with than trying to fix it later.
> 
> Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide and 
> Branched trees (which miscompiles the Chromium/QtWebEngine build tool GN on 
> x86_64), the fix (8.0.1-0.16) has already been in the right Koji tags for 
> days, but any third-party repository (RPM Fusion, Copr, etc.) will still get 
> the broken GCC. This is not acceptable.

I'm sure there's any number of bugs in any number of collections of
packages.

We had a successfull rawhide compose today. Many thanks to Patrick,
Adam, Dusty, Mohan, Dennis, the installer team and many others for
working through all the breakage.

Branched is running now, hopefully it will finish later today.

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1088  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 851  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 433  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 330  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 162  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  99  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  23  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832   
seamonkey-2.49.2-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4   
mbedtls-2.7.0-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3   
knot-resolver-2.1.0-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1   
openjpeg2-2.3.0-6.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7


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

copr-cli-1.66-1.el7
cycle-0.3.1-25.el7
dcap-2.47.12-4.el7
esteidcerts-3.8.0.9128-6.el7
mock-core-configs-28.3-1.el7
openblas-0.2.20-4.el7
python-copr-1.87-1.el7
python-pdir2-0.3.0-1.el7
python2-dns-1.12.0-0.el7
python2-httplib2-0.9.2-0.el7
python2-idna-2.4-0.el7
python2-pyyaml-3.10-0.el7
yubikey-piv-manager-1.4.2-2.el7

Details about builds:



 copr-cli-1.66-1.el7 (FEDORA-EPEL-2018-3411f2c3bf)
 Command line interface for COPR

Update Information:

- add missing frontend states to clientv2    - remove Group tag - build
python2-copr package conditionally - Remove unnecessary shebang sed in copr-
cli.spec and python-copr.spec - fix deps in spec - new custom source method -
use username from config if nothing is explicitly specified - remove outdated
modularity code - require to specify project when building module




 cycle-0.3.1-25.el7 (FEDORA-EPEL-2018-904f939753)
 Calendar program for women

Update Information:

Update to the latest packaging standards.




 dcap-2.47.12-4.el7 (FEDORA-EPEL-2018-6f7d6d)
 Client Tools for dCache

Update Information:

Fix a compiler warning.




 esteidcerts-3.8.0.9128-6.el7 (FEDORA-EPEL-2018-7d396fb6e6)
 Estonian ID-card certificates

Update Information:

First EPEL7 release




 mock-core-configs-28.3-1.el7 (FEDORA-EPEL-2018-386f64e833)
 Mock core config files basic chroots

Update Information:

- bump up releasever in rawhide configs - add CentOS SCL repositories to EPEL 6
& 7 (x86_64




 openblas-0.2.20-4.el7 (FEDORA-EPEL-2018-e3f0716e6d)
 An optimized BLAS library based on GotoBLAS2

Update Information:

Use proper linker flags.

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 961  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 851  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 822  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 433  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 162  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  81  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be69c94866   
clamav-0.99.3-8.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5   
mbedtls-2.7.0-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9   
seamonkey-2.49.2-2.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6ac908eac8   
openjpeg2-2.3.0-6.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6


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

copr-cli-1.66-1.el6
dcap-2.47.12-4.el6
packmol-18.013-1.el6
python-copr-1.87-1.el6
python2-dns-1.11.1-0.el6
python2-httplib2-0.7.7-0.el6
python2-pyyaml-3.10-0.el6

Details about builds:



 copr-cli-1.66-1.el6 (FEDORA-EPEL-2018-39bbb44ff0)
 Command line interface for COPR

Update Information:

- add missing frontend states to clientv2    - remove Group tag - build
python2-copr package conditionally - Remove unnecessary shebang sed in copr-
cli.spec and python-copr.spec - fix deps in spec - new custom source method -
use username from config if nothing is explicitly specified - remove outdated
modularity code - require to specify project when building module




 dcap-2.47.12-4.el6 (FEDORA-EPEL-2018-a761d972b5)
 Client Tools for dCache

Update Information:

Fix a compiler warning.




 packmol-18.013-1.el6 (FEDORA-EPEL-2018-4697c36edc)
 Packing optimization for molecular dynamics simulations

Update Information:

Update to version 18.013.




 python-copr-1.87-1.el6 (FEDORA-EPEL-2018-39bbb44ff0)
 Python interface for Copr

Update Information:

- add missing frontend states to clientv2    - remove Group tag - build
python2-copr package conditionally - Remove unnecessary shebang sed in copr-
cli.spec and python-copr.spec - fix deps in spec - new custom source method -
use username from config if nothing is explicitly specified - remove outdated
modularity code - require to specify project when building module




 python2-dns-1.11.1-0.el6 (FEDORA-EPEL-2018-a4c2a82fd6)
 Dummy package depending on python-dns

Update Information:

This package exists only to allow packagers to uniformly depend upon
python2-dns.




 python2-httplib2-0.7.7-0.el6 (FEDORA-EPEL-2018-7216f40c8e)
 Dummy package depending on python-httplib2

Update Information:

This package exists only to allow packagers to uniformly depend upon
python2-httplib2.

Re: Call for users of darkserver

[Pierre-Yves Chibon]

On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote:
> On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote:
> > So what do you advice as course of action here, should we fix darkserver or 
> > move
> > its functionality to ABRT?
> 
> "move its functionality to ABRT"
> 
> 
> > The later is tempting to me if it's just a few lines of code added on an 
> > app we
> > already maintain.
> 
> One problem of ABRT is that it cannot (or at least not easily) provide the
> core file to Bug Assignee.  Users always fail to figure out how when I ask
> them for that.  I do not know if it is just not user friendly enough or if the
> core files gets deleted from disk too quickly.
> 
> And developers (that is me) could not use ABRT so far as it OOM-killed machine
> on a first segfaulted program:
>   -fsanitize=address locks up abrt-hook-ccpp
>   https://bugzilla.redhat.com/show_bug.cgi?id=1164548
> It is EOLed again but maybe it works now on F-27 after my quick local
> re-check, I will check it later once I have access to an F-27 VM (travelling
> now).
> 
> Then the ABRT bugreport does not contain build-ids of the shared libraries
> involved, only build-ids of frames from a backtrace ("core_backtrace") which
> is not sufficient to reproduce the same memory layout.
> 
> It seems to me interactive crash core file analysis is just not a goal of ABRT
> (which is what was the goal of darkserver).

Did it ever meet this goal?
I never quite understood how it works, being far from this field, so I'm happy
to be enlighten on the topic.

> And currently after my reassignment in Red Hat I currently do not have any
> ABRT bugreports to investigate so I am currently not involved in this
> darkserver/ABRT build-id crash reproducibility (I may be again later).

Would you know if anyone in your old team would be interested by this?

I'm trying to assess if there is actually an interest for it.
You said you were interested by it but aren't working on this topic anymore, I
don't think anybody else than you noticed it not working over the course of last
year.
So I wonder if we shouldn't just call it a day, provide a dump of the DB
somewhere for people interested and decommission the app.
Fixing it on the other hand would require someone learning how the code works,
probably trying to poke at Kushal for inputs (but I don't want to assume he'll
fix it as I'm assuming he has other priorities) and finish deploying that new
version. It may not be quick.


Thoughts?

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

Re: can't install FreeSOLID-devel on F28

[Kevin Kofler]

Robert-André Mauchin wrote:
> It probably comes from your patch FreeSOLID-2.1.1-pkgconfig.patch:

I recommend dropping that patch entirely. IMHO, we should not add pkg-config 
files downstream for upstream libraries not using pkg-config. But of course 
that may break other packages expecting the downstream pkg-config support to 
be there, as the change in qhull did.

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

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Dusty Mabe wrote:
> FYI: atomic ostree composes are not release blocking so that is not why a
> compose will fail.

In the past we had composes failing due to something Atomic failing to 
compose, I guess that changed since.

Kevin Kofler
___
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

[Honza Horak]

On 02/25/2018 08:59 PM, Pierre-Yves Chibon wrote:

On Sun, Feb 25, 2018 at 12:12:33PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Feb 22, 2018 at 03:50:38PM +0100, 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?


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.


pingou, I share your thinking in general, but I think your concern is
overstated. Petr's original e-mail suggests that the new separate
namespace should be used *in* *preference* to the in-dist-git, and your
reply concentrates on that. But I think that we want to have both
possibilities, because both will work best for different cases, and it's
just the emphasis that needs to change.

I agree that having tests in a separate namespace is not any simpler
or more manageable for most packages. Thus, I think that *by* *default*
we should put tests in dist-git. IMHO this will apply to 90% of all
tests and packages.

OTOH, there will be cases where it'll be useful to split the tests out
into a separate area. The documentation for tests/ has the example of
shared tests for bash/zhs/dash. I'm sure that there will be other
cases, like testing of stacks consisting of multiple packages
apache+mysql+php or glibc+gcc+binutils, etc, where it'll be beneficial
to keep the test separate. The management of permissions in this case
will be _much_ more complicated, because to meaningfully update the
tests sometimes it'll be necessary to change the test repo and _each_
of the packages. But having them separate is better than randomly
sticking the shared tests in dist-git for one of the involved packages.
Nevertheless, because of the overhead of more repos and additional
permissions, IMHO this should never be advertised as the default
approach, but as an "advanced" possibility.


I violently agree with this :) I am very much advocating for using the test

Re: can't install FreeSOLID-devel on F28

[Robert-André Mauchin]

On jeudi 1 mars 2018 16:37:17 CET Martin Gansser wrote:
> Hi,
> 
> can't install FreeSOLID-devel on F28
> 
> [root@f28 tmp]# dnf install FreeSOLID-devel
> Last metadata expiration check: 1:45:49 ago on Thu Mar  1 14:49:33 2018.
> Error: 
>  Problem: conflicting requests
>   - nothing provides pkgconfig(qhull) needed by
> FreeSOLID-devel-2.1.1-29.fc28.i686
 - nothing provides pkgconfig(qhull)
> needed by FreeSOLID-devel-2.1.1-29.fc28.x86_6 
> how can this solved ?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

The pkgconfig for qhull was dropped a while ago:

* Fri Apr 29 2016 Ralf Corsépius  - 2015.2-1
- Update to 2015.2-7.2.0.
- Split out libqhull, libqhull_p, libqhull_r packages.
- drop pkgconfig.

But it seems in your F28 build, a Requires to pkgconfig(qhull) was added:

$ rpm -q --requires -p FreeSOLID-devel-2.1.1-29.fc28.x86_64.rpm 


17:44:00
/bin/sh
/bin/sh
/bin/sh
/usr/bin/pkg-config
FreeSOLID(x86-64) = 2.1.1-29.fc28
libFreeSOLID.so.0()(64bit)
pkgconfig
pkgconfig(qhull)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

It probably comes from your patch FreeSOLID-2.1.1-pkgconfig.patch:

diff --git a/FreeSOLID.pc.in b/FreeSOLID.pc.in
new file mode 100644
index 000..c354f05
--- /dev/null
+++ b/FreeSOLID.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: FreeSolid
+Description: 3D collision detection C++ library
+Version: @VERSION@
+Requires: qhull
+Libs: -L${libdir} -lFreeSOLID @QHULL_LIBS@
+Cflags: -I${includedir} -I/usr/include/FreeSOLID
+

You have a Requires: qhull which doesn't exist anymore as a pkgconfig, but it 
is still detected as a dependency. I'd remove it and add a Requires: qhull-
devel to your FreeSOLID-devel subpackages.

Tested in MockF29, it works.

Best regards,

Robert-André



___
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

[Honza Horak]

On 03/01/2018 04:00 PM, Petr Šplíchal wrote:

To sum up what I've heard so far from the developer side:

* I would like to enable tests for my component (yes, I want)
* I will take care of them (really, I see the benefit in CI)
* I want to easily collaborate on tests with qe (direct commits)
* I don't want to give qe commit access to the rpms dist git

This is quite likely the crux of the problem.

Personally, I'm perfectly happy to give write access to any repo
to people who have shown that they know what they are doing.
We have pull requests in dist-git pagure now, and I think this is
a better approach:
1. ask QE contributors to submit PRs
2. if enough cooperation happens and trust is established, give
   privileges to write to the repo directly, possibly with an agreement
   that this specific person should only touch tests, and not the
   packaging.

I think it's perfectly fine to never get to point 2.: many many
upstream projects require a review from a second person, or sometimes
even two reviews before a PR is merged, which means that one _never_
merges their own PR, and another contributor is always involved. We
usually don't do this in dist-git, but I'm quite sure that requiring
reviews for dist-git changes would raise quality and catch many silly
mistakes. Either way, it's nowadays possible to cooperate using a
single repo without fully trusting the other person, frictionlessly.


Good point. However, if there is a qe/devel team which prefers to
collaborate on tests in a separate repo because this is the most
efficient way they found so far, why should we stop them and try
to enforce a less efficient workflow? (Which they can workaround
by a different git repo.)


* I want to efficiently maintain tests long-term
* I want to have just a single place for my tests (no duplication)
* I don't want to backport new tests to old branches (enable once)
* I want to easily enable testing for all supported branches

Those four items depend strongly on the package. My thinking is
biased by some specific usecases (mainly systemd), but I'm sure many
other packages are like that: a lot of tests would be for new
functionality, and then the tests _are_ tied to the branch being
tested.

While I agree that keeping tests separate avoids a bit of effort
required to update multiple branches, this effort isn't very big. If
the tests indeed apply cleanly to all branches, then it's just a
matter of doing 'git merge' or 'git cherry-pick' once per branch.


* I want to keep rpms dist git clean (just metadata & patches)

Meh.


* I want to run all available relevant tests (not to list them)
* I want to execute set of tests based on a tag (e.g. Tier1)

Those two sound like stuff that should be solved in the tooling,
whatever is used to run tests.


* I want an easy way to clone tests (fedpkg clone tests/pkg)

Tests alone make no sense, you need something to test, and
cloning one repo is easier than cloning two repos, so there's no
advantage to the split here.


But "fedpkg clone tests" is easier than cloning from a "random"
git repository where I was forced to save my tests because I was
not allowed to save them in Fedora tests namespace.


I believe the tests namespace resolves them all.

None of those arguments convince me that separate repos for tests are
a good default. Sure, there are specific packages where this will make
sense, or specific packagers with idiosyncratic workflows, but I'd
rather "start small", with the simple configuration, and only move
specific packages to the more complicated setup once that proves to
be required.


Why default? Test namespace should be an option. Not the default.
Storing tests directly in dist git is and will be possible.
Anybody who finds this as a better way can do so. But why
enforcing this approach to all?


+1 Exactly! I don't really see any reason why to force people to follow 
one way when there are obvious disadvantages. All concerns against 
tests/ namespace in this thread are based on expectations that it won't 
work, but how can anybody know at this point? The only proof we have is 
that the tests/ namespace works internally.


I believe that what we really need here is flexibility -- let people 
find the way that works best for them.


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

Re: can't install FreeSOLID-devel on F28

[Kevin Kofler]

Martin Gansser wrote:
> can't install FreeSOLID-devel on F28
> 
> [root@f28 tmp]# dnf install FreeSOLID-devel
> Last metadata expiration check: 1:45:49 ago on Thu Mar  1 14:49:33 2018.
> Error:
>  Problem: conflicting requests
>   - nothing provides pkgconfig(qhull) needed by
> FreeSOLID-devel-2.1.1-29.fc28.i686
>   - nothing provides pkgconfig(qhull) needed by FreeSOLID-
> devel-2.1.1-29.fc28.x86_64
> 
> how can this solved ?

FreeSOLID-devel needs to be fixed to require qhull-devel instead of 
pkgconfig(qhull). qhull has not provided pkg-config support since 2016. It 
was never supported upstream, only by a downstream patch that has been 
dropped.

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

Re: qarte - compilation fails

[Kevin Kofler]

Try this:

BuildRequires:  python3-devel
# bytecompile with Python 3
%global __python %{__python3}

in your specfile to force it to bytecompile your Python code with Python 3.

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

Re: Frequently broken Rawhide/Branched composes

[Dusty Mabe]

On 03/01/2018 11:52 AM, Kevin Kofler wrote:
> Vít Ondruch wrote:
>> Speaking of that, it seems that the Rawhide compose failed yesterday due
>> to some KDE/QT soname bump:
> [actually a typo in a Requires, as was already pointed out]
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
>> https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log
> 
> Well, the real issue is that the entire Rawhide compose fails just because 
> one release-blocking deliverable failed to compose. In this case, it was the 
> KDE Spin, but it has been happening with any other release-blocking 
> deliverable, e.g., Atomic ostree composes.

FYI: atomic ostree composes are not release blocking so that is not why a 
compose
will fail.

> 
> Why can we not just deliver the parts that succeeded and keep the last 
> working version of the deliverables that failed to compose this time? In 
> other words, why can we not just upload the 20180228 compose and keep the 
> 20180227 or whatever KDE ISO that last built? Why does it have to be all or 
> nothing?
> 
> Kevin Kofler
> ___
> 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: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Vít Ondruch wrote:
> Speaking of that, it seems that the Rawhide compose failed yesterday due
> to some KDE/QT soname bump:
[actually a typo in a Requires, as was already pointed out]
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
> https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log

Well, the real issue is that the entire Rawhide compose fails just because 
one release-blocking deliverable failed to compose. In this case, it was the 
KDE Spin, but it has been happening with any other release-blocking 
deliverable, e.g., Atomic ostree composes.

Why can we not just deliver the parts that succeeded and keep the last 
working version of the deliverables that failed to compose this time? In 
other words, why can we not just upload the 20180228 compose and keep the 
20180227 or whatever KDE ISO that last built? Why does it have to be all or 
nothing?

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Kevin Kofler]

Simo Sorce wrote:
> It could be accomplished by changing our tooling[*] to use overlay
> filesystems to figure out exactly what a make install did and pick only
> those files.

Why is the overlay filesystem needed? We already install to a DESTDIR. The 
whole contents of the DESTDIR should be packaged. In fact, RPM already fails 
the build both if a listed file is missing and if an unlisted file is 
present.

The main issue is subpackages. You still need file lists to decide what 
files to put in what subpackages.

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

[RFC] Packages which are not installable (obsoleted by other pacakges)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran some check on latest compose and found that quite a few packages
in repo can't be installed due to being obsoleted. What do we do about
those packages? Should I submit bugs for each of them?

can't install zeroinstall-injector-2.3.3-9.fc28.noarch:
  package is obsoleted by 0install-2.12.1-1.fc27.x86_64
can't install ardour4-4.7.0-10.fc28.x86_64:
  package is obsoleted by ardour5-5.12.0-4.fc28.x86_64
can't install ardour4-audiobackend-alsa-4.7.0-10.fc28.x86_64:
  package is obsoleted by ardour5-audiobackend-alsa-5.12.0-
4.fc28.x86_64
can't install ardour4-audiobackend-dummy-4.7.0-10.fc28.x86_64:
  package is obsoleted by ardour5-audiobackend-dummy-5.12.0-
4.fc28.x86_64
can't install ardour4-audiobackend-jack-4.7.0-10.fc28.x86_64:
  package is obsoleted by ardour5-audiobackend-jack-5.12.0-
4.fc28.x86_64
can't install php-channel-drush-1.3-9.fc28.noarch:
  package is obsoleted by drush-8.1.10-4.fc28.noarch
can't install eclipse-mylyn-fedora-integration-1.0.4-6.fc28.noarch:
  package is obsoleted by eclipse-abrt-0.0.3-4.fc28.noarch
can't install emerald-themes-extra-0.7-10.fc28.noarch:
  package is obsoleted by emerald-themes-1:0.8.14-3.fc28.noarch
can't install jackson-dataformat-cbor-javadoc-2.7.6-3.fc27.noarch:
  package is obsoleted by jackson-dataformats-binary-javadoc-2.9.4-
3.fc28.noarch
can't install jackson-dataformat-smile-javadoc-2.7.6-3.fc27.noarch:
  package is obsoleted by jackson-dataformats-binary-javadoc-2.9.4-
3.fc28.noarch
can't install jackson-dataformat-csv-javadoc-2.7.6-3.fc27.noarch:
  package is obsoleted by jackson-dataformats-text-javadoc-2.9.4-
3.fc28.noarch
can't install jackson-dataformat-yaml-javadoc-2.7.6-3.fc27.noarch:
  package is obsoleted by jackson-dataformats-text-javadoc-2.9.4-
3.fc28.noarch
can't install jackson-module-jaxb-annotations-javadoc-2.7.6-
3.fc27.noarch:
  package is obsoleted by jackson-modules-base-javadoc-2.9.4-
2.fc28.noarch
can't install kdevplatform-5.1.2-2.fc28.x86_64:
  package is obsoleted by kdevelop-9:5.2.1-2.fc28.x86_64
can't install kdevplatform-devel-5.1.2-2.fc28.i686:
  package is obsoleted by kdevelop-devel-9:5.2.1-2.fc28.i686
can't install kdevplatform-devel-5.1.2-2.fc28.x86_64:
  package is obsoleted by kdevelop-devel-9:5.2.1-2.fc28.i686
can't install kdevplatform-devel-5.1.2-2.fc28.i686:
  package is obsoleted by kdevelop-devel-9:5.2.1-2.fc28.x86_64
can't install kdevplatform-devel-5.1.2-2.fc28.x86_64:
  package is obsoleted by kdevelop-devel-9:5.2.1-2.fc28.x86_64
can't install kdevplatform-libs-5.1.2-2.fc28.i686:
  package is obsoleted by kdevelop-libs-9:5.2.1-2.fc28.i686
can't install kdevplatform-libs-5.1.2-2.fc28.x86_64:
  package is obsoleted by kdevelop-libs-9:5.2.1-2.fc28.i686
can't install kdevplatform-libs-5.1.2-2.fc28.i686:
  package is obsoleted by kdevelop-libs-9:5.2.1-2.fc28.x86_64
can't install kdevplatform-libs-5.1.2-2.fc28.x86_64:
  package is obsoleted by kdevelop-libs-9:5.2.1-2.fc28.x86_64
can't install cadvisor-0.22.2-7.fc28.x86_64:
  package is obsoleted by kubernetes-1.9.3-1.fc28.x86_64
can't install kyua-cli-0.9-9.fc28.x86_64:
  package is obsoleted by kyua-0.13-1.fc28.x86_64
can't install kyua-testers-0.3-8.fc28.i686:
  package is obsoleted by kyua-0.13-1.fc28.x86_64
can't install kyua-testers-0.3-8.fc28.x86_64:
  package is obsoleted by kyua-0.13-1.fc28.x86_64
can't install kyua-testers-devel-0.3-8.fc28.i686:
  package is obsoleted by kyua-0.13-1.fc28.x86_64
can't install kyua-testers-devel-0.3-8.fc28.x86_64:
  package is obsoleted by kyua-0.13-1.fc28.x86_64
can't install kyua-cli-tests-0.9-9.fc28.x86_64:
  package is obsoleted by kyua-tests-0.13-1.fc28.x86_64
can't install kyua-testers-tests-0.3-8.fc28.x86_64:
  package is obsoleted by kyua-tests-0.13-1.fc28.x86_64
can't install lxshortcut-0.1.2-14.fc28.x86_64:
  package is obsoleted by libfm-gtk-utils-1.2.5-
5.gitD20171230.fc28.1.x86_64
can't install libhfi1-0.5-26.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.i686
can't install libmlx5-1.0.2-5.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.i686
can't install libocrdma-1.0.8-6.fc27.i686:
  package is obsoleted by libibverbs-16.2-3.fc28.i686
can't install libocrdma-1.0.8-6.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.i686
can't install libhfi1-0.5-26.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.x86_64
can't install libmlx5-1.0.2-5.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.x86_64
can't install libocrdma-1.0.8-6.fc27.i686:
  package is obsoleted by libibverbs-16.2-3.fc28.x86_64
can't install libocrdma-1.0.8-6.fc27.x86_64:
  package is obsoleted by libibverbs-16.2-3.fc28.x86_64
can't install liblxqt-mount-0.9.0-9.fc28.i686:
  package is obsoleted by lxqt-panel-0.11.1-7.fc28.x86_64
can't install liblxqt-mount-0.9.0-9.fc28.x86_64:
  package is obsoleted by lxqt-panel-0.11.1-7.fc28.x86_64
can't install liblxqt-mount-devel-0.9.0-9.fc28.i686:
  package is obsoleted by 

Re: qarte - compilation fails

[Tim Landscheidt]

"Martin Gansser"  wrote:

> when compiling qarte-4.4.0 with this spec file
> https://martinkg.fedorapeople.org/Packages/test/qarte.spec

>  '[' noarch = noarch ']'
> + case "${QA_CHECK_RPATHS:-}" in
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/brp-compress
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> Compiling 
> /home/martin/rpmbuild/BUILDROOT/qarte-4.0.0-1.fc27.x86_64/usr/share/qarte/arteconcert.py
>  ...
>   File "/usr/share/qarte/arteconcert.py", line 385
> def update_pitch(self, *args, html=False):
>  ^
> SyntaxError: invalid syntax

> error: Bad exit status from /var/tmp/rpm-tmp.rp9wQD (%install)

> only when i comment the following line, the program compiles fine:
> #cp -p *.py* %{buildroot}%{_datadir}/%{name}

To state the obvious: arteconcert.py is Python 3,
brp-python-bytecompile uses /usr/bin/python (which is most
likely Python 2):

| [tim@passepartout ~]$ python2 -m py_compile 
~/RPMS/BUILD/qarte-4.0.0/arteconcert.py
|   File "/home/tim/RPMS/BUILD/qarte-4.0.0/arteconcert.py", line 385
| def update_pitch(self, *args, html=False):
|  ^
| SyntaxError: invalid syntax

| [tim@passepartout ~]$ python3 -m py_compile 
~/RPMS/BUILD/qarte-4.0.0/arteconcert.py
| [tim@passepartout ~]$

Following the advice from
https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation,
prepending:

| %global __python %{__python3}

to your qarte.spec works, but there may be cleaner solu-
tions.

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

[Bug 1547288] perl-CPAN-Perl-Releases-3.48 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.48-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: qarte - compilation fails

[Charalampos Stratakis]

- Original Message -
> From: "Martin Gansser" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, March 1, 2018 11:35:25 AM
> Subject: qarte - compilation fails
> 
> Hi,
> 
> when compiling qarte-4.4.0 with this spec file
> https://martinkg.fedorapeople.org/Packages/test/qarte.spec
> 
>  '[' noarch = noarch ']'
> + case "${QA_CHECK_RPATHS:-}" in
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/brp-compress
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> Compiling
> /home/martin/rpmbuild/BUILDROOT/qarte-4.0.0-1.fc27.x86_64/usr/share/qarte/arteconcert.py
> ...
>   File "/usr/share/qarte/arteconcert.py", line 385
> def update_pitch(self, *args, html=False):
>  ^
> SyntaxError: invalid syntax
> 
> error: Bad exit status from /var/tmp/rpm-tmp.rp9wQD (%install)
> 
> only when i comment the following line, the program compiles fine:
> #cp -p *.py* %{buildroot}%{_datadir}/%{name}
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

It seems that rpm bytecompiles arteconcert.py with python2, and having a 
default argument (html=False) after *args is not allowed in python2.

What happens if you try to build it in rawhide?

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: new really minimal 'System' group (Core reduced more)

[Neal Gompa]

On Thu, Mar 1, 2018 at 10:57 AM, David Demelier  wrote:
> Hello all,
>
> I was searching a very possible minimal dnf group for chroot builds. It
> looks like the 'Core' group already minimal contains lots of packages
> that may be unneeded in containers/chroot scenarios. For example:
>
>   - sssd,
>   - cronie,
>   - selinux packages,
>   - NetworkManager,
>   - firewalld (host already have),
>   - grubby,
>   - kbd,
>   - e2fsprogs (in chroot, you usually don't need any disk tool)
>   - small minor packages.
>
> That's why I propose a brand new group that targets extremely minimal
> chroot or basic appliances machines with the following list:
>
> Group: System
>  Description: Smallest mandatory packages
>  Mandatory Packages:
>basesystem
>bash
>coreutils
>curl
>dhcp-client
>dnf
>dnf-yum
>filesystem
>glibc
>hostname
>initscripts
>iproute
>iputils
>less
>man-db
>ncurses
>openssh-clients
>openssh-server
>passwd
>procps-ng
>rootfiles
>rpm
>setup
>shadow-utils
>sudo
>systemd
>vim-minimal
>  Default Packages:
>   (none)
>  Optional Packages:
>   (none)
>  Conditional Packages:
>   (none)
>
> I'm also thinking about the name 'base' similar to 'base-x'. What's
> your thoughts on that?
>

We actually have a basesystem metapackage in Fedora that functions in
this manner. Try that and see if it serves your needs.

For minimal setups, I usually use "dnf
--setopt=install_weak_deps=False install basesystem fedora-release",
which gets the smallest subset without a package manager. Add "dnf"
and you have the package manager too.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Test gating enabled in Bodhi

[mcatanzaro]

On Wed, Feb 28, 2018 at 7:49 PM, Randy Barlow 
 wrote:

It does not appear to be blocked currently.


There is a bug. Yesterday it was red and said tests failed; the result 
changed itself. I see there are many more test results now than there 
were yesterday. It looks like the tests had not finished running when I 
checked yesterday.


I know Pierre-Yves warned us about the bug that the tests will be 
reported as a failure if the tests are still being run, but there was 
absolutely no indication that there were more tests that were still 
being run. So this could definitely stand to be improved.


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

Proposal: new really minimal 'System' group (Core reduced more)

[David Demelier]

Hello all,

I was searching a very possible minimal dnf group for chroot builds. It
looks like the 'Core' group already minimal contains lots of packages
that may be unneeded in containers/chroot scenarios. For example:

  - sssd,
  - cronie,
  - selinux packages,
  - NetworkManager,
  - firewalld (host already have),
  - grubby,
  - kbd,
  - e2fsprogs (in chroot, you usually don't need any disk tool)
  - small minor packages.

That's why I propose a brand new group that targets extremely minimal
chroot or basic appliances machines with the following list:

Group: System
 Description: Smallest mandatory packages
 Mandatory Packages:
   basesystem
   bash
   coreutils
   curl
   dhcp-client
   dnf
   dnf-yum
   filesystem
   glibc
   hostname
   initscripts
   iproute
   iputils
   less
   man-db
   ncurses
   openssh-clients
   openssh-server
   passwd
   procps-ng
   rootfiles
   rpm
   setup
   shadow-utils
   sudo
   systemd
   vim-minimal
 Default Packages:
  (none)
 Optional Packages:
  (none)
 Conditional Packages:
  (none)

I'm also thinking about the name 'base' similar to 'base-x'. What's
your thoughts on that?

Regards,

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

[Bug 1547288] perl-CPAN-Perl-Releases-3.48 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.48-1.fc26 has been pushed to the Fedora 26 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

[Bug 1546073] Upgrade perl-Text-Template to 1.50

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Text-Template-1.50-1.f
   ||c29
   ||perl-Text-Template-1.50-1.f
   ||c28
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |jples...@redhat.com
Last Closed||2018-03-01 10:43:33



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

can't install FreeSOLID-devel on F28

[Martin Gansser]

Hi,

can't install FreeSOLID-devel on F28

[root@f28 tmp]# dnf install FreeSOLID-devel
Last metadata expiration check: 1:45:49 ago on Thu Mar  1 14:49:33 2018.
Error: 
 Problem: conflicting requests
  - nothing provides pkgconfig(qhull) needed by 
FreeSOLID-devel-2.1.1-29.fc28.i686
  - nothing provides pkgconfig(qhull) needed by 
FreeSOLID-devel-2.1.1-29.fc28.x86_6

how can this solved ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Bruno Wolff III]

On Thu, Mar 01, 2018 at 10:31:21 +0100,
 Vít Ondruch <vondr...@redhat.com> wrote:


Actually yes, it would be super useful if I knew where the repos are.


I use the following to get the rawhide i386 compose repo. I need to change the 
date and sequence number to match the one I want. I use it to get update 
packages and rarely to rollback packages after a bad update.

You probably don't want the gpgcheck and sslverify disabled.

[compose]
name=Fedora - Compose
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/$basearch/os/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=rawhide=$basearch
#baseurl=http://bruno.wolff.to/fedora/development/rawhide/$basearch/os/
#baseurl=file:///home/fedora/development/rawhide/Everything/$basearch/os/
baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180301.n.0/compose/Everything/i386/os/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
sslverify=False

Note that there was a completed compose for March 1st, so you don't need 
this today.

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

[Bug 1546069] Upgrade perl-Proc-ProcessTable to 0.55

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Proc-ProcessTable-0.55
   ||-1.fc29
   ||perl-Proc-ProcessTable-0.55
   ||-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|andr...@bawue.net   |jples...@redhat.com
Last Closed||2018-03-01 10:08:43



-- 
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: rawhide: Can't locate ExtUtils/CBuilder.pm

[Petr Pisar]

On Thu, Mar 01, 2018 at 10:33:25AM +, Paul Howarth wrote:
> That'll be because Server-Starter's Build.PL has
> 
>  "c_source => [qw()],"
> 
> And that's generated by Minilla, so all non-XS Minilla-based dists are
> likely to be affected.
> 
Indeed. I reported a bug against Minilla
 and sent a patch to
Module-Build .

I also applied the patch to perl-Module-Build-0.42.24-7.fc29. Since then
noarch Minilla-generated packages should build again.

-- 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: New "tests" namespace to share test code

[Petr Šplíchal]

>> To sum up what I've heard so far from the developer side:
>>
>> * I would like to enable tests for my component (yes, I want)
>> * I will take care of them (really, I see the benefit in CI)
>> * I want to easily collaborate on tests with qe (direct commits)
>> * I don't want to give qe commit access to the rpms dist git
> This is quite likely the crux of the problem.
>
> Personally, I'm perfectly happy to give write access to any repo
> to people who have shown that they know what they are doing.
> We have pull requests in dist-git pagure now, and I think this is
> a better approach:
> 1. ask QE contributors to submit PRs
> 2. if enough cooperation happens and trust is established, give
>   privileges to write to the repo directly, possibly with an agreement
>   that this specific person should only touch tests, and not the
>   packaging.
>
> I think it's perfectly fine to never get to point 2.: many many
> upstream projects require a review from a second person, or sometimes
> even two reviews before a PR is merged, which means that one _never_
> merges their own PR, and another contributor is always involved. We
> usually don't do this in dist-git, but I'm quite sure that requiring
> reviews for dist-git changes would raise quality and catch many silly
> mistakes. Either way, it's nowadays possible to cooperate using a
> single repo without fully trusting the other person, frictionlessly.

Good point. However, if there is a qe/devel team which prefers to
collaborate on tests in a separate repo because this is the most
efficient way they found so far, why should we stop them and try
to enforce a less efficient workflow? (Which they can workaround
by a different git repo.)

>> * I want to efficiently maintain tests long-term
>> * I want to have just a single place for my tests (no duplication)
>> * I don't want to backport new tests to old branches (enable once)
>> * I want to easily enable testing for all supported branches
> Those four items depend strongly on the package. My thinking is
> biased by some specific usecases (mainly systemd), but I'm sure many
> other packages are like that: a lot of tests would be for new
> functionality, and then the tests _are_ tied to the branch being
> tested.
>
> While I agree that keeping tests separate avoids a bit of effort
> required to update multiple branches, this effort isn't very big. If
> the tests indeed apply cleanly to all branches, then it's just a
> matter of doing 'git merge' or 'git cherry-pick' once per branch.
>
>> * I want to keep rpms dist git clean (just metadata & patches)
> Meh.
>
>> * I want to run all available relevant tests (not to list them)
>> * I want to execute set of tests based on a tag (e.g. Tier1)
> Those two sound like stuff that should be solved in the tooling,
> whatever is used to run tests.
>
>> * I want an easy way to clone tests (fedpkg clone tests/pkg)
> Tests alone make no sense, you need something to test, and
> cloning one repo is easier than cloning two repos, so there's no
> advantage to the split here.

But "fedpkg clone tests" is easier than cloning from a "random"
git repository where I was forced to save my tests because I was
not allowed to save them in Fedora tests namespace.

>> I believe the tests namespace resolves them all.
> None of those arguments convince me that separate repos for tests are
> a good default. Sure, there are specific packages where this will make
> sense, or specific packagers with idiosyncratic workflows, but I'd
> rather "start small", with the simple configuration, and only move
> specific packages to the more complicated setup once that proves to
> be required.

Why default? Test namespace should be an option. Not the default.
Storing tests directly in dist git is and will be possible.
Anybody who finds this as a better way can do so. But why
enforcing this approach to all?

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Simo Sorce]

On Thu, 2018-03-01 at 06:21 -0500, Matthew Miller wrote:
> On Wed, Feb 28, 2018 at 01:29:38PM -0500, Simo Sorce wrote:
> > > I used to agree with this, but I've come around to thinking that spec
> > > files should be smaller, less complicated, and more automatable. I
> > > think we'd be better having a post-build test warning that this package
> > > has files missing from the previous build. That could be advisory, or
> > > it could even gate, with the packager clearing the gate by updating the
> > > file list in the test, rather than in the spec file.
> > 
> > If you still have to keep a list, why is it better to keep it in tests
> 
> Separation of concerns. But also, you shouldn't have to keep a list per
> se, just annotations of when it's okay that the list has changed.

On way would be to eliminate lists completely except for special cases,
like removal of things we do not want to distribute.

It could be accomplished by changing our tooling[*] to use overlay
filesystems to figure out exactly what a make install did and pick only
those files.

But unless we have that kind of automation we will always have to
maintain a list and I'd rather have it all in one single place (the
spec file) rather than multiple places that you then have to reconcile.

Simo.

[*] I know this is easier said than done, and comes with it's bag of
issues.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Vít Ondruch]

Dne 1.3.2018 v 14:47 Mamoru TASAKA napsal(a):
> Vít Ondruch wrote on 03/01/2018 06:44 PM:
>>
>>
>> Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
>>> Fabio Valentini wrote:
 AFAICT, those "broken deps in rawhide" mails are only sent if there
 is a
 compose, and during the past weeks, there have been few of those
 ... so
 breakage is sometimes allowed to sit unnoticed (and grow increasingly
 worse) for very long.
>>> Isn't that the real issue to fix? Failed Rawhide composes used to be
>>> a rare
>>> event.
>>
>> Speaking of that, it seems that the Rawhide compose failed yesterday due
>> to some KDE/QT soname bump:
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
>>
>> https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log
>>
>> Were these announced? Are they handled? Why aren't these done in
>> sidetag?
>
> No, the above root.log does not mean some KDE/QT soname bump. You must
> look at dnf complaint from the bottom to the top:
>
> 1. nothing provides gstreamer1-plugins-good5{?_isa} needed by
> phonon-qt5-backend-gstreamer-2:4.9.0-7.fc29.x86_64
> Apparently 5{?_isa} is typo (5 should be %, perhaps)

I might be wrong. Thx for pointing this out and thx to Adam for taking
care about this.

https://src.fedoraproject.org/rpms/phonon/c/8a0f0ad81bce771f85c1b0f4dc8b1f9c8372c17f?branch=master

Vít


>
> 2. So package phonon-qt5-4.10.0-1.fc29.x86_64 requires
> phonon-qt5-backend(x86-64) >= 4.7, but
> (as phonon-qt5-backend(x86-64) is provided by
> phonon-qt5-backend-gstreamer but
>  phonon-qt5-backend-gstreamer cannot be installed because of
> gstreamer1-plugins-good typo)
>    none of the providers can be installed
>
> 3. package kf5-knotifyconfig-5.43.0-2.fc28.x86_64 requires
> libphonon4qt5.so.4()(64bit), but
> (as libphonon4qt5.so.4 is provided by phonon-qt5-4.10.0-1.fc29.x86_64
> but phonon-qt5
>  cannot be installed because .  .) none of the providers
> can be installed
>
> 4. is the same, from the top to bottom.
>
>> V.
>
> Regards,
> Mamoru
>
>>
>>
>>>   Now we have both Rawhide and Branched composes broken for days at a
>>> time, e.g., currently since February 20. This is just not acceptable.
>>>
>>> Something needs to be done to make the compose process more robust,
>>> e.g.:
>>> * running createrepo on a stable release, so that we do not have to
>>> be able
>>>    to init a chroot of the target system to compose a repository. A
>>> broken
>>>    dependency, even in systemd or rpm, should NEVER be a reason for the
>>>    repository to fail to compose.
>>> * publishing individual deliverables one at a time, i.e.:
>>>    1. compose the repositories,
>>>    2. sync the repositories out to the mirrors,
>>>    3. build the images (atomic ostrees, live images etc.) one at a
>>> time,
>>>    4. sync those images that succeeded out to the mirrors, keep the old
>>>   versions of the other ones (the matching SRPMs are in Koji
>>> anyway, so
>>>   it does not matter if the SRPMs in the tree don't match)
>>> etc.
>>>
>>> Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the
>>> Rawhide and
>>> Branched trees (which miscompiles the Chromium/QtWebEngine build
>>> tool GN on
>>> x86_64), the fix (8.0.1-0.16) has already been in the right Koji
>>> tags for
>>> days, but any third-party repository (RPM Fusion, Copr, etc.) will
>>> still get
>>> the broken GCC. This is not acceptable.
>>>
>>>  Kevin Kofler
>>> ___
>>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Why size of repositories metadata is too high in Fedora?

[Farhad Mohammadi Majd]

Hello, in Debian (9, stable), size of all the official repositories metadata is 
maximum 10MB,
 while in Fedora, today I ran "dnf update" for first time after installing 
Fedora 27 (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two 
official repositories!

It is really too high, why there is such difference? why don't optimize it and 
fix this problem?
___
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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 01, 2018 at 02:44:37PM +0100, Petr Šplíchal wrote:
> > > > 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.
> >
> > I don't see how that's not possible with tests being in
> > dist-git.
> 
> What I've heard from devels is that they often don't feel like
> giving direct commit access to the rpms dist git to QE as spec
> files and packaging in general is a big responsiblity. But they
> are quite OK with directly collaborating with QE on test coverage.
> 
> > If the tests are defined in dist-git and adding new tests means
> > committing these changes to dist-git's yaml file, how does that
> > solve the concern about "noise" in the git commits?
> 
> Not necessarily. You could use advanced metadata to select desired
> tests only once. The very first proof of concept of using Flexible
> Metadata Format for testing selinux quite nicely illustrates this:
> 
> https://src.fedoraproject.org/tests/selinux/pull-request/1
> https://github.com/psss/fmf
> 
> Instead of listing individual tests you could say: Run all tests
> for this selinux component + all Tier1 selinux integration tests:
> 
> fmf --key test --filter 'component:libselinux | tags:Tier1'
> 
> For tests covering multiple components the benefit of the tests
> namespace approach is unquestionable. However, I see benefit of
> the approach for single components as well (and developers seem
> to often feel the same): That is not having to cherry-pick/merge
> test coverage between supported branches. So even for these cases
> there is the benefit of sharing the test code.
> 
> I believe that extending the integration testing coverage is one
> the most essential goals of Fedora CI. This is the crucial piece
> of the puzzle how to make an Always Ready Operating System: It is
> to ensure that packages play nicely together. So I guess there
> will be quite many tests which will benefit from this approach.
> 
> Do we really want/need to assess every new request for a tests
> repo if it is good-enough for the test namespace? Will there be
> a committee to decide whether a particular set of tests has a
> potential to be used by other components in the future or not? :)
> 
> To sum up what I've heard so far from the developer side:
> 
> * I would like to enable tests for my component (yes, I want)
> * I will take care of them (really, I see the benefit in CI)
> * I want to easily collaborate on tests with qe (direct commits)
> * I don't want to give qe commit access to the rpms dist git
This is quite likely the crux of the problem.

Personally, I'm perfectly happy to give write access to any repo
to people who have shown that they know what they are doing.
We have pull requests in dist-git pagure now, and I think this is
a better approach:
1. ask QE contributors to submit PRs
2. if enough cooperation happens and trust is established, give
  privileges to write to the repo directly, possibly with an agreement
  that this specific person should only touch tests, and not the
  packaging.

I think it's perfectly fine to never get to point 2.: many many
upstream projects require a review from a second person, or sometimes
even two reviews before a PR is merged, which means that one _never_
merges their own PR, and another contributor is always involved. We
usually don't do this in dist-git, but I'm quite sure that requiring
reviews for dist-git changes would raise quality and catch many silly
mistakes. Either way, it's nowadays possible to cooperate using a
single repo without fully trusting the other person, frictionlessly.

> * I want to efficiently maintain tests long-term
> * I want to have just a single place for my tests (no duplication)
> * I don't want to backport new tests to old branches (enable once)
> * I want to easily enable testing for all supported branches
Those four items depend strongly on the package. My thinking is
biased by some specific usecases (mainly systemd), but I'm sure many
other packages are like that: a lot of tests would be for new
functionality, and then the tests _are_ tied to the branch being
tested.

While I agree that keeping tests separate avoids a bit of effort
required to update multiple branches, this effort isn't very big. If
the tests indeed apply cleanly to all branches, then it's just a
matter of doing 'git merge' or 'git cherry-pick' once per branch.

> * I want to keep rpms dist git clean (just metadata & patches)
Meh.

> * I want to run all available relevant tests (not to list them)
> * I want to 

Fedora Rawhide-20180301.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 29/129 (x86_64), 8/24 (i386), 1/2 (arm)

ID: 196035  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/196035
ID: 196038  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/196038
ID: 196048  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196048
ID: 196051  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196051
ID: 196053  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196053
ID: 196054  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196054
ID: 196064  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196064
ID: 196066  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/196066
ID: 196067  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196067
ID: 196068  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196068
ID: 196069  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196069
ID: 196070  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/196070
ID: 196071  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/196071
ID: 196072  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196072
ID: 196073  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196073
ID: 196074  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196074
ID: 196084  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196084
ID: 196085  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/196085
ID: 196096  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/196096
ID: 196097  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196097
ID: 196108  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/196108
ID: 196109  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196109
ID: 196111  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196111
ID: 196114  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196114
ID: 196115  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/196115
ID: 196120  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196120
ID: 196121  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/196121
ID: 196123  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/196123
ID: 196125  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196125
ID: 196139  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/196139
ID: 196151  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/196151
ID: 196153  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196153
ID: 196157  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/196157
ID: 196158  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/196158
ID: 196161  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/196161
ID: 196163  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196163
ID: 196169  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/196169
ID: 196176  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/196176

Soft failed openQA tests: 9/129 (x86_64), 3/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 196023  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196023
ID: 196024  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196024
ID: 196046  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196046
ID: 196047  Test: i386 

Re: rawhide: Can't locate ExtUtils/CBuilder.pm

[Ralf Corsepius]

On 03/01/2018 11:33 AM, Paul Howarth wrote:

On Thu, 1 Mar 2018 11:17:18 +0100
Petr Pisar  wrote:


On Thu, Mar 01, 2018 at 09:38:08AM +0100, Ralf Corsepius wrote:

Hi,

perl-Plack fails to build in rawhide with
this error[1]


Sorry, of course this was perl-Server-Starter, not perl-Plack.


...
+ /usr/bin/perl Build.PL --installdirs=vendor
Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install
the ExtUtils::CBuilder module) (@INC contains:
/builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5
/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
/usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.
...

f26, f27 and f28 build fine.

What is going on here? perl-Plack does not carry any direct
dependency on ExtUtils::CBuilder, so my guess would be a dependency
is missing somewhere else.
   


is happennning due to GCC removal from F29 build root.

If you have a package with XS modules and use Module::Build, you need
to build-require ExtUtils::CBuilder.

In case of Server-Starter, there seems to be a bug in
Module::Build::Base. It invokes auto_require() that for some reason
has $self->c_source set to [], and thus it decides it needs a
compiler and hence ExtUtils::CBuilder.

I think this condition in auto_require() should be corrected:

 $self->needs_compiler( keys %$xs_files || defined
$self->c_source );

and also the reason why $self->c_source is [] instead of undef should
be investigated.


That'll be because Server-Starter's Build.PL has

  "c_source => [qw()],"

And that's generated by Minilla, so all non-XS Minilla-based dists are
likely to be affected.
I am not familiar with Minilla, but you seem to have a point. At least, 
removing this line from Build.PL lets building perl-Server-Starter 
succeed for rawhide:

https://koji.fedoraproject.org/koji/taskinfo?taskID=25390138

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

Re: Frequently broken Rawhide/Branched composes

[Mamoru TASAKA]

Vít Ondruch wrote on 03/01/2018 06:44 PM:



Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):

Fabio Valentini wrote:

AFAICT, those "broken deps in rawhide" mails are only sent if there is a
compose, and during the past weeks, there have been few of those ... so
breakage is sometimes allowed to sit unnoticed (and grow increasingly
worse) for very long.

Isn't that the real issue to fix? Failed Rawhide composes used to be a rare
event.


Speaking of that, it seems that the Rawhide compose failed yesterday due
to some KDE/QT soname bump:

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log

Were these announced? Are they handled? Why aren't these done in sidetag?


No, the above root.log does not mean some KDE/QT soname bump. You must
look at dnf complaint from the bottom to the top:

1. nothing provides gstreamer1-plugins-good5{?_isa} needed by 
phonon-qt5-backend-gstreamer-2:4.9.0-7.fc29.x86_64
Apparently 5{?_isa} is typo (5 should be %, perhaps)

2. So package phonon-qt5-4.10.0-1.fc29.x86_64 requires phonon-qt5-backend(x86-64) 
>= 4.7, but
(as phonon-qt5-backend(x86-64) is provided by phonon-qt5-backend-gstreamer but
 phonon-qt5-backend-gstreamer cannot be installed because of 
gstreamer1-plugins-good typo)
   none of the providers can be installed

3. package kf5-knotifyconfig-5.43.0-2.fc28.x86_64 requires 
libphonon4qt5.so.4()(64bit), but
(as libphonon4qt5.so.4 is provided by phonon-qt5-4.10.0-1.fc29.x86_64 but 
phonon-qt5
 cannot be installed because .  .) none of the providers can be 
installed

4. is the same, from the top to bottom.


V.


Regards,
Mamoru





  Now we have both Rawhide and Branched composes broken for days at a
time, e.g., currently since February 20. This is just not acceptable.

Something needs to be done to make the compose process more robust, e.g.:
* running createrepo on a stable release, so that we do not have to be able
   to init a chroot of the target system to compose a repository. A broken
   dependency, even in systemd or rpm, should NEVER be a reason for the
   repository to fail to compose.
* publishing individual deliverables one at a time, i.e.:
   1. compose the repositories,
   2. sync the repositories out to the mirrors,
   3. build the images (atomic ostrees, live images etc.) one at a time,
   4. sync those images that succeeded out to the mirrors, keep the old
  versions of the other ones (the matching SRPMs are in Koji anyway, so
  it does not matter if the SRPMs in the tree don't match)
etc.

Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide and
Branched trees (which miscompiles the Chromium/QtWebEngine build tool GN on
x86_64), the fix (8.0.1-0.16) has already been in the right Koji tags for
days, but any third-party repository (RPM Fusion, Copr, etc.) will still get
the broken GCC. This is not acceptable.

 Kevin Kofler
___
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

Re: New "tests" namespace to share test code

[Petr Šplíchal]

> > > 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.
>
> I don't see how that's not possible with tests being in
> dist-git.

What I've heard from devels is that they often don't feel like
giving direct commit access to the rpms dist git to QE as spec
files and packaging in general is a big responsiblity. But they
are quite OK with directly collaborating with QE on test coverage.

> If the tests are defined in dist-git and adding new tests means
> committing these changes to dist-git's yaml file, how does that
> solve the concern about "noise" in the git commits?

Not necessarily. You could use advanced metadata to select desired
tests only once. The very first proof of concept of using Flexible
Metadata Format for testing selinux quite nicely illustrates this:

https://src.fedoraproject.org/tests/selinux/pull-request/1
https://github.com/psss/fmf

Instead of listing individual tests you could say: Run all tests
for this selinux component + all Tier1 selinux integration tests:

fmf --key test --filter 'component:libselinux | tags:Tier1'

For tests covering multiple components the benefit of the tests
namespace approach is unquestionable. However, I see benefit of
the approach for single components as well (and developers seem
to often feel the same): That is not having to cherry-pick/merge
test coverage between supported branches. So even for these cases
there is the benefit of sharing the test code.

I believe that extending the integration testing coverage is one
the most essential goals of Fedora CI. This is the crucial piece
of the puzzle how to make an Always Ready Operating System: It is
to ensure that packages play nicely together. So I guess there
will be quite many tests which will benefit from this approach.

Do we really want/need to assess every new request for a tests
repo if it is good-enough for the test namespace? Will there be
a committee to decide whether a particular set of tests has a
potential to be used by other components in the future or not? :)

To sum up what I've heard so far from the developer side:

* I would like to enable tests for my component (yes, I want)
* I will take care of them (really, I see the benefit in CI)
* I want to easily collaborate on tests with qe (direct commits)
* I don't want to give qe commit access to the rpms dist git
* I want to efficiently maintain tests long-term
* I want to have just a single place for my tests (no duplication)
* I want to keep rpms dist git clean (just metadata & patches)
* I want to easily enable testing for all supported branches
* I don't want to backport new tests to old branches (enable once)
* I want to run all available relevant tests (not to list them)
* I want to execute set of tests based on a tag (e.g. Tier1)
* I want an easy way to clone tests (fedpkg clone tests/pkg)

I believe the tests namespace resolves them all.

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

[Bug 1546068] Upgrade perl-Net-OpenSSH to 0.77

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-OpenSSH-0.77-1.fc2
   ||9
   ||perl-Net-OpenSSH-0.77-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2018-03-01 08:32:03



-- 
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 1550538] perl-String-ToIdentifier-EN-0.12 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-String-ToIdentifier-EN
   ||-0.12-1.fc29
   ||perl-String-ToIdentifier-EN
   ||-0.12-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-03-01 08:11:07



-- 
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 1550538] New: perl-String-ToIdentifier-EN-0.12 is available

[bugzilla]

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

Bug ID: 1550538
   Summary: perl-String-ToIdentifier-EN-0.12 is available
   Product: Fedora
   Version: rawhide
 Component: perl-String-ToIdentifier-EN
  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: 0.12
Current version/release in rawhide: 0.11-9.fc28
URL: http://search.cpan.org/dist/String-ToIdentifier-EN/

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

-- 
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] perl-Mojolicious-7.69 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com
   Fixed In Version|perl-Mojolicious-7.69-1.fc2 |perl-Mojolicious-7.69-1.fc2
   |8   |8
   ||perl-Mojolicious-7.69-1.fc2
   ||9



-- 
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 1550533] New: perl-Mojolicious-7.70 is available

[bugzilla]

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

Bug ID: 1550533
   Summary: perl-Mojolicious-7.70 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.70
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 1347302] Please build perl-Crypt-SMIME for EPEL 7

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

  Flags|needinfo?(steve.traylen@cer |
   |n.ch)   |



-- 
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 1331520] Please update perl-Crypt-SMIME to at least 0.15 in EPEL 6

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

  Flags|needinfo?(steve.traylen@cer |
   |n.ch)   |



-- 
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 1550531] New: perl-DBD-ODBC-1.57 is available

[bugzilla]

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

Bug ID: 1550531
   Summary: perl-DBD-ODBC-1.57 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBD-ODBC
  Keywords: FutureFeature, Triaged
  Assignee: holca...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: holca...@gmail.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.57
Current version/release in rawhide: 1.56-6.fc28
URL: http://search.cpan.org/dist/DBD-ODBC/

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

-- 
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: /usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a

[Florian Weimer]

glibc-2.27.9000-7.fc29 will hopefully fix this.  It will take some time 
to build, so if anyone wants to untag -6 in the meantime, please do so.


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

[Bug 1550526] New: Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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

Bug ID: 1550526
   Summary: Upgrade perl-Image-ExifTool to 10.80
   Product: Fedora
   Version: rawhide
 Component: perl-Image-ExifTool
  Assignee: tcall...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest Fedora delivers 10.55 version. Upstream released 10.80. When you have
free time, please upgrade it

-- 
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: /usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a

[Florian Weimer]

On 03/01/2018 12:29 PM, Paul Howarth wrote:

Hi,

Just got a koschei report about perl-perl5i failing to build:
https://apps.fedoraproject.org/koschei/package/perl-perl5i?collection=f29

It seems the linker can't find /usr/lib64/libpthread_nonshared.a:

+ perl Build.PL --installdirs=vendor '--optimize=-O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables 
-fstack-clash-protection'
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'perl5i' version 'v2.13.2'
+ ./Build
Building perl5i
/usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a
collect2: error: ld returned 1 exit status

glibc problem? There seems to have been a related commit there 3 hours ago.


I see.  I will fix it.  Sorry about that.

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

[Bug 1550520] New: Upgrade perl-Crypt-SMIME to 0.25

[bugzilla]

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

Bug ID: 1550520
   Summary: Upgrade perl-Crypt-SMIME to 0.25
   Product: Fedora
   Version: rawhide
 Component: perl-Crypt-SMIME
  Assignee: steve.tray...@cern.ch
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org,
steve.tray...@cern.ch, xav...@bachelot.org



Latest Fedora delivers 0.23 version. Upstream released 0.25. When you have free
time, please upgrade it

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

[Bug 1550518] New: perl-CGI-Application-4.60 is available

[bugzilla]

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

Bug ID: 1550518
   Summary: perl-CGI-Application-4.60 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CGI-Application
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 4.60
Current version/release in rawhide: 4.50-19.fc28
URL: http://search.cpan.org/dist/CGI-Application/

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

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

/usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a

[Paul Howarth]

Hi,

Just got a koschei report about perl-perl5i failing to build:
https://apps.fedoraproject.org/koschei/package/perl-perl5i?collection=f29

It seems the linker can't find /usr/lib64/libpthread_nonshared.a:

+ perl Build.PL --installdirs=vendor '--optimize=-O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables 
-fstack-clash-protection'
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'perl5i' version 'v2.13.2'
+ ./Build
Building perl5i
/usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a
collect2: error: ld returned 1 exit status

glibc problem? There seems to have been a related commit there 3 hours ago.

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

Re: News in net-snmp package

[Tomasz Kłoczko]

On 27 February 2018 at 18:04, Adam Williamson
 wrote:
[..]
> Do you just mean the python2-net-snmp package will go away and anything
> using it has to migrate to python3-net-snmp? If so, have you actually
> looked at the things that use it and considered how difficult it will
> be to migrate them?
>
> I see, for instance, '389-ds-base-owner' CCed on this mail; if 389-ds-
> base depends on python2-net-snmp it is not at all going to be
> acceptable to just throw it away without regards to whether 389-ds-base
> can reasonably migrate to python3 right now. That is a core component
> of one of our release-blocking deliverables, Fedora Server.

FYI "dnf -qC repoquery --whatrequires python2-net-snmp" command does not
show even single package which requires python2-net-snmp (in current
rawhide repo).
If 389-ds-base really is using net-snmp python2 module it means that
something is wrong with 389-ds-base dependencies.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Matthew Miller]

On Wed, Feb 28, 2018 at 01:29:38PM -0500, Simo Sorce wrote:
> > I used to agree with this, but I've come around to thinking that spec
> > files should be smaller, less complicated, and more automatable. I
> > think we'd be better having a post-build test warning that this package
> > has files missing from the previous build. That could be advisory, or
> > it could even gate, with the packager clearing the gate by updating the
> > file list in the test, rather than in the spec file.
> If you still have to keep a list, why is it better to keep it in tests

Separation of concerns. But also, you shouldn't have to keep a list per
se, just annotations of when it's okay that the list has changed.

-- 
Matthew Miller

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Matthew Miller]

On Wed, Feb 28, 2018 at 06:38:36PM +, Daniel P. Berrangé wrote:
> The further down the workflow a problem is detected the more time expensive
> / disruptive it is to fix it. So while having post-build tests to validate
> lots of things is great (and I wish we had more of it in Fedora), I see it
> as complementary to anything that we can do to detect problems earlier. I
> rather see failures right away when I test the new RPM build locally, than
> waiting to push it through koji and wait again for post-build tests to find
> the problem, as by that time I've context switched my mind away to a
> different bit of work.

Oh, I agree, but I think this is optimizing at the wrong end. Instead
of failing when you build, the new-upstream tracker should update your
RPM and do a test build as soon as new upstream is detected, so your
first interaction should be "Hey, there's a new version of this, and
when we tried to build it, there's files missing from the previous
version... can you take a look?"

-- 
Matthew Miller

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

Re: Exclude paths for elfdeps dependency generator

[Till Hofmann]

On 02/20/2018 05:33 PM, Till Hofmann wrote:
> Hi all,
> 
> I have a question regarding the the RPM dependency generator scripts.
> I'm working on packaging the ROS stack [1,2] and I'm currently dealing
> with the dependency generation. My goal is to wrap all Provides and
> Requires for sonames because ROS does not use proper sonames (and
> therefore they shouldn't be in the ld cache), but I still want to use
> the information for ROS packages. This means I want to replace:
> 
> Provides: librosconsole.so()(64bit)
> =>
> Provides: ros(librosconsole.so()(64bit))
> [or possibly ros-kinetic(librosconsole.so()(64bit))]
> 
> and similarly for Requires.
> 
> I have a working solution [3] that wraps all ROS Provides and Requires
> and generates other Provides and Requirest just as elfdeps does, but it
> uses an (imho ugly) hack: As I don't want to have the normal Provides
> generated by elfdeps, I have:
> 
> %__ros_path ^/usr/lib.*/ros/.*$
> %__elf_exclude_path %__ros_path
> 
> 
> in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If
> %__elf_exclude_path is set by something else, it is overridden, because
> I couldn't figure out how to append to the exclude path. Second,
> %__elf_exclude_path should not be set at all in ros.attr, the doc [4] says:
> "NAME needs to be replaced by the name choosen for the file attribute
> and needs to be the same as the file name of the macro file itself"
> 
> It still works, but shouldn't according to the documentation.
> 
> So my question: Is there any other way to exclude the ROS dir to be
> checked by elfdeps? I cannot just use %__requires_exclude_from because I
> want my dependency generator to run on the directory.


Bump.
This is the current content of the ros.attr file, if it helps:

%__ros_provides %{_rpmconfigdir}/ros.prov
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__ros_requires %{_rpmconfigdir}/ros.req
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__ros_path ^/usr/lib.*/ros/.*$
%__ros_magic ^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$
%__ros_flags exeonly,magic_and_path
%__elf_exclude_path %__ros_path

Is the last line acceptable? If not, how else can I exclude the ROS
directory (%__ros_path) from being scanned by the ELF dependency generator?

Thanks,
Till

> 
> Thanks for any hints.
> 
> Kind regards,
> Till
> 
> [1] https://pagure.io/ros
> [2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/
> [3] https://pagure.io/ros-rpm-macros
> [4] http://rpm.org/user_doc/dependency_generators.html
> ___
> 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: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Jiri Kucera]

fixed in sox, passwd, and usermode
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

qarte - compilation fails

[Martin Gansser]

Hi,

when compiling qarte-4.4.0 with this spec file
https://martinkg.fedorapeople.org/Packages/test/qarte.spec

 '[' noarch = noarch ']'
+ case "${QA_CHECK_RPATHS:-}" in
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
Compiling 
/home/martin/rpmbuild/BUILDROOT/qarte-4.0.0-1.fc27.x86_64/usr/share/qarte/arteconcert.py
 ...
  File "/usr/share/qarte/arteconcert.py", line 385
def update_pitch(self, *args, html=False):
 ^
SyntaxError: invalid syntax

error: Bad exit status from /var/tmp/rpm-tmp.rp9wQD (%install)

only when i comment the following line, the program compiles fine:
#cp -p *.py* %{buildroot}%{_datadir}/%{name}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide: Can't locate ExtUtils/CBuilder.pm

[Paul Howarth]

On Thu, 1 Mar 2018 11:17:18 +0100
Petr Pisar  wrote:

> On Thu, Mar 01, 2018 at 09:38:08AM +0100, Ralf Corsepius wrote:
> > Hi,
> > 
> > perl-Plack fails to build in rawhide with
> > this error[1]
> > 
> > ...
> > + /usr/bin/perl Build.PL --installdirs=vendor
> > Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install
> > the ExtUtils::CBuilder module) (@INC contains:
> > /builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5
> > /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
> > /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
> > /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.
> > ...
> >
> > f26, f27 and f28 build fine.
> > 
> > What is going on here? perl-Plack does not carry any direct
> > dependency on ExtUtils::CBuilder, so my guess would be a dependency
> > is missing somewhere else.
> >   
> 
> is happennning due to GCC removal from F29 build root.
> 
> If you have a package with XS modules and use Module::Build, you need
> to build-require ExtUtils::CBuilder.
> 
> In case of Server-Starter, there seems to be a bug in
> Module::Build::Base. It invokes auto_require() that for some reason
> has $self->c_source set to [], and thus it decides it needs a
> compiler and hence ExtUtils::CBuilder.
> 
> I think this condition in auto_require() should be corrected:
> 
> $self->needs_compiler( keys %$xs_files || defined
> $self->c_source );
> 
> and also the reason why $self->c_source is [] instead of undef should
> be investigated.

That'll be because Server-Starter's Build.PL has

 "c_source => [qw()],"

And that's generated by Minilla, so all non-XS Minilla-based dists are
likely to be affected.

Paul.

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

Re: rawhide: Can't locate ExtUtils/CBuilder.pm

[Petr Pisar]

On Thu, Mar 01, 2018 at 09:38:08AM +0100, Ralf Corsepius wrote:
> Hi,
> 
> perl-Plack fails to build in rawhide with
> this error[1]
> 
> ...
> + /usr/bin/perl Build.PL --installdirs=vendor
> Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install the
> ExtUtils::CBuilder module) (@INC contains:
> /builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5
> /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
> /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.
> ...
>
> f26, f27 and f28 build fine.
> 
> What is going on here? perl-Plack does not carry any direct dependency on
> ExtUtils::CBuilder, so my guess would be a dependency is missing somewhere
> else.
> 

is happennning due to GCC removal from F29 build root.

If you have a package with XS modules and use Module::Build, you need to
build-require ExtUtils::CBuilder.

In case of Server-Starter, there seems to be a bug in Module::Build::Base. It
invokes auto_require() that for some reason has $self->c_source set to [], and
thus it decides it needs a compiler and hence ExtUtils::CBuilder.

I think this condition in auto_require() should be corrected:

$self->needs_compiler( keys %$xs_files || defined $self->c_source );

and also the reason why $self->c_source is [] instead of undef should be
investigated.

-- 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: Frequently broken Rawhide/Branched composes

[Vít Ondruch]

Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
> Fabio Valentini wrote:
>> AFAICT, those "broken deps in rawhide" mails are only sent if there is a
>> compose, and during the past weeks, there have been few of those ... so
>> breakage is sometimes allowed to sit unnoticed (and grow increasingly
>> worse) for very long.
> Isn't that the real issue to fix? Failed Rawhide composes used to be a rare 
> event.

Speaking of that, it seems that the Rawhide compose failed yesterday due
to some KDE/QT soname bump:

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log

Were these announced? Are they handled? Why aren't these done in sidetag?


V.


>  Now we have both Rawhide and Branched composes broken for days at a 
> time, e.g., currently since February 20. This is just not acceptable.
>
> Something needs to be done to make the compose process more robust, e.g.:
> * running createrepo on a stable release, so that we do not have to be able
>   to init a chroot of the target system to compose a repository. A broken
>   dependency, even in systemd or rpm, should NEVER be a reason for the
>   repository to fail to compose.
> * publishing individual deliverables one at a time, i.e.:
>   1. compose the repositories,
>   2. sync the repositories out to the mirrors,
>   3. build the images (atomic ostrees, live images etc.) one at a time,
>   4. sync those images that succeeded out to the mirrors, keep the old
>  versions of the other ones (the matching SRPMs are in Koji anyway, so
>  it does not matter if the SRPMs in the tree don't match)
> etc.
>
> Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide and 
> Branched trees (which miscompiles the Chromium/QtWebEngine build tool GN on 
> x86_64), the fix (8.0.1-0.16) has already been in the right Koji tags for 
> days, but any third-party repository (RPM Fusion, Copr, etc.) will still get 
> the broken GCC. This is not acceptable.
>
> Kevin Kofler
> ___
> 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: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Vít Ondruch]

Dne 28.2.2018 v 18:56 Bruno Wolff III napsal(a):
> On Wed, Feb 28, 2018 at 10:35:11 +0100,
>  Vít Ondruch  wrote:
>>
>> And was the compose successful today or not. Looking at
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
>>
>>
>> it probably was, but it is not obvious from the log.
>
> Depending on why you care, it may be useful to know that in most cases
> when it fails a lot still gets done. Typically you can use the repos
> from failed composes to do updates if you want. This might be easier
> than pulling updates from koji, especially if you can about multiple
> packages.

Actually yes, it would be super useful if I knew where the repos are.

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

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

[Nicolas Mailhot]

Le mercredi 28 février 2018 à 21:11 -0500, Orcan Ogetbil a écrit :
> On 28 February 2018 at 10:03, Nicolas Mailhot wrote:
> > Le 2018-02-28 15:28, Orcan Ogetbil a écrit :
> > > 
> > > On 28 February 2018 at 09:19, Nicolas Mailhot wrote:
> > 
> > 
> > > These are all _very_ edge use-cases.
> > 
> > 
> > Those are *not* edge-cases.
> 
> We have a few thousand build failures. If you cannot find as many (or
> at least in the same magnitude) such use case examples these will stay
> as edge cases.
> 
> Please start counting.

Apart from being a totally unfriendly attitude (I have more packages
that you, so I can piss on your builds) I *do* have more than 570 Go
specs that would be negatively affected by pulling gcc in the buildroot
for no good reason just to avoid fixing the specs that actually need
this.

And I'm just one packager.

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

rawhide: Can't locate ExtUtils/CBuilder.pm

[Ralf Corsepius]

Hi,

perl-Plack fails to build in rawhide with
this error[1]

...
+ /usr/bin/perl Build.PL --installdirs=vendor
Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install the 
ExtUtils::CBuilder module) (@INC contains: 
/builddir/build/BUILD/Server-Starter-0.34/_build/lib 
/usr/local/lib64/perl5 /usr/local/share/perl5 
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl 
/usr/lib64/perl5 /usr/share/perl5 .) at 
/usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.

...

f26, f27 and f28 build fine.

What is going on here? perl-Plack does not carry any direct dependency 
on ExtUtils::CBuilder, so my guess would be a dependency is missing 
somewhere else.



Ralf



[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1052034
https://kojipkgs.fedoraproject.org//work/tasks/4038/25384038/build.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1550049] perl-DBD-SQLite-1.56 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-SQLite-1.56-1.fc29
   ||perl-DBD-SQLite-1.56-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-03-01 03:34:05



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