Now that FESCo accepted http://fedoraproject.org/wiki/Features/RPM4.11
for F19... (in what might well be a record time - less than a minute in
the meeting from proposal to acceptance :)
Rpm 4.11 alpha (or actually post-alpha snapshot to pull in a few
accumulated fixes + enhancements) will be hitting rawhide shortly.
There's no soname bump involved this time, so no rebuilds required.
There's one thing that does affect nearly every package: new warnings
about bogus spec changelog dates. The most common cause is the day name
not matching the given date, such as:
warning: bogus date in %changelog: Tue Jun 03 2009 Panu Matilainen
<pmatilai(a)redhat.com> - 4.7.0-5
Jun 03 2009 was Wednesday, not Tuesday, hence the warning. As rpm hasn't
hasn't previously validated changelog dates make sense as a whole,
nearly every spec has one or more of these mistakes. It's just a warning
though and doesn't cause build failures.
Other than that, chances are you wont notice much anything at all.
Assuming all goes well that is. So its the usual drill: keep your eyes
open on rawhide builds and report any new oddities found ASAP. I'm not
expecting any major issues with this but you never really know.
For further details see the draft release notes at
- Panu -
what is the expected way of handling X11 keyboard layouts in Fedora 18?
I don't use xorg.conf, the configuration was autodetected from
/etc/sysconfig/keyboard (probably) till F17 and it worked just fine. After
upgrading to F18 using yum method, my keyboard layout stopped working.
Should the X11 server (or login managers) autodetect the layout from new
config files? Or is 'localectl set-x11-keymap' the only supported way now?
If 'localectl' is the only supported way, we should add this information to
"Upgrading Fedora using yum" instructions on the wiki. The same with old
kernel options. (I do not know how is this handled in the other upgrade
If the old configuration files are supposed to work, what is the responsible
component I should file bug on?
The old Fedora, heavily patched OpenBSD nc package was just
obsoleted by the nmap ncat implementation, available as the
nmap-ncat subpackage. Those are mostly compatible and this
change shouldn't cause much headache but please check your
netcat dependant scripts or apps.
Related bug: #226187
Thanks to Michal Hlavinka for this.
I am involved in a student group on FIT of Czech Technical University in
Prague - in that group, we focus on 3D printing (RepRap).
3D printing needs a set of software on a control PC, such as some kind
of 3D modeller (we're currently using OpenSCAD), a slicer (to convert a
3D model to set of instructions for the printer, we're currently using
skeinforge and/or Slic3r) and printer interface software (currently
Installing this basic set of tools on a Linux machine is painful,
they aren't usually available in repositories, compiling them includes
compiling a bunch of dependencies and we usually end up using binary
executables from a tar or git cloning plenty of python scripts. Desktop
files and menu entries -> you don't get what you don't create
I am currently working on adding this software to Fedora:
But that is not where I want to stop. I'd like to create a Fedora RepRap
spin and make Fedora the best choice for 3D print guys.
At this point, I would like to gather people interested in 3D printing
and eventually create a 3D printing SIG.
Would anyone be interested and help me?
I would like to be the maintainer for the Enlightenment e17 for
Fedora. I am sending this e-mail to seek guidance and also a sponsor.
Getting e17 on Fedora i will need to build and install the following
eina - Core data structure library.
eet - Data
encode/decode and storage library.
evas - Canvas and scenegraph
ecore - Core mainloop, display abstraction and
embryo - Small Pawn based virtual machine and
edje - Abstract GUI layout and animation object library.
efreet - Standards handling for freedesktop.org standards.
Dbus wrapping and glue layer library.
eeze - Device abstraction
elementary - Elementary, the widget set...
Emotion, video and audio codec API...
ethumb - EThumb, thumbnail
eio - Eio, async I/O library...
Enlightenment 17 - The Window Manager and Desktop Shell.
build Terminology a new terminal emulator based on the efl libraries. I
currently build these on a local vm and have a repository setup on my
website. I tried to use Koji however seeing that the required packages
needed to build e17 are not available i cannot build using Koji, or i
don't know how to do the builds. I would need to work my list down in
the order i have because eet depends on eina. So eina would need to be
build first then it's dev packages installed. Then ecore depends on the
packages listed above it.
On my local machine i wrote a script that
would build a package, install rpm and dev rpm then move on to the next
package. I am not sure how i would do this with koji.
I look forward to
feedback on this.
I am to start packaging MariaDB for Fedora.
Is there anyone who wants to co-maintain?
This is just me wanting to post it for a package review.
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
Hello devel list,
I want know... Why Fedora doesn't included TapButton support of touchpad by
I saw AskFedora and FedoraForum.org, and it happened to me too after
install or show live CD to people, a lot users request, or asking about How
to setup TapButton.
It's ok, you can enable it from GNOME control panel, or touchpad tool, or
KDE touchpad configuration, but who have installed only LXDE, XFCE... or
another Window Manager...? How do? Search solution on Internet?
Linux user #547784
I've just created
https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which
contains plan how to successfully move from current jpeg6 API/ABI to more recent
jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have
provenpackager privileges, I will cook some script which will rebuild all
pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task
Adam Tkac, Red Hat, Inc.
I want to push Ogre 1.8.1 into rawhide next week. This will most likely break some packages but we have a lots and lots of time to fix it all up in rawhide. The changes in Ogre API aren't extensive enough for this to be a real risk and we can always revert. The most common break is Ogre::Singleton<..>::ms_Singleton being renamed to Ogre::Singleton<..>::msSingleton.
As I am not a provenpackager I will need some cooperation from maintainers of pkgs depending on Ogre.