Re: Kernel development on Fedora

[Sérgio Basto]

Hi,

On Sáb, 2015-09-12 at 18:31 -0400, W. Michael Petullo wrote:
> I am interested in doing some kernel development on Fedora. I am familiar
> with kernel internals, but I am looking for some tips to help manage the
> build, compile, and install cycle. Unfortunately, I am developing against
> the Linux Security Module interface, so my work cannot take the form of
> a kernel module.
> 
> I would like to build RPMs because they are convenient to install,
> and they manage the kernel configuration for me. Put another way, I
> would like for practical reasons to track the Fedora kernel source RPMs
> as opposed to the upstream kernel tree. (This will eventually change,
> but not yet.)  However, building RPMs results in a full build each time,
> slowing down the development cycle.
> 
> I thought that I could speed this up using rpmbuild's --short-circuit.
> My idea was to perform an "rpmbuild -bp" once, apply my own changes to
> the build tree, and then on each compile run "rpmbuild -bc", "-bi", and
> "-bb".  The problem is that the RPM build runs "make mrproper" as part
> of the %build target.
> 
> Does anyone know of a good work flow for developing custom kernel code
> on Fedora in a convenient way? The next best thing I could come up with
> is to recreate much of the kernel RPM's %build target without the "make
> mrproper" and other troublesome parts. But this sort of duplicates things
> that I would rather dynamically track by making use of each kernel RPM.

Google for "fedora custom kernel" 

https://fedoraproject.org/wiki/Building_a_custom_kernel

And here is my own notes:

How to patch and building a kernel for Fedora
http://www.serjux.com/build_kernel/build_kernel.txt


> Thank you,
> 
> -- 
> Mike
> 
> :wq

-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20150912 compose check report

[Fedora compose checker]

Missing expected images:

Kde Live i386
Cloud base Disk i386
Cloud base Disk x86_64
Kde Live x86_64
Cloud atomic Disk x86_64
Kde Disk armhfp

Images in this compose but not Rawhide 20150911:

Workstation Disk armhfp
Workstation Live i386
Design_suite Live i386
Design_suite Live x86_64
Mate Live x86_64
Cinnamon Live i386
Mate Live i386
Cinnamon Live x86_64
Workstation Live x86_64
Mate Disk armhfp

No images in Rawhide 20150911 but not this.

Failed openQA tests: 42 of 46

ID: 2191Test: i386 generic_boot default_install
ID: 2190Test: x86_64 generic_boot default_install
ID: 2189Test: i386 universal server_updates_img_local
ID: 2188Test: i386 universal upgrade_desktop_32bit
ID: 2186Test: i386 universal server_kickstart_hdd
ID: 2185Test: i386 universal server_no_swap
ID: 2184Test: i386 universal server_lvmthin
ID: 2183Test: i386 universal server_ext3
ID: 2182Test: i386 universal server_btrfs
ID: 2181Test: i386 universal server_software_raid
ID: 2180Test: i386 universal server_multi_empty
ID: 2179Test: i386 universal server_simple_free_space
ID: 2178Test: i386 universal server_simple_encrypted
ID: 2177Test: i386 universal server_delete_partial
ID: 2176Test: i386 universal server_repository_http_variation
ID: 2175Test: i386 universal server_repository_http_graphical
ID: 2174Test: i386 universal server_mirrorlist_graphical
ID: 2173Test: i386 universal server_delete_pata
ID: 2172Test: i386 universal server_kickstart_user_creation
ID: 2171Test: i386 universal server_scsi_updates_img
ID: 2170Test: i386 universal server_sata_multi
ID: 2169Test: i386 universal package_set_minimal
ID: 2168Test: x86_64 universal server_shrink_ntfs
ID: 2167Test: x86_64 universal server_shrink_ext4
ID: 2166Test: x86_64 universal server_updates_img_local
ID: 2163Test: x86_64 universal server_kickstart_hdd
ID: 2162Test: x86_64 universal server_no_swap
ID: 2161Test: x86_64 universal server_lvmthin
ID: 2160Test: x86_64 universal server_ext3
ID: 2159Test: x86_64 universal server_btrfs
ID: 2158Test: x86_64 universal server_software_raid
ID: 2157Test: x86_64 universal server_multi_empty
ID: 2156Test: x86_64 universal server_simple_free_space
ID: 2155Test: x86_64 universal server_simple_encrypted
ID: 2154Test: x86_64 universal server_delete_partial
ID: 2153Test: x86_64 universal server_repository_http_variation
ID: 2152Test: x86_64 universal server_repository_http_graphical
ID: 2151Test: x86_64 universal server_mirrorlist_graphical
ID: 2150Test: x86_64 universal server_delete_pata
ID: 2149Test: x86_64 universal server_kickstart_user_creation
ID: 2147Test: x86_64 universal server_sata_multi
ID: 2146Test: x86_64 universal package_set_minimal

