Re: Best way to handle sub-package conflicts

[Kevin Kofler]

Digimer wrote:
>   I think "Conflict" is the way to go. However, given how much the guide
> urges not to use 'Conflicts', I worry that will make it
> harder/impossible later to have the package accepted into Fedora.

If your goal is to get the package into Fedora, will those hardcoded 
mutually exclusive roles even still make sense then? To me, this looks very 
much like policy specific to your deployment. Other deployments might want 
to allow a machine to take multiple of the roles you describe.

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

[Bug 1553503] perl-Time-Moment-0.43 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Moment-0.43-1.fc2 |perl-Time-Moment-0.43-1.fc2
   |6   |6
   ||perl-Time-Moment-0.43-1.fc2
   ||7



--- Comment #10 from Fedora Update System  ---
perl-Time-Moment-0.43-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

[Bug 1553503] perl-Time-Moment-0.43 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Time-Moment-0.43-1.fc2
   ||6
 Resolution|--- |ERRATA
Last Closed||2018-03-19 00:10:26



--- Comment #9 from Fedora Update System  ---
perl-Time-Moment-0.43-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

Re: Best way to handle sub-package conflicts

[Richard W.M. Jones]

On Sun, Mar 18, 2018 at 12:44:37PM -0400, Digimer wrote:
> On 2018-03-18 11:48 AM, Nicolas Mailhot wrote:
> > Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit :
> >>
> >> So this isn't a version conflict, as seems to be what Conflicts and
> >> Obsoletes are designed to handle, if I understand properly.
> > 
> > It is a conflict between the packages.
> > 
> > What you can’t do is to allow the installation of one package to replace
> > the others, because for rpm and dnf installations and updates have the
> > same constrains (so if foo-b is allowed to replace foo-a it will do it
> > for updates too)
> > 
> > So you have too solutions:
> > 
> > 1. make the packages conflict, to force users to choose one of them.
> > Installation of each packages will be forbidden while one of the others
> > is present
> > 
> > 2. make sure the packages do not conflict, and can be parallel
> > installed. Handle role conflicts at runtime, making sure whatever is
> > executed in each role refuses to run if one of the others is already
> > running (via lockfile for example)
> 
> Hi,
> 
>   I think "Conflict" is the way to go. However, given how much the guide
> urges not to use 'Conflicts', I worry that will make it
> harder/impossible later to have the package accepted into Fedora.
> 
>   Would a use-case like this be an acceptable exception, would you guess?
> 
>   As I mentioned in my reply to Micheal, I am not worried about
> auto-removal. If it simply refused to install one sub-package until the
> other is gone, that's fine.

Maybe another way to do it is to have a configuration file describing
the "role" of the machine:

  /etc/anvil.conf:
role = striker

The services check this file at start up (or with a systemd
precondition perhaps) and disable themselves if the role does not
match, but they can still be parallel installed.

Has the advantage that the sysadmin has to actively choose to change
the role of a machine, rather than having some random package update
change it accidentally.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28-20180318.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 12/137 (x86_64), 6/23 (i386), 1/2 (arm)

ID: 207002  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/207002
ID: 207030  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/207030
ID: 207038  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/207038
ID: 207039  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207039
ID: 207040  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/207040
ID: 207041  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207041
ID: 207053  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/207053
ID: 207057  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/207057
ID: 207058  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207058
ID: 207059  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/207059
ID: 207072  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/207072
ID: 207106  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/207106
ID: 207109  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/207109
ID: 207119  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207119
ID: 207143  Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/207143
ID: 207145  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/207145
ID: 207153  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/207153
ID: 207154  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/207154
ID: 207214  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/207214

Soft failed openQA tests: 9/137 (x86_64), 2/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 207016  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207016
ID: 207017  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/207017
ID: 207033  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/207033
ID: 207036  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/207036
ID: 207045  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/207045
ID: 207082  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/207082
ID: 207083  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/207083
ID: 207108  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/207108
ID: 207110  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/207110
ID: 207130  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/207130
ID: 207133  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/207133

Passed openQA tests: 100/137 (x86_64), 15/23 (i386)

Skipped openQA tests: 16 of 162
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to do when test gating in bodhi fails (no test results found)?

[Fabio Valentini]

On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth  wrote:
> On 03/18/2018 01:02 PM, Fabio Valentini wrote:
>>
>> I've looked at waiverdb-cli too, but since no tests seem to have run
>> at all, it looks like the wrong tool for the job:
>> I don't want to push an update despite a failed test, I want to push
>> my update despite no test data being available ...
>
>
> Randy said the tests refresh every 6 hours and/or every time the update is
> edited. Neither seemed to have occurred for you.

