It wasn't possible for me to build a MNG Mozilla from latest CVS with your patch.
The one problem on patching I can resolve but in config/autoconfig.mk.in the @*MNG*@ won't resolved while creating the *.mk file.
Ok, I can do this by hand (copy the one from png and rename to libmng) and mozilla builds ... but then no mng is included in the build.
Did you try using the tar distribution for 1.6 from
I'd tried the mngzilla-1.6-update-20040120.tar.bz2 file.
The problem is, that mozilla/configure isn't build from configure.in ... how I can do this?
Use "autoconf" to make "configure" from "configure.in". But the distribution mngzilla-1.6-update-20040120.tar.* contains a copy of "configure" as produced by autoconf from "configure.in" after running the patch.
It is in the mozilla-mng-files subdirectory.
Yes, thanks ... the autoconf helped ... it was yesterday to late for me ... now it builds and works. German packages will be available soon.
Now it's available the german (de-AT) mozilla-i686-linux-gnu-mng-full-installer-040129.tar.gz it's compiled inside the latest unstable debian (so needs some newer libs as the original mozilla).
Can I upload to sf? Maybe I also produce en-US builds.
ftp to the "incoming" directory at upload.sf.net,
then send me email or post here.
Ok, de-AT and en-US are both in the incoming directory of upload.sf.net
CVS Trunk-Checkout was from 29.01.2004
Compiled under daily updated Debian-unstable with gcc-3.3.3pre3 so it needs newer libs as the original mozilla builds, but the installer is patched so it will tell you what lib is needed instead of stop working :-)
Please do not run the mozilla installer as pseudo root (su/sudo) cause of bug in mozilla installer.
Please save your data first, I take no guarantee for loosing profile or other data.
Thanks; I installed them in the "Linux-binaries" download area.
The de-AT is 1.2 Megabytes larger than the en-US.
Is the language the only difference? ../glennrp
No, that's ok at the moment, cause it have the regus and deflenus inside but this shouldn't needed any more in the future. Also the spellchecker have the english libraries inside.
The differenzes between en-US and de-AT is:
+ langdeat.xpi (This is a soft patched(caused by an unknown mozilla bug) de-AT.xpi from kairo)
and some changes to the installer.ini, config.ini
The langdeat.xpi have regde, defldeat and german spellchecker inside.
New Builds are uploaded to upload.sf.net/incoming
Thx for adding the files,
but please can you add everytime a new release to "linux-binaries" instead of editing the release? So evrone who comes to the start page see's that there are new releases in "linux-binaries", else it will stay on the date of the first files.
As release Name you may choose 1.7a.YY.MM.DD
New packages (en-US and de-AT) and my latest mng-patch (as also can found on the mozilla bug) are now uploaded to sf and can be added to the release manager.
I've settup a new page for my MNG builds and patches
I will update it, if I have done something new.
I've spoke today a bit with tor (it isn't possible to talk with Pavlov) on #mozilla ... I hope I can satisfy his words.
At next I'll try to change the patch to using libmng 1.0.6 instead of 1.0.5 and will look how much it saves on space. Then eventually I'll try make some firefox+mng packages.
Can you add me as administrator of this project, so I can manage my packages by myself? Is it ok for you to take the work to bring MNG back to trunk?
Is in the old MNG patch (for mozilla 1.6) already a libmng1.0.7 version?
README tolds about 1.0.5 but libmng.h speaks about 1.0.7
The old patch for 1.6 doesn't supply libimg/mng or libpr0n/decoders/mng directories. The user must get those from libmng CVS, libmng tar distribition,
or mngzilla, etc. It works fine with 1.0.7 from the current libmng CVS. It would be useful to recreate the 1.6 patch but with built-in mng directories, to simplify matters for the user doing the patching.
The patch on the mng readd bug is with built-in mng directory
The patch from bug #18574 doesn't work for me. The files that are supposed to go into mozilla/modules/libimg/mng and mozilla/modules/libpr0n/decoders/mng are placed in the directory where I ran "patch". This happened on a GNU/Linux system and on a FreeBSD system. I was running "patch" from the directory containing "mozilla"
after downloading mozilla from CVS:
cvs co mozilla/client.mk
gmake -f client.mk checkout
patch < mng.diff
As I've wrote on http://opiswelt.de/mozilla/mng.html
use patch -p0 (-i mng.diff | < mng.diff)
without -p0 it will fail, cause we do not have the same directory structure on our hard disc :-)
Thanks, it works better with -p0. There are just two minor problems. The patch tries to update the non-existing file _img_list (so I just said to skip it), and it creates a lot of empty *.orig but harmless files in both mng directories.
Hmm, will be more accurate with my next patch ... hopefully.
modules/libpr0n/build/Makefile.in.orig should be the only one (else they are created from patch as they are already exists).
And the _img_list was build on runtime ... it seems it wasn't deletet on a distclean ... I hope it is in my memory for next time.
The next build will be done with -DMNG_BUILD_MOZ_MNG to save some resources :-)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.