Passed openQA tests: 3 of 46
1 openQA tests may be still running or broken!
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1262580] New: perl-Nagios-Plugin-0.990000 is available

[bugzilla]

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

Bug ID: 1262580
   Summary: perl-Nagios-Plugin-0.99 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Nagios-Plugin
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.99
Current version/release in rawhide: 0.37-3.fc23
URL: http://search.cpan.org/dist/Nagios-Plugin/

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1262580] perl-Nagios-Plugin-0.990000 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-yvXKlx/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-yvXKlx/100.0%: No such file or directory

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposal to reduce anti-bundling requirements

[Stephen John Smoogen]

On 12 September 2015 at 08:11, Orion Poplawski  wrote:
> On 09/11/2015 06:11 PM, Stephen John Smoogen wrote:
>>
>> On 11 September 2015 at 16:41, Jóhann B. Guðmundsson 
>> wrote:
>>>
>>>
>>>
>>> On 09/11/2015 09:09 PM, Orion Poplawski wrote:


 What does Fedora users gain with "dnf
 install rails" or "dnf install ipython" versus "gem install rails" and
 "pip
 install ipython"?
>>>
>>>
>>>
>>> This indeed is very good question.
>>>
>>> I'm not sure how things are elsewhere in the world but in the case of
>>> gem's
>>> on a rock in the middle of the north atlantic ocean , everybody is using
>>> bundler with nobody wanting to go back to non existing or not current
>>> gem's
>>> in distributions and or having to manually chase down components and
>>> resolve
>>> their dependency's.
>>>
>>> They prefer spending that time actually hacking or drinking beer or both.
>>>
>>
>> Depending on what the system is being used for the gain in having one
>> package system is usually in "inventory control". RPM allows me to
>> prove that the packages from it are installed and match the checksums
>> (or when they don't if they are config files or not). Every out of
>> band packaging requires me to figure out if that system has a
>> signature tree and how to know if the python-gumdrop is the one I got
>> from the original source or not.
>>
>> While most of this is important at say a bank, military, etc.. I have
>> had to do this in the University system where a machine was broken
>> into and we needed to make sure that other systems were not broken
>> into. The reason being that the experiments would have to be started
>> over from scratch and they would have probably lost their grant. The
>> grad students in the lab would have probably also had major problems
>> with their finalized thesis as it would have added years to getting it
>> final. The chem lab project was ok because we could check that the php
>> on the webserver hadn't been tampered with and the perl on the systems
>> either.
>>
>> I believe that some of the ecosystem packagers have this ability and
>> others do not. I expect that for most people the problems above aren't
>> really a concern.. but then again most of them set their root password
>> to 123456 if they can.
>>
>
> Thanks, that's a good point, and perhaps something to bring up with the
> pip/gem/etc folks.  There are also other tools to checksum an installed
> system so I don't think it's insurmountable to work around.
>

It has been brought up multiple times with each of the groups. It is
usually seen as a bunch of complexity that they do not want to add to
the system at this time. And it is also something that turns out can't
be retrofitted in without major changes in the ecosystem so ends up
never getting added. [There are multiple summaries of this in lwn.net
where various people have tilted this windmill a lot of times.] Some
of the problems are because the archive method used can't have
signatures in it (Zip and tar for a LOOONG time). Some of the issues
is that infrastructure has to be put in place.. and the third problem
is that it isn't a problem that most of the people writing with have
to deal with until it is too late. https://xkcd.com/1539/

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 23 Branched 20150912 compose check report

[Fedora compose checker]

Missing expected images:

Cloud atomic Disk x86_64
Cloud base Disk i386

No images in this compose but not 23 Branched 20150911

No images in 23 Branched 20150911 but not this.
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1230790] Upgrade perl-Proc-ProcessTable to 0.51

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Proc-ProcessTable-0.53-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.\nIf you want to test the update, you can install it with \n su -c 'yum
--enablerepo=updates-testing update perl-Proc-ProcessTable'. You can provide
feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-15592

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Kernel development on Fedora

