Good day all,
Please join us today (Wednesday, July 31th) at 4PM EDT (8PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Kernel Status Update
3) Aarch64 - Status Update, problem packages
- Koji Update
4) Open Floor
If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.
On Tue, 2013-07-30 at 21:05 +0200, poma wrote:
> OK, Adam can you please clarify this lib*indicator* thingies on
> Fedora, so we can safely do:
> yum remove lib\*indicator\*
The only reason I ever packaged it was as part of an abortive attempt to
build Unity. I never built anything against it. I don't know why
anything else might depend on it, but so far as I'm concerned it's
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
question as in the subject. I'd like to check what is causing this
before submitting to bugzilla. I'm on F19, and I checked this on last 3
CPU usage for watchdog/1 oscillates between 30% and even > 100%, only
falling below 10% for 1-2 second every 10 seconds.
Furthermore, kworker/n:m is next one to follow, using 10-40% CPU.
I noticed this couple of days ago. I tried to find something useful on
net, but without any luck.
Any hints where and how to start?
Seems that this bug , together with yesterday's libvoikko issue has
opened a can of worms. Since the discussion seems to be rather general,
it might make sense to continue here on the list.
Trying to summarize some aspects, the first is how we make the decision
what plugin(s) to run:
- If we base decisions on the sources, we should use buildsrc IMHO. We
should not care about things removed in %prep.
- Shouldn't the basic strategy be to check in what's in the rpms?
- How much should we handle pitfalls such as java packages putting
.class files into a .zip container?
- Could we assume that the GL are followed? Then we could just look
into %javadir and %jnidir to check if this is a java package...
Next aspect is user feedback on what plugins are run:
- Stan's approach is a short note why a certain plugin is activated (see
- Another way might be to focus on what plugins are run or not rather
then why.. Something like
Active plugins: generic, java
Disabled plugins: ruby, C/C++, R, perl, python, php
- In any case, we need better logs describing why plugins are activated
Finally, if we provide feedback like above it should be possible to
tweak the list of running plugins. Something like
--plugins/-P e. g., -P java:off,C/C++.
If a plugin is listed here the on/off value basically overrides the
automatic is_applicable() decision.
Just my 5 öre