Exactly. The "no test results found" status in bodhi hasn't been
refreshed in over 10 days now.

Bodhi also displays that all these tests were successful, bit still
blocks the update because "no test results found", which is obviously
just wrong.

A manual lookup in resultdb shows me that the tests have in fact been
run and have all passed:

https://taskotron.fedoraproject.org/resultsdb/results?item:like=*golang-github-xtaci-smux-1.0.7-1.fc27*
https://taskotron.fedoraproject.org/resultsdb/results?item:like=*golang-github-xtaci-smux-1.0.7-1.fc26*

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1105  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 868  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 450  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 347  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 179  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 117  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  66  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f7a629b46f   
python-django16-1.6.11.7-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-635348eab4   
php-simplesamlphp-saml2_1-1.10.6-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7150fa5dce   
php-simplesamlphp-saml2-2.3.8-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-673b3314a1   
exim-4.90.1-3.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f41541339   
monitorix-3.10.1-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae3a1eae7e   
glpi-0.90.5-2.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-add4fc19d8   
mosquitto-1.4.15-1.el7


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

NetworkManager-l2tp-1.2.10-1.el7
homebank-5.1.8-1.el7
verilator-3.922-1.el7

Details about builds:



 NetworkManager-l2tp-1.2.10-1.el7 (FEDORA-EPEL-2018-7cbec7dacb)
 NetworkManager VPN plugin for L2TP and L2TP/IPsec

Update Information:

Updated to 1.2.10 release




 homebank-5.1.8-1.el7 (FEDORA-EPEL-2018-c76ec7650b)
 Free easy personal accounting for all

Update Information:

- New upstream version 5.1.8, fixes rhbz #1557699

References:

  [ 1 ] Bug #1557699 - homebank-5.1.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1557699




 verilator-3.922-1.el7 (FEDORA-EPEL-2018-59b7278a29)
 A fast simulator for synthesizable Verilog

Update Information:

update to 3.922, fixes rhbz #1557720

References:

  [ 1 ] Bug #1557720 - verilator-3.922 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1557720

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote:
> On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> > modules are not RPMs.  I would not expect them to necessarily use the
> > same format as RPMs.  If we take koji out of the equation, we have
> > module builds in N:S:V:C format and module RPMs in N-V-R.A format.  They
> > use different separators, but both can be parsed consistently. 
> 
> I don't contest the above, but I am arguing that it is needlessly
> different and causes infrastructure software to need to handle module
> strings differently than they handle RPMs and containers. Perhaps there
> is a benefit that I've not been made aware of yet, but from where I sit
> it seems like a change that causes problems without bringing a tangible
> benefit.
> 
> The reasoning I've heard so far is that this allows stream names to have
> -'s in them - is that important? I don't know it to be, but am open to
> be convinced. Thus my question - is it important enough to have -'s in
> stream names to justify the work needed to make all things that interact
> with Koji parse them using a web service rather than local code (such as
> rsplit('-', 2) in Python)?

So, is anyone knowledgeable who can answer this question?

If nobody can, then mostly likely the answer is "no, it's not important".

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

Re: What to do when test gating in bodhi fails (no test results found)?

[Michael Cronenworth]

On 03/18/2018 01:02 PM, Fabio Valentini wrote:

I've looked at waiverdb-cli too, but since no tests seem to have run
at all, it looks like the wrong tool for the job:
I don't want to push an update despite a failed test, I want to push
my update despite no test data being available ...


Randy said the tests refresh every 6 hours and/or every time the update is edited. 
Neither seemed to have occurred for you.

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

Re: What to do when test gating in bodhi fails (no test results found)?

[Fabio Valentini]

On Sun, Mar 18, 2018 at 6:28 PM, Michael Cronenworth  wrote:
> On 03/18/2018 05:03 AM, Fabio Valentini wrote:
>>
>> I've got two updates sitting in F26 and F27 updates-testing:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2018-c455a245b0
>> 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0e13ff51
>>
>> I can't push either of them to batched or stable (despite them being in
>> -testing for over 10 days now), because "no test results found".
>>
>> Which is really annoying and the error message is ... rather unhelpful,
>> since it just tells me "I can't do this _shrug_", but not how to fix it.
>>
>> I guess this is caused by a bug in one of the involved components?
>> Where can/should I report this issue?
>> How can I fix this (if I can do it myself), or does somebody with more
>> power have to step in to fix this?
>
>
> I've been told[1] to create waivers[2] but I have tried to do that today and
> I still cannot push my update[3].