[W. Michael Petullo]

I am interested in doing some kernel development on Fedora. I am familiar
with kernel internals, but I am looking for some tips to help manage the
build, compile, and install cycle. Unfortunately, I am developing against
the Linux Security Module interface, so my work cannot take the form of
a kernel module.

I would like to build RPMs because they are convenient to install,
and they manage the kernel configuration for me. Put another way, I
would like for practical reasons to track the Fedora kernel source RPMs
as opposed to the upstream kernel tree. (This will eventually change,
but not yet.)  However, building RPMs results in a full build each time,
slowing down the development cycle.

I thought that I could speed this up using rpmbuild's --short-circuit.
My idea was to perform an "rpmbuild -bp" once, apply my own changes to
the build tree, and then on each compile run "rpmbuild -bc", "-bi", and
"-bb".  The problem is that the RPM build runs "make mrproper" as part
of the %build target.

Does anyone know of a good work flow for developing custom kernel code
on Fedora in a convenient way? The next best thing I could come up with
is to recreate much of the kernel RPM's %build target without the "make
mrproper" and other troublesome parts. But this sort of duplicates things
that I would rather dynamically track by making use of each kernel RPM.

Thank you,

-- 
Mike

:wq
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

No autocomplete for new package in bodhi 2.0?

[Dave Johansen]

I just finished the review for cppformat (
https://bugzilla.redhat.com/show_bug.cgi?id=1216279 ) and went to submit
the updates. I noticed that bodhi 2.0 won't autocomplete the names of
updates. I believe that would happen before the update to 2.0.
Is this a known issue? I didn't find it when looking through the list at
https://github.com/fedora-infra/bodhi/issues
Thanks,
Dave
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1262578] perl-Module-CoreList-5.20150912 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-yBqjFU/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-yBqjFU/100.0%: No such file or directory

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1262578] New: perl-Module-CoreList-5.20150912 is available

[bugzilla]

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

Bug ID: 1262578
   Summary: perl-Module-CoreList-5.20150912 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-CoreList
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



Latest upstream release: 5.20150912
Current version/release in rawhide: 5.20150820-1.fc24
URL: http://search.cpan.org/dist/Module-CoreList/

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1262576] New: perl-CPAN-Perl-Releases-2.36 is available

[bugzilla]

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

Bug ID: 1262576
   Summary: perl-CPAN-Perl-Releases-2.36 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
psab...@redhat.com



Latest upstream release: 2.36
Current version/release in rawhide: 2.34-1.fc24
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1261901] perl-Dist-Zilla-Plugin-ReadmeFromPod-0.33 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-ReadmeFromPod-0.33-1.fc23 has been pushed to the Fedora
23 testing repository. If problems still persist, please make note of it in
this bug report.\nIf you want to test the update, you can install it with \n su
-c 'yum --enablerepo=updates-testing update
perl-Dist-Zilla-Plugin-ReadmeFromPod'. You can provide feedback for this update
here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15586

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1262316] perl-Dancer-Session-Cookie-0.26 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.26-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.\nIf you want to test the update, you can install it with \n su -c 'yum
--enablerepo=updates-testing update perl-Dancer-Session-Cookie'. You can
provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-15593

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Sat, 2015-09-12 at 16:26 +0200, Reindl Harald wrote:

> bad idea to start the mess and when it goes wrong point somewhere
> else
> 
> i hear that all the time when something breaks terrible my workflows
> and 
> at the end of the day nobody feels responsible - well, i tell you
> what i 
> do: ignore pip, cpan & co as well as any software which requires me
> to 
> touch it and finally Fedora if it goes that way

I really don't think pip and cpan are the best examples to think about
here. As I said, both python and perl are reasonably well set up to
allow distribution packaging, and as ecosystems they have generally
fairly decent standards of library/package/module/whatever-you-want-to
-call it maintenance. I don't see a lot of examples of projects with no
releases, or layouts completely unsuitable for system-wide
installation, or anything like that.

