While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it.
I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead.
Here is a github commit with these changes from a testing repo:
And a list of the provided packages and the affected ones
Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages.
The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well).
Associate Software Engineer
Python Maintenance Team, Red Hat
I messed up the change proposal for Boost 1.61 in F25, which means it
isn't on the schedule.
Given the huge amount of work involved in every Boost update, I'm not
going to be too upset if I don't have to do it!
How upset will other people be if F25 ships with Boost 1.60 (same as
in F24)? Then F26 would get an update, possibly skipping 1.61 and going
straight to 1.62 which should be out by then.
Boost 1.61 adds four new libraries: Boost.Compute, Boost.DLL,
Boost.Hana and Boost.Metaparse.
Full 1.61 release notes:
I want to contribute to sssd project. I have builded and installed source code on my VM
These are my queries:
1. I tried to pick up a easyfix bug at https://fedorahosted.org/sssd/query?status=new&status=reopened&keywords=~...
But all bugs are owned by someone or else.
Though in filters I have selected .. Status new or reopened
2. Is there any documentation(Steps) for new comers to start with.
On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys(a)fedoraproject.org wrote:
> vim-syntastic has broken dependencies in the rawhide tree:
> On aarch64:
> vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp
> On aarch64:
> vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core
> On aarch64:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> On armhfp:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on
arch-dependant package, which is not available everywhere.
Hello, I'd like understand how groups of package are now detect ,
specially in 3rd repo packages which can't use comps.xml.
-------- Forwarded Message --------
From: Sérgio Basto <sergio(a)serjux.com>
Subject: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?
Date: Sun, 28 Aug 2016 07:24:58 +0100
On Seg, 2016-08-01 at 09:17 -0600, Dave Johansen wrote:
> On Sun, Jul 31, 2016 at 9:23 PM, Sérgio Basto <sergio(a)serjux.com>
> > Hi,
> > A year ago, I learned that Group tag is obsolete  I remember ask
> > the
> > reason and is something about comps.xml that I don't remember
> > neither
> > find on google , but for projects that still use repoview, Group
> > tag is
> > needed. So the questions are, have we any replacement for repoview
> > ? or
> > another way to show one repo content ? and why the Group tag is
> > obsolete ? can someone remind me why. And how we now the group of
> > one
> > package ? .
> > Thanks.
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1239067#c1
> Here's the FPC ticket about it:
Thanks I was able to find the reason:
RPM in Fedora 18 does not require the presence of the Group tag in the
spec file. If the tag is defined, it will be ignored. The package
groups of the yum application are used on a Fedora 18 system as the
relevant source of information on which group is the package a part
I remembered in one thread of devel mailing list on create hawaii group
and bingo found the link:
So now, how I know the group of the package (via yum or dnf) ? seems to
me many packages will not have group ... and 3rd-part software ?
Also /usr/bin/gnome-software how find the group of the package ?
Well this is not a very important matter , but I'd like try organize
packages in groups , via repoview.
Sérgio M. B.
Sérgio M. B.
OCaml 4.03 has been out for a while.
I'm intending to add it to Fedora Rawhide once a side tag has been
This will require rebuilding every OCaml package, which I normally do
using a script, but probably there will be manual rebuilds necessary
A few issues that may affect people:
(1) There is a new ppc backend upstream, and I intend to switch to this.
For years we have maintained our own out-of-tree ppc64 & ppc64le
backends. I want to switch to the upstream ppc backend (which
supports, in theory, ppc 32 bit, ppc64 and ppc64le). However when I
actually tried this I found it to be rather buggy, it couldn't even
compile many basic OCaml packages. This time I intend to switch, and
we'll deal with the bugs.
(2) There is a new s/390x backend upstream. This should enable us to
compile all s/390x packages as native code.
It also means that all supported architectures (yes, even riscv64)
will support native compilation for OCaml.
(3) The real reason I'm doing this now is because partners have asked
us to update the OCaml compiler in RHEL 7.4. This will be a binary
ABI break -- it's unfortunately unavoidable -- and will require all
OCaml-using programs to be recompiled, and of course that will affect
CentOS and any other RHEL derivatives.
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
I kinda hate kicking off discussions like this without having a solid
solution to propose or being able to promise to work on one, but this
really seems important. Unfortunately I can't claim I'm gonna have time
to do any concrete work on it, though I'd really *like* to. But I
thought it would be worthwhile to kick around still; perhaps someone
else will be inspired.
I just read Hedayat's review of Fedora 25 Beta:
and this really jumped out at me:
"And, if you care about your internet usage, make sure that you disable
both dnf makecache timer, and stop PackageKit from downloading updates
automatically. I don’t allow a new Fedora installation to access
internet before doing these, as it might just eat a considerable amount
There's two things I think are somewhat unfortunate here:
1) Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box,
without telling you about it. GNOME's is particularly bad, as it will
happily download available updates in the background, which can be
gigabytes worth of data. DNF only updates its metadata caches (on a
systemd timer), but even that could be behaviour that users in certain
circumstances really really do not want.
2) There is no particularly obvious or visible mechanism for a 'typical
user' (or, if you prefer, many of the target 'personas' for our
flavors) to configure this behaviour...and you have to figure out two
completely *different* configuration mechanisms in order to shut off
I think this is kind of poor behaviour on our part and we should make
it better. Do I have a specific concrete proposal? No. But I do have
some vague ideas.
* We could have some kind of configuration interface appear on install
/ first boot. This would require integration with anaconda and/or
initial-setup and gnome-initial-setup.
* We could invert the defaults and have the apps ask the user if they
want to enable data-hungry background operations on first interaction:
the first time you use dnf (without -y) it could say 'hey, do you want
to turn on background cache refreshes?' Similarly, the first time you
run GNOME Software or click on an update notification, it could say
'hey, do you want to turn on background update downloads'?
* We could at least make both of them respect one single config setting
for 'do data hungry background operations' (this is kinda one small
part of the bigger issue that is 'dnf and PK-based stuff don't share
any configuration aside from repo definitions').
Anyone have thoughts on this? Any DNF or Software devs want to say I'm
totally wrong and an idiot? Anyone inspired to do something more
concrete than a mailing list post? :)
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
Why does Bugzilla allow filing private Fedora bugs?
I'm not sure who has the capability (it may be tied to specific
accounts). It is not all that helpful because accounts on the Cc: list
still receive notifications and can access the bug. Recipients of the
notifications may include public mailing lists. This is probably not
what people make bugs private expect.
The other problem is that I keep having to ask people filing private
bugs if it is okay with them to make them public, and then to open the
bugs again if they accidentally turn it private afterwards.
Surely it's best to remove this capability from Bugzilla?
(In case anyone wonders: We do not file Fedora bugs for embargoed
security issues at all, so a Bugzilla permissions change would have zero
impact on that front.)
I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
you might think now that I went nut and it is bureaucracy, but let me
If I understand it correctly, during several past years, our build
process was more streamlined and we are trying to do the Rawhide
composes in a similar fashion we are doing stable releases. But for some
reason, we are still not using Bodhi for Rawhide and I see no reasons
not to use it. Here are some benefits if we were using Bodhi:
* One of the nice things which Bodhi does is running several check, such
as depcheck, rpmlint (actually question if we are using rpmlint for
Fedora builds was what triggered this email), etc. On one hand, I'd love
to see these checks running in Koji, but there is no support for them
and I don't even see the support coming. So enabling Bodhi for Rawhide
would give us this opportunity.
It is actually quite interesting, that while most of the development
happens in Rawhide, there is less sanity checks then for the Rawhide, so
if you screw up something in Rawhide, it will get into stable version
and you might not notice until you submit some stable update.
* From time to time, there is necessary to build some framework, which
consist of several components which must be released together.
Currently, we either temporarily break Rawhide or we are asking for side
tag. But why not use koji for that? Users of stable releases are not
affected by incomplete builds, since the don't reach even the
update-testing without pushing via Bodhi.
* And probably last think, why the Rawhide should be really exception?
Why we should not use Bodhi if we are using it anywhere else?
Lets use Bodhi for Rawhide, where the submitted update would immediately
go into Rawhide, unless maintainer wishes some testing period.
Any comments on this topic?