I've looked at waiverdb-cli too, but since no tests seem to have run
at all, it looks like the wrong tool for the job:
I don't want to push an update despite a failed test, I want to push
my update despite no test data being available ...

> I'd really prefer the test gates be disabled until the tooling is more
> complete. Right now the documentation is very spare and sometimes wrong as
> the tooling is in its early birthing stages and files are moving directories
> and new config options are added/removed.

Or at least make everything opt-in or optional, until the kinks in the
tooling, documentation, and expected workflow are worked out ...

> [1]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X7RTMVPYMLJ7DKPEC3PQC2JGFGDBWFXS/
> [2]
> https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests
> [3] https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
> ___
> 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: What to do when test gating in bodhi fails (no test results found)?

[Michael Cronenworth]

On 03/18/2018 05:03 AM, Fabio Valentini wrote:

I've got two updates sitting in F26 and F27 updates-testing:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-c455a245b0 


https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0e13ff51

I can't push either of them to batched or stable (despite them being in -testing 
for over 10 days now), because "no test results found".


Which is really annoying and the error message is ... rather unhelpful, since it 
just tells me "I can't do this _shrug_", but not how to fix it.


I guess this is caused by a bug in one of the involved components?
Where can/should I report this issue?
How can I fix this (if I can do it myself), or does somebody with more power have 
to step in to fix this?


I've been told[1] to create waivers[2] but I have tried to do that today and I still 
cannot push my update[3].


I'd really prefer the test gates be disabled until the tooling is more complete. 
Right now the documentation is very spare and sometimes wrong as the tooling is in 
its early birthing stages and files are moving directories and new config options 
are added/removed.


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X7RTMVPYMLJ7DKPEC3PQC2JGFGDBWFXS/
[2] 
https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests

[3] https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 compose report: 20180318.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180317.n.0
NEW: Fedora-28-20180318.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   94
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   7.08 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   46.93 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-28-20180318.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-28-20180317.n.0.s390x.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  BEDTools-2.26.0-7.fc28
Old package:  BEDTools-2.26.0-3.fc26
Summary:  A flexible suite of utilities for comparing genomic features
RPMs: BEDTools
Size: 31.94 MiB
Size change:  -21.82 MiB
Changelog:
  * Wed Jul 26 2017 Fedora Release Engineering <rel...@fedoraproject.org> - 
2.26.0-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

  * Wed Aug 02 2017 Fedora Release Engineering <rel...@fedoraproject.org> - 
2.26.0-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild

  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
2.26.0-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 2.26.0-7
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  Canna-3.7p3-53.fc28
Old package:  Canna-3.7p3-52.fc28
Summary:  A Japanese character set input system.
RPMs: Canna Canna-devel Canna-libs
Size: 46.08 MiB
Size change:  -936 B
Changelog:
  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 3.7p3-53
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  MagicPoint-1.13a-21.fc28
Old package:  MagicPoint-1.13a-20.fc28
Summary:  X based presentation software
RPMs: MagicPoint
Size: 4.22 MiB
Size change:  1.73 KiB
Changelog:
  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 1.13a-21
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  adonthell-0.3.6-8.fc28
Old package:  adonthell-0.3.6-7.fc28
Summary:  A 2D graphical RPG game
RPMs: adonthell adonthell-doc
Size: 79.27 MiB
Size change:  236 B
Changelog:
  * Wed Mar 07 2018 Alexandre Moine <nobra...@fedoraproject.org>
  - Add gcc-c++ as a build dependency.

  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 0.3.6-8
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  american-fuzzy-lop-2.52b-3.fc28
Old package:  american-fuzzy-lop-2.52b-2.fc28
Summary:  Practical, instrumentation-driven fuzzer for binary formats
RPMs: american-fuzzy-lop american-fuzzy-lop-clang 
american-fuzzy-lop-clang-fast
Size: 1.69 MiB
Size change:  1.11 KiB
Changelog:
  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 2.52b-3
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  ardour4-4.7.0-11.fc28
Old package:  ardour4-4.7.0-10.fc28
Summary:  Digital Audio Workstation
RPMs: ardour4 ardour4-audiobackend-alsa ardour4-audiobackend-dummy 
ardour4-audiobackend-jack
Size: 56.82 MiB
Size change:  -169.51 KiB
Changelog:
  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 4.7.0-11
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  ardour5-5.12.0-5.fc28
Old package:  ardour5-5.12.0-4.fc28
Summary:  Digital Audio Workstation
RPMs: ardour5 ardour5-audiobackend-alsa ardour5-audiobackend-dummy 
ardour5-audiobackend-jack
Size: 73.44 MiB
Size change:  -166.87 KiB
Changelog:
  * Wed Mar 07 2018 Adam Williamson <awill...@redhat.com> - 5.12.0-5
  - Rebuild to fix GCC 8 mis-compilation