A much better example is PHP. PHP does not have a reasonable official
class loading system baked into the interpreter which is compatible
with distribution packaging, nope. PHP has a complicated history of
shitty practices and conventions. The basic upshot is that you can't
just take a 'normal' PHP codebase, dump it on a system where all its
dependencies are installed systemwide, and expect it to use them, like
you generally can with a Python or perl codebase. PHP just doesn't have
that infrastructure. Whatever the details, the big picture is that the
codebase will basically be expecting to find and load its bundled
copies, and if they're not there it will throw a fit.

You *can* work around this, but it is almost entirely without exception
not what upstream expects and not what upstream cares about: it
requires messy downstream modifications of one kind or another.

The modern-day 'Standard Way' to build PHP projects against external
dependencies - Composer/Packagist - is *expressly designed* to
implement bundling and disregard system libraries. It has a very crappy
and inadequate, disabled-by-default option to load system copies of
libraries that follow one specific layout, but many many libraries do
not, and unbundling those is *always* a downstream-only change that
upstream does not care about helping.

There's been a kind of self-reinforcing spiral of shittiness around
this stuff in PHP for years. Here's the very short summary:

* PHP doesn't have a clear infrastructure/set of conventions for
loading modules and classes, so...
* People just throw them in their source trees and load them ad hoc,
so...
* Module developers don't give a crap about sensible versioning and
stable APIs (because projects just bundle their dependencies anyway),
so...
* The ecosystem rapidly becomes a mess of projects using incompatible
variants on the same modules, so everyone involved in it comes to
believe that it's futile/impossible to share modules in any case, so...
* They build a big machine for bundling dependencies and call it
Composer, and that's where we are now.

If your experience in this stuff is limited to actual shared objects
and perl and python modules, you are *only* seeing the *best possible*
story for distribution packaging. Other ecosystems are far, far worse. 
PHP is the one I'm most familiar with, but I'm given to understand
others are very similar. Javascript, for instance, is the same mess as
PHP only probably even worse.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Sat, 2015-09-12 at 16:41 +0200, Reindl Harald wrote:

> impossible in case of many complex setups

This is effectively a tautology: "you can't do that with my setup
because my setup can't do that".
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> > Similarly, if I'm developing some piece of software that embeds/uses
> > PostgreSQL, I'm likely targeting multiple distributions, potentially
> > including Fedora, CentOS, RHEL, Ubuntu, and more. Even if Postgres
> > is a core
> > well maintained part of Fedora, I'm not going to care about that
> > version.
> > I'm going to pick a constant version and pull it from something like
> > software collections (or, you know, upstream postgresql.org.)
> 
> Things like pgsql, for me, are the ones that make this discussion
> complex, because they can clearly go either way. There are certainly,
> I think, also cases where you *want* a distro package for it.

Yes, I can certainly see where you'd have a Postgres package for Fedora
end users, but not have it as part of the platform that third-party
packages are expected to use, for example.

> > To allow or not allow bundling is the small side point here - the
> > questions
> > should be more of "Are we a distribution of packages?  Are we an OS?
> >   Where
> > do we see the distribution/OS fit in how software is consumed and
> > provided?
> > Is that different for a Workstation vs an Atomic host?" Answer those
> > big
> > questions, and the questions on what to do along Ring0->RingN, what
> > bundling
> > to allow, etc. should fall out.
> 
> Absolutely this. Can you please stand for election to something again?
> :)

Heh. While I appreciate the sentiment, as Josh says, it's not about standing
for office, it's about having time to acutally do the consensus building,
the proposals, & the work, and that is time I don't have at the moment.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 13.09.2015 um 01:47 schrieb Adam Williamson:

On Sat, 2015-09-12 at 16:41 +0200, Reindl Harald wrote:


impossible in case of many complex setups


This is effectively a tautology: "you can't do that with my setup
because my setup can't do that"


what about a sensible quoting?
the topic was reinstall from scratch

