libvisio changed license from GPL 2+ / LGPL 2.1+ / MPL 1.1 to MPL 2.0 in
0.1.0 (built for Rawhide today).
AFAIK the users of libvisio in Fedora are calligra, inkscape,
libreoffice and writerperfect.
I have a bug 1083039 where basically an application logs everything
to syslog making a mess out of /var/log/messages. The logging facility
is configurable and the default is local0.
I'm toying with an idea of doing something like this in %post
sed -e "s/cron.none[ \t]*\/var\/log\/messages/cron.none;local0.none\t\/var\/log\/messages/" -i- /etc/rsyslog.conf
However, I have a feeling that such action is ill-advised.
For example, what does happen if the package is uninstalled and
some other package logs to local0? Or what if we ever move to
a different package as part of JournalD etc.
Does anyone have a better idea off the top of his/her head?
Thanks in advance,
Fedora is a big project, and it’s hard to follow it all. This series
highlights interesting happenings in five different areas every week.
It isn’t comprehensive news coverage — just quick summaries with links
to each. Here are the five things for May 27th, 2014:
Flock is Fedora’s annual contributor conference, held this year in
Prague on August 6th through 9th. The schedule is now up on sched.org.
The organizers reserve the right to make tweaks as needed, but this
should mostly be the final schedule.
Last year’s conference was amazing, and I think this year will be even
better. There are a lot of great talks, hackfests, and workshops
planned over a busy four days, with a vibrant “hallway track” and fun
social events (yet to be detailed). In general, we will get a lot of
real planning and solid work done, all built on top of Fedora’s
“Friendship” foundation. If you’re a Fedora contributor and not sure if
you should come, *you should*. Register now at the Flock site.
Thanks to everyone who proposed talks and to everyone who voted on
those proposals. And thanks to Flock organizers Josh Boyer, Tom
Callaway, and Ruth Suehle, who used those votes as the primary source
for the difficult jigsaw puzzle that is putting together the schedule.
Thanks also to Miro Hrončok and Jiri Eischmann for working out venue
Fedora 21 Schedule Reminder
Speaking of schedules… as we get to the end of May, it seems like a
good time to give a reminder of the Fedora 21 schedule. The summer is
going to go fast! So, a refresher:
- **June 6:** *Mass Rebuild.* This means that Release Engineering
will cause every package in the distribution to be rebuilt from
source, with the newest compilers and toolchains. Package
maintainers need to be prepared to fix any problems that are
exposed. (Packages that don’t build and aren’t updated will
eventually be dropped from the distribution.)
- **July 8:** *Change Freeze* and *Branch from Rawhide*. The first of
these means that any official change proposals for F21 need to be
a) substantially complete and in a testable state and b) enabled by
default (if that’s the plan for that change). We have a rather
large change set planned for this release, and many of those
changes involve big new Fedora.next ideas. The second means that
Fedora 21 will become a distinct repository from Rawhide, our
rolling development tree. That means that any changes packagers
make that are intended for F21 will go through the normal package
updates process — and it means that testers can decide if they want
to divert their systems to the upcoming release, or to keep on
Rawhide to follow the bleeding edge of what will eventually become
the release *after* next.
- **July 22:** *Alpha Change Deadline* and *Software String Freeze*.
The change deadline basically means that except for accepted fixes,
everything that’s going to land in the alpha release should be
there already. And the string freeze means that packages for which
Fedora is the upstream should stop making user-visible changes so
that translators have time to work.
- **August 5:** *Alpha Release*. The Fedora 21 Dress Rehearsal — we’ll
get real picture of what the upcoming release will look like (and
- **August 26:** *Beta Change Deadline*, *Changes 100% Complete*, and
*Software Translation Deadline*. Similar to the deadlines for
Alpha, but more so. Proposed changes which are off-track at this
point may need to be scaled back or delayed until the next release.
- **September 9:** *Beta Release*. Everything will be shaping up, and
we’ll be more concerned with polish than development. If you have
an idea for a big change at this point, that’s awesome — the
Rawhide development tree continues to be open for business so
progress can continue.
- **September 30:** *Final Change Deadline*. All the last changes
should be in.
- **October 14:** ***Fedora 21 Final Release!*** Fedora Cloud, Fedora
Server, Fedora Workstation, and all the spins and the rest will go
into the world.
All of these dates are officially expressed as “no earlier than”. As
always the schedule may… flex… a little bit, but generally we aim to
actually hit these targets. That gives us just 20 weeks from now — mark
Fedora.next Preliminary Branding
The Fedora Design Team is working on a plan for presentation of the
three different Fedora products we’ll be releasing this fall as part of
the Fedora.next initiative. Each of these will need their own logo, but
they also need a coherent look that ties them together as part of the
overall Fedora Project. Fedora Contributor Máirín Duffy kicks off the
process with some starting-point designs, which you can see at read
about at her blog.
What do you think? What ideas do you have?
Fedora 21 Test Planning
Those three products will also need testing; that’s one of the reasons
the schedule is longer than the typical six months. Fedora Quality
Assurance “Community Monkey” Adam Williamson wrote a draft test plan
for Fedora 21 in general, outlining different areas of work and
responsibilities. If you’re interested in helping (or just curious),
read Adam’s message about this draft and join the conversation on the
Fedora Test Mailing List.
Help Wanted (Soon) for Software Collection Package Reviews
Software Collections is a way to package software into RPMs which sit
in `/opt`, outside of the main part of the distribution. The main use
case of Software Collections (SCLs, for short) is to have a stack of
software which moves at a different speed from the distro proper — in
RHEL or CentOS, that usually means faster, but in Fedora, it could be a
way to provide consistent runtime environments across multiple
Specifically, we’re planning to have a Ruby 1.9.3 with Rails 3.2.8 SCL
in Fedora 21 as a first experiment, led by Fedora contributor Marcela
Mašláňová. Since F21 will have Ruby 2.1.x with Rails 4.1, this will let
users with code that isn’t ready for the new version update to newer
Fedora — but port their own code on their own schedule
The Fedora Packaging Committee has been working on draft guidelines,
and the remaining big hurdle is that the 60-some new packages will need
to go through the standard review process. The plan is to make this as
painless as possible, by organizing an online activity day to crank
through them. If you’ve done some package reviews (and ideally if you
know Ruby), and are interested in helping, watch the Environments and
Stacks mailing list for more soon.
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
the f21-python side tag, containing Python 3.4, has been merged into Rawhide.
We managed to rebuild 216 packages out of 452 that BR: python3-devel and 7 that BR: python3 - these were the packages (or dependencies of packages) that failed to build in my local mockchain build for some reason (either problem in the upstream source code, problem in specfile or dependency cycle). There are still few packages that failed to rebuild and weren't fixed yet:
- dnf and hawkey (I was told by Ales that he'll handle this once Python 3.4 is merged to rawhide; we also had rhbz#1098109 blocking us, but that's been fixed today)
- iPython and few depending packages (this needed a rebase to work properly with Python 3.4 - the new version hit Rawhide just recently, a simple rebuild should do)
I'll keep working on these packages with their maintainers to get them building and working fine.
All the other packages built fine for me locally, so the mass rebuild should get the job done for these.
Big thanks to all who helped with the rebuild.