See https://da.gd/YJVwk ("GCC 8 ABI change on x86_64")


Package:  bolt-0.2-1.fc28
Old package:  bolt-0.1-2.fc28
Summary:  Thunderbolt device manager
RPMs: bolt
Size: 664.97 KiB
Size change:  104.85 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
0.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Tue Mar 06 2018 Christian Kellner <ckell...@redhat.com> - 0.2-1
  - bolt 0.2 upstream release
  - Update BuildRequires dependencies.


Package:  bro-2.5.3-2.fc28
Old pac

Re: Best way to handle sub-package conflicts

[Nicolas Mailhot]

I should add, in a properly deployed rpm system, deploying
(downloading/installing), configuring and running are three completely
separate steps that do not imply one another. (deploying and updating
OTOH are quite similar)

It is a very powerful model that renders many complex operations easy to
handle.

However, it is also completely confusing to people that come from
systems with less advanced facilities, that are used to compensate the
management limitations with complex scripted or manual operation that
mix all phases in random order.

Learn to separate the steps in your design, you'll soon find out it
makes a lot of things simpler and rpm/dnf can take care transparently of
many things that used to be manual.

Trying to impose a workflow that is contrary to rpm/dnf basic design
usually ends badly. Not that rpm/dnf is not flexible enough to do it but
it usually works a lot worse than using them as they are intended to be
used (as all the people that try to replicate windows installers scripts
rediscover every year).

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

Re: Best way to handle sub-package conflicts

[Digimer]

On 2018-03-18 11:48 AM, Nicolas Mailhot wrote:
> Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit :
>>
>> So this isn't a version conflict, as seems to be what Conflicts and
>> Obsoletes are designed to handle, if I understand properly.
> 
> It is a conflict between the packages.
> 
> What you can’t do is to allow the installation of one package to replace
> the others, because for rpm and dnf installations and updates have the
> same constrains (so if foo-b is allowed to replace foo-a it will do it
> for updates too)
> 
> So you have too solutions:
> 
> 1. make the packages conflict, to force users to choose one of them.
> Installation of each packages will be forbidden while one of the others
> is present
> 
> 2. make sure the packages do not conflict, and can be parallel
> installed. Handle role conflicts at runtime, making sure whatever is
> executed in each role refuses to run if one of the others is already
> running (via lockfile for example)

Hi,

  I think "Conflict" is the way to go. However, given how much the guide
urges not to use 'Conflicts', I worry that will make it
harder/impossible later to have the package accepted into Fedora.

  Would a use-case like this be an acceptable exception, would you guess?

  As I mentioned in my reply to Micheal, I am not worried about
auto-removal. If it simply refused to install one sub-package until the
other is gone, that's fine.

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Digimer]

On 2018-03-18 11:40 AM, Michael Schwendt wrote:
> On Sun, 18 Mar 2018 11:22:23 -0400, Digimer wrote:
> 
>> So the .spec creates four RPMs; "anvil-core", "anvil-striker",
>> "anvil-node" and "anvil-dr".
>>
>> All machines require "anvil-core", plus one (and only one) of the other
>> three packages. There is no scenario where, for example, 'anvil-node'
>> and 'anvil-striker' would be installed on the same machine. So if a user
>> has 'anvil-striker' RPM installed, and they try to install 'anvil-node',
>> I want that to remove 'anvil-striker'. Similarly, if a machine has
>> 'striker-node' already installed and the user tries to install
>> 'anvil-dr', I want 'anvil-node' removed. This is because a single
>> machine can only play one role at a time.
>>
>> So this isn't a version conflict, as seems to be what Conflicts and
>> Obsoletes are designed to handle, if I understand properly.
> 
> The description of the packaging scenario is not complete yet.
> If -striker, -node and -dr are mutually exclusive, why is that?
> Are there implicit conflicts in the packaged files? Then you cannot
> avoid Conflicts tags. Or are there runtime conflicts? Then you should
> look into a solution that would resolve the conflict with a configuration
> file, which would define the operation mode of the software.
> 
> So far, the scenario sounds very much as if you want to add Conflicts tags
> to the subpackages as to achieve that only one of them can be
> installed. Trying to simulate automatic removal of conflicts through
> Obsoletes tags is not the right thing to do in your scenario. You would
> end up with circular Obsoletes, which would confuse depsolvers or lead
> to random behavior.