in case you have dozens of servers with customized configs, a ton of 
data and dependencies between the machines because you offer anything 
from domain-registar over webservers, mail/spamfiltering, dns, 
vpn-instances between networks and webservices all driven by housemade 
admin backends and hundrets of cms-systems deployed with own software 
you don't want to install anything from scratch every now and then for 
obvious reasons


if you just deal with a few 08/15 things that may work

frankly only the mess dealing with certificates used between servers, on 
clients and ssh known_hosts everywhere would drive you crazy


and since there was no reason to do so the last 20 fedora releases 
anything which would change that can only be called harmful


and no - hardware changes are no topic on a fully virtualized 
infrastructure where you happily move instances from old to new online




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No autocomplete for new package in bodhi 2.0?

[Haïkel]

There's autocompletion on package name, but looks like bodhi
autocompletion database was not refreshed.


H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Rawhide 20150911 compose check report

[Richard W.M. Jones]

On Fri, Sep 11, 2015 at 11:32:01AM -0700, Adam Williamson wrote:
> There seems to a be 32-bit kernel issue which
> causes the 32-bit images to crash during boot

Check it's not this one:

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

although that _should_ be fixed with any Rawhide kernel built
after 2015-09-04.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the rawhide tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-AutoBuild

[buildsys]

perl-Test-AutoBuild has broken dependencies in the F-23 tree:
On x86_64:
perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the F-23 tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the F-23 tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the F-23 tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the F-23 tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the rawhide tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the rawhide tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-AutoBuild

[buildsys]

perl-Test-AutoBuild has broken dependencies in the rawhide tree:
On x86_64:
perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fedora Rawhide 20150911 compose check report

[Adam Williamson]

On Sat, 2015-09-12 at 09:36 +0100, Richard W.M. Jones wrote:
> On Fri, Sep 11, 2015 at 11:32:01AM -0700, Adam Williamson wrote:
> > There seems to a be 32-bit kernel issue which
> > causes the 32-bit images to crash during boot
> 
> Check it's not this one:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1258223
> 
> although that _should_ be fixed with any Rawhide kernel built
> after 2015-09-04.

No, in fact it's exactly the opposite (it *appears* on 09-04). It
seems to be basically that a bug we previously knew about wasn't fixed
in 4.3 because the code was changed somewhat.
https://bugzilla.redhat.com/show_bug.cgi?id=1247382
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Orion Poplawski]

On 09/11/2015 08:51 PM, Reindl Harald wrote:


Am 11.09.2015 um 23:09 schrieb Orion Poplawski:

What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and
"pip
install ipython"?


a clean and maintainable installation over years instead a mess breaking
sooner or later


I'm sorry, but this seems like a bit of a knee jerk reaction.  Are pip 
and gem that bad?  Certainly maybe just some bugs to fix?


I am aware of the critical bug with pip currently on Fedora in that it 
installs in the system python directories directly overwriting rpm 
packages.  But hopefully we can get that fixed.  Although the fact that 
this bug has been open for 5 years does not give me much hope:


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

Although at least it looks like everyone (at least on the Fedora side) 
is in favor, just no one to drive the work.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Orion Poplawski]

On 09/11/2015 06:11 PM, Stephen John Smoogen wrote:

On 11 September 2015 at 16:41, Jóhann B. Guðmundsson  wrote:



On 09/11/2015 09:09 PM, Orion Poplawski wrote:


What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and
"pip
install ipython"?



This indeed is very good question.

I'm not sure how things are elsewhere in the world but in the case of gem's
on a rock in the middle of the north atlantic ocean , everybody is using
bundler with nobody wanting to go back to non existing or not current gem's
in distributions and or having to manually chase down components and resolve
their dependency's.

They prefer spending that time actually hacking or drinking beer or both.



