[HEADS UP] Sphinx updated to 3.2
by Miro Hrončok
I've updated python-sphinx to 3.2.1 in rawhide and f33.
It only breaks one package (python-graphql-core) -- all other packages either
build fine with new Sphinx or FTBFS for unrelated reasons.
I'll have a look at python-graphql-core to see how it can be fixed.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 8 months
fedora-review fails due to no annobin in mock
by Artur Iwicki
Recently (happened today and happened a month ago), whenever I try to run fedora-review for a Review Request that includes a C/C++ program, the mock build fails immediately due to gcc/g++ not being able to find the annobin plugin.
> cc1plus: fatal error: inaccessible plugin file plugin/annobin.so expanded from short plugin name annobin: No such file or directory
Downloading the SRPM of the package I want to review, adding "BuildRequires: annobin" and running fedora-review on this modified SRPM works, though obviously it's a rather tedious workaround.
Does anyone else have this problem, or should I be worried about something being broken in my setup?
3 years, 8 months
Re: CPE Feedback Survey
by Ant Carroll
Hey all,
First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.
Thanks again,
Ant
On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol(a)redhat.com> wrote:
> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedora...>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol(a)redhat.com
> M: +353876213163 IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs> redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>
--
Ant Carroll
Associate Manager, Software Engineering
Red Hat Waterford <http://www.redhat.com>
Communications House
Cork Road, Waterford City
ancarrol(a)redhat.com
M: +353876213163 IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
3 years, 9 months
ldc soname bump in f33 and rawhide
by Kalev Lember
Hi all,
I am about to build new ldc 1.23.0 that comes with a soname bump for
both f33 and rawhide. I'll handle rebuilds of dependencies, with the
exception of the following two packages that were already FTBFS prior to
the ldc bump:
appstream-generator
glibd
(Maintainers for the two failing packages are BCC'd.)
--
Kalev
3 years, 9 months
hundred percent cpu load
by Wells, Roger K.
Current kernel: 5.7.12-200.fc32.x86_64
gnome desktop
PC: Thinkpad X280, intel core i7, 8th gen
After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal
sometimes there are only three of these at 100% but usually four, never
more.
I have not been able to come up with a sequence of steps to cause it.
At this point the only way to shut down is to use the power switch, it
will run forever in a normal shutdown as the timeout limits increase.
The next start up will always be strange:
Things will proceed apparently normally up to the login opportunity:
If I check the upper right corner I will see that the wired and
wireless networks are both up.
After I login the wireless will not be up and nothing I try will
bring it up.
There will also be notifications about "problems", up to 35 occurrences
of "system problem" and "kerneloops" none of which is "reportable"
This login process will have to be repeated probably twice before a
normal environment with wireless network operating.
This also occurred prior to the last one or two updates.
At this point I think I will do a clean install.
I have assumed that if this happened to others it would have appeared
here already, but just in case....
I have been using Fedora forever as a software system development platform
screen shot of "top" available if anyone wants it.
--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells(a)leidos.com
3 years, 9 months
Re: Non-responsive maintainer: mstuchli
by Pierre-Yves Chibon
On Fri, Aug 21, 2020 at 10:40:07AM +0100, Matěj Stuchlík wrote:
> Hello Pierre,
> thanks for the nudge — I’m no longer interested in maintaining those
> packages.
Many thanks for the prompt response. I'll orphan python-docutils and remove you
from the other ones.
Thanks again!
Pierre
> Cheers,
> Matt
> On Fri 21 Aug 2020 at 10:38, Pierre-Yves Chibon <[1]pingou(a)pingoured.fr>
> wrote:
>
> Good Morning Everyone,
>
> While working on cleaning up the errors encountered when syncing default
>
> assignee and CC list from dist-git to bugzilla, I ran into the user
> mstuchli.
>
> The email address set in FAS does not seem to correspond to a valid
> bugzilla
>
> account.
>
> fedora_active_user indicates that the last login in FAS is from
> 2017-09-01
>
> zodbot indicates that this account is "Inactive"
>
> Yet, mstuchli is still listed as a maintainer for a number of packages:
>
> mstuchli is maintainer of rpms/binwalk
>
> mstuchli is maintainer of rpms/pipsi
>
> mstuchli is maintainer of rpms/python-docker-py
>
> mstuchli is main admin of rpms/python-docutils
>
> mstuchli is maintainer of rpms/python-flask-admin
>
> mstuchli is maintainer of rpms/python-peewee
>
> mstuchli is maintainer of rpms/python-pytest-capturelog
>
> mstuchli is maintainer of rpms/python-whoosh
>
> mstuchli is maintainer of rpms/python-wtf-peewee
>
> I am hereby starting the non-responsive maintainer procedure for
> mstuchli (Cc'ed
>
> to this email).
>
> @Matej if you are no longer interested in these packages let us know and
> we will
>
> orphan them.
>
> Thanks,
>
> Pierre
>
> Links:
> 1. mailto:pingou@pingoured.fr/
3 years, 9 months