The conflict is in the role the machine plays in the larger cluster,
rather than an application-level conflict. So, for example, if the
machine is "striker", it hosts the database and is not allowed to host
servers. If a machine is a "node", it is allowed to be a live migration
target, but must have synchronous storage replication. If a machine is
"dr", it is allowed to host VMs, but it is not allowed to be a live
migration target. These restrictions come from the design of the system,
not from code-level incompatibility.

I'm agreeing that "Conflicts" sounds like the right option, but my
concern came from the guide's strong language against its use.

I'm OK with the package not automatically removing the others, so long
as the sub packages can't be installed at the same time. It is ok to
just error and tell the user to remove the conflict first, then try again.

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20180318.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 19/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 206839  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/206839
ID: 206842  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/206842
ID: 206868  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/206868
ID: 206874  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/206874
ID: 206876  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/206876
ID: 206877  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/206877
ID: 206878  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/206878
ID: 206883  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/206883
ID: 206891  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/206891
ID: 206895  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/206895
ID: 206896  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/206896
ID: 206897  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/206897
ID: 206917  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/206917
ID: 206936  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/206936
ID: 206937  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/206937
ID: 206938  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/206938
ID: 206944  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/206944
ID: 206948  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/206948
ID: 206949  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/206949
ID: 206950  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/206950
ID: 206957  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/206957
ID: 206971  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/206971
ID: 206983  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/206983
ID: 206991  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/206991
ID: 206992  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/206992

Soft failed openQA tests: 7/137 (x86_64), 4/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 206854  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/206854
ID: 206855  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/206855
ID: 206860  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/206860
ID: 206861  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/206861
ID: 206871  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/206871
ID: 206875  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/206875
ID: 206879  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/206879
ID: 206920  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/206920
ID: 206947  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/206947
ID: 206975  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/206975
ID: 206990  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/206990

Passed openQA tests: 101/137 (x86_64), 14/23 (i386)

Skipped openQA tests: 8 of 162
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Nicolas Mailhot]

Le dimanche 18 mars 2018 à 11:22 -0400, Digimer a écrit :
> 
> So this isn't a version conflict, as seems to be what Conflicts and
> Obsoletes are designed to handle, if I understand properly.

It is a conflict between the packages.

What you can’t do is to allow the installation of one package to replace
the others, because for rpm and dnf installations and updates have the
same constrains (so if foo-b is allowed to replace foo-a it will do it
for updates too)

So you have too solutions:

1. make the packages conflict, to force users to choose one of them.
Installation of each packages will be forbidden while one of the others
is present

2. make sure the packages do not conflict, and can be parallel
installed. Handle role conflicts at runtime, making sure whatever is
executed in each role refuses to run if one of the others is already
running (via lockfile for example)

Regards, 

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

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 11:22:23 -0400, Digimer wrote:

> So the .spec creates four RPMs; "anvil-core", "anvil-striker",
> "anvil-node" and "anvil-dr".
> 
> All machines require "anvil-core", plus one (and only one) of the other
> three packages. There is no scenario where, for example, 'anvil-node'
> and 'anvil-striker' would be installed on the same machine. So if a user
> has 'anvil-striker' RPM installed, and they try to install 'anvil-node',
> I want that to remove 'anvil-striker'. Similarly, if a machine has
> 'striker-node' already installed and the user tries to install
> 'anvil-dr', I want 'anvil-node' removed. This is because a single
> machine can only play one role at a time.
> 
> So this isn't a version conflict, as seems to be what Conflicts and
> Obsoletes are designed to handle, if I understand properly.

The description of the packaging scenario is not complete yet.
If -striker, -node and -dr are mutually exclusive, why is that?
Are there implicit conflicts in the packaged files? Then you cannot
avoid Conflicts tags. Or are there runtime conflicts? Then you should
look into a solution that would resolve the conflict with a configuration
file, which would define the operation mode of the software.