Depending on what the system is being used for the gain in having one
package system is usually in "inventory control". RPM allows me to
prove that the packages from it are installed and match the checksums
(or when they don't if they are config files or not). Every out of
band packaging requires me to figure out if that system has a
signature tree and how to know if the python-gumdrop is the one I got
from the original source or not.

While most of this is important at say a bank, military, etc.. I have
had to do this in the University system where a machine was broken
into and we needed to make sure that other systems were not broken
into. The reason being that the experiments would have to be started
over from scratch and they would have probably lost their grant. The
grad students in the lab would have probably also had major problems
with their finalized thesis as it would have added years to getting it
final. The chem lab project was ok because we could check that the php
on the webserver hadn't been tampered with and the perl on the systems
either.

I believe that some of the ecosystem packagers have this ability and
others do not. I expect that for most people the problems above aren't
really a concern.. but then again most of them set their root password
to 123456 if they can.



Thanks, that's a good point, and perhaps something to bring up with the 
pip/gem/etc folks.  There are also other tools to checksum an installed 
system so I don't think it's insurmountable to work around.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 12.09.2015 um 16:09 schrieb Orion Poplawski:

On 09/11/2015 08:51 PM, Reindl Harald wrote:


Am 11.09.2015 um 23:09 schrieb Orion Poplawski:

What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and
"pip
install ipython"?


a clean and maintainable installation over years instead a mess breaking
sooner or later


I'm sorry, but this seems like a bit of a knee jerk reaction.  Are pip
and gem that bad?  Certainly maybe just some bugs to fix?


you even refuse trying to understand what i talk about

it's not a matter if they are that bad from a sysadmin perspective, you 
lose the central management and can no longer guarantee that you have 
repeatable installations when you do exactly the same 3 days later on a 
production machine which was tested - you may get newer versions


when i type "distribute-updates.sh" or "distribute-install.sh 
meta-package" i can be 100% sure in which state the destination ends



I am aware of the critical bug with pip currently on Fedora in that it
installs in the system python directories directly overwriting rpm
packages.  But hopefully we can get that fixed.  Although the fact that
this bug has been open for 5 years does not give me much hope:


that is the worst case of all

but you don't need such a bug when we talk over maintaining machines for 
many years, sooner or later you will have conflicts which happens als 
for rpm sometimes, with every additional package management you increase 
the probability



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

Although at least it looks like everyone (at least on the Fedora side)
is in favor, just no one to drive the work.




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Orion Poplawski]

On 09/11/2015 08:58 PM, Reindl Harald wrote:


Am 12.09.2015 um 04:49 schrieb Adam Williamson:

On Sat, 2015-09-12 at 04:46 +0200, Reindl Harald wrote:


Am 11.09.2015 um 23:54 schrieb Orion Poplawski:

I would argue that we need to be packaging much less than we do.
  Many
languages have developed packaging infrastructures around
themselves and
perhaps it's time to let those become the primary means of
distributing such
software


no, thanks, one time the mess with CPAN installed packages mixed
with
the OS and clean that up was enough while it's way more maintainable
over dist-upgrades to package the missing perl modules to get net-
dri
running for years now

having parallel worlds of software management ends in a mess on
systems
not re-installed every now and then - i maintain 30 productin
machines
installed 2008 and upgraded with yum - that's possible because one
central package management


perl and python are examples of languages whose packaging mechanisms
have been designed with system-wide installation / distribution
packaging broadly kept in mind. For other languages/ecosystems this is
not the case; they are expressly designed around bundling


and even if it works somehow - have fun to replicate a setup on
different machines - with one central package manager just "rpm -q" is
your friend and you can easily build your own meta-packages doing
nothing else than define Requires and stuck them together

that would not be possible in a clean way having to deal with dozens of
different install tools, some of them downloading things directly from
uptream, frankly you can' even be sure you end in the same versions 2
hours later, with RPM packages and repos nothing easier than setup a
internal cache-repo from /var/cache/yum and have on all other machines
in the network *only* that enabled - i am doing that from the very first
moment of setup production machines, the production servers *never*
touched any Fedora or other external repo over 7 years


Oh I certainly won't argue that it's easier for the end user/admin to 
work with one tool.  Although we are getting better tools: ansible, 
puppet, et. al. offer the ability to install and track packages with 
other tools like pip/gem/etc, though I admit to not having tried doing 
that specific thing yet.


But if we're in a situation where we are just killing ourselves 
shoehorning upstream's mess of bundled requirements into rpms and their 
response is just 'well just run "pip install foo" and be done with it', 
I think it's time to just let everyone do that.  Then maybe we can see 
if that is the way to software install nirvana or if admins start 
complaining about not being able to maintain their systems in a rational 
way.  We can then point these latter folks upstream and say this is what 
these folks wanted you to do, talk to them about it.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 12.09.2015 um 16:21 schrieb Orion Poplawski:

