Given the fun which looks to be happening over OOo due to Oracle, are
there any plans to drop OOo and move over to LibreOffice (which looks to
be at version 3.2.999 - pretty much the same as OOo currently is at).
The full release version is penned in for Christmas (or there abouts).
I have no problems helping package this behemoth!
Vertraue mir, ich weiss, was ich mache...
> I don't care if [[:space:]] is the POSIX correct behavior or not, all
> I know is every single build I've sent to build for F14 is failing.
AFAIK this is required by POSIX. The character class (e.g. [:space:] can be used only in bracketed expression, e.g. [[:space:]])
To clear the confusion, there is no change in the RE syntax in grep-2.7. The old grep silently interprets all these REs the way that probably nobody intended to, e.g.
The [:space:] match:
that is obviously not what is wanted in most cases. Probably all of such typos detected by grep-2.7 are bugs, that should be fixed, because it leads to incorrect/buggy behaviour of scripts (with any version of grep).
I noticed that this change was confused by https://bugzilla.redhat.com/show_bug.cgi?id=583011. The 583011 was fixed only in rawhide.
Also in case it is impossible to fix all these typos, I am ready to revert to 2.6. Feel free to comment on: https://bugzilla.redhat.com/show_bug.cgi?id=637940 But I think the revert is not good solution. Please note that the grep-2.7 was pushed some time ago as bug fix update and it passed critical path testing by proven testers with karma of 3. Probably nobody (including me) realized what could happened and how many packages are broken.
Arithmetic coding in Fedora libjpeg (bug #639531)
I want libjpeg packages in future Fedora distributions to support
reading arithmetic coded JPEG files.
Huffman coding and arithmetic are two different bit coding methods that
are available in the JPEG standard. Huffman is simpler to implement than
arithmetic coding and historically hasn't suffered from software
patents. Arithmetic coding (as used in JPEG) had been covered by
software patents, but these patents have now apparently expired. [Fedora
legal could check this.]
The vast majority of JPEG files so far used Huffman coding because of
the software patents issue. libjpeg version 7 (one of the forks of the
old IJG software) and newer enable support for arithmetic coding by
default. With older versions of libjpeg (such as the ones bundled by
Fedora up to release 13), support can be added in the form of a
patch. No application code modifications are required. (I'm not sure if
it's ABI compatible though, but on a re-reading of the libjpeg headers,
it might well be.)
Arithmetic coding is in every case a superior bit coding method than
Huffman, because arithmetic coding doesn't use an integral number of
bits to represent codes like Huffman does. So JPEG files created with
arithmetic coding are always smaller than those created with Huffman
Software such as jpegtran (as distributed with libjpeg 7 and above) can
losslessly convert Huffman coded images to arithmetic coded and vice
versa. The lossy behavior of JPEG does not happen at this (bit coding)
layer of the format.
The libjpeg package maintainer seems to be satisfied in closing the bug
rather than providing a good rationale for doing so. But I will be the
devil's advocate myself.
You see, .jpg files are assumed to be an ubiquitous file format. They
_just work_ everywhere. If you have a .jpg file, it is understood you
aren't going to have problems when using it. But arithmetic coded files
do not open everywhere. In fact, they rarely work in most applications,
devices, etc. today, because pretty much everyone is using an old
libjpeg with no support for it due to the historical software patents
As an example, in the context of GIMP creating such files, there were
some comments that people would start losing faith in JPEG if they see
incompatibilites, that such files are crippled JPEGs [sic], that people
who use devices such as digital photo frames will suffer, that I should
instead blog about free software and the evils of software patents, that
this option should never be available in a dialog to the end-user, etc.
* Fedora is not the only software that creates JPEG files. The nearest
first implementation of a .jpg file creator program is cjpeg which is
a part of libjpeg (the fork at ijg.org), and even that allows creating
arithmetic coded files now. It would be arrogance to think that just
because Fedora creates these files, the world of JPEG is going to
suffer. Or that if Fedora doesn't do it, nobody else would.
* The situation with arithmetic coding in the context of incompatibility
with existing embedded decoders is just like H.264 and profiles. The
iPhone for example does not play all kinds of H.264 files (it supports
only the baseline profile). But MPEG content creation software does
allow you to create files that use baseline as well as other
profiles. It doesn't say "Hey, you the user are pretty stupid, so I'm
not just turning this option off, but I'm not making it available to
you." It would be arrogance to not provide an option to the end-user,
just because I think the user may not know what he/she is doing.
* Due to the patents issue, we had to assume that Huffman was the only
bit coding method of this standard, whereas it isn't so. Arithmetic
coding has been in the standard all these umpteen years, and some
people used it. There was always the odd JPEG content that used
arithmetic coding and which still complied with the standards. These
are not broken JPEGs.
Also quoting from the bug:
> In any case, there are practical and political reasons not to encourage the
> spread of the arithmetic-coding variant of JPEG. It's not compatible with most
> implementations and it doesn't offer enough benefit to be worth creating an
> enormous compatibility problem. So even if the code existed I would resist
> turning it on. I think the author of libjpeg 8 has made a very serious error
> by adding support for it.
I have replied on the bug about it. Some of the text in my initial bug
description is incorrect, and I have corrected it in this email.
It is not upto Fedora to make political decisions when there is no good
reason for it. This goes against the values of free software.
"You shall not create images with arithmetic coding" is like saying "You
shall not create images of the flying sphagetti monster." It's not up to
Fedora to make this choice for me.
As libjpeg is a shared library on the system, if it can support
arithmetic coding, it should. Fedora doesn't have to decide about this
file compatibility issue. It is up to applications and users to make
The default is Huffman coding with libjpeg. Applications explicitly need
to turn on arithmetic coding by setting cinfo.arith_code. But this
doesn't really concern Fedora. Neither do Fedora have to, nor should
they make this decision for everyone.
The only relevant change that Fedora will influence is the implicit
support for _decoding_ JPEG files which use arithmetic coding. By adding
support, applications compiled against a libjpeg supporting arithmetic
coding can decode such images which are part of the standard. By not
doing it, some images compliant with the standard cannot be opened by
OTOH, if Fedora does not include support for arithmetic coding, and an
application wants it, it will bundle a local copy of libjpeg, and will
suffer from all of the static library issues. It will not affect the
creation of arithmetic coded images, which are bound to increase now
that the patents have expired.
If there is a standards compliant .jpg file, what currently remains
incompatible for a Fedora user is the libjpeg library package that
stops every application using it from decoding such an image.
Many people care about compatibility. I have had arguments with some
GIMP co-developers about GIMP's support for it. Because I am a Fedora
user, I had to create that bug for Fedora, and also present my case
here, because the bug was getting closed with every response. :) I
care about compatibility too, but I feel this is not a decision that
software has to make for end-users. But I am tired of arguing on this
topic, so please excuse me if I don't say more. I have written about
everything relevant in this email.
PS: Despite what the bug says, for libjpeg 6b (the current libjpeg in
Fedora 13), there is a patch by Guido Vollbeding that implements
arithmetic coding. It is by goes by the name "libjpeg6-arith.patch".
Start End Name
Fri 08-Oct Fri 08-Oct Final Blocker Meeting (f14blocker) #3
Mon 11-Oct Mon 11-Oct Submit Installer Builds for Final TC Compose
Mon 11-Oct Fri 15-Oct Daily Review & Notification of Open Final
Fri 15-Oct Fri 15-Oct Final Blocker Meeting (f14blocker) #4
Mon 18-Oct Mon 18-Oct Submit Installer Builds for Final RC Compose
Mon 18-Oct Mon 18-Oct Final Blocker Meeting (f14blocker)--Blocks RC
Mon 18-Oct Mon 18-Oct Final Change Deadline
How has schedule worked out for your team during Fedora 14?
The schedule is only as good as the information I receive so if you've
noticed things that would work better for Fedora 15, please add them to
There's a long standing bug which prevents FC14 to boot on most EFI systems
Would a knowledgeable kernel developer please review the patch for
drivers/video/efifb.c and commit it?
Thanks in advance for your help
Considering the fact that the maintainer is not responsible for a long
time, I'd like to ask if anybody knows how to contact David Zeuthen?!
Festival seems to be unmaintained for more than a year. But it has many
commiters which might decide to become its maintainer.
On ۱۰/۱۰/۰۲ 08:37, Hedayat Vatankhah wrote:
> On ۱۰/۱۰/۰۲ 03:55, Chen Lei wrote:
>> 2010/10/2 Hedayat Vatankhah<hedayat(a)grad.com>:
>>> There has been no response from the maintainer since 2009-06-24 as is
>>> clear in . Also, the package has not been updated since then. I
>>> wonder what should I do now (?)
>>>  https://bugzilla.redhat.com/show_bug.cgi?id=507966
>> Chen Lei
> Well, I've checked pkgdb, and apparently there are many people with
> commit access on festival. Also, it seems that David maintains many
> packages, so he is probably not completely unresponsive!
> I wonder what should be done in this case?!
I've finally managed to get mono-2.8 to build and it wasn't easy. A
tonne of things have changed, the biggest is that .NET 1.1 has gone.
Completely gone. 'tis no more!
If you have anything reliant on .NET 1.1, you will need to rebuild. I've
uploaded the source rpms to
They build fine on my x86 box, YRMV, but let me know of any build
I've not put it into rawhide yet as I'd rather people build first then
we can do a mass update rather than have a pile of broken deps.
I've not built any of the other parts of mono yet, they'll come
- Bump to preview 8 of 2.8 release
- Remove .NET 1.1 code
- Update ppc threading patch
- Update patch1 and 5 and rename
- Combine patches 2 and 7 (why two libdir patches?)
- Remove jay from the install step
- Realise that spelling is quite imporgtint...
- Big changes to the spec file to bring it into line with Novell's fixes
- New mvc, mvc-devel and winfx subpackages
- Some parts of the mono-web subpackage moved to mvc
- Fix the macro which looked for 1.0 things
- Remove and obsoletes mono-jscript
- Remove and obsolete data-sybase and data-firebird
- Modify macros to make sense now the 1.0 stuff has gone
- Extend the 4.0 subpackage to include lots of new stuff
If you have anything reliant on mono-jscript, mono-data-sybase and
mono-data-firebird, they're gone.
Please try and build, let me know of any problems though.
Vertraue mir, ich weiss, was ich mache...