So far, the scenario sounds very much as if you want to add Conflicts tags
to the subpackages as to achieve that only one of them can be
installed. Trying to simulate automatic removal of conflicts through
Obsoletes tags is not the right thing to do in your scenario. You would
end up with circular Obsoletes, which would confuse depsolvers or lead
to random behavior.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Digimer]

On 2018-03-18 11:12 AM, Michael Schwendt wrote:
> On Sun, 18 Mar 2018 10:22:49 -0400, Digimer wrote:
> 
>> Hi all,
>>
>>   I am creating a new RPM package for a cluster project we've created.
>> There is a common "core" package, and then three other packages that are
>> installed depending on the machine's role in the cluster;
>>
>> foo-core
>> foo-A
>> foo-B
>> foo-C
>>
>>   If 'foo-A' is installed, I want 'foo-B' and 'foo-C' to be removed, and
>> 'foo-B' replaces 'foo-A' and 'foo-C', etc. I originally planned to use
>> 'Conflicts: ' in our spec, but reading this:
>>
>> https://fedoraproject.org/wiki/Packaging:Conflicts
>>
>>   It seems like 'Conflicts' is strongly discouraged. So instead I tried
>> 'Obsoletes', and this seemed to work in that, if 'foo-A' was installed
>> and I tried to install 'foo-B', it would remove 'foo-A'. So I thought I
>> was ok, until I bumped the version and tried to to an update. With
>> 'foo-A' installed, it wanted to install 'foo-B' and 'foo-C' and failed,
>> which makes sense now that I think of it.
>>
>>   What is the best way to handle this in the .spec file? I'm having
>> trouble finding the right term to search form.
> 
> Could you proof-read your mail and correct the update scenario?
> First you wanted foo-A to replace foo-B and foo-C. Next you write that
> foo-B replaces foo-A and foo-C. Something's wrong in your description.
> Under normal circumstances, a subpackage would never replace a
> package with a different %name.
> 
> Better split your packaging scenario in two clear parts:
> 1) The packages that have been published before and which you start with.
> Describe them and their inter-package dependencies.
> 2) The set of packages you want to continue with after a major upgrade
> that replaces/removes packages. Describe them and their inter-package
> dependencies.
> 
> Obsoletes tags usually are versioned, so they only remove older packages
> up to a maximum version. That way you can reintroduce packages in the future.
> If you keep building subpackages you've obsoleted before, they remain
> available to be installed, and you would need to increase the version in
> your Obsoletes tags to cover them. Nevertheless, subpackages with
> different names would never replace eachother. Unless you've added
> Obsoletes tags to do that.

I'm sorry if I wasn't clear, perhaps I needed more coffee.

Let me use specifics; Our cluster has hardware that play one of three
roles; "Striker" (user dashboard and database host), "nodes" which hosts
virtual servers that can live-migrate between nodes, and "dr" hosts
which are used for disaster recovery in case the main cluster is destroyed.

So the .spec creates four RPMs; "anvil-core", "anvil-striker",
"anvil-node" and "anvil-dr".

All machines require "anvil-core", plus one (and only one) of the other
three packages. There is no scenario where, for example, 'anvil-node'
and 'anvil-striker' would be installed on the same machine. So if a user
has 'anvil-striker' RPM installed, and they try to install 'anvil-node',
I want that to remove 'anvil-striker'. Similarly, if a machine has
'striker-node' already installed and the user tries to install
'anvil-dr', I want 'anvil-node' removed. This is because a single
machine can only play one role at a time.

So this isn't a version conflict, as seems to be what Conflicts and
Obsoletes are designed to handle, if I understand properly.

I hope I made more sense this time. :)

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 10:22:49 -0400, Digimer wrote:

> Hi all,
> 
>   I am creating a new RPM package for a cluster project we've created.
> There is a common "core" package, and then three other packages that are
> installed depending on the machine's role in the cluster;
> 
> foo-core
> foo-A
> foo-B
> foo-C
> 
>   If 'foo-A' is installed, I want 'foo-B' and 'foo-C' to be removed, and
> 'foo-B' replaces 'foo-A' and 'foo-C', etc. I originally planned to use
> 'Conflicts: ' in our spec, but reading this:
> 
> https://fedoraproject.org/wiki/Packaging:Conflicts
> 
>   It seems like 'Conflicts' is strongly discouraged. So instead I tried
> 'Obsoletes', and this seemed to work in that, if 'foo-A' was installed
> and I tried to install 'foo-B', it would remove 'foo-A'. So I thought I
> was ok, until I bumped the version and tried to to an update. With
> 'foo-A' installed, it wanted to install 'foo-B' and 'foo-C' and failed,
> which makes sense now that I think of it.
> 
>   What is the best way to handle this in the .spec file? I'm having
> trouble finding the right term to search form.