Oh I certainly won't argue that it's easier for the end user/admin to
work with one tool.  Although we are getting better tools: ansible,
puppet, et. al. offer the ability to install and track packages with
other tools like pip/gem/etc, though I admit to not having tried doing
that specific thing yet.

But if we're in a situation where we are just killing ourselves
shoehorning upstream's mess of bundled requirements into rpms and their
response is just 'well just run "pip install foo" and be done with it',
I think it's time to just let everyone do that.  Then maybe we can see
if that is the way to software install nirvana or if admins start
complaining about not being able to maintain their systems in a rational
way.  We can then point these latter folks upstream and say this is what
these folks wanted you to do, talk to them about it.


bad idea to start the mess and when it goes wrong point somewhere else

i hear that all the time when something breaks terrible my workflows and 
at the end of the day nobody feels responsible - well, i tell you what i 
do: ignore pip, cpan & co as well as any software which requires me to 
touch it and finally Fedora if it goes that way


just because i migrated anything 7 years ago to Fedora don't mean i am 
married with it if it goes completly offroad.




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Orion Poplawski]

On 09/12/2015 08:19 AM, Reindl Harald wrote:



Am 12.09.2015 um 16:09 schrieb Orion Poplawski:

On 09/11/2015 08:51 PM, Reindl Harald wrote:


Am 11.09.2015 um 23:09 schrieb Orion Poplawski:

What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and
"pip
install ipython"?


a clean and maintainable installation over years instead a mess breaking
sooner or later


I'm sorry, but this seems like a bit of a knee jerk reaction.  Are pip
and gem that bad?  Certainly maybe just some bugs to fix?


you even refuse trying to understand what i talk about


Reindl - can you please stop being to F'ing obnoxious all the F'ing 
time?  Maybe it's a language thing, but I'm really not refusing to do 
anything here.  I really am trying to understand this.



it's not a matter if they are that bad from a sysadmin perspective, you
lose the central management and can no longer guarantee that you have
repeatable installations when you do exactly the same 3 days later on a
production machine which was tested - you may get newer versions


Okay, I grant you the loss of central management thing and that sucks. 
But I'm afraid it may become a fact of life.


As for versions, at least with pip and gem you can request specific 
versions to be installed.  These tools are very much designed for 
repeatable installs with specific version requirements.  That's why so 
many upstreams insist on people using them - because they want you to 
have the same versions they test with.


And heck, with the stream of Fedora updates, you can also get different 
versions using yum/dnf.  Sure, we try not to break things with updates 
unlike upstreams that seem to have lost all concept of trying to 
maintain API/ABI stability.



when i type "distribute-updates.sh" or "distribute-install.sh
meta-package" i can be 100% sure in which state the destination ends


Yeah, it sucks when your workflow breaks, it really does and I feel your 
pain here.  However it seems that much of the focus has shifted from 
maintaining installs over the years to being able to spin up new systems 
to a given spec quickly.  Long ago I shifted away from doing upgrades to 
using kickstart + (cfengine -> puppet -> ansible) to do fresh installs 
of systems to given specifications.  I've found this much more 
maintainable, and even faster.



I am aware of the critical bug with pip currently on Fedora in that it
installs in the system python directories directly overwriting rpm
packages.  But hopefully we can get that fixed.  Although the fact that
this bug has been open for 5 years does not give me much hope:


that is the worst case of all

but you don't need such a bug when we talk over maintaining machines for
many years, sooner or later you will have conflicts which happens als
for rpm sometimes, with every additional package management you increase
the probability


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

Although at least it looks like everyone (at least on the Fedora side)
is in favor, just no one to drive the work.







--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Reindl Harald]

Am 12.09.2015 um 16:36 schrieb Orion Poplawski:

Okay, I grant you the loss of central management thing and that sucks.
But I'm afraid it may become a fact of life.

As for versions, at least with pip and gem you can request specific
versions to be installed.  These tools are very much designed for
repeatable installs with specific version requirements.  That's why so
many upstreams insist on people using them - because they want you to
have the same versions they test with.

And heck, with the stream of Fedora updates, you can also get different
versions using yum/dnf


heck i don't because any production machine only sees the internal repos

