-----BEGIN PGP SIGNED MESSAGE-----
there are a lot of pidgin bugs (mainly crashes reported via abrt) that have been piling up in the bugzilla for quite some time now and nobody is taking a look at them. Although I am a co-maintainer, I can't devote much time to pidgin. I spoke to Milan Crha, the other co-maintainer, and neither can he.
I tried to contact the owner of the package (CC'd) in November, but got no response. I think that pidgin deserves more care than it currently gets.
Having said that, I'm about to start non-reponsive maintainer process, however I do not want to be the owner of the package. Is anybody willing grab pidgin?
Software Engineer, Red Hat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
If I understand the dep-chain correctly:
libreoffice-writer -> libreoffice-core -> jre ->
java-1.7.0-openjdk-headless -> apache-commons-logging -> log4j
This means I get an ugly icon called "Chainsaw" in the GNOME Software
center that when I try to remove also removes all the LibreOffice
If I actually launch the program I get a java-themed GUI full of low
level filter weirdness. Could we either clean up the depchain or split
off the actual log4j-chainsaw application off as a new subpackage?
The alternative is that I blacklist the log4j-chainsaw application in
the fedora-appstream metadata generation, which is a shame if someone
is actually wanting to search for a log viewer for java.
I've sent two builds of linux-firmware to koji this morning and both
fail with a strange error in root.log/mock_output.log:
ERROR: Command failed. See logs for output.
# ['fedpkg', 'sources']
error: line 41: Double separator '-' in: iwl100-firmware-184.108.40.206-4:
Obsoletes: iwl100-firmware < iwl100-firmware-220.127.116.11-4
error: query of specfile
/tmp/scmroot/linux-firmware/linux-firmware.spec failed, can't parse
The line in question hasn't changed since June of 2012 and it builds
fine on F20 locally.
To make things even more strange, I didn't get a build failure email
for either build.
An F20 build of literally the same Fedora git commit (F20/master
branches are in sync) builds fine:
>From the release note request:
gpodder is being upgraded from 2.20.3 to 3.5.2.
There is a configuration and date storage change between these versions.
After upgrading the RPM, any user on the system who uses gpodder, prior
to opening it, should run /usr/bin/gpodder-migrate2tres, which will
migrate the user's data and configuration to the new format, including
all subscribed feeds and downloaded podcasts.
in your fear, seek only peace
in your fear, seek only love
I'm looking for something and not quite sure what it's called.
In thinking about what the music SIG can do to add value I've hit on
wondering whether it's possible to write desktop-based guided
tutorials without having to interfere in the application in question
itself (otherwise you have to persuade every upstream to build it
separately in their codebase, even if it's in their interest to do so
that's a massive duplication of effort). You may have used this kind
of thing - it tells you 'click this next' and waits until you do.
As you might expect, googling for anything along these lines without
having a very precise set of keywords only returns pages of tutorials.
Any suggestions what to look for or, even better, tools in Fedora that
can already do this appreciated.
I have updated Python in Rawhide to version 2.7.6. The build is already
tagged as f21. As far as I checked, the API/ABI should remain the same.
Most patches applied neatly, only a few needed a rebase, and two were
1:1 incorporated upstream.
If something Python-related starts acting up, try looking at this
first, and if this version is indeed the cause, don't hesitate to untag
the build and/or let me know, I will fix it.
Tomas Radej <tradej(a)redhat.com>
The Board was recently notified of a serious violation of our Code of
Conduct made on the development list last week. Physical threats of
violence are an egregious offense and may result in further censure or
disciplinary action. While we look into the matter further, we would
like to remind everyone that threats of any nature are not appropriate
and will not be tolerated in our community. Fedora is a welcoming
project and while debates may be heated, they should never be hostile.