Could you proof-read your mail and correct the update scenario?
First you wanted foo-A to replace foo-B and foo-C. Next you write that
foo-B replaces foo-A and foo-C. Something's wrong in your description.
Under normal circumstances, a subpackage would never replace a
package with a different %name.

Better split your packaging scenario in two clear parts:
1) The packages that have been published before and which you start with.
Describe them and their inter-package dependencies.
2) The set of packages you want to continue with after a major upgrade
that replaces/removes packages. Describe them and their inter-package
dependencies.

Obsoletes tags usually are versioned, so they only remove older packages
up to a maximum version. That way you can reintroduce packages in the future.
If you keep building subpackages you've obsoleted before, they remain
available to be installed, and you would need to increase the version in
your Obsoletes tags to cover them. Nevertheless, subpackages with
different names would never replace eachother. Unless you've added
Obsoletes tags to do that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora rawhide compose report: 20180318.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180317.n.0
NEW: Fedora-Rawhide-20180318.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  5
Dropped packages:4
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  6.60 MiB
Size of dropped packages:263.69 KiB
Size of upgraded packages:   920.14 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   4.21 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: 90-Second-Portraits-1.01b-2.fc29
Summary: Frantic street painting game
RPMs:90-Second-Portraits
Size:5.04 MiB

Package: golang-github-nsf-termbox-0-0.3.20180317gite2050e4.fc29
Summary: A minimalistic API which allows programmers to write text-based user 
interfaces
RPMs:golang-github-nsf-termbox-devel
Size:23.94 KiB

Package: golang-github-unknwon-goconfig-0-0.3.20180317gitef1e4c7.fc29
Summary: Configuration file parser for the Go Programming Language
RPMs:golang-github-unknwon-goconfig-devel
Size:23.70 KiB

Package: golang-github-vividcortex-ewma-1.1.1-4.fc29
Summary: Exponentially Weighted Moving Average algorithms for Go
RPMs:golang-github-vividcortex-ewma-devel
Size:14.45 KiB

Package: kiwi-9.13.7-2.fc29
Summary: Flexible operating system image builder
RPMs:dracut-kiwi-lib dracut-kiwi-live dracut-kiwi-oem-dump 
dracut-kiwi-oem-repart dracut-kiwi-overlay kiwi-cli kiwi-pxeboot 
kiwi-systemdeps kiwi-tools python2-kiwi python3-kiwi
Size:1.50 MiB


= DROPPED PACKAGES =
Package: golang-github-Unknwon-goconfig-0-0.2.20161121git87a46d9.fc28
Summary: Configuration file parser for the Go Programming Language
RPMs:golang-github-Unknwon-goconfig-devel 
golang-github-Unknwon-goconfig-unit-test-devel
Size:124.95 KiB

Package: golang-github-VividCortex-ewma-1.1.1-3.fc28
Summary: Exponentially Weighted Moving Average algorithms for Go
RPMs:golang-github-VividCortex-ewma-devel 
golang-github-VividCortex-ewma-unit-test-devel
Size:85.47 KiB

Package: golang-github-nsf-termbox-go-0-0.2.20171104gitaa4a75b.fc28
Summary: A minimalistic API which allows programmers to write text-based user 
interfaces
RPMs:golang-github-nsf-termbox-go-devel
Size:37.73 KiB

Package: python-txrequests-0.9.2-9.fc28
Summary: Asynchronous Python HTTP for Humans
RPMs:python2-txrequests
Size:15.54 KiB


= UPGRADED PACKAGES =
Package:  BEDTools-2.27.0-1.fc29
Old package:  BEDTools-2.26.0-7.fc29
Summary:  A flexible suite of utilities for comparing genomic features
RPMs: BEDTools
Size: 32.09 MiB
Size change:  154.56 KiB
Changelog:
  * Wed Mar 14 2018 Iryna Shcherbina <ishch...@redhat.com> - 2.26.0-8
  - Update Python 2 dependency declarations to new packaging standards
(See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)

  * Sat Mar 17 2018 Adam Huffman <bl...@verdurin.com> - 2.27.0-1
  - Update to latest upstream release 2.27.0