why should i waste time and ressources on my side as well as on the 
mirrors having 30 machines downloading their stuff from the internet and 
risk they hit different mirrors with different states?


[root@buildserver:~]$ cat /buildserver/repo-cache.sh
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf "%{version}\n" fedora-release`
for g in `ls -1b /var/cache/yum`
do
 if [ -d /var/cache/yum/$g/packages ]
 then
  echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/"
  sudo mv --verbose /var/cache/yum/$g/packages/*.rpm 
/repo/cache/fc$releasever/ 2> /dev/null

 fi
done
/buildserver/repo-create.sh


when i type "distribute-updates.sh" or "distribute-install.sh
meta-package" i can be 100% sure in which state the destination ends


Yeah, it sucks when your workflow breaks, it really does and I feel your
pain here.  However it seems that much of the focus has shifted from
maintaining installs over the years to being able to spin up new systems
to a given spec quickly.  Long ago I shifted away from doing upgrades to
using kickstart + (cfengine -> puppet -> ansible) to do fresh installs
of systems to given specifications.  I've found this much more
maintainable, and even faster.


impossible in case of many complex setups



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-23 Branched report: 20150912 changes

[Fedora Branched Report]

Compose started at Sat Sep 12 07:15:03 UTC 2015
Broken deps for armhfp
--
[ScientificPython]
ScientificPython-2.8-20.fc22.armv7hl requires libmpi.so.1
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[cego]
cego-2.20.21-3.fc23.armv7hl requires liblfcbase.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.armv7hl requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.armv7hl requires 
libqtaccountsservice-qt5.so.0.1.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0
[licq]
licq-1.8.2-9.fc23.armv7hl requires libboost_regex.so.1.57.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 
0:25.3.3
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[nodejs-grunt-saucelabs]
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(sauce-tunnel) 
>= 0:2.2.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) < 
0:1.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) 
>= 0:1.2.2
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(lodash) >= 
0:3.7.0
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(colors) >= 
0:1.0.0
[nodejs-proxy-agent]
nodejs-proxy-agent-1.1.0-1.fc22.noarch requires npm(socks-proxy-agent) 
< 0:1
[nodejs-socks-proxy-agent]
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
< 0:2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
>= 0:1.1.2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(extend) < 0:2
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires 

[Test-Announce] Fedora 23 Beta Freeze

[Dennis Gilmore]

Hi all,

Tuesday was an important day on the Fedora 23 schedule[1], with two
significant cut-offs. 

Tuesday was the Beta freeze[2]. This means that only packages which
fix accepted blocker or freeze exception bugs[3][4] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Finally, Tuesday was the '100% code complete deadline' Change Checkpoint[8],
meaning that Fedora 23 Changes must now be ' New accepted changes must be code 
complete, meaning all the code required to enable to the new change is 
finished. The level of code completeness is reflected as tracker bug state 
ON_QA. The change does not have to be fully tested by this deadline'.

Regards

Dennis

[1] https://fedoraproject.org/wiki/Releases/23/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[8] https://fedoraproject.org/wiki/Changes/Policy

signature.asc
Description: This is a digitally signed message part.
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1262536] New: perl-Contextual-Return-0.004008 is available

[bugzilla]

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

Bug ID: 1262536
   Summary: perl-Contextual-Return-0.004008 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Contextual-Return
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.004008
Current version/release in rawhide: 0.004007-8.fc23
URL: http://search.cpan.org/dist/Contextual-Return

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20150912 changes

[Fedora Rawhide Report]

Compose started at Sat Sep 12 05:15:03 UTC 2015
Broken deps for i386
--
[FlightGear]
FlightGear-3.7.0-2.gitf4fa687.fc24.i686 requires FlightGear-data >= 
0:3.7.0
[FlightGear-Atlas]
FlightGear-Atlas-0.5.0-0.14.cvs20141002.fc24.i686 requires 
libSimGearCore.so.3.4.0
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
[ScientificPython]
ScientificPython-2.8-20.fc22.i686 requires libmpi.so.1
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aqsis]
aqsis-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_program_options.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_wave.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-hakyll-4.5.4.0-3.fc23.i686 requires 
ghc(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
ghc-hakyll-devel-4.5.4.0-3.fc23.i686 requires 
ghc-devel(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686