I'm rebasing libgcrypt in rawhide to libgcrypt-1.6.1. The new upstream
release contains many improvements over the old one especially in terms
of new crypto algorithm support and performance improvements.
Unfortunately the rebase bumps soname to libgcrypt.so.20 due to dropping
some long-ago deprecated API calls. This should not break builds of any
reasonably current software. I've included the temporary old shared
library so the buildroots are not broken.
I will try to rebuild the dependencies eventually.
No matter how far down the wrong road you've gone, turn back.
(You'll never know whether the road is wrong though.)
devel-announce mailing list
Rpm 4.12 alpha just got released:
The plan is to update rawhide to this shiny new version first thing on
Monday morning and babysit as needed (ie the usual drill), but if you're
feeling bored over the weekend or its as rainy wherever you live as it
is in here now, and you're feeling a little bit brave, give it a spin in
The copr packages are for rawhide only and should be very close to what
goes into rawhide on Monday. If you're dying to test but not willing to
rawhide all the way, they can be used on F20 too if you
1) install perl-generators from rawhide
2) remove rpm-python3 package before updating
As the announcement says, there are some rough edges still (as in,
there's a reason its alpha). I run it on my systems and it's not
expected to eat anybody (or their systems) alive, but do pay attention...
Bug reports and other feedback welcome.
- Panu -
As we are ramping up the development effort around the workstation we wanted to help increase transparency and enable more community participation in the Fedora Workstation
effort by providing a more detailed view of the various tasks underway as derived from the more high level PRD and Technical Specification documents. You can find the current
version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but we hope to expand on it in the coming days and weeks to be even more comprehensive and also include more explanations around the motivation for each task.
The list enumerates the various efforts that is being undertaken around the Fedora Workstation effort and also puts a name next to many of the items.
If you are interested in helping out with any of these efforts please get in touch by reaching out either to the Working group board members or to
the people listed next to the tasks in question. For those of you not familiar with the working group we have contact information and board membership information
available on this page:
If you are getting this email you probably already know about the mailing list, but the working group can also be reached on IRC on #fedora-workstation on freenode.
Looking forward to discussing our plans with both new and old contributors to the workstation product effort.
Feel free to ask questions about the various tasks as I realize that the list is quite low on detail atm., and not all items might be self explanatory and as mentioned we do hope to add more detailed information to each item in the next few days.
On odd weeks WG meeting will be at 15:00 UTC, 17:00 Central Europe,
11:00 (noon) Boston, 8:00 San Francisco, 0:00 Tokyo in #fedora-meeting
= Topics =
* free seats in Env WG
* Taskotron and rpmgrill
As fas as we know Hubert quit Fedora for a very long time (said in his
private email). So it's time to change a poit of contact for the only
package Hubert maintained - RabbitMQ server.
I propose myself (FAS name: peter) and John Eckersberg (FAS name:
jeckersb) as a primary maintainers. If anyone has any objections
and/or suggestions, please, let us know.
With best regards, Peter Lemenkov.
Apparently, people can still file bugs for dead packages:
And I (and many others) get CC:ed on those bugs files, with
no possibility to remove ourselves from the CC: in pkgdb.
Any idea where I should be filing a bug for this bug?
Fedora 21 Changes Freeze is currently scheduled to no earlier than
2014-07-08  and we're getting closer to this date. Btw this is
also Fedora 21 Branch from Rawhide date.
At this point, all accepted changes should be substantially complete,
and testable. Additionally, if a change is to be enabled by default,
it must be so enabled at Change Freeze.
Change tracking bug should be set to the MODIFIED state to indicate
it achieved completeness. 
As Fedora 21 scope is really huge, progress at Changes Freeze
will help us to think about where we are and what we can do for
this release. This applies not only to change owners but to all
other groups - especially from WGs and teams involved in Fedora
re-design. Let us know if you're blocked, if you need any help
etc. or just to say, hey, we're ready :).
devel-announce mailing list
From time to time, I see trivial patches posted in bugzilla which end
up sitting there because the maintainer is too busy / gets bombarded
with tons of bugzilla mails and misses that particular one / whatever
reason. As a packager, sometimes it seems very hard to get such trivial
patches applied. What you can do is
- You can keep pinging bugzilla
- You can apply for commit rights, which might be excessive for just
this one patch, and still requires the maintainer to answer.
- You can start the non-responsive maintainer procedure, even if you
know perfectly well that the maintainer is still active. Or you might
suspect that the maintainer is inactive, but you'd rather not have to
wait for an entire month, because this one bug is blocking your work.
- You can start asking on irc for a proven packager to jump in and hope
a proven packager is online and has time at that moment.
- You can post on -devel, though again, unless someone has time right
now it gets forgotten an people move on.
- Repeat the above n times until someone shouts at you and flags your
email as spam :)
So wondering, if there is a way we can improve the situation. One idea
which comes to mind would be something like "trivial patch policy"
- after i.e. one week of inactivity one can flag such a bug as a trivial
bug. You can only do so if you are a packager and post a patch (which
also updates the SPEC, so just a matter of apply patch, fedpkg commit &
- for anything else than packaging issues, the patch may only be a well
justified upstream commit backport
- a proven packagers gets notified about the issue, validates the patch
and if ok fires the update. The entire thing might work similar to how a
New Package / Package Change request works, by posting something like
this to the bug:
Trivial Patch Request
From my experience such situations do not occur too frequently, but
when they happen, they can be hard to deal with.