Working on a python project using PIL, and wanting to port it to
python3, I got bitten by the absence of a python3 compatible PIL. Doing
some research, there seems to be an actively developed PIL fork, called
Pillow, which can be found here . It describes itself as
Pillow is the "friendly" PIL fork. PIL is the Python Imaging Library.
started for and is currently maintained by the Plone community. But it
is used by
many other folks in the Python web community, and probably elsewhere too.
The fork author's goal is to foster packaging improvements via:
- Publicized development and solicitation of community support.
- Exploration of packaging problems within the fork, most noticably
via adding setuptools support but also via clean up & refactoring
of packaging code.
Now, the PIL project has been rather inactive lately (last release in
2009), and there seems to be some general agreement that Pillow is a
likely candidate to succeed PIL, and in particular to bring python3
support see the discussion at  and . Now, there already seems to
have been some discussion about adopting it in Fedora (at least, it was
mentioned in ), and I'd like to bring up the issue again.
I've packaged the latest Pillow release (1.7.8) here , based on the
python-imaging package, and the state is the following
- Compiles for both python2 and python3, both variants pass the self-tests
- Python 3 support is all upstream code, except for pysane, which I
needed to patch (and I'll propose the changes upstream once github is
- Python 2 looks like a drop-in replacement for PIL, except that you
need to write i.e. "from PIL import Image" instead of directly "import
Image" (the latter was allowed only by a PIL.pth file in the
site-packages dir, and looked like a hack anyway - with the changes for
python3 compatibility, the files in the PIL directory use relative
imports, and hence the "import Image" does not work anymore, one could
still patch away the relative imports in the python2 variant for 100%
- Note: because of what I think is a nasty python3-distutils bug
(shared-library extension incorrect, see ) I needed to patch a file
in the python3 distutils modules for the package to compile, see .
So, since Pillow seems to be the most likely candidate for
python3-imaging, the questions are:
- Do we want Pillow to succeed PIL in Fedora?
* According to , it is likely that Pillow will soon become an
"unfriendly fork" of PIL, so Pillow-PIL compatibility is likely to break
in the future
* But still being compatible at the moment, I'd say it would be
easier to make the transition now
- Python2 and 3, or only the python-3 variant?
- Plus some packaging questions for the maintainers (I could co-maintain
* Keep the package name?
* Need new review request?
According to Ruby 2.0 release schedule:
- code freeze: 23 Dec.
- 2.0.0-rc1 release: 1W Jan. (expected)
- 2.0.0-rc2 release: 1W Feb. (expected)
- 2.0.0-p0 release: 24 Feb.
the official release date is quickly approaching. Therefore, I would
like to update you about current plans for Fedora
* I am trying to closely track recent development of Ruby 2.0 and the
.spec is available in ruby-2.0 branch of dist-git repo .
* I started to put together pieces of feature proposal for Ruby 2.0 in
* Every package which depends on Ruby will need to be rebuild. There are
- The Ruby 2.0 is ABI incompatible with Ruby 1.9.3 (although it
should be source level compatible).
- Due to better integration of JRuby into Fedora , we would like
to take this opportunity to restructure RubyGems folder
layout. This should allow us to support Rubinius in the future as well.
- I would like to get rid of ruby(abi) virtual provide, since it does
not express enough the level of compatibility
between JRuby and MRI. There is ongoing discussion about it on
packaging list .
So at the beginning of January, I'd like to ask rel-eng for dedicated
build target for rebuild of Ruby packages (we will probably use this
target for JRuby build as well). Please let me know if you want to
opt-out and rebuild your packages by yourself.
Howdy folks, saw that you hadn't patched system-config-firewall to
support conntrack so I thought I'd send our patch your way. Not a large
contribution by any means, but I hope it helps.
diff -rupN system-config-firewall-1.2.29.orig/src/fw_iptables.py
--- system-config-firewall-1.2.29.orig/src/fw_iptables.py 2012-12-24
+++ system-config-firewall-1.2.29/src/fw_iptables.py 2012-12-24
@@ -362,7 +362,7 @@ class iptablesClass:
# accept established and related connections as early as possible
# RELATED is extremely important as it matches ICMP error
- fd.write("-A INPUT -m state --state ESTABLISHED,RELATED -j
+ fd.write("-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED
self._icmp(conf, fd, "INPUT", reject_type)
@@ -377,7 +377,7 @@ class iptablesClass:
for fwd in conf.forward_port:
- line = "-A INPUT -i %s -m state --state NEW -m %s -p
%s" % \
+ line = "-A INPUT -i %s -m conntrack --ctstate NEW -m %s
-p %s" % \
(fwd["if"], fwd["proto"], fwd["proto"])
line += " --dport %s" % self._portStr(fwd["toport"])
@@ -394,7 +394,7 @@ class iptablesClass:
_dest = ""
_port = ""
if proto in [ "tcp", "udp" ]:
- _state = "-m state --state NEW "
+ _state = "-m conntrack --ctstate NEW "
_proto = "-m %s -p %s " % (proto, proto)
if self.type == "ipv4":
@@ -411,7 +411,7 @@ class iptablesClass:
# open ports
if conf.ports and len(conf.ports) > 0:
for (ports, proto) in conf.ports:
- fd.write("-A INPUT -m state --state NEW -m %s -p %s
--dport %s "
+ fd.write("-A INPUT -m conntrack --ctstate NEW -m %s -p
%s --dport %s "
"-j ACCEPT\n" % (proto, proto,
@@ -419,7 +419,7 @@ class iptablesClass:
(self.type == "ipv4" and conf.masq and len(conf.masq)
> 0) or \
(self.type == "ipv4" and remote_forward):
# accept established and related connections
- fd.write("-A FORWARD -m state --state ESTABLISHED,RELATED "
+ fd.write("-A FORWARD -m conntrack --ctstate
self._icmp(conf, fd, "FORWARD", reject_type)
@@ -442,7 +442,7 @@ class iptablesClass:
port = self._portStr(fwd["toport"])
port = self._portStr(fwd["port"])
- fd.write("-A FORWARD -i %s -m state --state NEW "
+ fd.write("-A FORWARD -i %s -m conntrack --ctstate NEW "
"-m %s -p %s -d %s --dport %s "
"-j ACCEPT\n" % (fwd["if"], fwd["proto"],
Disclaimer: This mail is written from the position of a Fedora
community member. Red Hat has nothing to do with this.
I don't want to start yet another rant saying that everything is broken
and we'd be better off if we aped Debian. Absolutely not. I don't want
to put blame on someone, I want to improve.
Fedora is all about passionate people doing what they want to
do in a community of like-minded folks. That's probably the most
awesome thing I've seen in my life - a bunch of folks not actually
charging money to each other, while providing everybody with fruits of
their efforts. It's probably trivial for you, because you've been doing
that for years. But for me (as I've been a part only for one year now),
it's something almost unimaginable. But reading this list showed me
that often the passion goes, at least in my eyes, too far. Instead of
constructive criticism, vitriolic scolding and personal insults are to
be found. This only makes effort in Fedora fragmented and inconsistent.
One of the results was a conversation I had with a few guys to
whom I recommended Fedora as a development environment. It showed me
that there's indeed something wrong. While they all said that Fedora's
features were brilliant, they unanimously rejected Fedora as a
primary system. The reason they gave me was, now quoting: It doesn't
While it's a simplistic statement with which I don't agree, it points
finger at the tradeoff Fedora had to make to become the fastest updated
Linux distro in the known universe - to give up much of stability. I
sort of like that decision, but I propose to step back and look at the
big picture to see if we aren't on the fast side a tad too much. Having
a completely new system out every half a year is great, but having a
system where various things crash for various reasons pretty much all
the time isn't. I don't have a definitive way to fix this, but I have
some ideas, and you people out there have better ones. Something like
having a solid, tested core that updates half as often as the developer
libraries springs into my mind, so I want to know what springs into
The threat for Fedora is that even in the FOSS, there is competition.
Distros are competing for users - users that give back, users that
report bugs, or users that are or become maintainers and developers.
When the overwhelming response to Fedora is "Hey, they've got some neat
features, but I need it to work, so that's why I'm using XYZ instead",
the user/dev base is going to wither and move elsewhere.
As I said, I don't have the knowledge, mental capacity, or mandate to
give the answer to where Fedora is going and where it should be going.
I am just worrying that if there is no change in how Fedora is done, it
will be harder and harder for the community to thrive, and I wouldn't
like that. So, through this e-mail addressed to all the Fedora
community, I am seeking support for a movement, both collective and
individual, that would improve communication, cooperation and generally
the life of Fedora on the most fundamental basis.
To conclude, I don't want this e-mail to be accusing, flaming, or
mentoring. It is meant to be concerned, inspiring and accepted with a
good, yet scrutinizing mind.
A Fedora contributor, Tomas Radej
Tomas Radej <tradej(a)redhat.com>
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.
Just a heads up to rawhide users... Terminal has been renamed upstream
to xfce4-terminal and I have just landed the renamed package in
rawhide. It should be in tomorrow's compose.
So, Xfce (or Terminal users) will need to adjust your sessions to use
'xfce4-terminal' instead of 'Terminal'.
Dear list, Dear Lennart,
a week ago I have submitted a pulseaudio bug alongside with the patch
. There was no response so far.
Knowing that Lennart is busy with systemd these days, I proceeded to
check the pkgdb status of pulseaudio. The only other maintainer with
commit access is lkundrak, who has been declared non-responsive a while
ago himself, plus 3 request pending.
To have such a critical subsystem barely maintained does not seem
sustainable. I have already stepped up to co-maintain pavucontrol and
paprefs, but PA proper is a whole other level. I have joined the waiting
list and am willing communicate the issues between Fedora and upstream,
but someone with an ability to fix bugs on their own would be welcome too.
Lennart, could you please look at the pending ACL requests? Thank you.
Merry Christmas everyone,
My yum update on f18 took about 20 minutes installing 3380 packages.
Cleanup : bash-4.2.39-1.fc18.x86_64 3377/3380
Cleanup : nss-softokn-freebl-3.14-5.fc18 3378/3380
Cleanup : glibc-2.16-24.fc18 3379/3380
Cleanup : tzdata-2012i-1.fc18.noarch 3380/3380
And then it just sat there and sat there......
Cpu(s): 1.7 us, 1.9 sy, 0.0 ni, 86.8 id, 9.2 wa, 0.2 hi, 0.2 si, 0.0 st
KiB Mem: 16412252 total, 16259348 used, 152904 free, 2064256 buffers
KiB Swap: 16777212 total, 1289788 used, 15487424 free, 1120880 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8268 root 20 0 5024m 4.8g 2688 R 22.5 30.5 7:51.49 texlua
2738 paul 20 0 2203m 359m 31m S 2.6 2.2 40:48.75 gnome-shell
79 root 20 0 0 0 0 S 1.0 0.0 1:47.27 kswapd0
$ ps auxw|grep texlua
root 8268 37.5 32.7 5515148 5369112 pts/2 D+ 18:56 8:30 texlua /usr/bin/mtxrun --generate
$ rpm -qf /usr/bin/mtxrun
What is this? The man page hints of pdf generations. Why is this
happening? Why is it taking 8+ hours? Why is it taking 5GB of RES RAM?
These are several bugs that should be addressed. Endusers will not wait
8+ hours, so right now whoever owns this can be sure it will just get
killed by impatient people. Some people won't have 5GB for this.