Package:  R-lubridate-1.7.3-3.fc29
Old package:  R-lubridate-1.7.3-2.fc29
Summary:  Make dealing with dates a little easier
RPMs: R-lubridate
Size: 5.53 MiB
Size change:  -196.20 KiB
Changelog:
  * Sat Mar 17 2018 Elliott Sales de Andrade <quantum.anal...@gmail.com> - 
1.7.3-3
  - Unbundle cctz.


Package:  appcenter-0.2.9-1.fc29
Old package:  appcenter-0.2.8-2.fc28
Summary:  Software Center for the Pantheon desktop
RPMs: appcenter
Size: 2.42 MiB
Size change:  43.28 KiB
Changelog:
  * Thu Mar 08 2018 Fabio Valentini <decatho...@gmail.com> - 0.2.9-1
  - Update to version 0.2.9.
  - Add patch to fix build with the newer vala and PackageKit on f28+.


Package:  awscli-1.14.58-1.fc29
Old package:  awscli-1.14.55-1.fc29
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.04 MiB
Size change:  -4 B
Changelog:
  * Sat Mar 17 2018 Kevin Fenzi <ke...@scrye.com>  - 1.14.58-1
  - Update to 1.4.58. Fixes bug #1555085


Package:  bitlbee-3.5.1-5.fc29
Old package:  bitlbee-3.5.1-4.fc27
Summary:  IRC to other chat networks gateway
RPMs: bitlbee bitlbee-devel bitlbee-otr
Size: 2.99 MiB
Size change:  22.02 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
3.5.1-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


Package:  bitlbee-facebook-1.1.2-3.fc29
Old package:  bitlbee-facebook-1.1.2-2.fc28
Summary:  Facebook protocol plugin for BitlBee
RPMs: bitlbee-facebook
Size: 491.03 KiB
Size change:  5.09 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.1.2-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


Package:  botan2-2.4.0-8.fc29
Old package:  botan2-2.4.0-7.fc29
Summary:  Crypto and TLS for C++11
RPMs: botan2 botan2-devel botan2-doc p

Best way to handle sub-package conflicts

[Digimer]

Hi all,

  I am creating a new RPM package for a cluster project we've created.
There is a common "core" package, and then three other packages that are
installed depending on the machine's role in the cluster;

foo-core
foo-A
foo-B
foo-C

  If 'foo-A' is installed, I want 'foo-B' and 'foo-C' to be removed, and
'foo-B' replaces 'foo-A' and 'foo-C', etc. I originally planned to use
'Conflicts: ' in our spec, but reading this:

https://fedoraproject.org/wiki/Packaging:Conflicts

  It seems like 'Conflicts' is strongly discouraged. So instead I tried
'Obsoletes', and this seemed to work in that, if 'foo-A' was installed
and I tried to install 'foo-B', it would remove 'foo-A'. So I thought I
was ok, until I bumped the version and tried to to an update. With
'foo-A' installed, it wanted to install 'foo-B' and 'foo-C' and failed,
which makes sense now that I think of it.

  What is the best way to handle this in the .spec file? I'm having
trouble finding the right term to search form.

Thanks!

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1557588] perl-Mojolicious-7.71 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.71-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-03-18 07:31:34



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

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

What to do when test gating in bodhi fails (no test results found)?

[Fabio Valentini]

Hi,

I've got two updates sitting in F26 and F27 updates-testing:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-c455a245b0
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0e13ff51

I can't push either of them to batched or stable (despite them being in
-testing for over 10 days now), because "no test results found".

Which is really annoying and the error message is ... rather unhelpful,
since it just tells me "I can't do this _shrug_", but not how to fix it.

I guess this is caused by a bug in one of the involved components?
Where can/should I report this issue?
How can I fix this (if I can do it myself), or does somebody with more
power have to step in to fix this?

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

Fedora-Atomic 27-20180318.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: QMake equivalent of CMake flag -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}

[Germano Massullo]

2018-03-18 1:38 GMT+01:00 Kevin Kofler :
> Upstream should probably add LIBPATH=$(LIBPATH) to their qmake invocation in
> the makefile so that their makefile variable actually works without
> requiring you to touch the qmake invocation directly. I pointed that out to
> them now.

Thank you. As I just wrote in Github ticket[1], before doing anything,
I will wait for a comment or hopefully a patch from upstream, so I
could avoid fixing and "unfixing" qmake arguments
[1]: 
https://github.com/open-eid/chrome-token-signing/issues/80#issuecomment-373977504
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org